Cómo he montado un sistema de desarrollo autónomo con agentes de IA

Llevo unos días experimentando con algo que me tenía intrigado: dejar que la IA desarrolle un proyecto de software de forma casi completamente autónoma.

No hablo de pedirle que te genere una función o un componente, hablo de un sistema de agentes que escanean el código, detectan problemas, crean issues, las priorizan, las implementan, hacen push y cierran las issues. Todo sin intervención humana.

El proyecto es Learnfolx (nombre final TBD 😄), una plataforma de formación B2B que estoy construyendo (Next.js + PostgreSQL + Prisma + Redis). Y la IA está trabajando a ritmo incansable: 80 issues creadas y ~50 cerradas en 3 días. Sin tocar una línea de código.

Aquí te cuento cómo lo tengo montado, y te doy todos los prompts para que puedas replicarlo:

La arquitectura: scanners + triaje + executor

El sistema tiene 3 capas:

Scanners — Agentes especializados que analizan el código buscando un tipo concreto de problema. Cada uno crea issues en GitHub con lo que encuentra.
Triaje — Un cron diario que prioriza automáticamente las issues nuevas (p1/p2/p3).
Executor — Un agente que cada hora coge la issue de mayor prioridad, la implementa, pasa los checks y la cierra.

Y hay una cuarta capa que actúa como red de seguridad:

Smoke tests — Cada 4 horas verifica que el proyecto compila, pasa tests y no tiene regresiones.

Todo corre en automatizaciones en Codex App + un cron externo para el triaje (aunque también podría estar en Codex).

Que esto no te eche para atrás si no usas Codex: un proceso que ejecute tareas cron haría lo mismo.

Los scanners: 6 especialistas

Aquí te cuento cómo lo hemos organizado. Esto fue muy curioso, porque configurar esto a mano habría sido tedioso. En vez de eso le pedí a mi chatbot de Telegram (una especie de OpenClaw muy sencillo) que quería hacer esto.

Entre ambos definimos los scanners, y automáticamente, revisando la configuración de Codex en ~/.codex fue capaz de localizar cómo se configuran las autos y hacerlo por su cuenta.

1. Security Scanner (diario, 9:00)

El de seguridad combina herramientas deterministas con revisión del LLM. Ejecuta Semgrep y npm audit primero, y luego hace una revisión manual buscando lo que las herramientas no cubren.

Eres un scanner de seguridad. Tu ÚNICO trabajo es detectar problemas
y crear issues en GitHub. NO implementes nada.

## Paso 1: Semgrep (análisis estático)
Ejecuta semgrep con reglas automáticas:
  semgrep --config auto --json --quiet .
Analiza los resultados JSON. Agrupa por severidad y tipo de vulnerabilidad.

## Paso 2: npm audit
Ejecuta pnpm audit --json para detectar dependencias vulnerables.

## Paso 3: Revisión manual complementaria
Analiza el proyecto buscando cosas que semgrep no cubre bien:
- Secrets o API keys hardcodeadas en el código
- Endpoints sin autenticación/autorización adecuada
- Variables de entorno sensibles expuestas
- Configuraciones inseguras (CORS, headers, etc.)
- Lógica de autorización incorrecta (ej: tenant isolation bypass)

Resultado real: Detectó credenciales hardcoded en el script de seed (solo era para desarrollo, pero no está de más), un CVE en la dependencia qs, y una exposición CORS en el dev server de esbuild.

2. Architecture Scanner (diario, 13:00)

Usa madge para detectar dependencias circulares y knip para código muerto, además de la revisión del LLM para archivos demasiado grandes o funciones largas.

## Paso 1: Dependencias circulares (madge)
Ejecuta:
  npx madge --circular --extensions ts,tsx apps/web/src/

## Paso 2: Código muerto (knip)
Ejecuta:
  npx knip --no-progress

## Paso 3: Revisión manual complementaria
- Código duplicado entre archivos
- Archivos demasiado grandes (>300 líneas)
- Funciones demasiado largas (>50 líneas)
- Patrones inconsistentes
- Componentes con demasiadas responsabilidades
- TODOs y FIXMEs pendientes

Resultado real: Encontró 19 issues de deuda técnica, desde servicios de 600+ líneas hasta CSS duplicado en 8 módulos de admin.

3. Test Scanner (diario, 11:00)

Ejecuta vitest --coverage y analiza la cobertura real, priorizando módulos críticos.

## Paso 1: Cobertura real (vitest)
Ejecuta:
  pnpm vitest run --coverage --reporter=json
Analiza qué archivos tienen cobertura baja (<50%) o nula.
Prioriza archivos en src/lib/services/, src/app/api/, y src/lib/auth/.

## Paso 2: Tests que fallan
## Paso 3: Revisión manual complementaria
- Funciones críticas sin test (auth, pagos, acceso a datos, tenant isolation)
- Tests flaky o con dependencias externas sin mock
- Endpoints de API sin tests de integración

4. Performance Scanner (diario, 15:00)

Busca N+1 queries, componentes sin memoización, bundles grandes y llamadas API redundantes.

Eres un scanner de rendimiento. Tu ÚNICO trabajo es detectar problemas
de performance y crear issues en GitHub. NO implementes nada.

Analiza el proyecto buscando:
- Queries N+1 en Prisma o accesos a BBDD ineficientes
- Componentes React sin memoización que deberían tenerla
- Bundles JavaScript demasiado grandes
- Imágenes sin optimizar o sin lazy loading
- Renders innecesarios
- Falta de caché en endpoints que lo necesitan
- Llamadas API redundantes o en cascada

Resultado real: Detectó 4 problemas de rendimiento, incluyendo N+1 queries en el dashboard de analytics y lookups individuales por fila en la importación CSV.

5. DX Scanner (diario, 17:00)

Combina herramientas de análisis estático con revisión manual para detectar fricciones de desarrollo.

## Paso 1: Código muerto y dependencias sin usar (knip)
Ejecuta:
  npx knip --no-progress

## Paso 2: Type checking
Ejecuta:
  pnpm tsc --noEmit
Revisa errores de tipos que no se ven en el IDE pero rompen el build.

## Paso 3: Dependencias desactualizadas
Ejecuta:
  pnpm -r outdated

## Paso 4: Revisión manual complementaria
- Errores de linting no resueltos
- Scripts de package.json que faltan o están rotos
- Documentación desactualizada o faltante
- .gitignore incompleto

Resultado real: Detectó que tsc no estaba accesible como comando, que knip no cargaba la config, y varias dependencias con major versions pendientes (Prisma 7, Vitest 4, Zod 4).

6. Feature Scanner (diario, 14:00)

Este es el más interesante. Lee las especificaciones del proyecto (business rules, milestone capabilities, entities) y las compara con el código actual para detectar funcionalidad que debería existir pero no está implementada.

Eres un scanner de funcionalidad. Tu ÚNICO trabajo es detectar
mejoras y features nuevas y crear issues en GitHub. NO implementes nada.

Proceso:
1. Lee las specs: docs/domain/business-rules.md,
   docs/domain/milestone-capabilities.md,
   docs/domain/entities-and-invariants.md
2. Lee docs/architecture/overview.md y docs/design/navigation-map.md
3. Revisa el código actual y compáralo con las specs

Busca:
- Funcionalidad especificada en docs que no está implementada o incompleta
- Flujos de usuario que faltan validaciones, feedback, o estados de error
- Features parcialmente implementadas
- Oportunidades de mejora UX evidentes
- Datos que se recogen pero no se muestran
- Edge cases no cubiertos en flujos críticos

Resultado real: Detectó que las evaluaciones de alumnos no tenían flujo de entrega, que el progreso del estudiante no se mostraba en la UI, y que los exports de FUNDAE eran mocks.

El throttle: para que no se desmadre

Un aprendizaje importante: el primer día los scanners crearon 26 issues porque estaban haciendo el barrido inicial de todo el repo. Para evitar que la cola se descontrole, cada scanner tiene un throttle:

Antes de crear issues, cuenta cuántas issues abiertas hay con
label [tipo]. Si hay 10 o más, NO crees nuevas issues y termina.

Excepción: vulnerabilidades de seguridad críticas siempre se crean, independientemente del throttle.

El triaje automático

Un cron diario a las 10:00 revisa todas las issues sin prioridad y las clasifica automáticamente:

p1: vulnerabilidades activas (CVE), funcionalidad core que falta, bugs que bloquean
p2: mejoras de rendimiento, features útiles, tests de módulos críticos
p3: refactors, mejoras menores, optimizaciones de baja frecuencia

La clave es que asigna directamente las labels, no solo recomienda. Yo solo hago override si no estoy de acuerdo con alguna prioridad.

Además, genera un resumen diario con issues creadas, cerradas, commits y estado del smoke test.

El executor: el que trabaja

Este es el corazón del sistema. Se ejecuta cada hora y coge la issue de mayor prioridad para implementarla.

Proceso de selección (prioridad > tipo > antigüedad):
1. Busca issues p1. Si hay, selecciona según orden de tipo.
2. Si no hay p1, busca p2. Si hay, selecciona según orden de tipo.
3. Si no hay p2, busca p3.
4. Si no hay ninguna issue con prioridad, no hagas nada.

Orden de tipo dentro del mismo nivel de prioridad:
1. security (vulnerabilidades primero)
2. bug (errores funcionales)
3. feature (funcionalidad nueva o incompleta)
4. performance (optimización)
5. tests (cobertura)
6. architecture (refactors)
7. dx (developer experience)

Detalle importante: las features van antes que los refactors al mismo nivel de prioridad. No quiero que el agente se pase el día partiendo archivos en trozos cuando hay funcionalidad real pendiente.

El executor trabaja directamente en main (sin PRs), ejecuta lint + typecheck + tests antes de cada commit, y cierra la issue automáticamente con referencia al commit.

La red de seguridad: smoke tests

Cada 4 horas, un agente independiente verifica que todo sigue funcionando:

pnpm build
pnpm typecheck
pnpm test
pnpm lint
Verifica que los commits recientes cerraron correctamente sus issues

Si algo falla, crea una issue con label bug, p1 — y el executor la coge en la siguiente iteración. Las regresiones son siempre prioridad máxima.

Registra cada ejecución en docs/smoke-log.md para tener trazabilidad.

Resultado real: El primer día el smoke test detectó 7 regresiones en cadena. El executor las fue arreglando automáticamente una tras otra.

Los números

En 3 días de funcionamiento:

~80 issues creadas por los scanners
~50 issues cerradas por el executor
~60 commits automáticos
0 líneas de código escritas por mí
Las 5 issues p1 de seguridad se cerraron el mismo día
Funcionalidades core implementadas: evaluaciones de alumnos, progreso en UI, exports FUNDAE reales, sincronización de asistencia con Zoom

Qué he aprendido

Lo que funciona bien:

La separación scanner/executor es clave. El que detecta problemas NO debe ser el que los arregla. Evita sesgos.
Las herramientas deterministas (Semgrep, knip, madge, vitest coverage) complementan muy bien al LLM. El LLM pilla cosas que las herramientas no ven, y las herramientas tienen cero falsos negativos en sus patrones.
El throttle es imprescindible. Sin él, los scanners ahogan al executor con issues más rápido de lo que puede procesarlas.
El smoke test como red de seguridad funciona: pilló 7 regresiones que el executor introdujo al hacer cambios concurrentes.

Lo que hay que vigilar:

Las features core (funcionalidad nueva con lógica de negocio) necesitan revisión humana. El agente puede implementar mal un requisito y tú no te enteras si no revisas.
Los refactors p3 se acumulan. El executor siempre prioriza features y bugs, así que la deuda técnica “menor” crece. Hay que hacer purgas periódicas o dedicar un día a solo p3.
La calidad de los tests generados es cuestionable. Cubren código pero a veces las assertions son débiles. Mutation testing (Stryker) sería el siguiente paso para verificar que los tests realmente validan algo.

Velocidad: no es magia, son tus tokens

He estado aplicando esto durante 5 días, y muchos me preguntáis cómo aguantan los tokens. La realidad es que con una cuenta de 20$ de Codex no puedes mantener este ritmo.

Al final hay que decidir: velocidad vs precio, y encontrar un equilibrio.

A día de hoy yo me voy manejando con 2 cuentas de 20$ de ChatGPT (Codex), y creo que aún así se me van a quedar cortas. Esto teniendo en cuenta que ahora mismo los tokens de Codex App están duplicados.

Así que para tomárselo en serio e ir a una buena velocidad, parece bastante necesaria la cuenta de 200$.

¿Es esto el futuro?

Spotify acaba de publicar que sus mejores desarrolladores no escriben código desde diciembre gracias a herramientas como Claude Code y su sistema interno Honk. Mi experimento es mucho más modesto, pero apunta en la misma dirección: el rol del desarrollador pasa de escribir código a orquestar agentes.

No creo que estemos listos para dejar esto funcionando sin supervisión en proyectos críticos. Pero para un side project o una fase temprana de producto, la velocidad es absurda. 3 días de trabajo autónomo equivalen a lo que me habría llevado semanas hacer manualmente.

Si quieres replicarlo, los prompts son exactamente los que he compartido aquí. Si lo pruebas, cuéntame cómo te va.