Copiloto, no piloto automático.

01 Filosofía

Las personas deciden. La IA ejecuta y se audita.

Usamos IA para construir con más control, no para delegar el criterio. Tres principios guían todo lo demás:

• Una persona define qué se construye y aprueba qué sale a producción.
• Un desacuerdo entre modelos lo decide el que no escribió el punto, y cada PR lo revisan dos jueces independientes y ciegos.
• Lo que no se verificó se dice, no se esconde.

02 Orquestación y agentes

Un orquestador, agentes especializados y un escritor a la vez.

Un orquestador coordina y delega. Cada tarea va a un agente con un rol acotado, y cada agente entrega un resultado que el orquestador sintetiza.

Hay un escritor a la vez por worktree de git, una copia aislada del repositorio. Así varios frentes avanzan en paralelo sin pisarse: por ejemplo, un prototipo visual, un cambio de tipografía y un estudio de diseño al mismo tiempo.

03 Dos modelos

Claude y Codex: dos empresas, dos opiniones.

Claude, de Anthropic, orquesta y construye. Codex, de OpenAI, es la segunda opinión independiente.

Codex revisa automáticamente, en solo lectura, los cambios sin commitear al cerrar un turno de trabajo; si el turno ya hizo commit, si nada nuevo cambió o si ya hay una revisión en curso, esa vuelta se salta. Puede señalar problemas, pero no escribir código. Sus hallazgos entran como evidencia que hay que verificar, no como órdenes.

Cómo usamos Codex y ChatGPT →

Revisión cruzada a ciegas

Para los cambios que lo merecen usamos cross-model-review, una revisión doble en la que un desacuerdo lo decide el modelo que no escribió el punto:

1. 01

   Se congela el cambio

   Los dos modelos analizan exactamente la misma versión.

2. 02

   Análisis independiente

   Cada modelo revisa por su cuenta, sin ver el trabajo del otro.

3. 03

   Examen cruzado

   Cada uno examina los hallazgos del otro y el autor responde.

4. 04

   Arbitraje sin conflicto de interés

   Un punto en disputa lo resuelve solo el modelo que no lo planteó. Los hallazgos van anónimos.

5. 05

   Consenso calculado

   El consenso lo calcula el código; nunca se le pregunta a un modelo.

04 Judgment day

Dos jueces ciegos en cada pull request.

Cada pull request lo revisan dos jueces independientes y ciegos, cada uno en su propio worktree, sin ver el trabajo del otro. Son agentes de Claude en contextos separados, no el otro modelo. No se limitan a leer el código:

• Hacen pruebas de mutación: rompen el código a propósito para demostrar que los tests lo detectarían.
• En este sitio, además, compilaron la versión de producción y la midieron en un navegador real.

Los hallazgos confirmados se corrigen, con un máximo de dos rondas de corrección. Si después queda algo crítico, se escala a una persona en lugar de publicarse.

05 Skills y reglas

Instrucciones versionadas, las mismas para los dos modelos.

Una skill es una instrucción reutilizable y versionada: cómo dividir un commit, cómo revisar una animación, cómo escribir un registro de decisión. Tenemos una biblioteca compartida de más de 50, que Claude y Codex usan a través de adaptadores mínimos. Cada repositorio indica cuáles aplican.

• Flujo de features
• Judgment day
• Commits por unidad de trabajo
• PRs encadenados
• Registros de decisión (ADR)
• Runbooks
• Diseño (impeccable)
• Revisión de animaciones
• Guías de interfaz web
• Seguridad OWASP
• Revisión entre modelos

Reglas

Un reglamento global y las reglas de cada repositorio (CLAUDE.md o AGENTS.md), que las dos herramientas leen. Algunas de ellas:

• Ningún secreto en el código: los valores viven fuera de él, en un gestor de secretos y en la máquina del operador; el repositorio de operaciones solo guarda sus nombres en un inventario.
• Imágenes de contenedor con versión fija y healthcheck.
• Commits convencionales.
• Todo pasa por pull request y revisión.
• Nunca se fusiona con la integración continua en rojo.

06 Memoria

Lo aprendido una vez no se vuelve a aprender.

Las decisiones, los descubrimientos y las trampas encontradas se guardan en Engram, una memoria persistente, con claves por tema. Al empezar cada sesión se recupera lo relevante, y al cerrarla se guarda un resumen.

Así, una lección aprendida en un proyecto queda disponible en la siguiente sesión, en lugar de depender de que alguien la recuerde.

07 Infraestructura documentada

La infraestructura también es un registro de decisiones.

Nuestra infraestructura vive en un repositorio propio, ops, como decisiones documentadas y no como conocimiento en la cabeza de alguien.

En el repositorio de operaciones, el AGENTS.md lleva las mismas reglas duras que el CLAUDE.md, así cualquiera de las dos herramientas puede operarlo con las mismas reglas.

08 Plantillas

Plantillas con el equipo de agentes incluido.

launchkit-optimized

Nuestra plantilla de proyecto trae un orquestador y 12 agentes especializados en tres departamentos.

landing-forge

Un pipeline de skills que construye una landing a partir de un prompt. Cada paso tiene exactamente un responsable, y nada se publica hasta que una persona lo revisó.

09 SDD

Especificar antes de construir, cuando hace falta.

Para el trabajo ambiguo usamos desarrollo guiado por especificaciones (SDD). Es opcional: un cambio claro no necesita esta ceremonia, uno ambiguo sí.

1. 01

   Explorar

   Entender el código y el problema antes de proponer nada.

2. 02

   Proponer

   Intención, alcance y enfoque.

3. 03

   Especificar

   Requisitos y escenarios verificables.

4. 04

   Diseñar

   Decisiones técnicas y sus alternativas.

5. 05

   Dividir en tareas

   Pasos pequeños y ordenados.

6. 06

   Aplicar

   Construir siguiendo las tareas.

7. 07

   Verificar

   Comprobar que lo construido cumple la especificación.

8. 08

   Archivar

   Cerrar el ciclo y conservar lo decidido.

10 El circuito completo

De tu idea a producción.

1. 01

   Tu idea

   Nos cuentas el problema. Si es ambiguo, lo especificamos antes de escribir código.

2. 02

   Prototipo en vivo

   Diseñamos una vista previa que puedes abrir y aprobar antes de construir.

3. 03

   Construcción en paralelo

   El orquestador reparte el trabajo; un escritor a la vez en cada copia aislada, guiado por skills y reglas.

4. 04

   Revisión de lo no commiteado al cerrar cada turno

   Codex revisa en solo lectura los cambios sin commitear; si no hay nada nuevo o ya hay una revisión en curso, se salta. Sus hallazgos se verifican, no se obedecen.

5. 05

   Pull request y jueces

   Dos jueces independientes y ciegos (agentes de Claude) revisan antes de producción y rompen el código a propósito para probar los tests. Hasta dos rondas de corrección.

6. 06

   Integración continua en verde

   Nunca se fusiona con la integración continua en rojo.

7. 07

   Tu aprobación

   Lo revisas funcionando y das el visto bueno. Sin él, nada sale.

8. 08

   Producción

   Se publica, y lo aprendido queda en la memoria para la próxima vez.

11 Lo que la IA no hace

Dónde se detiene la máquina.

• No decide qué se construye: eso lo decides tú.
• No publica en producción sin el visto bueno de una persona.
• No se da por buena sola: Codex revisa los cambios sin commitear y, en cada PR, dos jueces independientes.
• No insiste sin fin: tras dos rondas de corrección, lo crítico se escala a una persona.
• No esconde lo que no verificó: si una revisión no probó Safari o Firefox, el informe lo dice.
• No guarda secretos en el código ni en el repositorio de operaciones: solo sus nombres.