Desacuerdo controlado: el método detrás de disensor

Disensor es la implementación de referencia de un método: desacuerdo controlado. Esta página explica la idea. El contrato exacto, con las claves del esquema, los enums y las reglas del validador, vive en la referencia y en la guía de llenado.

Si la revisión adversarial de código es nueva para vos como práctica, la guía de revisión adversarial de código la explica antes de que esta página explique el método.

El problema

Un asistente de código que revisa su propio trabajo comparte los puntos ciegos del trabajo. Pedirle que se autocritique produce autocrítica, no revisión: los supuestos que no vio al escribir tampoco los ve al releer.

La respuesta del método es decorrelacionar. Que ataque un modelo de otra familia, cuyo entrenamiento y cuyos modos de fallar son distintos. Acá no sirve por más capaz. Sirve porque falla en otros lugares.

El ciclo

1. Genera. Un modelo produce el plan o el diff.
2. Ataca. Un modelo de otra familia lo revisa con una consigna adversarial, cuyo hash queda registrado: cualquiera puede recomputarlo y ver qué se le pidió realmente al revisor.
3. Verifica. El generador contrasta cada hallazgo contra el repositorio y lo lleva a un estado terminal: incorporado, deuda registrada, decisión del dueño, refutado o escalado sin resolver. Una refutación verificable tiene que traer evidencia; una interpretativa tiene que mirarla un humano.
4. Declara. El ciclo cierra cuando todo hallazgo llegó a un estado terminal.

El paso interesante es el tercero. Un hallazgo del revisor no es automáticamente cierto: puede ser un falso positivo, y el método exige que la refutación traiga evidencia, no opinión. Cuando la refutación es interpretativa y no verificable, el artefacto obliga a que la mire un humano.

Esa exigencia es del método. Hasta dónde la hace cumplir el validador cambia con cada versión del esquema, y los límites conocidos se declaran en la referencia: no todo lo que el método pide es algo que una máquina pueda verificar.

La declaración de residuo

Lo que la herramienta define y hace cumplir es el artefacto con el que el ciclo termina: un JSON versionado en el repositorio, al lado del código que juzga.

Registra los actores y su familia, cada hallazgo con su estado terminal, las métricas del evento y el residuo, que es el bloque que le da nombre a todo. El residuo es lo que la ronda deja para que lo mire una persona, y el esquema lo nombra por clase: un hallazgo escalado que todavía espera una decisión; un hallazgo que el generador refutó, sea con evidencia o por juicio; una verificación que no se pudo ejecutar; y dos límites del propio revisor, un revisor de la misma familia que el generador o un endurecimiento que no se verificó. Una decisión que el dueño ya tomó, con su riesgo registrado, no es residuo: cierra el hallazgo y no le pide nada a nadie.

Por qué residuo y no cobertura

Es la decisión de diseño que ordena todo el resto.

Un artefacto que reportara cobertura se leería como un sello de calidad, y un sello de calidad invita a dejar de mirar. La declaración lista el residuo, ítem por ítem, cada uno con la evidencia que haya. Dirige el escrutinio del revisor humano hacia los puntos donde el ciclo se quedó corto.

El residuo es más ancho que “lo que quedó abierto”. Un hallazgo que el generador refutó con evidencia queda cerrado y aun así entra, porque la refutación es del principal sobre el revisor y alguien tiene que poder auditarla. El residuo tiene tres clases: escalado sin decisión, refutación del principal y gap de ejecución. El esquema residue/v0.4 agrega dos más para los modos degradados, reviewer_correlation y reviewer_hardening_gap, que registran las limitaciones del revisor y no las del código.

Eso tiene un costo que el método acepta a sabiendas: una declaración honesta puede verse peor que una falsa. Más automatización no lo arregla, así que el método lo declara.

El límite

El validador detecta el campo vacío y el marcador genérico. No detecta la declaración falsa, y ninguna herramienta puede. Alguien tiene que abrir PR ya mergeados al azar y leerlos.

El gate, además, corre dentro del workflow que audita. Esa frontera no la cruza ningún código propio; la resuelven la plataforma y el despliegue. Son cinco controles, y son requisito, no sugerencia:

1. Un required check estricto, o una merge queue.
2. CODEOWNERS sobre la configuración efectiva y sobre .github/workflows/.
3. Un ruleset o required workflow definido fuera del repositorio auditado.
4. El pin de la Action por SHA en lugar de por tag.
5. Un bootstrap administrativo, porque el primer PR que agrega el gate no puede convertirse a sí mismo en raíz de confianza.

El porqué de cada uno está en requisitos de despliegue.

Cómo se relaciona con otros enfoques

Casi todo el vocabulario con el que se busca en este espacio describe la revisión: quién revisa, con cuántos modelos, en qué orden. Disensor está un paso después. Define y valida el registro con el que la revisión termina, y lo hace cumplir en el pull request. Así que comparte el lado de la revisión con cada uno de estos términos y se diferencia en lo que agrega.

• Revisión de código entre modelos (cross-model, multi-model code review). El método la exige: el revisor viene de una familia de modelo distinta de la del generador (R4), y desde residue/v0.4 la declaración dice qué independencia tuvo realmente la ronda. Lo que disensor agrega es que el resultado queda escrito, versionado y con gate, participen los modelos que participen.
• Maker-checker. La misma separación entre quien construye y quien certifica, con una diferencia en lo que firma el que certifica: no “aprobado” sino la lista de lo que no cerró. El árbitro humano (R0) es el último checker, y sin él el artefacto no valida.
• Segunda opinión (second-opinion review). Un revisor de otra familia es una segunda opinión por construcción. Disensor no se queda en la opinión: cada hallazgo tiene que llegar a un estado terminal, y una refutación necesita evidencia, no una réplica.
• IA que revisa código generado por IA. El caso para el que se escribió el método. Su límite conocido es el que se dijo más arriba: el gate detecta el campo vacío y el marcador genérico, no la declaración falsa.
• Diversidad de modelos, revisor decorrelacionado. La razón detrás de R4 es la decorrelación: dos modelos del mismo linaje tienden a fallar en los mismos lugares. La magnitud de ese efecto no está medida, y el repositorio de la herramienta lo dice; la regla es un diseño plausible, no un resultado demostrado.

Las herramientas que ya existen cubren bien el lado de la revisión: la guía de revisión adversarial de código de Augment Code, el loop alecnielsen/adversarial-review entre Claude y Codex, y las funciones de revisión de asistentes como GitHub Copilot. Cualquiera puede alimentar una declaración de residuo; ninguna la reemplaza, porque ninguna deja un registro versionado y con gate de lo que la revisión dejó para que lo mire una persona.

Relación con Adversarial Review (arXiv 2608.18167)

Qiu, E. S. y Gill, J. (2026). Adversarial Review: Structured Disagreement for Grounded Agentic Code Review. arXiv:2608.18167. Los nombres se superponen y las preocupaciones son vecinas, así que conviene decir la diferencia.

AR es un protocolo de orquestación: un agente principal trabaja con un revisor y un crítico, el crítico audita la revisión mediante desacuerdo estructurado antes de que el agente principal edite, y el resultado se mide por pass rate y F1 en benchmarks. El gate no orquesta ni corre modelos: disensor define el artefacto con el que termina cualquier ciclo de revisión, lo valida y lo hace cumplir en CI. El disensor round opcional sí corre el paso del revisor, con uno instalado en tu máquina, y nunca juzga lo que devuelve; el diálogo entre revisor y crítico que AR orquesta no es algo que disensor haga.

AR reporta un modo de falla de falso consenso, agentes que convergen en un acuerdo sin evidencia suficiente, y lo ataca dentro del protocolo obligando al crítico a fundar su desacuerdo en evidencia. Disensor ataca el mismo problema desde el otro lado: la declaración lista residuo, no cobertura, el árbitro humano es obligatorio (R0) y generador y revisor tienen que ser de familias distintas (R4). Acá el desacuerdo no es un paso del protocolo: es lo que queda registrado, aunque el ciclo haya cerrado.

Son complementarios: un ciclo AR puede terminar en una declaración de residuo, y lo que el crítico no pudo zanjar con evidencia es exactamente lo que la declaración le lleva a un humano.

El paper

Rocchia, N. (2026). Desacuerdo controlado: revisión adversarial automatizada con un segundo asistente de código en el desarrollo de software. DOI 10.5281/zenodo.21633495.

La terminología del paper es en español; el contrato del esquema y la CLI están en inglés desde la v0.2. La referencia incluye el glosario que mapea una cosa a la otra.