Dual-Brain — la habilidad para añadir un “flujo de trabajo de debate de hemisferio izquierdo y derecho” a Codex/Claude Code

Hola. Quiero presentar Dual-Brain, un protocolo de habilidades en expansión que estoy desarrollando como proyecto open source, pensado para usarlo recientemente con Codex o Claude Code en trabajo real y reducir problemas como que un LLM se sobrecargue fácilmente al escribir código complejo o revierta decisiones anteriores.

Dual-Brain se parece menos a repartirle al AI cargos como “PM / desarrollador / QA” y más a separar las funciones de pensamiento con las que observa el problema.

En lugar de que un solo agente dé una respuesta de inmediato, se le obliga a pasar en orden por un interrogatorio de contexto en el papel del hemisferio derecho y una verificación lógica en el papel del hemisferio izquierdo, para que luego el orchestrator sintetice el resultado final.

1. Tres modos de falla de la ejecución tradicional con un solo agente

Cuando se le encarga de una sola vez a un LLM en la terminal un diseño de arquitectura complejo o un refactor, normalmente aparecen con frecuencia los siguientes problemas.

• La trampa de tomar el texto al pie de la letra
  Acepta requisitos ambiguos tal como vienen y luego construye con seguridad código equivocado.
• El infierno de los detalles
  Se atasca en sintaxis de código microscópica y edge cases, y pierde de vista rutas arquitectónicas más simples y mejores.
• El bucle de amnesia
  Cuando termina la sesión, desaparece el contexto anterior, así que en la siguiente sesión vuelve a revertir la dirección de arquitectura que ya se había decidido la semana pasada.

2. La solución: dos funciones de pensamiento

Cuando se carga Dual-Brain, el agente principal asume el rol de orchestrator y no responde de inmediato. En cambio, ejecuta dos etapas internas de revisión en un orden definido.

• Hemisferio derecho, Right Brain: contexto / patrones / interrogatorio
  No implementa de inmediato lo que pide el usuario, sino que primero lo pone en duda. Examina preguntas como “¿Cuál es el punto ciego de este requisito?”, “¿No entra en conflicto con decisiones anteriores?” y “¿La terminología no es ambigua?”.
• Hemisferio izquierdo, Left Brain: lógica / verificación / código
  Compara la definición del problema creada por el hemisferio derecho con el codebase real, la documentación oficial y la memoria del proyecto. Filtra APIs alucinadas, supuestos desactualizados y diseños imposibles de implementar, y los refina hasta volverlos ejecutables.

Al final, el orchestrator sintetiza ambos resultados para continuar hasta cambios de código, documentación y actualización de memoria.

3. Sistema de niveles de memoria

La habilidad guarda memoria de largo plazo en .dual-brain/MEMORY.md dentro de la raíz del proyecto.

Pero a medida que el proyecto crece, puede surgir el problema de que decisiones muy antiguas y restricciones activas de la semana pasada se mezclen con el mismo peso. Para resolverlo, la memoria no se trata como un documento plano, sino como memoria por niveles.

• Hot Memory
• Warm Memory
• Cold Memory
• Archived Decisions

Hot Memory contiene decisiones activas y restricciones que influyen fuertemente en el trabajo actual.

Warm Memory es contexto útil que solo se lee en tareas relacionadas.

Cold Memory y Archived Decisions no se leen completas por defecto; solo se consultan cuando hace falta una búsqueda por palabras clave o una validación de conflictos.

refs no aumenta simplemente por haber leído algo, sino solo cuando realmente influyó en preguntas, verificación, síntesis o implementación.

Las memorias antiguas o duplicadas se comprimen automáticamente, y las decisiones contradictorias o descartadas se envían a Archived.

La información sensible, tokens, keys y datos personales no se almacenan ni se resumen; se tratan como contenido que debe eliminarse o no guardarse.

Lo importante es que la memoria no es la fuente de verdad. En Dual-Brain, la memoria es contexto de apoyo, y el código actual y la documentación oficial tienen prioridad sobre la memoria desactualizada.

4. Benchmark

El repo incluye, con base en Codex, un pequeño benchmark harness que compara el enfoque single-agent con el enfoque Dual-Brain.

Dual-Brain no es un enfoque rápido. Más bien, busca hacer pensar más al modelo al principio para reducir después el ciclo en el que una persona tiene que volver a corregir y explicar.

5. Instalación

Si usas SkillsGate, puedes instalar y administrar la habilidad en entornos de Codex CLI y Claude Code.

npx skillsgate add sleeplesshan/dual-brain -g  
La instalación manual también es posible.  
 - Codex  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.codex/skills/dual-brain  
 - Claude Code  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.claude/skills/dual-brain  
Después de la instalación, puedes invocarlo como siempre usando lenguaje natural.  
  
6. Cuándo conviene usarlo  
Dual-Brain es excesivo para cambios simples. No hace falta usarlo para renombrar variables, corregir un bug de una sola línea o generar boilerplate claro.  
En cambio, encaja bien en estas situaciones.  
- refactors con requisitos ambiguos  
- decisiones de arquitectura  
- integración con APIs o SDKs desconocidos  
- cambios que podrían entrar en conflicto con decisiones anteriores  
- trabajos donde una API alucinada podría convertirse en una falla real  
- tareas en las que piensas “ni siquiera sé si estoy haciendo la pregunta correcta ahora mismo”  
  
He publicado como open source (licencia MIT) el `SKILL.md` completo y el benchmark harness.  
 Me gustaría recibir feedback de personas interesadas en el diseño de LLM orchestration, prompt engineering y memoria para agentes.