Temario · lección 30 de 74
1Por qué fallan los agentes
2Qué es un harness
3Patrones de agentes
4Herramientas
5Ingeniería de contexto
6El repositorio como memoria
7Tareas largas
8Alcance y “hecho” de verdad
9Observabilidad y estado limpio
10Loops y grafos
11Harness reales
12Proyecto final
- Proyecto 1, solo prompt contra harness mínimo
- Proyecto 2, un workspace legible
- Proyecto 3, continuidad entre sesiones
- Proyecto 4, feedback de runtime e indexado
- Proyecto 5, que el agente verifique su trabajo
- Proyecto 6, el harness completo (capstone)
- Proyecto 7, tu primer loop automático
- Proyecto 8, dibuja tu flujo como un grafo
- Checklist final y plantillas
Dibuja el mapa del repo
Un buen mapa permite que un agente nuevo responda cinco preguntas sin ayuda humana. Compruébalo con la prueba de arranque en frío.
Llegar a una ciudad sin mapa
Llegas a una ciudad que no conoces. Sin mapa, adivinas calles, pierdes tiempo y a veces te metes en callejones sin salida. Con un mapa pequeño pero fiable, llegas.
Cada sesión nueva de un agente es llegar a esa ciudad. Tu repositorio es la ciudad, y falta saber si tiene mapa.
La prueba de arranque en frío
Abre una sesión completamente nueva, sin explicarle nada de palabra, solo con lo que hay en el repo, y comprueba si puede responder cinco preguntas:
| Pregunta | Dónde debería estar la respuesta |
|---|---|
| ¿Qué es este sistema? | AGENTS.md / README |
| ¿Cómo está organizado? | ARCHITECTURE.md / docs de módulos |
| ¿Cómo lo ejecuto? | Makefile, init.sh, scripts de package |
| ¿Cómo lo verifico? | Comandos de test, lint y check |
| ¿Dónde estamos ahora? | PROGRESS.md, lista de funciones, historial git |
Donde el mapa está en blanco, el agente adivina. Las malas conjeturas se convierten en bugs, y adivinar gasta contexto. Y como cada sesión empieza de cero, vuelve a adivinar todo cada vez. Dibujar bien el mapa sale más barato.
Cuatro principios para dibujarlo
- El conocimiento vive junto al código. Una regla sobre la API va al lado del código de la API, no en un documento global gigante. Como las etiquetas de estantería en una biblioteca.
- Un archivo de entrada estándar.
AGENTS.md(oCLAUDE.md) es la página de aterrizaje. Debe responder rápido qué es el proyecto, cómo se ejecuta y cómo se verifica. Con 50-100 líneas basta. - Mínimo pero completo. Si quitar una regla no cambia las decisiones del agente, sobra. Pero cada pregunta de la prueba debe tener respuesta.
- Se actualiza con el código. Si la documentación del módulo vive en su carpeta, la ves al tocar el código y te acuerdas de actualizarla.
Un ejemplo de estructura
project/
├── AGENTS.md # entrada: resumen, comandos, restricciones duras
├── src/
│ ├── api/
│ │ └── ARCHITECTURE.md # decisiones de la capa API
│ └── db/
│ └── CONSTRAINTS.md # restricciones de la base de datos
├── PROGRESS.md # hecho, en curso, bloqueado
└── Makefile # setup, test, lint, check
La checklist del curso añade preguntas útiles para repasar tu mapa: ¿qué producto se construye?, ¿qué debe hacer la app para los usuarios?, ¿cómo se inicia?, ¿cómo se comprueba que está sana?, ¿qué trabajo está en curso?, ¿qué estándares de calidad importan?
¿Para qué sirve la prueba de arranque en frío?
Fuentes: Learn Harness Engineering, lección 03 · Recursos del curso: system-of-record-checklist