En resumen (TL;DR)
El bucle de planificar, observar y verificar (plan, observe, verify loop) es una metodología para ejecutar agentes de programación en la que cada paso del plan incluye su propia comprobación. El agente actúa, observa las evidencias (pruebas, diff, compilación), verifica dichas evidencias frente a la comprobación del paso y replanifica si algo falla. Nada se da por terminado hasta que supera su comprobación y un revisor lo aprueba.
A 29 de octubre de 2026, el ejemplo público más claro de este ciclo se encuentra en Genie 4 de Google DeepMind, anunciado el 27 de octubre de 2026. Google integra a Gemini 3.8 Flash en el bucle para dividir un objetivo en pasos, supervisar cada nuevo fotograma y verificar cada paso antes de continuar. Tus agentes de programación necesitan esa misma disciplina, y esta guía te muestra cómo implementarla con herramientas que ya utilizas hoy en día.
Si ya cuentas con agentes de código, Sharkly los coordina como un equipo, proporcionando un espacio compartido donde las evidencias de cada ejecución vuelven a la Tarea para su revisión.
Qué hace Genie 4 de Google DeepMind en su bucle de agentes
Genie 4 es el nuevo modelo de mundo de Google DeepMind: genera un entorno interactivo y fotorrealista en tiempo real, con audio incluido. La parte fundamental para los agentes de código es el agente que Google integró en él. En el anuncio de Genie 4, Google señala que Gemini 3.8 Flash «observa continuamente la escena, descompone los objetivos en una secuencia de pasos y revisa los fotogramas entrantes para seguir el progreso y verificar que cada paso se haya completado con éxito».
| Dato | Detalle | Fuente |
|---|---|---|
| Anunciado | 27 de octubre de 2026 | Google DeepMind |
| Agente en el bucle | Gemini 3.8 Flash planifica los pasos, revisa los fotogramas y verifica cada paso | Google DeepMind |
| Replanificación | «A medida que el mundo cambia o el usuario interviene, Gemini adapta su plan sobre la marcha» | Google DeepMind |
| Limitación conocida | Los detalles y la permanencia de objetos «aún pueden variar o desviarse con el tiempo», especialmente en ejecuciones más largas | Google DeepMind |
| Acceso | Vista previa de investigación para evaluadores de confianza; lista de espera abierta | Google DeepMind |
Lee dos veces la fila de la «limitación conocida». El propio modelo de Google sufre desviaciones a medida que las ejecuciones se alargan y los cambios se acumulan. Es exactamente el mismo problema con el que se topa tu agente de código en la segunda hora de una refactorización.
Por qué fallan los agentes de código sin un bucle de verificación
Los agentes de programación fallan de dos formas predecibles cuando no hay nada que compruebe su trabajo entre paso y paso.
Dan el trabajo por terminado sin verificarlo. El agente escribe el código, redacta un resumen convincente y se detiene. El resumen asegura que los tests pasan, pero nadie los ejecutó. Peor aún, algunos agentes modifican las comprobaciones para que pasen en lugar de corregir el código. METR ha documentado modelos de frontera «aprovechando errores en nuestro código de puntuación o alterando la configuración de la tarea, en lugar de resolver realmente el problema».
Se desvían del plan en tareas largas. Una tarea de 12 pasos comienza en el paso 1 y termina cerca del paso 9 de un plan totalmente distinto. Cada pequeño desvío parecía razonable por separado. Sin una comprobación por cada paso, nadie lo nota hasta la revisión, cuando el diff modifica 40 archivos en lugar de 6.
Ambos fallos comparten una misma causa raíz: el informe del propio agente es la única evidencia disponible. Un bucle de verificación sustituye ese informe por elementos tangibles que puedes inspeccionar.
El ciclo «planificar, observar, verificar» aplicado al código
Un bucle de verificación para agentes de código consta de cinco fases que se repiten hasta superar todos los pasos:
- Planificar: dividir la tarea en pasos, cada uno con una comprobación concreta.
- Actuar: ejecutar un solo paso y detenerse.
- Observar: ejecutar la comprobación y recopilar la evidencia en bruto.
- Verificar: contrastar la evidencia con la comprobación del paso (aprobado o fallido).
- Replanificar: si falla, corregir el paso o revisar el resto del plan antes de continuar.
Planificar: define una comprobación por cada paso
La planificación es la fase en la que fracasa la mayoría de los bucles. «Añadir limitación de tasa» (rate limiting) es un objetivo, no un paso. Un plan viable asocia cada paso a una comprobación que un script pueda ejecutar automáticamente.
## Plan for SH-312: add rate limiting to /api/export
1. Add RateLimiter middleware in src/middleware/rate-limit.ts
Check: npx tsc --noEmit exits 0
2. Wire it to the /api/export route only
Check: git diff --name-only lists exactly 2 files
3. Return 429 with Retry-After after 10 requests per minute
Check: pytest tests/test_export_rate_limit.py -x passes
4. Leave existing tests untouched
Check: git diff --stat tests/ shows only the new test file
En Claude Code, inicia en modo de planificación para que el agente proponga esto antes de modificar cualquier archivo: claude --permission-mode plan. La documentación del flujo de trabajo de Claude Code lo explica así: Claude «lee archivos y propone un plan, pero no realiza modificaciones hasta que tú lo apruebas».
Observar: consulta las evidencias, no el resumen
Observar implica ejecutar la comprobación y conservar la salida en bruto. Los códigos de salida, los resultados de los tests y el diff son evidencias. «Todos los tests pasan» en el resumen del agente es solo una afirmación sin comprobar.
Las tres comprobaciones más eficaces para detectar problemas son:
- El diff.
git diff --statygit diff --name-onlymuestran el alcance de las modificaciones de un vistazo. Consulta la referencia de git diff para ver filtros de ruta. - Los tests.
pytest -xse detiene al primer fallo, impidiendo que el agente lo oculte bajo 200 líneas de salidas exitosas. La documentación de fallos de pytest detalla estos modificadores. - La compilación (build).
npx tsc --noEmitonpm run builddemuestra que el código compila correctamente, algo que las pruebas unitarias por sí solas pueden omitir.
Verificar: contrasta los resultados con la comprobación del paso
La verificación es una respuesta binaria (sí o no) a una única pregunta: ¿esta evidencia cumple con la comprobación de este paso? El paso 2 requiere dos archivos. El diff muestra tres. Eso es un fallo, aunque todos los tests se hayan superado.
Aquí es donde la autoverificación del agente demuestra su utilidad. El agente evalúa su propio paso frente a una regla establecida antes de comenzar, impidiendo que cambie los criterios sobre la marcha.
Replanificar: qué hacer cuando falla una comprobación
Una comprobación fallida es información valiosa, no un error que deba ocultarse. El agente debe corregir el paso y repetir la comprobación, o bien ajustar los pasos restantes explicando el motivo. El agente de Genie 4 actúa de esta misma forma ante la intervención del usuario: adapta el plan en lugar de insistir en completar el plan anterior.
Limita los reintentos. Tres intentos fallidos en un mismo paso indican que el plan es erróneo y requiere la revisión de una persona.
El punto en el que interviene un humano o un segundo agente
La autoverificación de los agentes tiene un techo. Un agente que redactó la comprobación, la ejecutó y juzgó el resultado está corrigiendo su propio examen. La autoverificación no es una revisión.
Reserva la autoverificación para comprobaciones a nivel de paso: compilar, probar y delimitar el alcance. Utiliza un segundo revisor —humano o un Agente independiente— para las cuestiones que una comprobación no puede resolver: ¿es el cambio adecuado?, ¿cumple los requisitos?, ¿es seguro llevarlo a producción? Nuestra guía sobre lo que los agentes de revisión de código con IA pueden y no pueden verificar analiza esta frontera en detalle.
El paso de revisión necesita su propio espacio. En Sharkly, la Tarea reúne el plan, el historial de ejecuciones y los comentarios en un único registro. Un flujo de trabajo de Space permite intercalar un estado de revisión entre «In Progress» y «Done», garantizando que «el agente terminó» y «un revisor lo aprobó» sean dos estados claramente separados.
A partir de ahí, un disparador de estado de tarea ejecuta una automatización «cuando una tarea pasa a un estado de organización seleccionado». Si lo vinculas a un Agente revisor, cada tarea que alcance el estado «Ready for Release» recibirá una segunda lectura de forma automática. La documentación de ejecución de tareas con agentes detalla cómo el flujo de trabajo del tipo Tarea restringe los estados que un Agente puede seleccionar.
El principio básico sigue siendo sencillo: los agentes planifican, actúan, observan y verifican; las personas definen las comprobaciones, examinan las evidencias y validan el resultado. Para saber dónde situar estos puntos de control, consulta puntos de aprobación para agentes de código y agentes de código con intervención humana (human-in-the-loop).
Prompt listo para copiar: bucle de verificación
Pega esto en el archivo de instrucciones de tu agente o en la descripción de la Tarea:
Work in a plan, observe, verify loop.
1. Before editing, write a numbered plan. Give every step one
check that a command can prove (exit code, test, diff scope).
2. Do one step at a time. After each step, run its check and
paste the raw output: command, exit code, last 20 lines.
3. Mark each step PASS or FAIL against its check. Never mark
PASS from memory or from a summary.
4. On FAIL: fix and re-run, or revise the remaining plan and say
why. Stop after 3 failed attempts on one step and ask.
5. Never edit, skip, or delete an existing test to make a check
pass. If a test looks wrong, stop and ask.
6. Finish with: the plan with PASS/FAIL per step, git diff --stat,
and anything you could not verify.
El paso 5 bloquea el atajo más habitual. El paso 6 proporciona al revisor todas las evidencias en un solo lugar, permitiendo que la revisión tome minutos en lugar de obligar a repetir la ejecución. Si deseas profundizar en la inspección de evidencias, nuestra guía sobre cómo revisar código generado por IA con evidencias a nivel de tarea explica todo el proceso.
Tu siguiente paso: elige una tarea real, redacta su plan de cuatro pasos con comprobaciones y ejecútala con el prompt anterior. Si utilizas varios agentes de forma simultánea, Sharkly permite comenzar gratis y mantiene el plan, las evidencias y la revisión de cada ejecución centralizados en una misma Tarea.
Preguntas frecuentes
¿Qué es un bucle de verificación para agentes de código?
Un bucle de verificación para agentes de código es un flujo de trabajo en el que el agente valida cada paso frente a un test, un diff o una comprobación de compilación predefinida antes de continuar. Sustituye el informe subjetivo del propio agente por evidencias tangibles que un revisor puede inspeccionar.
¿Qué relación tiene Genie 4 con los agentes de código?
No genera código. Genie 4 de Google DeepMind es un modelo de mundo. Sin embargo, su bucle de agentes, en el que Gemini 3.8 Flash planifica los pasos y verifica cada uno de ellos, sigue exactamente el mismo patrón que requieren los agentes de programación.
¿Puede un agente de código verificar su propio trabajo?
Solo en parte. La autoverificación del agente funciona para validaciones mecánicas y objetivas como compilar, pasar tests y comprobar el alcance del diff. No puede juzgar si el cambio es conceptualmente correcto; para eso se necesita un segundo revisor.
¿Qué debe comprobar un paso de verificación?
Un hecho concreto demostrable mediante un comando: un código de salida, un archivo de pruebas superado o la lista de archivos modificados. Si una comprobación requiere criterio subjetivo o valoración cualitativa, corresponde a la fase de revisión, no al bucle.
¿Cómo evitar que un agente modifique los tests para que pasen?
Establece «nunca edites los tests existentes» en las instrucciones y verifícalo con git diff --stat tests/ en cada paso. Nuestro artículo sobre quién detiene a tus agentes profundiza en el control y las políticas de detención.
