Auditoría de Código Multi-Modelo: El Patrón Council

El Problema

Cuando usas un solo modelo de lenguaje para revisar código, heredas sus puntos ciegos. Claude Opus puede ser excelente detectando problemas de arquitectura, pero perder casos límite en la validación de entrada. GPT-4 puede encontrar vulnerabilidades de seguridad obvias, pero ignorar fugas de recursos sutiles. Gemini puede tener un rendimiento superior en razonamiento matemático, pero pasar por alto problemas de concurrencia.

No es culpa del modelo. Es su naturaleza. Cada LLM se entrena con diferentes datasets, tiene diferentes arquitecturas, y optimiza para diferentes objetivos. Lo que uno ve, otro lo ignora.

La respuesta obvia es: usa el modelo más caro. Pero incluso los modelos flagship tienen límites. Y más importante: la investigación reciente muestra que un conjunto diverso de modelos baratos puede superar a un solo modelo premium.

El Patrón

La auditoría multi-modelo (o "Council Pattern") consiste en ejecutar múltiples LLMs en paralelo sobre el mismo código y sintetizar sus hallazgos. No es simplemente ejecutar varios modelos y concatenar resultados. Es aprovechar la diversidad para encontrar lo que cualquier modelo individual pasaría por alto.

Mixture-of-Agents: Fundamento Académico

En 2024, Wang et al. publicaron un paper sobre Mixture-of-Agents (MoA) que demuestra este principio formalmente. Su arquitectura MoA superó a GPT-4o en AlpacaEval 2.0 con un 65.1% vs 57.5%, usando una combinación de modelos más débiles que el modelo individual más fuerte.

La idea central: cada modelo tiene un "campo de visión" diferente sobre el problema. Cuando combinas múltiples perspectivas, capturas ángulos que ningún modelo solo vería. Es la "sabiduría de multitudes" aplicada a LLMs.

Por Qué Funciona el Consenso

Cuando 3 de 4 modelos encuentran el mismo issue, hay dos explicaciones:

1. Es un problema real y obvio
2. Es un falso positivo que múltiples modelos comparten (raro)

En mi experiencia auditando código real: cuando múltiples modelos independientes convergen en un hallazgo, casi siempre es legítimo. Los falsos positivos tienden a ser idiosincrásicos del modelo.

El patrón inverso también es valioso: cuando un solo modelo encuentra algo que nadie más ve, puede ser:

1. Un hallazgo único que otros modelos no tienen la capacidad de detectar
2. Una interpretación incorrecta del código

Ambos casos requieren investigación humana. El punto es: la diversidad de opiniones te da señales que un modelo solo no puede proporcionar.

Arquitecturas y Puntos Ciegos

Cada familia de modelos tiene fortalezas distintas:

• Anthropic Claude: Excelente en análisis de flujo de datos, razonamiento sobre arquitectura
• OpenAI GPT: Fuerte en patrones de seguridad comunes, conocimiento general
• Google Gemini: Superior en razonamiento matemático, eficiencia de análisis
• Modelos chinos (Kimi, DeepSeek): Diferentes corpus de entrenamiento, perspectivas únicas

Estas diferencias no son bugs, son features. Cuando auditas código, quieres todos estos ángulos.

Mi Prueba

Probé este patrón en un proyecto real: un AI Gateway en TypeScript con ~5,000 líneas de código distribuidas en 46 archivos fuente. Ejecuté 4 modelos en paralelo:

• Claude Opus 4.6 (~$0.83)
• Claude Sonnet 4.5 (~$0.25)
• Gemini 3 Pro (~$0.08)
• Kimi K2.5 (~$0.04)

Costo total: ~$1.20. Tiempo de ejecución: ~2 minutos.

Resultados

Consenso: 9 hallazgos encontrados por 3 o más modelos.

Críticos universales: 2 problemas encontrados por los 4 modelos (una falta de autenticación en un endpoint y una vulnerabilidad de inyección en la capa de caching).

Lo Que Encontraron los Modelos Baratos

El resultado más sorprendente: el modelo más barato ($0.04 Kimi) encontró una vulnerabilidad crítica de SSRF que los 3 modelos más caros pasaron por alto. Gemini ($0.08) detectó una fuga de costos que ningún modelo de Anthropic capturó.

Esto valida la hipótesis MoA: la diversidad importa más que el precio individual.

Comportamientos Únicos

Opus 4.6 fue el único modelo que exploró archivos proactivamente más allá de los que estaban en el prompt inicial. Los demás se limitaron al scope explícito.

Gemini tuvo la mejor relación señal-ruido: 11 hallazgos, todos relevantes. Sonnet fue más exhaustivo pero con más overlap.

Desacuerdos

Los modelos no siempre concordaron en severidad. Un problema de crecimiento de memoria fue clasificado como "Medium" por Opus y Gemini, pero "Critical" por Sonnet y Kimi. La diferencia: depende del volumen de tráfico esperado. Ambas evaluaciones son válidas bajo diferentes supuestos.

Falsos Positivos

Cero. Todos los hallazgos fueron legítimos, aunque con diferentes niveles de urgencia.

Insights Prácticos

1. Diversidad > Cantidad

4 modelos diversos superan a 10 copias del mismo modelo. No ejecutes GPT-4 diez veces. Ejecuta GPT-4, Claude, Gemini, y un modelo chino una vez cada uno.

2. Retornos Decrecientes

Después de 4-5 modelos diversos, los hallazgos únicos adicionales caen drásticamente. En mi test, 15 hallazgos únicos de 84 totales significa que cada modelo contribuyó ~3-5 insights únicos. El quinto modelo probablemente agregaría 1-2.

3. Los Modelos Baratos Importan

No asumas que los modelos premium encuentran todo. Kimi ($0.04) encontró un SSRF crítico. Gemini ($0.08) encontró una fuga de costos. Ambos se habrían perdido con solo Claude.

4. La Síntesis es Difícil

Combinar 84 hallazgos de 4 modelos en un reporte coherente requiere esfuerzo humano o un modelo sintetizador adicional. En mi implementación, usé un quinto modelo (otro Claude Opus) para deduplicar y priorizar.

5. Consenso no es Corrección

Que 4 modelos concuerden no significa que tengan razón. Pero en código de seguridad, es una señal fuerte que merece investigación inmediata.

Implementación

Ejemplo simplificado usando OpenClaw y OpenCode:

# Same prompt, 4 models, parallel execution
PROMPT=$(cat audit-prompt.md source-code.txt)
 
opencode run --model anthropic/claude-opus-4-6 --agent coder "$PROMPT" &
opencode run --model anthropic/claude-sonnet-4-5 --agent coder "$PROMPT" &
opencode run --model google/gemini-3-pro-preview --agent coder "$PROMPT" &
opencode run --model opencode/kimi-k2.5-free --agent coder "$PROMPT" &
wait

Ejecuta en paralelo, espera todos los resultados, sintetiza. Total: ~2 minutos para un repositorio mediano.

Conclusión

La auditoría multi-modelo no es teoría. Con $1.20 y 2 minutos, encontré 15 problemas únicos en código de producción, incluyendo 2 vulnerabilidades críticas que todos los modelos confirmaron.

El patrón es simple: ejecuta modelos diversos en paralelo, busca consenso en hallazgos críticos, investiga los hallazgos únicos. No necesitas el modelo más caro. Necesitas el conjunto más diverso.

La investigación MoA lo confirma. Mi prueba real lo valida. Los modelos tienen puntos ciegos. Los consejos no.

Construido con OpenClaw (orquestación) y OpenCode (ejecución de modelos). El patrón de auditoría del consejo es model-agnostic -- adáptalo a tu setup de providers.