Informe de experiencia
Desacuerdo controlado: revisión adversarial automatizada con un segundo asistente de código.
Un asistente de código planifica e implementa. Un segundo asistente, de otro proveedor, lo ataca. El evento cierra cuando cada hallazgo quedó resuelto, refutado con evidencia o transferido al desarrollador. Nunca por consenso.
Por qué escribí esto
Trabajo solo. Mi código no se revisa solo.
La pregunta razonable de cualquiera que me confía un sistema: si no hay equipo, quién controla lo que entregás. Esta es mi respuesta, con los números de ocho semanas de trabajo real.
Cuando alguien contrata a un estudio de una persona, el descuento mental es inmediato: no hay quien revise. Es una objeción legítima, y responderla con buenas intenciones no alcanza.
Mi respuesta es un procedimiento. El asistente de código con el que trabajo escribe el plan y después lo implementa. Antes de que ese plan se cierre, y otra vez antes de confirmar los cambios, un segundo asistente de otro proveedor recibe el material con una instrucción explícita: no aprobar, atacar. Buscar los agujeros de seguridad, los casos borde, los supuestos mal puestos. Cada hallazgo que devuelve se verifica contra el código antes de darlo por bueno, y el evento no termina hasta que cada uno quedó resuelto, refutado con evidencia o pasado a mi nombre como decisión consciente.
Que sea de otro proveedor no es capricho. Pedirle a un modelo que revise su propia salida no constituye un control independiente: la literatura documenta que la autocorrección sin señal externa no mejora de forma confiable y puede degradar, y que hay defectos que un modelo no ve en lo que produjo pero sí corrige cuando le llegan desde afuera. El punto no es asumir que el segundo sea más inteligente, sino introducir una señal externa que pueda tener puntos ciegos diferentes.
Este informe documenta ocho semanas de operar así sobre cinco proyectos profesionales, con la contabilidad a la vista. Incluye lo que el método no encontró, los hallazgos falsos que costó descartar, y una regresión que introdujo una corrección mía derivada de un hallazgo correcto. Sin esa parte sería publicidad, no un informe.
La operación
Ocho semanas, contadas.
Entre el 2 de junio y el 23 de julio de 2026, sobre cinco proyectos en producción y desarrollo. Los conteos salen de los registros de sesión y de una bitácora escrita al cierre de cada ronda.
Sobre el subconjunto auditable —los 277 hallazgos de eventos con conteo numérico— al menos el 64,9 % fue incorporado y el 3,6 % fue refutado con evidencia. Incorporado no equivale a defecto confirmado: incluye endurecimientos, mejoras de diseño y mitigaciones aceptadas a partir de la revisión. El resto son derivaciones a deuda técnica registrada, riesgos aceptados de forma explícita y descartes justificados. Es un piso calculado sobre un artefacto auto-reportado, no una auditoría: el informe declara esa limitación y las reglas de cómputo en el apéndice.
Los cinco proyectos se identifican como P1 a P5 y no se nombran: tres son trabajo para terceros y el informe generaliza cualquier detalle que permitiera identificar sistemas u organizaciones ajenas. Los datos operativos no fueron alterados.
El método
Dos compuertas y una regla de corte.
Los roles no se mezclan: uno genera, otro ataca, la ejecución arbitra lo que puede arbitrar y la última palabra es humana.
Si querés aplicarlo, lo condensé en una carilla con la consigna, los estados de cierre y los límites: receta mínima de adopción →
Roles fijos
El asistente principal planifica, implementa, verifica los hallazgos contra el repositorio y reconcilia. El revisor, de otro proveedor, ataca. La compilación y las pruebas actúan de árbitro parcial: resuelven todo aquello para lo que existe un oráculo independiente. El desarrollador es dueño del resultado y responde por él.
Dos compuertas, no una
La primera corre sobre el plan, antes de que exista código. La segunda sobre el conjunto de cambios, antes de confirmarlos. La compuerta de plan fue percibida como la de mayor valor en la bitácora. Es plausible: cambiar un diseño antes de implementarlo suele ser menos costoso, aunque esa diferencia no fue medida. Es también la que ninguna batería de pruebas puede cubrir, porque todavía no hay nada que probar.
La consigna pide atacar, no aprobar
El prompt del revisor es explícitamente adversarial: errores funcionales, regresiones, concurrencia, seguridad, persistencia, supuestos de dominio, con severidad y evidencia de archivo y línea por hallazgo. Y una restricción estructural que condiciona todo lo demás: el revisor ve el repositorio pero no la conversación del asistente principal, así que todo el contexto le llega, y solo le llega, por la consigna. Dos de las refutaciones del corpus vienen justamente de ahí: el revisor objetó contra una versión del contexto que una decisión posterior ya había cambiado.
Se corta por disposición, nunca por consenso
El acuerdo entre dos asistentes que comparten datos de entrenamiento no vuelve verdadera una conclusión, y ambos pueden malinterpretar la misma especificación ambigua de la misma manera. Por eso el evento termina cuando cada hallazgo, individualmente, quedó resuelto, refutado con evidencia verificable o transferido de forma explícita al desarrollador. La transferencia cierra el evento, pero deja el hallazgo abierto y con responsable: deuda registrada con identificador, riesgo aceptado, mitigación parcial o escalamiento pendiente. Nada se cierra por cansancio.
La activación es una decisión, no un automatismo
No todo cambio pasa por el revisor. La política escrita dispara una ronda cuando la unidad de trabajo cruza una barra de impacto alto —contrato entre componentes, migración de base de datos, seguridad o autorización, concurrencia, lógica difícil de revertir— o cuando hay incertidumbre real. Se omite en cambios locales, reversibles o por plantilla. Y cada corrida se propone y se aprueba: cuesta tokens y minutos.
Los límites
Lo que el método no detectó.
La parte que un informe honesto tiene que traer al frente. Los defectos escapados siguen un patrón claro, y casi ninguno es lógica del cambio revisado.
- Contratos externos — cinco diferencias entre lo planificado y el XML real de un servicio de terceros. Inverificables con los artefactos del repositorio: solo el ejemplo real las reveló.
- Entorno de ejecución — una declaración faltante en el manifiesto de Android que rompía la cámara en todos los dispositivos. Pasó por el revisor y por tres revisiones internas; la cazó únicamente la prueba de humo en un emulador.
- Estado real del sistema — una prueba integral posterior a cinco sprints reveló 23 hallazgos que ninguna revisión estática tenía.
- Decisiones de producto — requieren autoridad y responsabilidad humanas. No son un defecto que un revisor pueda encontrar.
La regresión que introdujo una corrección
El caso más instructivo del corpus, y el peor. El revisor encontró un problema real: pérdida de archivos locales ante una caída de la aplicación. La corrección que apliqué resolvió eso, pero su mecanismo de mitigación introdujo una regresión distinta —duplicación— que sobrevivió al cierre del ciclo, que yo mismo atribuí a otra causa, y que terminé detectando en un dispositivo real dos días después.
La causa de fondo no fue el revisor: el componente carecía de pruebas porque dependía de APIs de plataforma. La lección quedó anotada en la bitácora y vale más que cualquier porcentaje: una corrección derivada de un hallazgo es también código nuevo sin cobertura, y merece su propio ciclo antes de darse por cerrada.
La objeción que conviene hacerse
Que los defectos escapados delaten pruebas faltantes antes que revisores faltantes. Es cierto, y no compite: la revisión estática y la ejecución real actúan sobre clases de defecto y momentos distintos. Las pruebas no pueden revisar un plan —la compuerta donde se concentraron los hallazgos incorporados actúa antes de que exista código que probar— y el revisor no puede ejecutar el entorno real. Esta experiencia no midió cuánto del aporte del revisor podría reproducirse con especificaciones o pruebas más fuertes.
Lo que el informe deliberadamente no afirma: que la diversidad de proveedor sea la causa del beneficio observado, ni que el balance neto de costos sea favorable. No se hizo la comparación controlada que permitiría sostenerlo. El diseño experimental que haría falta queda especificado en el trabajo futuro.
Resumen
El abstract, textual.
Tal como aparece en el PDF, partido en párrafos para que se lea en pantalla.
Este informe de experiencia documenta una metodología de desarrollo operada durante 52 días distribuidos en ocho semanas calendario sobre cinco proyectos profesionales: un asistente de código (Claude Code, que ejecutó dos modelos de Anthropic a lo largo del período) genera planes e implementaciones; un segundo asistente de otro proveedor (Codex CLI, de OpenAI) los ataca con una consigna adversarial; el primero recibe la instrucción de verificar cada hallazgo contra el repositorio; y cada evento de revisión termina cuando cada hallazgo ha quedado resuelto, refutado con evidencia o transferido explícitamente al desarrollador (la transferencia termina el evento; el hallazgo puede quedar abierto), un criterio de corte aquí denominado desacuerdo controlado.
El informe explica por qué el diseño es plausible (límites documentados de la autorrevisión, diversidad de errores, la ejecución como árbitro), cómo se opera (mecanismo, receta mínima de adopción) y narra un flujo completo real de punta a punta, con la consigna, los 20 hallazgos del revisor, su disposición y los tiempos y consumos de tokens disponibles.
Se observaron dos mecanismos de intervención: la detección de defectos existentes y la conformación del diseño en la compuerta de plan; ambos se ilustran con casos trazables, junto con los falsos positivos, los defectos que el método no detectó y una regresión introducida por una corrección. Sobre el subconjunto auditable del corpus, al menos el 64,9 por ciento de los hallazgos fue incorporado y el 3,6 por ciento fue refutado con evidencia. La contabilidad disponible y reconciliada (91 eventos de compuerta documentados, unidades, universos de cobertura y reconciliaciones) se presenta en el Apéndice A.
La atribución causal del beneficio a la diversidad de proveedor, y el balance neto de costos, quedan explícitamente como hipótesis: no se realizó comparación controlada, y el experimento pendiente se especifica.
El documento
El informe completo, en PDF.
Texto completo con las referencias y los tres apéndices: datos de operación, receta operacional e instanciación de referencia. Descarga directa, sin registro.
La versión 3.7 incorpora la discusión de tres trabajos contemporáneos: el experimento controlado de revisión cruzada entre Claude y Codex (Xiang et al., 2026), el protocolo de desacuerdo estructurado (Qiu y Gill, 2026) y Refute-or-Promote (Agarwal, 2026).
Cómo citarlo
Referencia y BibTeX.
El identificador es un DOI de concepto: apunta siempre a la versión más reciente, así que no queda desactualizado si el informe se revisa.
BibTeX
Contacto
El informe deja explícito lo que no probó: la comparación controlada. Si tenés datos de un flujo así, o si querés discutir el diseño experimental que falta, escribime.