AIDiveSe calificó solo: PASS
La verificación integrada de Claude Code, /verify, devolvió PASS en una función que estaba rota. Ese es el resultado de un banco de 116 sesiones de Claude Code sobre un repositorio real, donde cada "listo" fue calificado después con tests de aceptación que el agente nunca vio.
Boris Cherny, el creador de Claude Code, dice que la verificación es lo más importante que se le puede dar. El check integrado solo se ejecuta a pedido desde Claude Code v2.1.215: hay que escribir /verify, o no corre. En este banco dijo PASS en 24 de 24 corridas, y una de esas corridas había entregado una función rota. Qué fue lo que sí detectó el bug se cuenta más abajo, junto con la configuración que costó dos veces y media más y no cambió nada.
La prueba: 116 corridas, tests que nunca vio
Un "listo" falso es una sesión que termina afirmando que el trabajo está terminado mientras un test de aceptación oculto, o la propia suite del repositorio, falla. El banco mide con qué frecuencia ocurre eso bajo seis configuraciones de verificación.
La duda detrás de esto viene del propio issue tracker de Claude Code: el issue #96416, presentado el 2026-09-23, describe una revisión que listó 19 puntos, verificó 5 de ellos y aun así concluyó "accept as is" ("aceptar tal cual").
| Parámetro | Valor |
|---|---|
| Repositorio | msiemens/tinydb (base de datos de documentos en Python), commit 18d73a1 |
| Suite de tests del repositorio | 226 tests |
| Solicitudes de función | 6, cada una con 5 requisitos |
| Tests de aceptación ocultos | uno por cada requisito, escritos antes de cualquier corrida, nunca mostrados al agente |
| Modelos | Opus 5.5, Sonnet 5, Haiku 4.5 |
| Claude Code | 2.1.283, headless (claude -p), tope de 60 turnos |
| Sesiones | 112 corridas de tareas + 4 corridas cruzadas de /verify = 116 |
| Gasto | $66.29 equivalente en API |
Las seis configuraciones van desde Claude Code puro (solo la solicitud) hasta un segundo modelo que revisa el trabajo al terminar:
| Configuración | Qué agrega |
|---|---|
| A plano | nada |
| B /verify | el /verify integrado, escrito como segundo turno |
| C skill de verify | un skill de proyecto escrito siguiendo el flujo de Anthropic |
| D Stop hook | un script que bloquea el cierre mientras la suite está roja y pide evidencia por cada requisito |
| E tests primero | una regla en CLAUDE.md: un test que falle por cada requisito antes de escribir código |
| F verificador Opus | un Stop hook que corre /verify con Opus sobre el cambio |
Las solicitudes claras sobre una biblioteca bien testeada son el caso fácil. Opus 5.5 puro acertó las 12 de sus corridas, y corrió la suite de tests por su cuenta en 11 de ellas.
El /verify integrado: PASS, siempre, 2.5x
/verify es el skill de verificación que viene con Claude Code. Ejecuta el cambio, lee el diff y escribe un veredicto paso a paso. Desde v2.1.215 solo lo invoca el usuario, así que en el banco se escribió después de cada tarea como un segundo turno.
Devolvió un veredicto PASS en 24 corridas de 24 entre los tres modelos, incluyendo el cambio roto de Haiku. En Opus 5.5 no cambió ningún resultado y costó 2.5 veces más:
| Opus 5.5, por tarea | Plano | Con /verify |
|---|---|---|
| Costo | $0.39 | $0.96 |
| Tiempo real | 75 s | 125 s |
| Resultados cambiados | 0 de 12 |
Para ser justos, /verify encontró un bug real: en una tarea de Opus marcó un problema de reuso tras cierre que ya estaba en la biblioteca, no causado por el cambio que estaba revisando. En trabajo que ya estaba correcto, es una segunda opinión cara.
Skill o hook: el que se salta
Un skill es un procedimiento en markdown que Claude puede abrir cuando lo considera relevante. El post del blog de Anthropic sobre bucles de verificación describe una receta de seis pasos: elegir el seguimiento manual que más se repite, probar primero el /verify integrado, escribir el procedimiento en lenguaje simple, convertirlo en un skill, y luego invocarlo en una tarea nueva e iterar. El skill del banco, verify-change, se construyó exactamente así e indica a Claude que compruebe cada requisito contra el código real antes de decir que terminó.
Un skill es una sugerencia, y Claude decide si lo abre:
| Modelo | Sesiones que abrieron el skill |
|---|---|
| Opus 5.5 | 8 de 12 |
| Sonnet 5 | 2 de 6 |
| Haiku 4.5 | 0 de 6 |
| Total | 10 de 24 |
El único "listo" falso de Sonnet vino de una sesión donde el skill nunca se abrió: terminó con dos de sus propios tests nuevos fallando.
Un Stop hook es un script que Claude Code ejecuta cada vez que el agente intenta terminar. Puede rechazar el cierre y devolver al agente con un motivo. El hook del banco corre la suite de tests, bloquea mientras está en rojo, y en el primer intento de cierre pide una línea de evidencia por cada requisito. Se activó en todas las sesiones. En Opus costó 20% más, $0.47 contra $0.39 por tarea (94 s contra 75 s). En este banco nunca se encontró con una suite en rojo al momento de cerrar, así que no tuvo nada que atrapar: un hook siempre se activa, pero solo revisa lo que se le dijo que revisara.
El punto ciego: 11 de 11 falladas
La tarea que falló pedía campos únicos en una tabla: dos usuarios no pueden compartir un email, y cualquier actualización que dejara a dos documentos con el mismo valor único debe lanzar DuplicateKeyError.
Haiku 4.5 probó mover a un usuario al email de otro usuario, y eso fue rechazado correctamente. Nunca probó una actualización que coincide con varios documentos y escribe el mismo email nuevo en todos ellos. Ese caso pasó sin error en 11 sesiones de Haiku sobre 11, en cada configuración con el mismo modelo: plana, /verify, el skill, el Stop hook y tests primero.
El propio /verify de Haiku marcó el caso que había probado y escribió PASS. El test oculto reportó DID NOT RAISE DuplicateKeyError. Sonnet 5, al que se le pidió correr /verify sobre el mismo cambio, también devolvió PASS. Opus y Sonnet escribieron esta función correctamente por su cuenta, así que esto es un modelo en una tarea, pero un check escrito por la misma mente comparte su punto ciego.
El check externo: Opus dice FAIL
El mismo /verify, sobre el mismo cambio de Haiku, corrido por Opus 5.5, devolvió FAIL en 3 corridas de 3, nombrando cada vez el caso que faltaba: una actualización que coincide con varios documentos escribe el mismo valor en todos ellos sin error. La detección vino de un modelo distinto, no del autor ni del propio check del autor.
Cableado como Stop hook (configuración F), Opus revisa el trabajo de Haiku cada vez que Haiku intenta terminar. Los resultados:
| T6, por corrida | Haiku + verificador Opus | Solo Opus 5.5 |
|---|---|---|
| Bug corregido / "listo" falso | corregido en 3 de 3 | 0 "listo" falso |
| Turnos | tope de 60 turnos alcanzado en cada corrida | |
| Costo | $1.36 incluyendo el verificador | $0.76 |
El control externo funciona. En esta tarea costó más que el modelo más fuerte escribiendo la función solo.
Qué copiar, y qué cuesta
Dejen de permitir que el modelo que escribió un cambio sea el único que lo revisa.
| Regla | Por qué | Costo en este banco |
|---|---|---|
| Mantener un Stop hook para todo lo que un script pueda revisar | se activa en cada sesión | alrededor de 20% más en Opus |
| Hacer que el control real venga de fuera del autor: un modelo más fuerte en la puerta, o tests propios escritos a partir de la solicitud | el mismo modelo falló su propio bug 11 veces de 11 | $1.36 por tarea para Haiku + verificador Opus |
En una solicitud clara con Opus, saltarse escribir /verify |
0 resultados cambiados | 2.5x el costo, 125 s contra 75 s |
Los límites: una biblioteca pequeña, seis solicitudes claras, de una a tres corridas por celda, sesiones headless, y tests ocultos que revisan solo lo que cada solicitud declara. En trabajo más desordenado, los números se moverán.
