CodeConductor: de prompts sueltos a un sistema de ingeniería orquestado
Cómo convertí el prompting ad-hoc en un framework open source de orquestación multi-agente —para que planificar, implementar, probar y revisar dejen de depender del "chat de la suerte" y se vuelvan un flujo reproducible.
Targets de instalación: opencode · claude · codex · agy · cursor · gemini
El Reto
En 2026 el tooling de coding con IA ya no era el cuello de botella: lo era la falta de sistema. Una sesión brillante; la siguiente, el mismo modelo inventaba arquitectura, saltaba pruebas o "arreglaba" lo que nadie pidió. Lo vi en mi práctica y en equipos con Claude Code, Codex, Cursor u OpenCode.
- → Prompts sin contrato: la intención vivía en la cabeza de quien chateaba. Sin task card, sin criterios de aceptación, sin rastro versionado.
- → El modelo como "el desarrollador": diseñar, implementar, probar y auto-aprobar en un solo rol —sin veto ni quorum.
- → Flujos no portables: lo que funcionaba en un IDE no se instalaba limpio en otro; skills y comandos eran artesanales.
- → Riesgo sin routing: un cambio cosmético y uno de seguridad entraban por el mismo tubo.
El objetivo: dejar de prompting y empezar a orquestar. Un framework —no un wrapper de un solo vendor— que trate a los modelos como trabajadores especializados, con contratos, loops y control humano. Stop prompting. Start orchestrating.
La Arquitectura y Decisiones Técnicas
Opté por un CLI/framework en TypeScript, npm cc-codeconductor, con instalación multi-target y una filosofía explícita: modelos como workers, no como reemplazo del desarrollador. Encima: contratos de agente versionados, task cards y routing por riesgo.
Antes — Prompting caótico
Después — Orquestación CodeConductor
¿Por qué un framework y no otro prompt pack?
Un pack se pudre en una semana. Necesitaba install, migrate, doctor/status/version/update y presets por target. CodeConductor detecta el entorno y deja skills/comandos coherentes —no un gist copiado a mano.
Workers especializados + council
Diseñé 15 Conductor Agents con roles acotados (reviewer, security-reviewer, complexity-auditor, entre otros). El de seguridad no implementa features; el implementador no se auto-aprueba. El council aplica quorum y veto cuando el riesgo lo exige.
Loop CCEP + OpenSpec
En lugar de "hazlo todo", el flujo se descompone hasta materializar la task card. OpenSpec y el scorecard cierran con evidencia, no con "parece que quedó bien".
Skills de stack y multi-target
Skills por ecosistema (ts-next-drizzle, spring-kotlin-jpa, laravel-tall, python-data-api) para hablar el idioma del repo. Mismo sistema si el equipo vive en Cursor o en Claude Code.
Lo que aún no es (a propósito): sin runtime sandbox, policy compiler ni pruning completo de assets. Preferí un 1.5.x estable a un roadmap inflado: esas piezas quedan como trabajo futuro explícito.
El Impacto
Contratos, task cards y roles: el loop planificar → implementar → probar → revisar se puede retomar, auditar y migrar.
opencode, Claude, Codex, AGY, Cursor y Gemini. Baja el costo de cambiar de IDE sin forks mentales.
Fricción en seguridad y complejidad, velocidad donde no. Ingeniería, no autocompletado con superpoderes.
Lección clave
El problema no es "mejorar el prompt": es diseñar un sistema donde la IA tiene contratos, límites y un lugar en el SDLC. Tratar al modelo como oráculo invita al caos; tratarlo como worker especializado —con task cards, consenso y veto— convierte la asistencia en ingeniería. CodeConductor es esa apuesta: en evolución, usable en 1.5.x.
Stack Utilizado
¿Tu equipo está ahogado en prompts brillantes pero irreproducibles?
Hablemos de orquestación, contratos de agente y cómo meter IA en el flujo real de entrega —sin magia y con gobernanza.