Hace cinco meses un equipo decidió probar algo que suena a ciencia ficción pero es muy real: construir y lanzar un producto de software con cero líneas de código escritas por humanos. Todo, desde la lógica de la aplicación hasta la documentación y la infraestructura, fue generado por agentes guiados por Codex.
Qué hicieron
Abrieron un repositorio vacío en agosto de 2025 y, en cinco meses, dejaron que Codex y un conjunto de agentes lo llenaran. Resultado: alrededor de un millón de líneas de código, 1,500 pull requests fusionadas, y una base de usuarios internos que usa la app a diario.
La diferencia clave no es que la IA sea mágica. Es que la ingeniería cambió de tarea: los humanos dejaron de teclear la implementación y pasaron a diseñar entornos, especificar intenciones y construir los lazos de retroalimentación que permiten a los agentes hacer trabajo confiable.
Cómo trabajaron los agentes (y qué significa eso)
- Los agentes escribieron el
scaffoldinicial: estructura del repo, CI, reglas de formato y hasta unAGENTS.mdque explica cómo operar en el repositorio. - Los ingenieros interactúan con el sistema mediante prompts. Describen una tarea, el agente abre un pull request, revisa su propio cambio, atiende feedback de otros agentes y de humanos, y repite hasta completar la tarea.
- Muchas revisiones se manejan agente a agente. Los humanos revisan cuando es necesario, pero no son el cuello de botella.
¿Te imaginas dormir y que mientras tanto un agente trabaja seis horas seguidas en una tarea, reproduce un bug, hace el fix y genera evidencia en video? Eso pasó aquí.
Cambios en la disciplina de ingeniería
Con agentes al frente, la disciplina no desaparece: se traslada. Ya no se trata tanto de escribir líneas perfectas sino de crear scaffolding, reglas y herramientas que el agente entienda. Algunas prácticas que adoptaron:
- Documentación estructurada en
docs/y unAGENTS.mdcorto que actúa como mapa. El resto está catalogado y versionado para que los agentes lo encuentren. - Linters y tests estructurales que no solo detectan errores, sino que ofrecen instrucciones de remediación legibles por agentes.
- Arquitectura rígida por dominio con capas definidas para que el agente no invente dependencias erráticas.
- Observabilidad y UIs legibles por la IA: logs, métricas y snapshots que el agente puede consultar con
LogQLyPromQLpara validar comportamientos.
En la práctica tuvieron que priorizar lo que es accesible al agente dentro del repo. Lo que vive en Google Docs o en chats no existe para la IA a menos que se ponga en el repositorio.
Lecciones prácticas y reglas simples
Dale al agente un mapa, no un manual de 1,000 páginas.
Contexto es un recurso limitado. Un archivo gigante confunde más que ayuda. Mejor: entradas pequeñas, enlazadas y verificables. Algunas reglas útiles:
- Documentación corta como punto de entrada y fuentes de verdad versionadas.
- Planes ejecutables y verificables dentro del repo para que el agente sepa qué cambiar y por qué.
- Enforce invariants, no microgestión: define límites claros (por ejemplo, validaciones en el borde) y deja libertad en la implementación.
Además, las piezas aburridas y predecibles de la tecnología suelen ser mejores para agentes: son más modelables y menos propensas a comportamientos opacos.
Control de calidad y deuda técnica automática
Cuando la producción del agente escala, la capacidad humana para revisar se vuelve el cuello de botella. La respuesta fue automatizar limpieza y coherencia:
- Principios "golden" codificados que un agente puede aplicar constantemente.
- Agentes de limpieza que detectan patrones malos, abren PRs de refactor y permiten autocommit en cambios menores.
- Reglas de arquitectura y lints que inyectan instrucciones de remediación en el contexto del agente.
La deuda técnica se pagó en pequeñas cuotas diarias en vez de grandes limpiezas mensuales. Eso reduce el interés acumulado del mal diseño.
Riesgos, límites y lo que aún no saben
No todo es perfecto ni extrapolable automáticamente. Algunos límites importantes:
- Este repositorio fue diseñado desde el inicio para ser legible por agentes. No cualquier código heredado se adapta igual sin inversión.
- Los agentes replican patrones existentes, incluso los malos. Sin principios firmes, el código puede degradarse.
- Hay preguntas abiertas sobre cómo se mantiene la coherencia arquitectónica a largo plazo y cuándo la intervención humana aporta mayor palanca.
¿Y tú qué puedes hacer mañana?
Si alguien en tu equipo quiere experimentar con agentes para acelerar ingeniería, piensa primero en estas inversiones:
- Estructura el repo como fuente de verdad versionada.
- Define límites claros y pruebas estructurales que los agentes puedan ejecutar.
- Automatiza observabilidad legible por la IA: logs, métricas y snapshots.
- Empieza por encapsular dependencias y comportamientos críticos con pruebas y contratos.
No es magia: es ingeniería con una nueva paleta de herramientas. Si organizas bien el terreno, el beneficio principal es multiplicar el tiempo humano, no reemplazarlo.
La experiencia de este experimento muestra que la velocidad es posible, pero exige disciplina para mantener coherencia y calidad. En la práctica, construir con agentes es menos sobre el código que sobre los caminos que permites que la IA recorra.