Anthropic acaba de abrir a usuarios de Pro y Max una versión de Claude Code Projects donde un coordinador reparte una tarea entre varios hilos de trabajo que corren en paralelo, cada uno en su propia rama, con su propia copia del repositorio, abriendo pull requests y corriendo tests por su cuenta. Comparten memoria del proyecto y una biblioteca común de archivos. Si tu equipo todavía le pide a sus agentes de código tareas sueltas por chat, esto debería preocuparte un poco: la diferencia entre que ese paralelismo funcione o genere un caos de pull requests contradictorios no está en el modelo, está en si existe una especificación clara de la que cada agente pueda partir.
El problema que nadie te cuenta del "vibe coding" en equipo
Un desarrollador solo, iterando con un agente en su propia máquina, puede darse el lujo de pedir algo vago, ver qué sale y corregir sobre la marcha. En un equipo de 8 o 15 personas, cada una con su propio agente, ese estilo escala mal. Dos desarrolladores le piden a sus agentes resolver el mismo problema con supuestos distintos, y terminan con dos soluciones que no encajan entre sí. El code review se vuelve una negociación sobre qué se supone que debía hacer el código, no sobre si está bien escrito. Y cuando alguien nuevo entra al equipo, no hay un documento que explique las decisiones, solo un historial de conversaciones con un agente que nadie más leyó.
Lo vemos seguido en el diagnóstico inicial con equipos técnicos: adoptaron agentes de código hace meses, la velocidad individual subió, pero la coherencia del producto bajó. Nadie lo nota hasta que dos features chocan en producción o hasta que el onboarding de alguien nuevo toma el triple de tiempo de lo normal porque no hay nada escrito que explique por qué el sistema es como es. Y la tentación, cuando eso pasa, es culpar a la herramienta y prohibir los agentes en vez de arreglar el proceso que los rodea.
Qué es Spec-Driven Development en la práctica
Spec-Driven Development (SDD) no es escribir un documento de requerimientos de 40 páginas antes de tocar código, como se hacía hace 20 años. Es escribir, antes de delegar una tarea a un agente, una especificación corta y concreta: qué problema resuelve, qué casos límite tiene que cubrir, qué contratos de API no se pueden romper y cómo se va a verificar que quedó bien. Esa spec se vuelve el contrato entre la persona que lidera la tarea y el agente (o los agentes) que la ejecutan. No reemplaza el criterio técnico del equipo, lo hace explícito antes de que el código exista.
- ▸El objetivo de negocio en una frase: qué cambia para el usuario o para el sistema si esto funciona.
- ▸Los contratos que no se tocan: endpoints, esquemas de datos, nombres de funciones que otros módulos ya consumen.
- ▸Los casos límite que importan de verdad (no los 20 que se te ocurren en cinco minutos, los 4 o 5 que de verdad rompen algo si fallan).
- ▸Cómo se valida: qué test, qué métrica o qué revisión humana confirma que la tarea quedó resuelta.
La pregunta que le hacemos a los equipos técnicos con los que hablamos no es "¿usan IA para programar?", eso ya lo da por hecho casi todo el mundo. Es "¿cualquiera de sus agentes podría tomar esta tarea mañana sin que ustedes tengan que explicarle nada por chat?". Casi nunca la respuesta es sí.
Cómo se ve esto en un equipo real
En los equipos que ya migraron a este modelo, la spec vive en el mismo repositorio, versionada junto al código, no en un Google Doc aparte que nadie vuelve a abrir. El tech lead o el PM técnico escribe o revisa la spec antes de asignar la tarea, sea a una persona o a un agente. Cuando el trabajo se reparte entre varios hilos paralelos, como en el esquema que acaba de abrir Anthropic, cada hilo trabaja contra la misma spec, así que el resultado final es coherente aunque lo hayan construido procesos distintos en paralelo. Y la revisión de pull request deja de ser una reconstrucción arqueológica de qué se quiso hacer: el revisor compara el resultado contra la spec, que es mucho más rápido y mucho más objetivo.
Un ejemplo concreto: un equipo de producto fintech con el que trabajamos tenía tres desarrolladores usando Claude Code cada uno a su manera para construir distintos módulos de un mismo flujo de pagos. Al escribir una spec compartida de apenas media página por módulo, con los contratos de API fijados desde el inicio, pasaron de integrar los tres módulos en dos días de ajustes manuales a integrarlos en una tarde, porque ya coincidían desde el principio en los nombres de los campos y en cómo se manejaban los errores.
No hace falta una herramienta especial para empezar. Muchos equipos arrancan con algo tan simple como un archivo markdown por tarea dentro del propio repositorio, que el agente lee antes de escribir una línea de código. Lo que importa no es el formato, es que exista y que todos lo usen de la misma manera. Herramientas como Claude Code ya soportan leer ese tipo de archivos de contexto de forma nativa, así que el costo de adopción técnica es mucho más bajo que el costo de cambiar el hábito del equipo.
Qué necesita tu equipo para dar el salto
No es una herramienta nueva que se compra, es un hábito que se entrena. Los equipos que lo logran bien suelen empezar por un piloto acotado: una sola squad, dos o tres sprints, con una plantilla de spec simple y un criterio claro de qué tareas sí se delegan a agentes y cuáles no. De ahí se expande. La parte técnica (cómo delegar trabajo a Claude Code de forma estructurada, cómo coordinar agentes que trabajan en paralelo sobre el mismo repo) es justo lo que cubrimos en la capacitación in-company para equipos de ingeniería. La parte de diseñar agentes y arquitecturas más complejas, más allá de un asistente de código, es terreno de ingeniería de agentes, y conviene que al menos una o dos personas del equipo la dominen antes de que el resto dependa de ellas para todo.
Lo que nadie te dice antes de empezar: el primer piloto va a ser más lento que programar como siempre, porque escribir una buena spec toma tiempo que antes no se tomaba nadie. La ganancia aparece en el segundo y tercer ciclo, cuando esa misma spec sirve para delegar la siguiente tarea parecida sin reexplicar nada, y cuando dos agentes trabajando en paralelo no pisan el trabajo del otro.
- ▸Señal de que tu equipo ya está listo: más de la mitad de los pull requests necesitan una ronda extra solo para aclarar qué se quiso hacer, no para corregir errores de código.
- ▸Señal de que tu equipo ya está listo: dos o más desarrolladores usan agentes de código a diario, pero cada uno con su propio estilo de prompts, sin ningún estándar compartido.
- ▸Señal de que tu equipo ya está listo: el onboarding de una persona nueva depende de que alguien le explique el sistema en vivo, porque no hay nada escrito que lo documente.
Si quieres que tu equipo de desarrollo pase de usar IA de forma suelta a trabajar con Spec-Driven Development de verdad, conversemos en DataPath para Empresas: Spec-Driven Development. El diagnóstico inicial no tiene costo, y de ahí armamos un plan sobre el stack y los repositorios reales de tu equipo, no sobre un caso genérico. Lo que aprendería tu equipo en el camino parte de Claude Code para equipos de desarrollo.
