Temario · lección 6 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
Arregla primero el harness
Cuando algo falla, no cambies de modelo: localiza qué capa del entorno falló y arréglala. El experimento del millón de líneas de OpenAI lo demuestra.
El coche que se para
Tu coche se detiene en mitad de la carretera. ¿Sospechas primero del motor? No: miras si tiene gasolina. Con los agentes funciona igual. Si el mismo modelo rinde bien en tareas parecidas y bien montadas, el problema suele estar en el entorno y no en el modelo.
Principio central: cuando algo falla, no cambies primero el modelo; revisa el harness.
Las cinco capas donde buscar
En lugar de decir «el modelo es malo», pregunta a qué capa pertenece el fallo:
| Capa | Pregunta |
|---|---|
| Especificación de la tarea | ¿Estaba claro qué hacer y cuándo terminar? |
| Contexto | ¿Tenía la información y las reglas a la vista? |
| Entorno de ejecución | ¿Podía arrancar, instalar y ejecutar sin problemas? |
| Verificación | ¿Tenía forma de comprobar su trabajo? |
| Estado | ¿Recordaba lo hecho en la sesión anterior? |
El bucle diagnóstico
Es el método central del curso, y es sencillo:
- Ejecuta la tarea.
- Observa el fallo.
- Atribúyelo a una capa concreta.
- Corrige esa capa.
- Vuelve a ejecutar.
Como reparar una carretera: cada bache que tapas hace más suave el tramo siguiente. Si además apuntas qué capa causó cada fallo, tras unas cuantas rondas verás cuál es tu cuello de botella y dónde gastar energía.
Escribe cuándo está «hecho»
Una de las correcciones más baratas es una Definition of Done (definición de terminado): condiciones que una máquina pueda comprobar. En lugar de «añade búsqueda», algo así:
Criterios de finalización:
- Nuevo endpoint GET /api/search?q=xxx
- Paginación, 20 resultados por defecto
- Los resultados incluyen fragmentos resaltados
- Todo el código nuevo pasa pytest
- Pasa la comprobación de tipos
Sin una definición explícita, el agente inventará la suya, y casi siempre será más cómoda que la tuya.
El experimento del millón de líneas
En agosto de 2025, tres ingenieros de OpenAI empezaron a construir un producto interno entero con Codex desde un repositorio vacío. La regla clave: los humanos no escribían código directamente. No era un truco; obligaba al equipo a descubrir qué cambia cuando tu trabajo deja de ser teclear y pasa a ser diseñar el entorno, expresar la intención y montar bucles de comprobación.
Cinco meses después el repositorio tenía alrededor de un millón de líneas; el equipo creció a siete personas y se fusionaron unas 1.500 propuestas de cambio (PRs).
Lo revelador está en el principio: el avance inicial fue más lento de lo esperado, no porque Codex no pudiera, sino porque el entorno estaba incompleto. Cuando algo fallaba, la solución casi nunca era «inténtalo con más fuerza». Era preguntar qué capacidad le falta al agente y cómo la hacemos comprensible y ejecutable.
Mide si mejoras
Lleva un registro sencillo: cada tarea, si salió bien o mal, y qué capa causó el fallo. Tres columnas bastan.
Un agente falla en una tarea. ¿Qué haces primero según el principio del curso?
Fuentes: Learn Harness Engineering, lección 01 · OpenAI, Harness engineering (citado en la lección)