La IA no refactorizará tu Web Component

11 min de lectura

Las ramas nunca dejan de crecer

La configuración no era exótica.

Ningún framework gigante. Ningún carnaval de dependencias. Solo web components, elegidos deliberadamente para mantener la superficie bajo control y evitar arrastrar a la mitad del ecosistema de JavaScript para un problema que no lo necesitaba.

Esa elección envejeció bien. El componente no.

Cuantas más funciones pedía, más hacían los modelos aquello en lo que estas herramientas son muy buenas: extender el patrón local que tienen enfrente. ¿Nuevo modo? Agrega otra rama. ¿Nueva opción? Agrega otro condicional. ¿Nuevo flujo de trabajo? Entrelaza otro estado a través del mismo componente y espera que nadie note el olor.

No estaban siendo estúpidos. Estaban siendo estadísticamente obedientes.

Esa es la parte que mucha gente aún se niega a entender. Claude Code, Codex y herramientas similares son fuertes para continuar el trabajo. Son mucho más débiles para decidir que la forma actual del trabajo está equivocada.

El éxito local no es diseño de sistemas

Un componente en crecimiento puede parecer productivo durante bastante tiempo.

Cada cambio funciona localmente. La demo sobrevive. Aparece el nuevo botón. El nuevo modo hace lo suyo. El diff parece plausible. El recuento de ramas aumenta educadamente en segundo plano.

Hasta que un día el componente ya no es un componente. Es una situación de rehenes.

Eso le estaba sucediendo a neo-chat-box. El componente se había convertido en el lugar donde demasiadas decisiones chocaban entre sí:

• Selección de modo
• Manejo de prompts
• Renderizado de opciones
• Interfaz de usuario específica de la función
• Ramificación del flujo de trabajo
• Comportamiento compartido del chat
• Comportamiento de casos especiales para tareas de imagen, video y correo electrónico

Ninguna de esas preocupaciones es absurda por sí misma. Empujarlas todas en el mismo cuerpo es la forma en que crías a un monstruo muy moderno.

Los modelos no protestaron. ¿Por qué lo harían? El repositorio les mostraba un componente que ya manejaba múltiples modos, por lo que siguieron reforzando esa forma. Si pides controles de imagen en un cuadro de chat multimodelo, la herramienta no se pregunta de forma natural si esos controles pertenecen a un componente hijo especializado. Normalmente se pregunta qué tan rápido puede agregar el siguiente condicional.

Eso es continuación. No diseño.

La refactorización comenzó con preguntas

La salida no fue otra gran especificación. Fue una secuencia de preguntas dirigidas.

¿Qué se comparte genuinamente en todos los modos?

¿Qué cambia solo porque el usuario está creando una imagen en lugar de enviar un mensaje de texto plano?

¿Qué piezas representan un comportamiento estable del chat y qué piezas son en realidad interfaces de configuración específicas del modo que fingen ser un comportamiento del chat?

¿Dónde se ramifica el componente porque el concepto de negocio difiere y no porque difiera el detalle de renderizado?

¿Qué decisiones deberían ser visibles en la interfaz de usuario como composición explícita en lugar de ocultarse en condicionales?

Esa investigación condujo a la respuesta obvia que los modelos no habían ofrecido por sí solos. La estructura genérica del chat debía seguir siendo genérica. El comportamiento específico del modo debía trasladarse a componentes específicos. El usuario debía seleccionar opciones específicas del modo a través de elementos de interfaz de usuario dedicados en lugar de forzar a un solo componente hinchado a hacerse pasar por cuatro productos de mala manera.

Así que la dirección de la refactorización se convirtió en composición.

Un chat normal puede seguir siendo un chat normal.

Un flujo de trabajo de imágenes puede exponer opciones específicas de imágenes a través de un componente enfocado.

Un flujo de trabajo de video puede hacer lo mismo para el video.

Un flujo de trabajo de correo electrónico puede sacar a la superficie los controles y restricciones que pertenecen al trabajo de correo electrónico en lugar de fingir que son solo otra rama de un cuadro de conversación genérico.

Misma aplicación. Menos mentiras.

Por esto las demos engañan a la gente

Mucha gente ahora ve videos de demostración y concluye que el criterio de diseño humano tiene los días contados.

Las demostraciones son persuasivas porque las herramientas son reales. Pueden inspeccionar un repositorio, generar código rápidamente, entrelazar cambios a través de varios archivos y recuperarse de errores obvios. Esa parte ya no es hipotética.

El salto equivocado viene justo después de eso.

La gente ve la salida fluida y deduce que la máquina también reconocerá cuándo necesita cambiar la estructura misma. Asumen que ofrecerá voluntariamente la refactorización incómoda, rechazará la rama conveniente y simplificará el diseño antes de que la complejidad se convierta en un costo de mantenimiento duro.

Normalmente no lo hará.

La propia guía de Anthropic sobre la creación de agentes efectivos es mucho más sobria que la fantasía pública. Abogan por patrones simples y componibles sobre la complejidad innecesaria de los frameworks, advierten sobre los errores compuestos en agentes autónomos y dicen que los agentes de codificación funcionan especialmente bien donde las soluciones son verificables a través de pruebas automatizadas. Agregan la oración que más importa aquí: la revisión humana sigue siendo crucial para garantizar que las soluciones se alineen con los requisitos más amplios del sistema.

Esa no es una nota al pie menor. Ese es todo el argumento.

Los requisitos más amplios del sistema son exactamente donde reside el problema:

• Qué abstracción debería existir
• Qué responsabilidad debería moverse
• Qué rama es una señal de que el límite es incorrecto
• Qué conveniencia aparente empeorará los próximos diez cambios

Esos no son problemas de autocompletado.

Los modelos están optimizados para continuar

El artículo de OpenAI sobre por qué los modelos de lenguaje alucinan plantea el punto adyacente desde el lado del modelo. Estos sistemas siguen siendo recompensados con demasiada frecuencia por adivinar con confianza en lugar de por una moderación calibrada. La consecuencia práctica en la programación es familiar: si dejas la puerta abierta para una continuación plausible, el modelo a menudo elegirá la continuación sobre la vacilación.

Eso no siempre se manifiesta como una llamada a una API inventada. A veces aparece como una confianza inventada en una dirección de diseño.

¿El componente ya tiene cuatro modos? Bien, agreguemos una quinta rama.

¿La clase ya posee el renderizado de la interfaz de usuario, las transiciones de estado, las opciones de flujo de trabajo y el comportamiento específico del modo? Bien, mantengamos todo eso en un solo lugar y hagamos los nombres más largos.

La herramienta no es malvada. No es perezosa. Simplemente no está cargando con el costo de la estructura futura de la forma en que lo hace un desarrollador experimentado.

Si has pasado años limpiando sistemas a los que se les añadió «solo una rama más» durante dos trimestres seguidos, puedes sentir el daño desde el principio. La herramienta por lo general no puede. O más exactamente, no actuará según ese sentimiento a menos que fuerces la conversación allí.

Los datos no son amables con el optimismo ingenuo

La creencia de que la generación de código conduce naturalmente a sistemas más limpios siempre fue perezosa. La evidencia externa se ha vuelto menos paciente con eso.

El informe de GitClear Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality analizó aproximadamente 153 millones de líneas de código modificadas y encontró un aumento en la rotación (churn), más código agregado y copiado-pegado, y menos evidencia de reutilización. Su resumen es lo suficientemente contundente por sí solo: los cambios de código con un uso intensivo de IA se parecían cada vez más al trabajo de un contribuyente itinerante en lugar del de un mantenedor cuidadoso a largo plazo.

Eso no significa que las herramientas de programación de IA sean inútiles. Significa que la velocidad es real y que la disciplina de diseño sigue siendo necesaria.

La desordenada verdad es más interesante que el hype.

Estas herramientas pueden ayudar a los desarrolladores experimentados a moverse mucho más rápido. También pueden industrializar una estructura mediocre a una velocidad impactante si nadie dirige activamente la arquitectura, los límites y las pruebas.

Mi ejemplo de neo-chat-box es exactamente eso en miniatura. El asistente fue útil para implementar cambios. Pero no estaba protegiendo espontáneamente al componente de la deuda de diseño acumulada.

Sigue las contrataciones, no el hype

Vale la pena observar esta parte porque atraviesa la niebla del marketing.

Los laboratorios que venden magia de programación también están contratando un gran número de desarrolladores de software para trabajos empresariales y de negocios que requieren un criterio profundo.

Anthropic ha anunciado un puesto de Software Engineer, Enterprise Foundations para su iniciativa Claude for Work. La descripción no se trata de velocidad de escritura. Se trata de funciones de nivel empresarial, seguridad, cumplimiento, escalabilidad, gestión de identidades, gobernanza, control de acceso basado en roles y soluciones específicas para la industria de la salud, las finanzas y la educación.

Las listas de carreras de OpenAI ahora se leen de la misma manera. Su página pública de empleos incluye roles en Forward Deployed Engineering, B2B Applications, Internal Applications, Finance, and enterprise deployment work. Un rol publicado de Backend Software Engineer, Enterprise AI Platform describía el trabajo en sistemas seguros y conformes, acceso a datos corporativos, autenticación, confiabilidad e infraestructura administrada por el cliente para que las grandes organizaciones realmente puedan ejecutar agentes de manera segura en producción.

Esa es la señal reveladora.

Los laboratorios de vanguardia no están contratando personal como si el desarrollo de software hubiera colapsado en la redacción de prompts. Están contratando como si el trabajo valioso se estuviera trasladando al difícil punto medio donde las limitaciones comerciales, la seguridad, la identidad corporativa, la realidad del despliegue, el cumplimiento y el criterio de producto chocan entre sí.

Porque eso es exactamente lo que está sucediendo.

Lo que realmente necesitaba de la IA

No necesitaba que el modelo reemplazara mi criterio. Necesitaba que me ayudara a aplicar mi criterio más rápido.

Esa es una expectativa mucho más sensata.

Una vez que las preguntas de diseño estuvieron claras, la herramienta volvió a ser útil:

• Comparar las responsabilidades actuales dentro del componente
• Aislar lo que verdaderamente se comparte
• Identificar las costuras para los componentes hijos especializados
• Esbozar composiciones alternativas
• Ayudar a mover la lógica de renderizado hacia elementos enfocados
• Mantener la refactorización en movimiento sin reescribir toda la aplicación a mano

Ese es un fuerte efecto palanca.

Pero fíjate en el orden.

El apalancamiento llegó después del criterio de diseño, no en lugar de él.

La valiosa contribución humana fue reconocer que el problema ya no era «agregar otra función», sino «evitar que un componente pretendiera ser cuatro productos diferentes». Una vez que esa decisión tuvo un dueño, la IA pudo acelerar la ejecución.

Sin esa decisión, habría seguido sonriendo y agregando ramas.

Mejores preguntas para la codificación agéntica

Cuando un componente comienza a hincharse bajo el desarrollo asistido por IA, estas preguntas ayudan más que otro prompt heroico:

• ¿Qué responsabilidades se comparten y cuáles solo coexisten porque la historia las juntó a la fuerza?
• ¿Qué ramas representan conceptos de negocio diferentes en lugar de una variación menor de la interfaz de usuario?
• ¿Cómo se vería el componente de contenedor estable más pequeño?
• ¿Qué opciones específicas del modo merecen su propio componente enfocado?
• ¿Qué estado pertenece al contenedor y qué estado debería moverse detrás de una interfaz especializada?
• ¿Qué característica futura se vuelve más fácil si dividimos esto ahora?
• ¿Qué prueba fallaría si mantuviéramos el límite incorrecto en su lugar?

La última pregunta es importante porque convierte el gusto por el diseño en evidencia.

Una buena refactorización no solo es más bonita. Debería hacer que los cambios posteriores sean más baratos, las pruebas más claras y el comportamiento específico del modo menos enredado.

La parte difícil aún tiene un dueño

El mito más dañino sobre la IA en el software en este momento no es que los modelos sean inútiles.

Es que las buenas demostraciones y las victorias tempranas prueban que el criterio humano se está volviendo opcional.

No lo hacen.

Prueban que las partes burocráticas del desarrollo de software se están volviendo más baratas. Prueban que la continuación es más rápida. Prueban que un desarrollador capaz ahora puede pasar mucho más rápido de la idea a la implementación.

No prueban que la máquina decidirá cuándo la arquitectura ha comenzado a mentir.

Mi web component no necesitaba un asistente más entusiasta. Necesitaba a alguien dispuesto a decir que la forma actual estaba equivocada, a hacer preguntas precisas y a elegir la composición en lugar de la acumulación de ramas.

Es por eso que Claude Code y Codex son herramientas poderosas y aún así no son sustitutos del criterio.

Pueden ayudar a construir la cosa.

Alguien todavía tiene que decidir qué debería ser la cosa.