Los agentes escriben el código; el punto débil sigue siendo la especificación
Los controles del pipeline comparan el código con la especificación, nunca la especificación consigo misma. Con un requisito mal escrito, seis tests en verde certificaron un sistema que fallaba su objetivo.
Un equipo sembró a propósito un requisito malo en una unidad pequeña y dejó que el agente generara implementación y tests a partir de él. Seis tests en verde, una puerta de trazabilidad y una ejecución limpia certificaron el resultado. Nadie detectó que el propio requisito ejecutaba justo el fallo que esa funcionalidad existía para impedir.
La conclusión es incómoda: todos los controles del pipeline responden a la misma pregunta, si el código cumple lo que dice la especificación. La especificación nunca se juzga.
Cómo llega el trabajo al agente
Casi todo pasa antes de que el agente vea una línea. La funcionalidad arranca en una reunión grabada, y no solo con el equipo que va a escribir el código: se sientan las cuatro o cinco áreas que tocan el servicio compartido. Cuando se resuelve un punto conflictivo, alguien lo verbaliza para la grabación. De esa transcripción sale el documento de alcance, no del documento de requisitos previo, que queda como histórico.
El documento de alcance divide la funcionalidad en grupos de entrega y estos en unidades numeradas, aproximadamente una por porción desplegable. Cada unidad lleva propósito, límites de alcance, requisitos funcionales, capas arquitectónicas, dependencias, feature flags y criterios de aceptación en formato dado/cuando/entonces. Se sincroniza con el gestor de incidencias, un elemento de trabajo por unidad, y se reparte.
Al coger una, el desarrollador genera una especificación: interfaces con nombre, firmas de métodos, archivos a crear o modificar, matriz de errores, flujo de consulta paso a paso y lo que la unidad no va a hacer. Las dudas abiertas vuelven a una persona en lugar de resolverse a ojo. En una unidad, una pregunta sobre el constructor de una clase base destapó que el diseño especificaba una llamada que no compilaba.
Solo entonces el agente escribe código, y se le exige cubrir la ruta de llamada completa con tests unitarios y de integración. La cobertura parcial es peor que ninguna: sugiere que alguien pensó en los caminos no probados. Después vienen la revisión automática del pull request, el pipeline que bloquea lo que discrepa de la especificación, entornos efímeros, el visto bueno de un segundo desarrollador y el QA, que revisa a mano cada caso generado. La entrega sale los jueves.
El requisito que nadie juzga
El requisito sembrado tenía la forma de cualquier decisión razonable: si la consulta de clasificación no devuelve determinación, tratar el registro como permitido y continuar, para que una dependencia no disponible no bloquee la entrega. Suena a alguien que sopesó disponibilidad frente a corrección. En un documento de 40 páginas se pasa de largo en dos segundos, pero iba sobre la población exacta que nadie prueba a mano.
Ahí está el hueco. Revisión automática, trazabilidad, tests y aprobación humana comparan artefactos con la especificación; ninguno pone la especificación en el banquillo. Y como código y tests se generan de los mismos criterios, coinciden entre sí diga lo que diga el criterio.
Queda por ver si ese hueco se cierra con un control aguas arriba y quién lo ejerce. La herramienta es la parte barata; lo caro es organizativo, porque hace falta alguien que entienda el dominio y pueda parar la unidad antes de que se genere nada. En este pipeline, el último punto donde algo se decide es la especificación de unidad.
