La demo siempre funciona

Toda demostración de programación con IA sigue el mismo arco. Alguien le da un prompt a un modelo. Una aplicación funcional se materializa. La audiencia queda impresionada.

Y deberían estarlo. La velocidad es real. La capacidad es real. La versión uno genuinamente se publica más rápido con IA en el proceso.

El problema es que la versión uno nunca fue la parte difícil.

Dónde realmente se concentra el costo

El costo de la ingeniería de software no se concentra en la creación inicial. Se concentra en la iteración cuatro, cinco y seis:

  • El proveedor de autenticación necesita cambiar porque los precios cambiaron.
  • La analítica necesita moverse porque el proveedor fue adquirido.
  • Una funcionalidad necesita añadirse que toca tres pantallas que la generación original nunca anticipó.
  • Un sistema de estilos necesita reemplazarse porque el diseñador cambió de dirección.
  • Una integración de pagos necesita intercambiarse porque el producto se expandió a un nuevo mercado.

Ninguno de estos son fallos de la generación inicial. Todos son desarrollo de producto normal. La pregunta es si el codebase hace que estos cambios sean baratos o costosos.

El codebase generado por IA bajo presión de cambio

La mayoría de los codebases generados por IA manejan bien el primer cambio. El segundo cambio es incómodo. Para el cuarto cambio, los equipos empiezan a reportar los mismos síntomas:

  • “Le pedimos a la IA que intercambiara el proveedor de autenticación, pero tocó 14 archivos.”
  • “El refactor rompió pruebas en módulos que deberían haber sido independientes.”
  • “No podemos saber qué partes del sistema dependen del SDK de analítica.”
  • “Cada cambio requiere re-entender todo el codebase.”

Estos síntomas no son fallos del modelo. Son fallos de arquitectura. El modelo generó un sistema sin límites, y ahora cada cambio tiene un radio de impacto impredecible.

Por qué los codebases generados por IA se degradan más rápido

Los codebases tradicionales también se degradan. Pero los codebases generados por IA se degradan más rápido por razones específicas:

Sin modelo mental compartido. Un equipo humano construye intuición estructural durante meses. Una IA genera código sin memoria de por qué se tomaron decisiones anteriores.

Optimización para el prompt inmediato. Los modelos resuelven la solicitud actual. No optimizan para las próximas cinco solicitudes. Cada generación toma decisiones localmente correctas que son globalmente incoherentes.

El volumen amplifica el acoplamiento. La IA genera más código más rápido. Más código con límites débiles significa más acoplamiento, más rápido. La ventaja de velocidad se convierte en el acelerador de la degradación.

El refactor requiere contexto global. Los modelos tienen dificultades con refactors que abarcan todo el codebase porque las ventanas de contexto son finitas y la intención arquitectónica es implícita.

El verdadero desafío de ingeniería

El verdadero desafío de ingeniería en el desarrollo AI-native no es “¿Cómo genero mejor código?”

Es “¿Cómo estructuro el sistema para que las partes generadas por IA puedan cambiarse independientemente?”

Eso significa:

  • Límites que hacen predecible el radio de impacto.
  • Interfaces que desacoplan lo que cambia de lo que permanece.
  • Composition roots que hacen explícitos los grafos de dependencia.
  • Contract tests que verifican la integración sin requerir el sistema completo.
  • La capacidad de eliminar y regenerar cualquier module sin fallos en cascada.

El mantenimiento a largo plazo es un problema estructural

Ninguna cantidad de mejores prompts corrige un codebase donde cada module accede a todos los demás módulos. No puedes salir del acoplamiento arquitectónico a base de prompts.

El mantenimiento a largo plazo de un codebase con IA requiere la misma disciplina que siempre requirió: límites, contracts e aislamiento. La diferencia es que la velocidad de la IA hace visible la ausencia de estas disciplinas más rápido. Un equipo que habría tardado dos años en crear un monolito inmantenible ahora puede hacerlo en dos meses.

La velocidad es un regalo y una trampa. Sin estructura, solo significa que llegas a la crisis de mantenimiento antes.

La conexión con la arquitectura AI-native

Este es el argumento central que presenté en Stanford CS146S tiene razón sobre la programación con IA — El tema ausente es la arquitectura: la fluidez con herramientas sin disciplina arquitectónica produce codebases que son rápidos de crear y costosos de mantener.

El desarrollador de software moderno necesita ambas cosas. Las herramientas de IA para publicar rápido. La disciplina arquitectónica para seguir publicando rápido después de la versión uno.

La versión uno nunca fue el problema. El problema es si la versión cinco sigue siendo barata.

Preguntas frecuentes

¿Por qué los codebases generados por IA se vuelven difíciles de mantener?

Los modelos de IA optimizan para el prompt inmediato, no para el cambio futuro. Esto produce código que funciona pero carece de los límites necesarios para la modificación independiente. Sin restricciones arquitectónicas explícitas, el acoplamiento se acumula más rápido que en los codebases escritos a mano porque la IA genera más código, más rápido.

¿Cómo se previene la degradación de un codebase con IA a lo largo del tiempo?

Tres prácticas estructurales: aplicar límites de module con interfaces que la aplicación posee, centralizar el cableado de dependencias en un composition root, y ejecutar contract tests que verifican los puntos de integración de forma independiente. Esto hace que el costo del cambio sea predecible independientemente de cómo se generó el código.

¿Es el código generado por IA más difícil de refactorizar que el código escrito por humanos?

No inherentemente. Pero el código generado por IA es más propenso a carecer de los límites estructurales que hacen seguro el refactor, porque los modelos no optimizan espontáneamente para el cambio futuro. La solución es imponer esos límites antes de la generación, no esperar que el modelo los produzca por sí solo.

¿Cuál es el mayor riesgo de la programación con IA para proyectos a largo plazo?

El mayor riesgo es la trampa de la velocidad: publicar tan rápido en la fase temprana que la deuda arquitectónica se acumula antes de que el equipo lo note. Para cuando el mantenimiento se vuelve costoso, el codebase está demasiado acoplado para arreglarlo incrementalmente.