🎯 Acepta que el verificador es el límite
En el tema 5 del módulo anterior viste el paso verificar del loop descubrir/planificar/actuar/verificar/detenerse. Este módulo entero trata sobre ese único paso, porque él define lo que el loop persigue. El bucle no se detiene en lo que querías — se detiene en lo que aprobó el verificador. Si el verificador acepta cualquier cosa, el bucle entrega cualquier cosa.
🆕 ¿Nuevo aquí? Dos palabras antes de seguir
- Verificador: cualquier cosa que comprueba si un resultado es bueno — puede ser código (una prueba), otro modelo de IA o una persona.
- Límite de calidad: el mejor resultado posible que ese sistema puede producir. Ningún bucle supera el criterio que lo aprueba.
Qué observar: seis intentos arriba, una franja estrecha abajo. No importa cuántas vueltas dé el loop de acción: lo que sale está determinado por el ancho del cuello de botella, no por la cantidad de intentos. Un verificador amplio (acepta casi todo) deja pasar basura; uno demasiado estricto bloquea el loop para siempre.
✓ Combinación que funciona
- ✓Prompt mediocre + verificador óptimo — el loop tantea, pero el cuello de botella bloquea lo malo
- ✓Criterio escrito antes de ejecutar la primera vuelta
- ✓Verificador que sabe decir «no» con frecuencia
✗ Combinación que falla
- ✗Prompt óptimo + verificador débil — converge hacia algo que solo parece bueno
- ✗Criterio de «que quede bien», decidido en el momento
- ✗Verificador que aprueba casi todo lo que recibe
Conceptos clave
Define qué sale, no qué entra
Nada supera al verificador
Escribe verificadores, no prompts
Parece bueno ≠ es bueno
🪜 Apila la escalera de verificadores
No existe un solo verificador. Existe una escalera: compilar → lint → prueba automatizada → otro modelo que juzga → una persona. Cada paso cuesta más y detecta un tipo distinto de error: compilar detecta errores de sintaxis, la prueba detecta errores de lógica, y la persona detecta errores de criterio que ninguna máquina ve.
🆕 ¿Nuevo aquí? Tres palabras antes de seguir
- Lint: herramienta que revisa el estilo y los errores comunes de código sin ejecutar el programa — más rápida que una prueba.
- Determinista: mismo input, mismo output, siempre. Una prueba automatizada y determinista.
- LLM-as-judge (modelo que evalúa): usar un segundo modelo de IA para evaluar el resultado del primero: es probabilístico y puede variar entre ejecuciones.
Qué observar: la subida de izquierda a derecha. Compilar y hacer lint cuestan casi nada y son deterministas: ejecútalos en cada vuelta del loop. La evaluación del modelo y la humana cuestan caro y tardan más; resérvalas para los casos que ya pasaron por los escalones baratos. Determinista > probabilístico siempre que haya una opción: solo sube la escalera cuando el escalón de abajo no puede detectar el error que buscas.
📊 Dónde cada peldaño detecta el error
- Compila — sintaxis incorrecta, falta un import
- Lint — patrón de código, variable sin usar, indicio de bug
- Prueba automatizada — lógica incorrecta en un caso conocido
- El modelo juzgando — tono, coherencia, adhesión a un estilo
- Humano — criterio de negocio, contexto que ninguno de los anteriores tiene
Conceptos clave
No es un verificador, son varios
Ejecuta lo barato en cada vuelta
Solo cuando lo barato salió caro
Prueba > modelo, cuando sea posible
🚫 No dejes que califique su propio trabajo
¿El mismo agente, en la misma conversación, escribe y después “revisa” su propio trabajo? Casi siempre lo aprueba. No es pereza ni malicia: es que todo el razonamiento que produjo ese resultado sigue ahí al lado, en la misma ventana de contexto, inclinando el juicio hacia «está bien». Una revisión de verdad exige contexto limpio.
🆕 ¿Nuevo aquí? Una palabra antes de seguir
- Contexto limpio: quien evalúa solo ve el resultado final y el criterio de aprobación — no el borrador, no el razonamiento, no los intentos anteriores.
Qué observar: la línea divisoria punteada del medio. A la izquierda, todo vive en el mismo cuadro y la flecha vuelve sobre sí misma: no hay una separación real entre quien produjo y quien evalúa. A la derecha, solo el resultado y el criterio cruzan la frontera; el revisor nunca ve el borrador ni el razonamiento. Esa separación —contexto limpio, revisor distinto— es exactamente lo que un grafo entrega gratis (cada nodo con su propio contexto) es lo que a un solo loop le cuesta hacer por sí solo. La Trilha 3 ofrece la comparación completa; aquí solo queda el motivo.
⚠️ Atención: “déjame revisar mi propio trabajo” no existe gratis
Esto también nos pasa a nosotros: seguro releíste un texto tuyo en la misma sesión sin ver el error que un colega encontró en cinco segundos. Con un modelo de IA, el efecto es igual o peor: tiene acceso literal a su propio razonamiento, así que la “revisión” se convierte solo en una segunda pasada por el mismo camino de pensamiento.
Conceptos clave
Aprueba casi siempre
Solo el resultado + el criterio
No ve el proceso
Motivo concreto para existir por separado
📐 Elige la referencia
Todo verificador compara el resultado con algo. Ese algo es la referencia: una prueba que pasa, un ejemplo aprobado de antemano, una regla escrita, un número objetivo. Sin una referencia concreta, la verificación se convierte en opinión, y la opinión cambia de humor entre una vuelta y otra del loop.
Referencia concreta: prueba que pasa
"Esta función debe devolver 42 para esta entrada." Sí o no, sin punto medio.
El loop sabe exactamente cuándo parar. No queda ninguna ambigüedad para el juicio.
Referencia por ejemplo: un caso aprobado antes
"Debe sonar como este correo que el equipo ya aprobó." Menos rígido, pero aún basado en algo real.
Funciona bien cuando «correcto» tiene más que ver con el estilo que con un número exacto.
Sin referencia: “que quede bien”
Ningún número, ningún ejemplo, ninguna regla: solo una sensación.
El verificador se convierte en una moneda al aire: hoy aprueba lo que mañana rechazaría. El ciclo converge por suerte, no por calidad.
💡 Consejo práctico
Antes de escribir el verificador, escribe una frase con este formato: “el resultado es correcto si ___”. Si no puedes completar la frase con algo que se pueda comprobar (número, prueba, ejemplo, regla), todavía no tienes un verificador: tienes una esperanza.
Conceptos clave
El «algo» con que se compara
La referencia más estricta
Referencia de estilo
«Que quede bien» no verifica nada
👁️ Vigila al vigilante
El verificador se deteriora con el tiempo, incluso si nadie lo modifica. Las pruebas dejan de cubrir lo que cambió en el código. Los datos de ejemplo envejecen. La definición de una métrica cambia por debajo, en otro sistema, y nadie le avisó al verificador. La verificación pasa de comprobar a realidad para solo comparar papel con papel — y el panel sigue en verde todo el tiempo.
🎯 El síntoma clásico
Panel verde, mal resultado real.
Si el verificador desaparece de tu atención después de escribirlo —se convierte en “código heredado que nadie toca”—, va a seguir aprobando según el criterio antiguo mientras el mundo cambia a su alrededor. Es el mismo mecanismo del tema 5 del módulo anterior: las métricas se convierten en objetivos y, sin mantenimiento, el objetivo deja de representar lo que realmente importa.
⚠️ Atención: un verificador sin responsable no se actualiza por sí solo
Alguien tiene que revisar el verificador cuando cambie el proceso: nueva regla de negocio, nuevo formato de datos, nuevo caso de uso. Trata el verificador como código de producción: tiene responsable, changelog y revisión periódica. Un verificador olvidado es peor que no tener ninguno, porque te da una falsa confianza.
✓ Verificador activo
- ✓Se revisa cuando cambia el proceso real
- ✓Falla de vez en cuando (señal de que todavía está activo)
- ✓Tiene un responsable asignado
✗ Verificador deteriorado
- ✗Escrito una vez, nunca revisado
- ✗Siempre verde, nunca falla
- ✗Nadie recuerda por qué existe la regla
Conceptos clave
Envejece incluso estando inactivo
Deja de comprobar la realidad
Falsa confianza visual
Alguien lo revisa periódicamente
✍️ Escribe el verificador antes del prompt
La misma lógica de escribir la prueba antes del código. Escribe el verificador antes del prompt del agente y pruébalo contra un resultado malo a propósito. Un verificador que nunca rechaza nada no está verificando — solo está poniendo un sello. Ese verificador luego se convierte en un en el de tu grafo: la Ruta 4 muestra cómo.
✓ Orden correcto
- ✓1. Escribe el verificador
- ✓2. Pruébalo con un caso malo conocido — debe fallar
- ✓3. Solo entonces escribe el prompt del agente
✗ Orden que sale mal
- ✗Escribe primero el prompt, mira qué sale, verifica “a simple vista”
- ✗Escribe el verificador solo para confirmar lo que ya salió bien
- ✗Nunca prueba el verificador con un caso malo
🧪 Ejemplo práctico: prompt listo para Claude Code
Objetivo: pídele a Claude Code que escriba el verificador ANTES de escribir el prompt del agente que va a verificar — y que fuerce un caso de prueba malo junto con él.
Antes de escrever qualquer prompt de agente, escreva o VERIFICADOR para a tarefa <descreva a tarefa, ex: "resumir um artigo em ate 5 bullets">. O verificador deve: 1. Ser um script/funcao deterministica sempre que possivel (nao outro modelo). 2. Definir a referencia por escrito: o que torna o resultado aprovado (ex: "tem no maximo 5 bullets", "cada bullet tem menos de 30 palavras", "nenhum bullet repete a frase de outro"). 3. Retornar aprovado/reprovado + o motivo. Depois, crie um CASO RUIM DE PROPOSITO: um resultado que claramente viola a referencia (ex: 12 bullets, ou bullets repetidos). Rode o verificador contra esse caso ruim. So depois disso, escreva o prompt do agente que vai gerar o resultado de verdade.
Cómo verificar: ejecuta el verificador contra el caso malo a propósito. Si aprobar en el caso malo, el verificador está roto: vuelve y reescribe la referencia antes de continuar. Avanza al prompt del agente solo después de que el verificador rechace correctamente el caso malo e aprobar un caso bueno conocido.
Ahora cámbialo por el tuyo: reemplaza
<descreva a tarefa> por tu tarea real y la lista de criterios según
tus criterios de aceptación. Guarda el caso defectuoso: se convertirá para siempre en una prueba de regresión del verificador.
Verificación rápida (no bloquea nada): probaste tu verificador con un caso malo a propósito y aprobó el caso malo. ¿Qué significa eso?
Conceptos clave
Antes del prompt del agente
Necesita fallar de verdad
No está verificando
Puente hacia la Trilha 4
📌 Resumen del módulo
Próximo módulo:
2.3 — Dónde falla el ciclo: los fallos estructurales que ningún buen verificador puede resolver por sí solo.