Cómo evaluar si un ensemble de agentes revisores supera a un solo revisor sin confundir consenso con calidad

Construye un benchmark que no conozcan los agentes. Reúne cambios reales o sintéticos que contengan defectos de severidad distinta, casos correctos que no deberían generar observaciones y ejemplos ambiguos donde la respuesta razonable sea abstenerse. Oculta las etiquetas durante la ejecución para no ajustar el sistema contra el examen. Cada caso necesita una verdad de referencia construida por revisión humana o pruebas deterministas. El objetivo no es fabricar un conjunto donde el ensemble luzca bien, sino representar la mezcla de ruido, estilo, lógica y regresiones que aparecerá cuando el producto revise trabajo cotidiano.

Define qué significa mejorar antes de ejecutar. Un sistema de varios agentes puede encontrar más problemas y al mismo tiempo producir más comentarios inútiles. Fija métricas separadas: cobertura de defectos reales, precisión de observaciones, severidad correctamente asignada, tiempo hasta primer hallazgo útil y costo por revisión. Añade una métrica de carga humana, como minutos necesarios para descartar falsos positivos. Esa última cifra importa porque un revisor que parece exhaustivo puede empeorar la experiencia si obliga al desarrollador a leer una lista extensa de advertencias que no cambian ninguna decisión.

Compara contra un revisor único fuerte. El baseline no debe ser un sistema deliberadamente débil. Ejecuta el mejor revisor individual disponible con el mismo contexto, herramientas y presupuesto razonable. Después corre el ensemble sobre exactamente los mismos casos. Si el conjunto gana únicamente porque consume tres veces más tokens o ejecuta muchas más pruebas, registra esa diferencia. Puede seguir siendo una buena inversión, pero ya no es una comparación gratuita. El producto necesita saber qué parte de la mejora proviene de diversidad de enfoques y qué parte simplemente compra más cómputo.

Mide desacuerdos en lugar de esconderlos. Guarda qué agente detectó cada problema, quién lo ignoró y quién lo contradijo. Construye una matriz simple de coincidencias por tipo de defecto. Los desacuerdos pueden revelar especialización útil: un agente encuentra problemas de seguridad que otro rara vez ve, mientras un tercero reduce falsos positivos de estilo. También pueden mostrar redundancia. Si todos producen casi las mismas observaciones, quizá tres agentes no estén aportando diversidad real. El valor del ensemble aparece cuando las diferencias complementan cobertura sin multiplicar ruido.

Prueba reglas distintas de agregación. No conviertas el voto mayoritario en verdad automática. Algunos defectos raros pueden ser detectados por un solo especialista precisamente porque los demás no tienen esa fortaleza. Compara varias políticas: mayoría, cualquier hallazgo de alta confianza, árbitro final o combinación basada en especialidad. Evalúa cada política con el benchmark ciego y observa cómo cambia precisión y cobertura. Una regla de agregación es parte del producto, no un detalle invisible. Debe responder a la consecuencia de equivocarse y al tipo de revisión que el equipo quiere automatizar.

Incluye costo de coordinación y latencia. Un ensemble puede ejecutar en paralelo y aun necesitar una fase adicional para deduplicar, priorizar y explicar comentarios. Mide tiempo total hasta una salida utilizable, número de llamadas, herramientas ejecutadas y tamaño final del feedback. Observa la cola larga, no solo el promedio: algunos casos pueden disparar mucha exploración. Si el sistema se vuelve demasiado lento para una revisión interactiva, quizá convenga reservar el ensemble para cambios de alto riesgo y usar un revisor único en modificaciones pequeñas. La arquitectura puede adaptarse al contexto en lugar de aplicar siempre el modo más caro.

Decide con evidencia de producto. Resume resultados en una tabla que compare baseline y ensemble por severidad, precisión, cobertura, costo, latencia y carga humana. Ejecuta además un piloto corto con desarrolladores reales para detectar fricciones que el benchmark no capture. Si el ensemble mejora hallazgos críticos con un costo aceptable, despliega gradualmente. Si solo genera más comentarios, vuelve al diseño. Para Goatify, esta metodología sirve más allá del código: cualquier grupo de agentes que vote, critique o investigue necesita demostrar que su diversidad produce mejores decisiones, no simplemente más actividad.