AIDiveTL;DR
- La recomendación de Anthropic acierta en el fondo: el modelo con un bucle de feedback produce mejor trabajo. El problema es quién ejecuta el bucle. En 116 ejecuciones, el
/verifyintegrado devolvió PASS 24 de 24 veces, incluso en un cambio que rompía un requisito declarado. - Un modelo que revisa su propio cambio comparte su punto ciego. Haiku 4.5 falló el mismo caso de campo único en 11 de 11 ejecuciones, en todas las configuraciones con el mismo modelo, y su propio
/verifymarcó con un check el caso equivocado. - En Opus 5.5,
/verifycostó 2,5x ($0.96 frente a $0.39) y no cambió ningún resultado. Opus solo acertó 12 de 12 y ejecutó la suite de tests por su cuenta en 11 de esas ejecuciones. - Un skill de proyecto es opcional para el modelo: se activó en 10 de 24 ejecuciones, 0 de 6 con Haiku. Un Stop hook se activó en todas las ejecuciones por un 20 % más en Opus.
- La verificación que funcionó vino de alguien distinto al autor: el mismo
/verifyejecutado por Opus dijo FAIL 3 de 3 sobre el cambio de Haiku y nombró el bug. Conectado como Stop hook, hizo que Haiku corrigiera el bug 3 de 3 veces, a $1.36 por tarea frente a $0.76 de Opus escribiendo solo. - Copia esto: un Stop hook para la parte determinista, un verificador que no sea el autor para el juicio, y nada de
/verifyen Opus para trabajo bien especificado.
Qué dicen las mediciones
La afirmación de Anthropic: «Si Claude tiene ese bucle de feedback, multiplicará por 2-3 la calidad del resultado final». s4 El blog lo convierte en un flujo de adopción de 5 pasos: elegir tu comprobación manual más repetida, probar el /verify integrado, escribir el procedimiento en lenguaje llano como skill, hacerlo determinista y después moverlo a CI. s1 Desde la v2.1.215, «Claude ya no ejecuta por su cuenta los skills /verify y /code-review; invócalos con /verify o /code-review cuando los quieras». s3
Los reportes de campo hablan de verificación declarada pero no ejecutada. El issue #96416 es un veredicto de revisión con 19 preocupaciones, 5 verificadas, y un «accept as-is» emitido igualmente. s6 El issue #97039 es una afirmación «held up» tras comprobaciones parciales a pesar de tener una checklist cargada. s7 «El build pasa» y «listo para producción» son listones distintos, y cada fallo cuesta 2-3 rondas de reprompt. s8
Nuestro banco puntuó cada «done» con tests de aceptación ocultos que el agente nunca vio. 112 ejecuciones de tareas + 4 ejecuciones /verify entre modelos = 116 ejecuciones, $66.29 de gasto equivalente en API. Falsos «done»: 12 de 112, 11 de ellos de Haiku en T6 en todas las configuraciones A a E, 1 de Sonnet en T6 con el skill, donde sus propios tests nuevos fallaban y el skill nunca se activó. s1
El /verify integrado dijo Verdict: PASS en 24 de 24 ejecuciones con los tres modelos (23 interpretables, 1 pass sin etiqueta), incluido el T6 roto de Haiku. En Opus costó $0.96 frente a $0.39 sin él (2,5x) y 125 s frente a 75 s; no cambió ningún resultado. s3
El skill de proyecto escrito según el flujo de 5 pasos se invocó en 10 de 24 ejecuciones: Opus 8/12, Sonnet 2/6, Haiku 0/6. El Stop hook se activó en todas, a $0.47 frente a $0.39 en Opus (+20 %). s19
El punto ciego es un solo requisito, T6 req. 4: un único update que da el mismo valor único a varios documentos coincidentes debe lanzar DuplicateKeyError. Haiku lo falló en 11 de 11 ejecuciones, en todas las configuraciones (plain, /verify, skill, hook, tests primero). El /verify de Haiku comprobó «update de un doc al email de otro» y nunca probó un update que afecte a varios documentos. La regla de tests primero no ayudó: 3/3 siguen fallando el req. 4, y uno además rompió el req. 3. s1
El mismo cambio de Haiku, con /verify ejecutado por otro modelo: Sonnet dijo PASS (1/1), Opus dijo FAIL 3/3, cada ejecución nombrando el mismo caso, un update que escribe el mismo valor en varios documentos, a $0.39 a $0.47 por comprobación. Como Stop hook sobre Haiku (configuración F), el verificador Opus consiguió que el bug se corrigiera en 3 de 3 ejecuciones; las tres llegaron al límite de 60 turnos al corregir, con una media de $1.36 por ejecución de T6 incluido el verificador, frente a $0.76 de Opus escribiendo T6 solo con 0 falsos «done». s19
Mediciones
Banco: Claude Code 2.1.283 headless (claude -p), directorio de config aislado, mismo prompt por tarea, límite de 60 turnos. Repo: msiemens/tinydb @ 18d73a1 (Python, 226 tests). Seis peticiones de funcionalidad T1 a T6 con 5 requisitos declarados cada una (T5: 6). Tests de aceptación ocultos, uno por requisito declarado y nunca mostrados al agente, puntúan cada ejecución; la suite del propio repo también corre. Un falso «done» es una ejecución que termina afirmando que acabó mientras un test oculto o la suite del repo falla.
Configuraciones: A plain (solo la petición); B /verify (A, y luego el /verify integrado como segundo turno); C skill verify (un skill de proyecto invocable por el modelo, escrito según el flujo de 5 pasos); D Stop hook (prove-it.py: bloquea la parada mientras la suite está en rojo, y bloquea la primera parada pidiendo una línea de evidencia por requisito); E tests primero (una regla de CLAUDE.md: un test que falle por requisito antes de cualquier código); F hook verificador Opus (claude -p /verify --model opus sobre el cambio, bloquea con un veredicto distinto de PASS, máximo 2 rondas).
| modelo | configuración | ejecuciones | falso done | coste medio | turnos medios | tiempo medio |
|---|---|---|---|---|---|---|
| Opus 5.5 | A plain | 12 | 0 | $0.39 | 16.6 | 75 s |
| Opus 5.5 | B /verify | 12 | 0 | $0.96 | 22.3 | 125 s |
| Opus 5.5 | C skill | 12 | 0 | $0.43 | 19.5 | 80 s |
| Opus 5.5 | D hook | 12 | 0 | $0.47 | 19.8 | 94 s |
| Opus 5.5 | E tests primero | 2 (T6) | 0 | $0.64 | 18.5 | 129 s |
| Sonnet 5 | A | 7 | 0 | $0.44 | 24.0 | 112 s |
| Sonnet 5 | B | 6 | 0 | $1.18 | 36.3 | 210 s |
| Sonnet 5 | C | 7 | 1 | $0.48 | 25.7 | 136 s |
| Sonnet 5 | D | 6 | 0 | $0.53 | 27.0 | 157 s |
| Haiku 4.5 | A | 8 | 3 | $0.34 | 35.4 | 172 s |
| Haiku 4.5 | B | 6 | 1 | $0.68 | 43.3 | 217 s |
| Haiku 4.5 | C | 6 | 1 | $0.26 | 28.2 | 124 s |
| Haiku 4.5 | D | 8 | 3 | $0.37 | 38.9 | 179 s |
| Haiku 4.5 | E | 3 (T6) | 3 | $0.41 | 38.3 | 186 s |
| Haiku 4.5 | F verificador Opus | 3 (T6) | 0 | $1.36 verificador incluido | 61 (límite) | 457 s |
| Sonnet 5 | F | 1 (T6) | 0 | $2.30 verificador incluido | 50 | 512 s |
Límites: un solo repo (una biblioteca Python pequeña y bien testeada), seis peticiones bien especificadas, 1 a 3 repeticiones por celda, ejecuciones headless. Los tests ocultos solo comprueban lo que la petición declara.
Haz esto el lunes
- Escribe tú mismo un test de aceptación por requisito declarado, antes de leer el «done» del modelo. Los tests ocultos del banco atraparon lo que toda comprobación del mismo modelo pasó por alto.
- Añade un Stop hook que ejecute tu suite de tests y devuelva una decisión block mientras esté en rojo. Se activa en todas las ejecuciones; un skill no.
- Haz que la primera parada de una tarea cueste una línea de evidencia por requisito (el patrón
prove-it.py): un comando y su salida, no una frase. - Lleva la comprobación de juicio a un modelo que no escribió el cambio:
claude -p /verify --model opussobre el diff, bloqueando con un veredicto distinto de PASS, con tope de 2 rondas. - En Opus 5.5 con una petición bien especificada, deja de escribir
/verifypor costumbre. Costó 2,5x y no cambió nada en 12 ejecuciones; resérvalo para una zona sin tests o la caza de un bug preexistente. - Si delegas en Haiku 4.5 por coste, presupuesta el verificador: $1.36 por tarea con el hook de Opus frente a $0.76 de Opus escribiendo solo.
- Registra cada reintento de un arreglo fallido en un ledger y detén el bucle tras una repetición, para que un hook bloqueante no gaste tokens en el mismo parche erróneo.
- Relee tus requisitos pensando en el caso multifila: «un update que coincide con varios documentos» es la forma del caso que 11 de 11 ejecuciones de Haiku nunca probaron.
Para ir más lejos
- El flujo de 5 pasos y la escalera de madurez, de la comprobación manual a la CI: los peldaños altos (CI y gates de PR) son donde va la parte determinista una vez que tu hook funciona en local. s1
- Semántica del Stop hook: una decisión block con motivo devuelve el turno al modelo; lee el contrato de códigos de salida y JSON antes de escribir tu propio gate. s19
- Groundtruth, un Stop hook que rechaza el fin del turno hasta que pasen las comprobaciones: la versión determinista de la idea, lista para leer como implementación de referencia. s5
- regressionledger, el lado del coste: un hook que impide que el bucle reintente el mismo arreglo fallido, la pieza que a nuestro Stop hook le faltaba cuando las ejecuciones llegaron al límite de 60 turnos. s10
Fuentes
- Building verification loops in Claude Code with skills, Anthropic blog. Por qué leerlo: el flujo de 5 pasos y la escalera sobre los que se construyó el skill del banco.
- Building verification loops in Claude Code, official Claude channel. Por qué leerlo: tres minutos sobre lo que hace
/verifyen su primera ejecución, antes de decidir si lo conservas. - Claude Code CHANGELOG, GitHub. Por qué leerlo: la v2.1.215 es donde
/verifypasó a invocarse solo por el usuario, lo que cambia cuánto se ejecuta en tu caso. - Boris Cherny: give Claude a way to verify its work, X. Por qué leerlo: la afirmación de «2-3x la calidad», con su redacción exacta.
- Groundtruth, GitHub. Por qué leerlo: un gate de Stop hook funcional para copiar en vez de escribir el tuyo desde cero.
- Issue #96416, GitHub. Por qué leerlo: una transcripción fechada de un veredicto de revisión que verificó 5 de 19 preocupaciones y aceptó igualmente.
- Issue #97039, GitHub. Por qué leerlo: el mismo fallo dos días después con una checklist cargada, así que la checklist no es la solución.
- AI coding agents can verify some of their work now, dev.to. Por qué leerlo: el enunciado más claro de la brecha entre «el build pasa» y «listo para producción».
- Saguaro, GitHub. Por qué leerlo: el debate entre revisión dentro del bucle y a nivel de PR, con el contraargumento en los comentarios.
- regressionledger, GitHub. Por qué leerlo: el problema de coste de reintentos que crea un hook bloqueante, y una forma de limitarlo.
- SPICE simulation to oscilloscope to verification with Claude Code, personal blog. Por qué leerlo: un bucle de verificación cuyo oráculo es un instrumento físico.
- Hooks reference, code.claude.com. Por qué leerlo: el contrato de la decisión block que tu Stop hook debe respetar.
FAQ
¿El /verify integrado detecta bugs?
No en este banco. Devolvió PASS en 24 de 24 ejecuciones con Opus 5.5, Sonnet 5 y Haiku 4.5, incluido un cambio de Haiku que rompía un requisito declarado. Su único hallazgo útil fue un bug upstream preexistente sin relación con el cambio.
¿Por qué un verificador más fuerte ayuda a un autor más débil?
La comprobación de Haiku probó el caso en el que ya había pensado. Opus, con el mismo cambio y el mismo /verify, probó un update que afecta a varios documentos y dijo FAIL 3 de 3. Sonnet dijo PASS. El verificador tiene que ver un caso que el autor no vio.
¿Es más barato verificar a Haiku con Opus, o escribir con Opus?
Escribir con Opus. El hook verificador de Opus sobre Haiku costó una media de $1.36 por ejecución de T6 y llegó al límite de 60 turnos siempre; Opus escribiendo T6 solo costó una media de $0.76 con 0 falsos «done».