Maker y checker

El examen que te corriges tú

Haces un examen y luego te lo corriges tú mismo, sabiendo lo que querías decir. Te pondrás buena nota, no por mentir, sino porque al releerlo ves tu razonamiento y no tus fallos. Con los modelos pasa exactamente igual: el agente que escribió el código se ha convencido durante la generación de que el camino era bueno. Al revisarlo, no ve errores: ve su propio razonamiento.

No es un defecto de un modelo concreto, es una propiedad de los modelos generativos. Un modelo es el mejor abogado defensor de su propia salida.

Cómo se separa en la práctica

• En /goal de Claude Code, una sesión supervisora independiente decide si el objetivo se ha cumplido, no la que lo intentó.
• En Codex puedes definir un subagente verificador con otro modelo y otro nivel de razonamiento.
• Una práctica de la comunidad, la «verificación adversarial», lanza varios escépticos independientes por cada hallazgo, cada uno con la misión de refutarlo; si la mayoría lo rechaza, el hallazgo cae.

Dos prompts, dos actitudes

El maker se centra en que funcione. El checker se centra en encontrar problemas. El curso trae un prompt para cada uno. Resumidos:

# Maker
Tu trabajo es implementar. Lee AGENTS.md primero, explica tu plan antes de cambiar nada,
ejecuta build, lint y tests tú mismo, di lo que no sepas (no inventes) y apunta el progreso.
Entrega: archivos modificados, resumen, resultados de verificación y zonas inseguras.

# Checker
Tu trabajo es verificar lo que produjo el maker. No estás para elogiar: estás para encontrar fallos.
No encontrar problemas es tu fracaso. Revisa funcionalidad, calidad, tests, comandos y seguridad.
Cada problema lleva: descripción, ubicación (archivo:línea), evidencia y gravedad.
Cierra con un veredicto: Pasa / Falla / Problemas menores aceptables.

Fíjate en dos detalles del checker: la evidencia obligatoria (no vale «me parece raro») y el veredicto cerrado (el loop necesita una salida que pueda leer). Puedes combinarlo con la rúbrica del evaluador.

Un ejemplo real: autoresearch

El proyecto autoresearch de Karpathy es el ejemplo de manual de un loop bien diseñado. Son tres archivos con tres roles:

La idea: las personas no tocan el código, tocan la dirección; el agente no toca la dirección, toca el código. Cada iteración sigue un «trinquete» (solo avanza): lee la dirección, propone una hipótesis, edita, hace commit, entrena con un presupuesto fijo de 5 minutos, y evalúa una métrica. Si mejora, el commit se queda y se registra; si no, se revierte y se anota el fallo. Por la mañana encuentras un historial de git con solo las mejoras y un registro de todos los experimentos.

Lo más revelador: el loop está escrito en español (o inglés), no en código. program.md no es una tarea, es una metodología, y la metodología es el loop. Además, aquí el juez no es el agente: es una métrica fija e independiente, la versión más pura de separar quien hace de quien comprueba.

Reglas para tu primer par

1. El implementador lee la incidencia, escribe el arreglo y los tests.
2. El verificador ejecuta los tests por su cuenta, revisa el diff y juzga si realmente se resuelve.
3. Si falla, el problema vuelve al maker con la lista de evidencias.
4. Los resultados de cada ronda van a un archivo de estado.