La mayoría de los equipos que adoptan la programación con agentes trasladan el cuello de botella de la generación a la revisión; si no corrigen este ciclo, la mejora neta de velocidad es casi nula.
En entornos de CI a gran escala —con millones de pruebas nocturnas y cientos de ingenieros—, la tarea de mayor valor para un agente es asignar responsables y clasificar incidencias, no generar código.
Los resultados útiles de un agente resisten el análisis y explican la causalidad, en lugar de limitarse a identificar patrones.
Diseñar la capa de recopilación de pruebas y creación de contexto importa más que la capa de generación.
Gran parte del debate sobre la programación con agentes aún parte de una promesa sencilla: escribir más código y más rápido.
A veces, esta promesa se amplía hasta convertirse en una visión más ambiciosa: agentes que planifican el trabajo, abren Pull requests y publican cambios con una intervención humana mínima. Sin embargo, para la mayoría de los equipos de ingeniería, el valor más claro a corto plazo tiene un alcance menor. Se trata de reducir el coste de cada iteración.
La entrega de software no consiste solo en generar código. Escribir código es solo una fase de un ciclo más largo que incluye la revisión, las pruebas, el despliegue y la investigación cuando algo falla. La mayoría de los equipos que adoptan la programación con agentes sin rediseñar el ciclo de revisión se limitan a trasladar el cuello de botella a una fase posterior.
Acelerar únicamente la generación no hace que un equipo sea más rápido de forma automática. Puede limitarse a trasladar más trabajo a la revisión, la verificación y la generación de confianza.
En muchos entornos de ingeniería, lo costoso no es producir un primer borrador, sino alcanzar la certeza necesaria.
¿El cambio ha corregido realmente el problema o mejorado el sistema? ¿Ha introducido una regresión en otro punto? ¿El fallo está en el código, el entorno, las pruebas o una dependencia? ¿La solución propuesta aborda la causa o solo el síntoma visible?
Los agentes pueden ayudar en este punto, no porque sustituyan a los ingenieros, sino porque pueden realizar una primera revisión estructurada de pruebas desordenadas: examinar registros, comparar cambios recientes, resumir señales relevantes, rastrear causas probables, ejecutar comprobaciones y devolver algo que una persona pueda analizar.
En muchos equipos, el uso de mayor impacto para un agente no consiste en generar código desde cero. Consiste en acotar el espacio de búsqueda de un problema antes de que una persona dedique horas a hacerlo manualmente.
Esto resulta especialmente evidente en los flujos de depuración a gran escala. Imagina una CI nocturna que ejecuta millones de pruebas en bases de código modificadas por cientos de ingenieros (una realidad para uno de nuestros clientes). Cuando algo falla, asignar la incidencia al responsable adecuado resulta difícil. El problema podría estar en el código de la aplicación, una dependencia, el arnés de pruebas o cualquier otro punto de la pila. Los registros pueden ocupar gigabytes y el primer equipo que detecta el problema no siempre es el responsable.
Un flujo de trabajo así no requiere de forma natural que un agente escriba la solución. Está pensado para un sistema que acote rápidamente el problema.
Un proceso útil podría obtener registros, seleccionar las pruebas relevantes, resumir lo importante, examinar el código en un entorno aislado y elaborar un análisis estructurado de la causa raíz con una puntuación de confianza, trazabilidad y próximos pasos recomendados. Para generar una puntuación de confianza, un especialista en la materia evalúa el resultado inicial del agente. Después, esta evaluación se introduce en un LLM que actúa como juez para automatizar las puntuaciones futuras sin perder la correspondencia con el criterio humano.
El objetivo no es eliminar el criterio de los ingenieros, sino ofrecer a los revisores un punto de partida más sólido. La clasificación de regresiones, la revisión de Pull requests, la reparación de pruebas, la validación de versiones y la investigación posterior al despliegue siguen el mismo patrón. Exigen muchas pruebas y revisiones, y están llenas de ambigüedad. No piden que un agente sustituya el proceso de ingeniería, sino que ayude a impulsarlo.
Esta es también la razón por la que los equipos deben evaluar estos sistemas con cautela.
La pregunta equivocada es si un agente puede producir por sí solo algo impresionante. La pregunta adecuada es si mejora un flujo de trabajo real sin generar fricción en otro punto.
Eso implica comprobar si el resultado es lo bastante específico para verificarlo, si explica la causalidad en lugar de limitarse a identificar patrones y si facilita la revisión en vez de dificultarla. Una respuesta plausible no es lo mismo que una respuesta útil. En la práctica, los equipos confían en el resultado de un agente cuando resiste el análisis y les ofrece algo concreto que comprobar.
La lección de fondo es que los sistemas de agentes útiles dependen de algo más que la generación. Dependen de cómo se recopilan las pruebas, cómo se crea el contexto, cómo se comprueban los resultados y cómo se presenta la incertidumbre al revisor.
Por eso es poco probable que el futuro inmediato de la ingeniería con agentes dé un salto directo hacia la autonomía total. Es más probable que consista en una serie de ciclos cuidadosamente diseñados en los que los agentes ayuden a los equipos a examinar, revisar, verificar y perfeccionar su trabajo, reduciendo el esfuerzo desperdiciado entre pasos.
Puede que resulte menos espectacular que la visión más amplia de la autonomía, pero se acerca mucho más a cómo se adoptan realmente los sistemas útiles.