Dale siempre a Claude una forma de verificar su propio trabajo, ya sean pruebas, una compilación o una comparación de capturas de pantalla. Una sesión revisa su propio trabajo y corrige sus propios errores antes de que un ingeniero los vea.
El ciclo de retroalimentación no debe confundirse con un subagente verificador (Etapa 3: Construcción). El ciclo de retroalimentación recorre toda la tarea tantas veces como el trabajo lo requiera. El subagente verificador, por otro lado, es una forma de empaquetar la verificación final ejecutando una ventana de contexto nueva una vez que la sesión cree que el trabajo está terminado. De esta manera, el veredicto no se ve influenciado por los supuestos que produjeron el código.
Qué cambia
| Tradicional | Nativo de IA |
|---|---|
| La señal de que el código funciona llega tarde. El CI minutos después, un probador días después, producción semanas después. Con un agente produciendo el código, una señal tardía significa que una persona tiene que revisar toda su salida, y esa persona se convierte en el cuello de botella. | A la sesión se le da una forma de revisar su propio trabajo antes de que una persona lo vea. Ejecuta las pruebas, ejecuta la compilación, toma la captura de pantalla. Claude itera hasta que la verificación pasa, de modo que lo que llega al ingeniero ya la ha superado. Configurar el ciclo recae en el ingeniero que ejecuta la sesión, y los pasos a continuación están escritos para esa persona. |
Primeros pasos
- Requisitos previos: Ninguno.
- Infraestructura: Un conjunto de pruebas y una compilación que se ejecuten localmente con un solo comando cada una. Para el trabajo de UI, es crucial que Claude tenga una forma de ver el resultado, ya sea una herramienta de navegador o una utilidad de capturas de pantalla conectada mediante MCP.
Cómo ejecutarlo
- Si hoy revisar el trabajo requiere una secuencia de comandos y algo de conocimiento del entorno, envuélvelo en un único objetivo como
make testonpm testque salga con un código distinto de cero en caso de fallo. - En la sección de Comandos de
CLAUDE.md, enumera cada comando con un ejemplo de una salida saludable. - Establece un objetivo y hazlo cuantificable para que Claude pueda revisar el trabajo sin preguntarte, por ejemplo: "Todas las pruebas en
test_status.pypasan", "la captura de pantalla coincide con el mockup adjunto" o "el endpoint devuelve 200 con el nuevo campo". - Para correcciones de errores, escribe primero la prueba que falla. Pídele a Claude que reproduzca el error como una prueba, que la ejecute y confirme que falla por la razón que esperas. Confirma (commit) esa prueba. Solo entonces pídele a Claude que la haga pasar sin editar la prueba, con el hook de archivos de prueba del paso final haciendo cumplir la restricción. Una prueba que existía antes de la corrección, y que el agente no pudo reescribir, es prueba de que el error desapareció.
- Para el trabajo de UI, cierra el ciclo con una verificación visual. Dale a Claude una herramienta de navegador o de capturas de pantalla, dale el mockup y deja que itere. Implementa, captura, compara y ajusta. Dos o tres rondas es normal, y el resultado debería mejorar con cada una.
- Haz que la verificación forme parte de "terminado". La instrucción vive en
CLAUDE.md: "Ejecuta las pruebas antes de reportar una tarea como completa, y muestra la salida". - Finalmente, el ciclo en sí necesita protección, porque un agente que corrige código no debe poder debilitar la verificación sobre ese código. Un hook que bloquea las ediciones a los archivos de prueba durante una tarea de corrección logra esto. La alternativa es revisar el diff y rechazar cualquier cambio que toque una prueba.
Cómo se ve
Bloque de verificación de CLAUDE.md:
markdown
## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)
Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.Consideraciones de gobernanza
- Qué se hace cumplir: La verificación antes de que una tarea se reporte como terminada, y el bloqueo a que el agente edite archivos de prueba durante una corrección, ambos implementados como hooks donde la organización quiere que estén garantizados.
- Cuál es la evidencia: La salida literal de
make test, el registro de la compilación, o la comparación de capturas de pantalla que Claude ejecutó y pegó, de modo que la evidencia proviene de la cadena de herramientas. - Dónde se registra: En la transcripción de la sesión, que la exportación de OpenTelemetry reenvía a la pila de observabilidad de la organización, y en la ejecución de verificación del PR, donde tanto el revisor como cualquier auditor posterior pueden verla.
- Quién aprueba: El propietario del código que revisa el PR, quien puede concentrarse en la intención y el riesgo porque la evidencia mecánica ya está adjunta.
Cómo medirlo
- Indicador adelantado: La tasa de éxito en el primer intento de CI para los cambios escritos por el agente, que el sistema de CI ya admite.
- Indicador rezagado: El tiempo de revisión por PR (a partir de los metadatos del PR), que debería disminuir una vez que las pruebas detecten lo que los revisores solían detectar, y la tasa de fallos de cambios de un rastreador de incidentes.