La mayoría de los equipos que adoptan la codificación con agentes trasladan los cuellos de botella de la generación a la revisión; si no corrigen ese ciclo, la ganancia 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 problemas, no generar código.
Los resultados útiles de un agente resisten el análisis y explican la causalidad, no solo las coincidencias de patrones.
Diseñar la capa de recopilación de evidencia y construcción de contexto importa más que la capa de generación.
Gran parte del debate sobre la codificación con agentes aún parte de una promesa sencilla: escribir más código en menos tiempo.
A veces, esa promesa se amplía hasta convertirse en una visión más ambiciosa: agentes que planifican el trabajo, abren Pull requests e implementan 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 más limitado. Se trata de reducir el costo de cada iteración.
La entrega de software no consiste solo en generar código. Escribir código es apenas una etapa de un ciclo más largo que incluye revisión, pruebas, implementación e investigación cuando algo falla. La mayoría de los equipos que adoptan la codificación con agentes sin rediseñar el ciclo de revisión solo trasladan el cuello de botella a una etapa posterior.
Acelerar la generación por sí sola no hace que un equipo avance 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 confianza necesaria.
¿El cambio realmente corrigió el problema o mejoró el sistema? ¿Introdujo una regresión en otra parte? ¿La falla está en el código, el entorno, las pruebas o una dependencia? ¿La corrección propuesta aborda la causa o solo el síntoma visible?
Los agentes pueden ayudar aquí, no porque sustituyan a los ingenieros, sino porque pueden hacer una primera revisión estructurada de evidencia desordenada: inspeccionar 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 es generar código desde cero. Es reducir el espacio de búsqueda en torno a un problema antes de que una persona dedique horas a hacerlo manualmente.
Esto resulta especialmente claro 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, como ocurre con uno de nuestros clientes. Cuando algo falla, es difícil identificar y asignar al responsable. El problema podría estar en el código de la aplicación, una dependencia, el arnés de ejecución o alguna otra parte de la pila. Los registros pueden ocupar gigabytes, y el primer equipo que detecta el problema no siempre es responsable de resolverlo.
Ese tipo de flujo de trabajo no requiere, por naturaleza, que un solo agente escriba la corrección. Está pensado para un sistema que reduzca rápidamente el espacio del problema.
Un proceso útil podría obtener registros, seleccionar la evidencia relevante, resumir lo importante, inspeccionar código en un entorno aislado y producir un análisis estructurado de la causa raíz con una puntuación de confianza, trazabilidad y próximos pasos sugeridos. Para generar una puntuación de confianza, un especialista en la materia califica el resultado inicial del agente. Luego, esto se introduce en un LLM que actúa como juez para automatizar las calificaciones posteriores sin dejar de ajustarse al criterio humano.
El objetivo no es eliminar el criterio de ingeniería, sino ofrecer a quienes revisan 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 a la implementación comparten la misma estructura. Requieren mucha evidencia y revisión, y están llenas de ambigüedad. No le piden a un agente que sustituya el proceso de ingeniería, sino que ayude a impulsarlo.
Por eso, los equipos también deben evaluar estos sistemas con cuidado.
La pregunta equivocada es si un agente puede producir algo impresionante de forma aislada. La pregunta correcta es si mejora un flujo de trabajo real sin generar obstáculos en otra parte.
Esto implica determinar si el resultado es lo bastante específico para verificarlo, si explica la causalidad en lugar de limitarse a detectar 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 los resultados de un agente cuando resisten el análisis y ofrecen algo concreto que comprobar.
La lección de fondo es que los sistemas útiles con agentes dependen de algo más que la generación. Dependen de cómo se recopila la evidencia, se construye el contexto, se verifican los resultados y se comunica la incertidumbre a quien revisa.
Por eso, es poco probable que el futuro cercano de la ingeniería con agentes dé un salto gigantesco hacia la autonomía total. Es más probable que consista en un conjunto de ciclos cuidadosamente diseñados en los que los agentes ayuden a los equipos a inspeccionar, revisar, verificar y perfeccionar su trabajo, con menos esfuerzo desperdiciado entre cada paso.
Quizá sea menos impactante que la visión más amplia de la autonomía, pero se acerca mucho más a la forma en que realmente se adoptan los sistemas útiles.