PTENES
Saltar al contenido
MÓDULO 2.2

🔬 El verificador es el cuello de botella

El loop persigue lo que el verificador aprueba — nada más. Deja de escribir prompts, empieza a escribir verificadores: definen el límite de calidad de todo lo que produce el bucle, y este módulo muestra cómo construir un verificador que resista la carga.

6
Temas
40
Minutos
Intermedio
Nivel
Práctico
Tipo
Progreso de este módulo
0%0 de 6
1

🎯 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.
verificador aprobado el embudo solo entrega lo que el cuello de botella deja pasar

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

Cuello de botella

Define qué sale, no qué entra

Límite, no mínimo

Nada supera al verificador

La disciplina

Escribe verificadores, no prompts

Falso positivo

Parece bueno ≠ es bueno

2

🪜 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.
compila $ lint $ prueba automática $$ modelo evaluando $$$ humano $$$$$ el costo aumenta; cada nivel detecta un error diferente

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

Escalera

No es un verificador, son varios

Primero lo barato

Ejecuta lo barato en cada vuelta

Costoso al final

Solo cuando lo barato salió caro

Prefiere el determinismo

Prueba > modelo, cuando sea posible

3

🚫 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.
CONTEXTO SUCIO borrador + razonamiento + resultado, todo junto "se revisa" a sí mismo aprueba casi siempre CONTEXTO LIMPIO resultado + criterio revisor revisor separado, solo ve esto

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

Autor revisión

Aprueba casi siempre

Contexto limpio

Solo el resultado + el criterio

Revisor independiente

No ve el proceso

Puente hacia el grafo

Motivo concreto para existir por separado

4

📐 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.

1

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.

2

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.

3

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

Referencia

El «algo» con que se compara

Prueba

La referencia más estricta

Ejemplo aprobado

Referencia de estilo

Vago = suerte

«Que quede bien» no verifica nada

5

👁️ 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

Se pudre

Envejece incluso estando inactivo

Papel con papel

Deja de comprobar la realidad

Panel verde

Falsa confianza visual

Dueño

Alguien lo revisa periódicamente

6

✍️ 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

Primero, el verificador

Antes del prompt del agente

Caso incorrecto

Necesita fallar de verdad

Nunca rechaza = está roto

No está verificando

Se convierte en el del grafo

Puente hacia la Trilha 4

📌 Resumen del módulo

✓
El verificador es el límite — el loop persigue aquello que aprueba; nunca supera ese criterio.
✓
Escalera de verificadores — compilación, lint, prueba, evaluación del modelo, persona. Barato en cada vuelta, caro solo después.
✓
Nunca te revises a ti mismo — una revisión real exige un contexto limpio y un revisor independiente.
✓
Referencia concreta — una prueba, un ejemplo o una regla escrita. «Que quede bien» no verifica nada.
✓
Vigila al que vigila — el verificador se deteriora por sí solo; necesita un responsable y revisiones periódicas.
✓
Verificador antes del prompt — pruébalo a propósito con un caso desfavorable antes de confiar en él.

Próximo módulo:

2.3 — Dónde falla el ciclo: los fallos estructurales que ningún buen verificador puede resolver por sí solo.