Cómo construyo software con agentes de programación con IA
Qué delego en los agentes de programación, los dos errores que no detectaron y por qué el cuello de botella pasó de escribir código a verificarlo.
Lo que delego de verdad
Ahora uso agentes de programación para la mayor parte del trabajo mecánico. Este sitio es el ejemplo más claro: en unas semanas ganó un front end en cuatro idiomas, una página de servicios, un formulario de contacto con su propio endpoint de API y su almacenamiento, casos de estudio montados a partir de contenido que ya existía y un widget de progreso alimentado por un perfil de Duolingo. Casi nada de eso necesitó que yo escribiera código a mano.
Lo que nunca delego es saber qué debería existir. Un agente construirá tan tranquilo la cosa equivocada a toda velocidad. La habilidad útil es escribir una especificación lo bastante precisa como para que equivocarse se vea.
El fallo que me enseñó a comprobar el resultado
Mientras añadía una insignia de madurez a las páginas de proyecto, hice que se escribiera un campo status nuevo en la base de datos, extendí el tipo y actualicé el componente. Compilaba. La página se renderizaba. La insignia decía «en desarrollo» en todos los proyectos.
La causa era un controlador que aplicaba una lista blanca a los campos que devolvía, así que el campo nuevo nunca salía del servidor. Nada en el sistema de tipos protestó, porque cada capa era correcta por separado.
Dos días después apareció el mismo patrón en el sitemap. Se generaba mientras se construía la imagen del contenedor, cuando el backend no es accesible, así que la lista de identificadores de proyecto volvía vacía y el sitemap se publicó sin un solo caso de estudio. La compilación pasó. El archivo tenía buen aspecto.
Ninguno de los dos errores era exótico. Los dos eran invisibles salvo que mires lo que el sistema desplegado emite de verdad.
Dónde son realmente fuertes los agentes
Amplitud mecánica. Renombrar un concepto en cuarenta archivos. Añadir un cuarto idioma a cada sitio que ya tenía tres. Escribir el andamiaje de pruebas de un repositorio que no tiene ninguna. El trabajo amplio, aburrido y fácil de verificar es donde la ganancia de velocidad es real, porque verificar sale barato cuando el cambio es uniforme.
También se les da bien eso que yo solía posponer: la segunda pasada. Un modelo que revisa su propio diff detecta errores de tipos, ramas inalcanzables e imports olvidados más rápido que yo a las once de la noche.
Dónde fallan en silencio
No saben qué es verdad. Pide un caso de estudio y puedes recibir un párrafo seguro sobre un producto que no existe. Toda afirmación factual sigue necesitando una fuente, y «las pruebas pasan» no es una fuente.
También se detienen en la compilación. Un modelo declarará terminada una funcionalidad porque la compilación está en verde, cuando la funcionalidad no está conectada a la página, un serializador descarta el campo o la migración nunca se ejecutó.
El cuello de botella se movió
Antes, la parte cara era escribir el código. Ahora es decidir con precisión qué construir y demostrar que lo construido es lo que pediste. Mis días son distintos: menos teclear, más leer diffs y más comprobar la salida en vivo.
Eso tiene una consecuencia en cómo trabajo. Cambios pequeños, verificados en producción y con vuelta atrás. Un diff grande generado por un agente que «parece correcto» es lo más caro que puedes fusionar.