Crew coding: cómo construimos con una tripulación de agentes de Claude Code

En NORKÄRŸM construimos todos los productos con Claude Code. No lo hacemos con un solo agente que lo hace todo, sino con una tripulación: muchas sesiones a la vez, cada una con un trabajo, revisadas por otras y con unas reglas escritas. Lo llamamos crew coding. No es «vibe coding»: hay roles, revisores y reglas.

Una sesión, una tarea

En un solo ordenador trabajan varias sesiones de Claude Code a la vez. Cada una se ocupa de una parte: una app, un módulo o un proyecto.

Cada sesión trabaja en su propia carpeta (un worktree de git) y con su propia banda de puertos. Así ninguna sesión toca los ficheros de otra, ni el entorno donde trabajan las personas.

La documentación de Claude Code explica cómo abrir sesiones en paralelo con worktrees para que las ediciones no choquen. Nosotros hemos llevado esa receta a un equipo entero.

Las sesiones que coordinan

Unas cuantas sesiones no construyen producto: coordinan. Cada una lleva el nombre de su rol. Ninguna gobierna: ven, avisan, reparten el trabajo o ejecutan lo que ha decidido una persona.

• Panel: lo que espera una decisión de la persona, y las versiones que salen al público.
• Mensajes: entre sesiones, y cada decisión de una persona hasta quien debe ejecutarla.
• Impuestos y legal: las dudas las lleva a la persona responsable y a la asesoría.
• Seguridad: claves y contraseñas, permisos, software de terceros y revisiones.
• Pantallas: la línea visual; revisa cada cambio de pantalla.
• Pruebas: las pruebas automáticas que fallan, los controles de calidad y las pruebas de usar la app en un entorno de prueba.
• Herramientas: para los agentes: avisos automáticos, programas pequeños y guías de trabajo.
• Máquina: memoria, espacio en disco y coste del ordenador.
• Orden: lo que nadie espera: el trabajo olvidado y la limpieza semanal.
• Versiones: las versiones que salen al público.

Las reglas que lo hacen fiable

• La primera regla: no inventar nada. Ningún agente dice que algo está hecho, probado o decidido si no lo está. «No lo sé» es una buena respuesta, y quien duda pregunta a quien lo sabe.
• Primero el plan, después el código. Una función, una pantalla o un permiso nuevo empieza con un plan corto por escrito, y lo revisan a la vez los revisores de pantalla, de seguridad y de legal, antes de que haya código.
• Cada fusión en nuestros productos necesita el sí de una persona.
• El trabajo pesado (instalaciones, compilaciones, pruebas, capturas) pasa por una cola compartida, para que la máquina no se ahogue.
• Todos los mensajes entre agentes usan un solo formato (INFO, PREGUNTA o BLOQUEO) y van firmados, para que una persona sepa siempre quién ha dicho qué.
• Las lecciones aprendidas se apuntan donde todos los agentes pueden leerlas.

Lo que hace siempre una persona

Hay cosas que ningún agente hace por su cuenta: decidir que un trabajo se fusiona o se publica, promover una versión, decidir sobre el producto y el dinero, y dar secretos. Los agentes lo preparan, lo prueban y lo explican; la decisión es de una persona.

La documentación de Claude Code recomienda planificar antes de editar. Nosotros le añadimos algo: el plan lo leen revisores distintos a la vez, y quien decide es una persona.