Two desk lamps facing each other over a sheet of paper marked in red pencil
Back to blog
EngineeringAI Automation

2.481 revisiones cruzadas: Claude Code y Codex se revisan mutuamente

Durante dos meses hicimos que Claude Code y Codex revisaran el trabajo del otro antes de publicar nada. Tras 2.481 revisiones, esto dicen los números y esta es la regla que tuvimos que añadir.

S
Sno AI Team
September 22, 2026
|
6 min read
|
139 views
Share:

Claude Code termina el trabajo y Codex lo lee antes de que se publique. Cuando escribe Codex, lee Claude.

Un banco funciona igual. Nadie aprueba su propio préstamo. Una persona prepara la solicitud, otra la firma y nadie se lo toma como una ofensa. A nuestra versión la llamamos Dual Brain: dos agentes de IA que trabajan en pareja en una misma tarea, uno la realiza y el otro la revisa. Está integrado en Sno Station y trabajamos así desde mediados de julio.

Cada revisión deja una línea en un archivo de registro de nuestra máquina de compilación. Hace un tiempo me entró la curiosidad y las conté.

Las cifras

Del 19 de julio al 21 de septiembre, los dos agentes de IA se revisaron mutuamente 2.481 veces. Trabajaron durante 63 de esos días, unas 39 revisiones diarias. Leyeron 3,2 millones de líneas en 9.452 archivos.

Una revisión tarda unos dos minutos. La mediana es de 141 segundos y nueve de cada diez terminan en menos de seis minutos. Esa cifra importa más de lo que parece. Una revisión humana tarda un día, dedicado sobre todo a esperar a la persona. Cuando bastan dos minutos, dejas de preguntarte si algo merece una revisión. Todo pasa por una.

Pensé que la mayoría de los trabajos se aprobarían.

De las revisiones que emitieron un veredicto, 431 aprobaron el trabajo. Otras 1.953 pidieron cambios. Así que, cuatro de cada cinco veces, el segundo agente de IA devolvió el trabajo.

Cuatro de cada cinco. No hablamos de borradores descuidados de un becario cansado. El modelo ya había ejecutado sus pruebas y declarado que el trabajo estaba terminado.

Código frente a planes

Después conté por separado las revisiones de código y las de planes.

El código se aprobó el 27 por ciento de las veces. Hubo 398 aprobaciones en 1.475 revisiones. No es gran cosa, pero se puede vivir con ello.

Los planes se aprobaron el 3,6 por ciento de las veces. 33 de 907.

Tuve que mirarlo dos veces. Un plan es un documento. Dice qué vamos a construir y por qué. Podrías pensar que es más fácil acertar con un documento que con el código, porque no tiene que compilar. Ocurre al revés. La realidad corrige el código cada vez que lo ejecutas. Un plan puede afirmar que la base de datos tiene una columna que no existe, y la frase parecerá perfectamente razonable hasta que alguien construya algo a partir de ella.

Por eso ahora entregamos al revisor los hechos junto con el plan. Antes de revisar un plan, el agente de IA que lo escribió ejecuta los comandos, cuenta las filas, vuelca el esquema y adjunta la salida sin procesar. Así el revisor tiene algo con lo que contrastar las afirmaciones. Sin eso, es un examen sin consultar apuntes. El revisor puede detectar contradicciones dentro del documento, pero no que el documento contradice la realidad.

La mayoría de los hallazgos más graves vienen precisamente de esa distancia. En el mismo período, los revisores señalaron 4.277 problemas graves en 1.395 revisiones. No los he comprobado todos, y no todos son reales. Pero los que sí lo eran solían ser del mismo tipo: una afirmación hecha con seguridad que nadie había verificado de verdad.

Lo que salió mal

Si terminara aquí, sería una bonita historia. Me gustaría pensar que todas esas revisiones mejoraron el trabajo.

No es tan sencillo. Lo cierto es que un revisor siempre encuentra algo.

Mira las rondas posteriores. Después de que el autor corrigiera los hallazgos y pidiera otra revisión, el trabajo se aprobó el 21 por ciento de las veces. En la primera ronda fue el 17 por ciento. Corregir cada hallazgo apenas cambió las probabilidades. Un trabajo llegó a pasar por quince rondas.

Eso no significa que el autor fallara quince veces. El revisor hacía lo que hacen los revisores. Si le pides a un modelo capaz que busque problemas, los encuentra. Si el uso normal no tiene fallos, busca en los rincones. Dos solicitudes que llegan en el mismo milisegundo. Una cancelación a mitad de una escritura. Casos posibles, más o menos, como también es posible que te caiga un meteorito.

Y el autor, siempre dispuesto a colaborar, arregla cada uno añadiendo algo.

A principios de este mes tuvimos un pequeño error. La corrección pasó por seis rondas de revisión. En cada ronda, el revisor planteaba una preocupación nueva y el autor añadía una defensa. Un límite para el número de tokens. Un bloqueo por sesión. Una tabla aparte para registrar lo que se había entregado. Un mapa de alias. Al final, el parche era una pequeña fortaleza.

Ninguno de esos mecanismos llegó a ejecutarse en producción. Y, debajo de todos ellos, la corrección seguía teniendo un error de identidad en una sola línea que nadie vio porque estaba enterrado bajo las defensas. Era como subir la ganancia para escuchar un instrumento tenue y acabar oyendo sobre todo siseo.

La regla que añadimos

Así que escribimos una regla, lo más útil que salió de todo el experimento.

Un hallazgo no es una orden de añadir código.

Ahora la revisión devuelve dos grupos de hallazgos. El primero contiene los problemas que un usuario real encontraría en un día normal y cuya corrección más pequeña no añade nada nuevo. Esos se corrigen. El segundo contiene todo lo demás: los casos insólitos y lo que exigiría un bloqueo, un reintento o una tabla nuevos. Esos se anotan y se comunican. No se convierten en código a menos que una persona así lo decida.

También hicimos que el revisor busque primero lo que sobra, antes de buscar lo que falta. Un bloqueo que nadie necesitaba. Una opción con un único punto de uso. Una prueba que solo repite el código. Ahora eliminar también cuenta como hallazgo.

Y hay un límite. Tres rondas para el código. Una para las pruebas. Después, la discusión pasa a una persona, que probablemente era quien debía resolverla desde el principio.

Cuánto vale

No puedo darte una cifra clara de su valor. Me gustaría. No tengo un grupo de control, una segunda empresa que haya publicado el mismo trabajo sin revisión.

Lo que sí tengo es esto: cuatro de cada cinco veces, un modelo distinto quiso cambiar algo que el primero había dado por terminado. Parte de eso es ruido. Pero un agente de IA que revisa su propio trabajo casi nunca lo devuelve, porque ya cree en lo que escribió. La segunda opinión tiene que venir de otra parte. De otro modelo, entrenado por otras personas, que no estaba presente cuando el primero decidió que todo estaba bien.

Dos cabezas piensan mejor que una. Resulta que también es cierto cuando ninguna de ellas es humana.

Sno Station es de código abierto y la revisión cruzada forma parte de él. Está en sno.ai.

S

Written by Sno AI Team

Contributing writer at Sno.ai, sharing insights about AI, productivity, and knowledge management.

Related Articles

Comments

Comments coming soon. Configure Giscus at giscus.app

2.481 revisiones cruzadas: Claude Code y Codex se vigilan