El Protocolo Crisol: Refactorización Red-Team/Blue-Team con IA
Hace ya varios meses se me ocurrió una idea para resolver una de las broncas más frustrantes cuando programas con inteligencia artificial. Llevo un buen rato probándola, puliéndola y echándole coco en proyectos reales de infraestructura y desarrollo core y, la neta, los resultados están bien perros. Hoy te quiero compartir exactamente cómo funciona The Crucible Protocol (El Protocolo Crisol) para que tú también lo puedas aplicar en tus flujos de trabajo.
Ya sabes cómo se pone el asunto cuando le pides a un agente de IA que te refactorice un módulo o te arregle un bug complejo: el bato se pone a tapar el sol con un dedo. Para salir del paso rápido, te mete un //nolint:, se traga las excepciones en silencio, o se inventa abstracciones raras que ni al caso. Y si pones a un solo agente a revisar su propio código, el sesgo de confirmación hace que no vea sus mermas. De hecho, hasta creo que los agentes se aburren de tu proyecto y empiezan como niños de 5 años; a hacerse weyes. ;D
Para acabar de una vez por todas con esas alucinaciones y mañas, diseñé este loop iterativo, estricto y de cero confianza (zero-trust) que combina agentes de ataque Red-Team en parejas con auditoría Blue-Team hasta lograr un código 100% puro.
Note
El nombre le queda al putazo: un crisol es ese recipiente donde se funden los metales a temperaturas extremas para separar la escoria del oro puro. Eso mismito le hacemos al código aquí, compa.
La Revelación: Por qué Necesitaba una Pareja de Adversarios
En mis primeros experimentos hace meses, intenté usar un solo agente "revisor estricto". Pero me topé con dos extremos igual de malos:
- El sesgo de confirmación del creador:
- El agente que escribió la solución siempre defenderá su postura. Si cometió una falla de diseño, buscará el parche más superficial nomás para que pase la prueba rápido.
- La pedantería hiperbólica del revisor único:
- Si creas un agente súper mamón para revisar, empieza a alucinar problemas inexistentes, quejándose de patrones perfectamente válidos o exigiendo reescrituras masivas que nomás rompen todo.
- La trampa del "último chequeo" (flojera del orquestador):
- Otro problema bien común que detecté en la práctica es que, aunque le digas explícitamente al agente que revise en loop hasta que todo esté bien, el vato termina dándole instrucciones mañosas al sub-agente de QA de que "haga una última revisión rápida" para ya dar por terminado el jale, saltándose la verdadera convergencia.
La solución que descubrí tras meses de afinar el jale fue dividir la revisión de ataque en dos roles secuenciales: un atacante sin freno (extreme_adversary) seguido inmediatamente por un juez pragmático (measured_adversary), imponiendo reglas de parada estrictas donde el orquestador no puede decretar el cierre por su cuenta.
El Flujo de Desarrollo: TDD e Implementación a Ciegas
Es fundamental entender dónde encaja este protocolo dentro de todo el ciclo de ingeniería. El Protocolo Crisol no trabaja en el vacío; depende de una disciplina estricta de Desarrollo Guiado por Pruebas (TDD):
- Paso 1: Especificaciones y Hojas de Ruta: Primero se crean las especificaciones (técnicas, funcionales y de negocios) junto con el roadmap por fases.
- Paso 2: Generación de Pruebas (TDD Estricto): Se escriben las pruebas automatizadas (unitarias y de integración) directamente desde las especificaciones. Estas pruebas deben fallar al inicio.
- Paso 3: Implementación a Ciegas: El desarrollador construye el código guiándose únicamente por las especificaciones, sin leer las pruebas. Al implementar "a ciegas", se evita que el modelo haga trampa o maquille la lógica para complacer al test.
- Paso 4: El Protocolo Crisol: Una vez creada la implementación inicial, se desata el enjambre Red-Team/Blue-Team para refactorizar, auditar y pulir el código hasta alcanzar convergencia total.
El Enjambre: La Arquitectura del Protocolo Crisol
Dividimos la responsabilidad en cinco etapas bien delimitadas usando sub-agentes especializados:
┌─────────────────────────────────────────────────────────┐
│ 1a. EXTREME ADVERSARY (Ataque Hiper-Pedante) │
│ Busca hasta el mínimo olor a código y fallas de diseño │
└────────────────────────────┬────────────────────────────┘
│ (Pasa reporte de ataque)
▼
┌─────────────────────────────────────────────────────────┐
│ 1b. MEASURED ADVERSARY (Adjudicación y Auditoría) │
│ Filtra alucinaciones y crea lista definitiva de tareas │
└────────────────────────────┬────────────────────────────┘
│ (Entrega lista verificada)
▼
┌─────────────────────────────────────────────────────────┐
│ 2. DEVELOPER AGENT (Refactorización y Corrección) │
│ Aplica correcciones de raíz (Sin Expansión de Alcance) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. SECURITY QA (Verificación Blue-Team) │
│ Corre linter, pruebas automáticas y audita diffs │
└────────────────────────────┬────────────────────────────┘
│
├─── [Fallas en QA] ──► 4. Corregir y Re-verificar
│
▼ [Pasada Limpia]
┌─────────────────────────────────────────────────────────┐
│ 5. CONVERGENCE GATE (Loop Iterativo de Red-Team) │
│ Re-inicia la cadena de ataque hasta obtener 0 hallazgos │
└─────────────────────────────────────────────────────────┘
Las 5 Etapas Explicadas Paso a Paso
- Etapa 1a: Ataque Encarnizado con extreme_adversary:
- Lanzamos primero al extreme_adversary (sin permisos de modificación de archivos). Su única misión es destrozar el código buscando violaciones a SOLID, acoplamiento lechozo, manejo deficiente de errores, falta de propagación de contextos y casos de borde no contemplados. Es súper pedante a propósito.
- Etapa 1b: Adjudicación Pragmática con measured_adversary:
- Aquí está la verdadera magia. Le entregamos el reporte de ataque al measured_adversary. Este agente entiende perfectamente que el adversario extremo es extraordinariamente hábil y capaz de detectar fallas sutiles que a cualquiera se le pasan, pero también sabe que la presión brutal que le impone su prompt extremo (que lo obliga a encontrar defectos a como dé lugar) a veces lo hace alucinar problemas inexistentes o exagerar nimiedades. El measured_adversary contrasta cuidadosamente cada reclamo contra el código real, filtra las alucinaciones provocadas por la presión del prompt, valida los defectos genuinos y emite la lista definitiva y verificada de tareas.
- Etapa 2: Refactorización por el Agente Desarrollador:
El desarrollador recibe únicamente la lista verificada y aplica las correcciones de raíz.
Important
Aquí rige la Directiva de No Expansión de Alcance: el desarrollador tiene estrictamente prohibido andar inventando características nuevas nomás porque sí. El loop es primordialmente para limpiar, refactorizar y reparar.
Sin embargo, existe una excepción de último recurso: si para resolver un problema de diseño grave o una falla estructural no queda más remedio que desarrollar una nueva implementación o un componente de soporte totalmente nuevo, esto se permite únicamente como medida excepcional de último recurso con el fin de sanar la arquitectura de raíz.
- Etapa 3: Verificación Blue-Team con security_qa:
- Una vez hechos los cambios, entra security_qa a ejecutar linters en seco (como golangci-lint run), correr la suite de pruebas unitarias y verificar que los diffs no introduzcan vulnerabilidades de seguridad ni regresiones.
- Etapa 4: Convergencia de QA:
- Si security_qa detecta el menor detalle o advertencia de compilación, el desarrollador lo corrige de inmediato y se vuelve a auditar hasta obtener un pase 100% impecable.
- Etapa 5: Gate de Convergencia Final:
- Una vez que QA aprueba, volvemos a lanzar la cadena de ataque Red-Team completa (Etapas 1a y 1b). El protocolo termina ÚNICAMENTE cuando ambos adversarios declaran 0 hallazgos (VERDICT: APPROVE - 0 ISSUES FOUND).
Cómo Implementar las Personas de los Sub-Agentes
Para que esto te jale al cien en tu entorno (ya sea con Antigravity, Opencode o la herramienta de agentes que utilices), te comparto las definiciones clave de los prompts que uso:
Prompts del Red-Team:
{
"extreme_adversary": {
"role": "Extreme Adversarial Code Reviewer",
"prompt": "Inspect code brutally and pedantically. Hunt for architectural smells, coupling leaks, SOLID violations, error swallowing, missing context propagation, and unhandled edge cases.",
"enable_write_tools": false
},
"measured_adversary": {
"role": "Measured Adversarial Auditor",
"prompt": "Evaluate extreme_adversary's report against the codebase. Understand that extreme_adversary is highly skilled at finding subtle bugs but prone to hallucinating or exaggerating due to extreme prompt pressure. Filter out hyper-pedantic noise, exaggerations, or hallucinations. Validate genuine defects and deliver the definitive task list.",
"enable_write_tools": false
}
}
El Límite de Pasos y la Estrategia por Pasadas
Un detalle técnico crítico que descubrí en la práctica es que los agentes no deben intentar revisar todo el proyecto de un solo jalón. Si pretendes que un adversario audite un repositorio entero en una sola ejecución monolítica, el modelo se satura, se brinca archivos o termina haciendo una revisión superficial nomás por pura fatiga.
La clave está en fijar límites de pasos acotados y trabajar mediante múltiples pasadas enfocadas:
- Acotamiento por Dominio: En lugar de lanzar una auditoría global masiva, cada pasada del extreme_adversary se delimita a un módulo o paquete de dominio específico.
- Pasadas Progresivas: El agente procesa un conjunto acotado de archivos en cada iteración. Al limitar el presupuesto de pasos, fuerzas al modelo a profundizar de verdad en la arquitectura de ese bloque en lugar de andar explorando por encima.
- Convergencia Acumulativa: El loop del protocolo se repite haciendo varias pasadas secuenciales. Conforme se aprueba un módulo, la cadena avanza al siguiente hasta que todo el proyecto alcanza la convergencia total con cero hallazgos.
Reglas de Oro Aprendidas en el Campo de Batalla
- Cero Tolerancia a Parches Superficiales: Prohibido usar directivas para ocultar errores como //nolint: o bloques try/except: pass. Si el linter chilló, el código se reestructura bien.
- Manejo Explicito de Errores: Todo error debe ser capturado, logueado estructuradamente y envuelto (wrapping con %w en Go o el estándar equivalente en tu lenguaje).
- Bitácora Obligatoria de Sesión con mi protocolo PJP: Registra cada iteración completada en la bitácora del proyecto usando la CLI de mi protocolo PJP (Project Journaling Protocol) mediante ajourn log para mantener trazabilidad inalterable de las decisiones de diseño.
Tip
Llevo meses usando este protocolo en módulos críticos donde un fallo en producción sale muy caro. La neta, el tiempo extra que toma la convergencia se paga solo con la tranquilidad de tener un código impecable.
Note
Para que el Protocolo Crisol brille en todo su esplendor, se complementa de maravilla con mi estructura de especificaciones (specs) y roadmaps por fases. Mis especificaciones no son cualquier borrador rápido; abarcan tres niveles clave: técnicos, funcionales y de negocios, lo que le da a los agentes los límites exactos de la arquitectura y la visión del proyecto. Ese tema de la metodología de especificaciones y roadmaps está tan chingón que merece su propio espacio, así que te lo platicaré a detalle en un próximo artículo.
Conclusión
El Protocolo Crisol demuestra que la mejor forma de trabajar con IA no es pedirle que haga todo a la primera, sino poner a competir a agentes especializados dentro de una estructura de cero confianza. La separación entre ataque y adjudicación es lo que marca la diferencia entre un código parcheado y una arquitectura sólida como roca.
Pruébalo en tu próximo refactor complejo y verás cómo cambia la jugada. ¿Qué te parece este enfoque? ¡A poco no está perrísimo, no?!