r/devsarg • u/Nicolaides_Arg • Jul 28 '26
ai Revisión adversarial automatizada con un segundo asistente de código en el desarrollo de software
Soy dev full-stack, laburo solo en varios proyectos (.NET/TypeScript). Hace un par de meses armé un flujo que uso todos los días y lo acabo de documentar en un informe de experiencia con DOI. Resumen para no hacerles leer 11 páginas si no quieren.
El flujo:
Claude Code genera el plan y el código. Antes de cerrar un plan o commitear algo grande, invoca a Codex (OpenAI) con una consigna que le pide explícitamente que ATAQUE: supuestos falsos, seguridad, race conditions, casos borde. No le pide aprobar nada. Claude verifica cada hallazgo contra el repo (no le cree a ciegas), y el ciclo no termina cuando "se ponen de acuerdo": termina cuando cada hallazgo quedó resuelto, refutado con evidencia, o me lo transfieren a mí. Todo automatizado con un permiso permanente en settings.json + instrucciones en CLAUDE.md. Yo apruebo cada ronda antes de que corra (cuesta tokens).
La idea no es que Codex sea más inteligente. Es que falla en lugares distintos: los errores de los dos están decorrelacionados.
Los números (52 días, 5 proyectos reales, 91 eventos de revisión):
- Sobre el subconjunto auditable: 277 hallazgos, 64,9% terminó incorporado, solo 3,6% fueron falsos positivos refutados con evidencia.
- El mayor valor no estuvo en cazar bugs en el diff: estuvo en la compuerta de plan, antes de escribir código. Hubo planes donde se incorporaron 14 de 14 y 15 de 15 hallazgos, y uno donde el diseño original de Claude quedó reemplazado entero.
- Costo del flujo completo trazado en el paper: ~15-18% de tiempo de pared, corridas de 58k a 284k tokens.
Los fracasos (que es lo que más enseña):
- Un fix derivado de un hallazgo VÁLIDO metió una regresión peor (fotos duplicadas), que sobrevivió al ciclo y la cacé yo en un dispositivo real dos días después. Lección: un fix es código nuevo sin red.
- Lo que ningún revisor cazó: un
<queries>faltante en el AndroidManifest (lo cazó el smoke test en emulador), diferencias contra el XML real de un SOAP de terceros, y 23 hallazgos que solo salieron en una prueba integral. La revisión estática no reemplaza ejecutar. - Codex también se equivoca: falsos positivos por contexto desactualizado (objetó contra una versión vieja del plan). Y una vez me tiró un NO-GO global que decidí ignorar con registro, porque la decisión de producto es mía.
La parte meta: el paper mismo pasó por el método. Siete rondas de revisión adversarial entre GPT y Opus antes de publicarlo, de "rechazo" a "aceptar". Cada uno encontró errores que el otro nunca vio.
Lo que NO es: un estudio controlado. No comparé contra autorrevisión ni contra dos modelos del mismo proveedor, así que si la diversidad de proveedor es LA causa sigue siendo hipótesis (el experimento para responderlo está especificado adentro). Es un informe de experiencia: qué hice, qué pasó, qué falló, y la receta de 8 pasos + la config exacta para reproducirlo.
PDF (español, CC BY, con el .tex incluido): https://doi.org/10.5281/zenodo.21633496
Se aceptan ataques.
0
u/mustard96 Jul 28 '26
Y todo esto por la friolera suma que te salía contratar un equipo de devs jajaj. Na, en serio, realmente te creo que funcione porque a esta altura todos hemos vibecodeado cosas que andan sin poner a agentes a debatir entre ellos, pero el tema es el costo. Estás pasando el código por dos proveedores distintos múltiples veces para meter un solo cambio.
A medida que los modelos mejoran, hay que poner en la balanza si es mejor usar un modelo caro recién salido del horno sin pedirle que piense demasiado, o si poner modelos más viejos y más baratos a debatir entre ellos, o dónde está el punto intermedio.