El agente ejecutó un ciclo durante 40 horas: cómo integrar la IA en el desarrollo sin regresiones

Los debates sobre si siguen haciendo falta desarrolladores en la era del vibe coding suelen reducirse a emociones. En cambio, el autor de un análisis publicado en Habr muestra qué sucede en la práctica cuando se asigna una tarea a un agente sin imponerle límites.

Dónde falla el vibe coding

En Xenodrift, un proyecto personal que se rehízo varias veces, las decisiones anteriores dejaron de respetarse al introducir nuevos cambios. Aparecieron regresiones y algunas funcionalidades simplemente desaparecieron. La causa era trivial: los requisitos no estaban documentados en ninguna parte y no había forma de comprobar su cumplimiento. En cada ocasión, el agente trabajaba con el fragmento de contexto disponible y no recordaba lo que se había acordado antes.

Sin embargo, la mala calidad del código no es inevitable. En DemoBank, la demo de una aplicación bancaria, el autor definió requisitos de rendimiento, reutilización de funcionalidades y sistema de diseño, pero evitó deliberadamente imponer una arquitectura. El resultado fue una estructura modular feature-first con elementos de Clean Architecture, BLoC/Cubit para la gestión del estado, e idempotencia y reintentos en la capa de red. La funcionalidad para pagar multas opera tanto dentro de la aplicación como de forma independiente, sin arrastrar dependencias innecesarias.

El rendimiento se comprobó en un realme RMX3760 económico y real. Durante una ejecución de un minuto con 12.000 operaciones, el 0,25% de los fotogramas superó el presupuesto de 16,7 ms, frente al criterio de menos del 1%. El autor advierte con franqueza que se trata de un solo dispositivo y un único escenario.

Velocidad no equivale a estar listo

DemoBank requirió unas 27 horas de trabajo total de Codex y alrededor de 19 horas de tiempo real, teniendo en cuenta la ejecución en paralelo, más 2–3 horas del propio autor. Las ejecuciones de las pruebas de rendimiento en el teléfono resultaron especialmente costosas. La métrica de un equipo no debería ser “a qué velocidad se generó el código”, sino “cuánto tiempo transcurrió desde la definición de la tarea hasta la aceptación del cambio”, incluidas la revisión y las correcciones.

Harness, quality gates y responsabilidad

Por AI Harness, el autor entiende el entorno de trabajo del agente: el contexto del proyecto, las herramientas, las restricciones sobre sus acciones, las comprobaciones automáticas y el procedimiento para entregar el resultado a una persona. Estas son las ideas clave:

• Las comprobaciones de las que depende la aceptación deben ejecutarse automáticamente y bloquear la fusión. Escribir “ejecuta las pruebas” en un prompt no lo garantiza.
• El ciclo “continúa hasta que pasen las comprobaciones” debe tener límites. Uno de los proyectos del autor estuvo ejecutándose durante 40 horas hasta que él lo detuvo manualmente. Hacen falta límites de tiempo y dinero y, cuando un error se repite sin avances, el agente debe detenerse e informar de lo que ha intentado.
• Tras una parada forzada, hay que corregir el proceso, no solo el código. Es posible que el agente haya entendido mal la tarea, que el mapa del proyecto esté desactualizado o que el modelo sea demasiado débil.
• Cada decisión debe tener un responsable claramente identificado: producto y analítica aprueban el comportamiento, el propietario del módulo verifica sus contratos y un desarrollador revisa la interpretación de la tarea por parte del agente antes de que se escriba código.

Contexto, contratos y dominios

Una ventana de contexto grande no garantiza que la información se utilice correctamente: el estudio Lost in the Middle mostró que la calidad depende de la posición de los datos dentro del contexto. Por eso hacen falta un mapa de módulos, contratos actualizados y ADR. El autor propone mantener el contrato de la API en una única fuente, por ejemplo TypeSpec, y generar a partir de ella OpenAPI, la documentación y el código de cliente, comprobando la coherencia en CI. Los ADR obsoletos deben marcarse como superseded.

Sin embargo, un contrato no sustituye a las pruebas de comportamiento. Una clave de idempotencia puede describirse en un esquema, pero la ausencia de un reembolso duplicado solo puede verificarse mediante un escenario independiente. Un ejemplo de e-commerce: con un mapa del proyecto deficiente, el agente puede llamar directamente a la API del proveedor de pagos desde el módulo de pedidos, haciendo que los reembolsos no aparezcan en el registro de pagos. Aquí resultan útiles DDD y las reglas arquitectónicas verificadas automáticamente, además de una revisión realizada por otro modelo.

Qué hacer

Las limitaciones están claras: es la experiencia de un solo autor con proyectos pequeños y sin una auditoría independiente del código. Aun así, las conclusiones son transferibles. Documente los requisitos en especificaciones como OpenSpec, Spec Kit, BMAD o Kiro; haga obligatorios los quality gates; establezca presupuestos para los ciclos de los agentes; y asigne responsables del contexto. El papel del desarrollador está pasando de escribir código a definir límites y aceptar el resultado.