Flujo de trabajo de desarrollo VM0: Gestionando agentes de IA como un equipo

En el equipo de desarrollo de VM0, cada desarrollador trabaja con múltiples instancias de Claude Code al mismo tiempo. Usualmente más de ocho.

Tratamos a Claude Code de la misma manera que tratamos a un desarrollador real. (Sí, nuestra empresa se llama medio en broma AI Colleagues Co!)

Debido a eso, la filosofía de diseño detrás del flujo de trabajo de desarrollo VM0 refleja las prácticas clásicas de gestión de equipos en ingeniería de software.

Usamos GitHub Issues para rastrear el trabajo, Pull Requests para revisión de código y fusión, y GitHub Actions para manejar la automatización. Durante dos meses, esta configuración nos ayudó a lanzar 404 releases y escribir más de 230,000 líneas de código.

Esta publicación explica cómo logramos que esto funcionara, y por qué el problema clave nunca fue la capacidad de la IA, sino la coordinación humana.

Flujo de trabajo de desarrollo impulsado por IA en la práctica

Cuando coordinas muchos agentes de IA en paralelo, el cuello de botella no es si el modelo puede escribir código. El verdadero cuello de botella es la carga cognitiva humana.

Este flujo de trabajo consiste en 14 comandos slash, organizados en tres capas: Deep Dive, Gestión de Issues y Gestión de PRs.

Primero veamos cómo se ve mi flujo de trabajo y cómo se construye típicamente una funcionalidad.

1. Alineación de requisitos

   Un humano abre una sesión de Claude y comienza con /deep-research. Claude recopila información de la base de código, documentación y contexto relevante. Discutimos los hallazgos y nos alineamos sobre qué problema estamos realmente resolviendo.

2. Exploración de soluciones

   Usando /deep-innovate, Claude propone varias direcciones posibles, con compromisos. Discutimos, reducimos opciones y elegimos una dirección.

3. Creación de issue

   Creamos un issue de GitHub usando /issue-create. El humano revisa el issue para asegurarse de que los requisitos estén claramente capturados.

4. Planificación y aprobación

   Usa /issue-todo para permitir que Claude continúe el trabajo. Claude ejecutará automáticamente el flujo completo de deep-dive y publicará los resultados en el issue, incluyendo:

   1. hallazgos de /deep-research
   2. comparaciones de /deep-innovate
   3. un plan de implementación concreto de /deep-plan

5. Implementación

   Después de la aprobación, /issue-continue permite que Claude implemente el plan, escriba pruebas, abra un PR y asegure que el CI pase.

6. Revisión y fusión

   Usamos /pr-review-and-comment para una revisión estructurada, luego hacemos la revisión humana final antes de fusionar.

   El humano interviene en tres puntos de control: requisitos, dirección y aceptación. Todo lo demás se ejecuta de forma autónoma.

Cambio de mentalidad: estás liderando un equipo de desarrolladores de IA

El momento en que me di cuenta de que necesitábamos un flujo de trabajo estructurado fue cuando agregar más sesiones de Claude en realidad empeoró las cosas. Cuantas más instancias ejecutaba en paralelo, más difícil se volvía rastrear qué estaba haciendo cada una, en qué estado estaba el trabajo y qué ya se había decidido.

Sin herramientas externas, simplemente no podía gestionar tantas instancias de Claude a la vez. Ahí fue cuando lo comprendí: esto no era un problema de IA, era un problema de gestión.

GitHub ya es la herramienta natural para la colaboración en el desarrollo de software, así que en lugar de inventar algo nuevo, comencé a tratar a Claude de la misma manera que trato a un compañero de equipo humano. Una vez que hice eso, mi capacidad de gestión se escaló repentinamente.

Diez años de experiencia en gestión de proyectos y equipos finalmente cobraron sentido en este nuevo contexto. Al tratar a Claude como un miembro del equipo y a GitHub como nuestro espacio compartido de comunicación y gestión, todo el sistema se volvió manejable nuevamente.

Un buen líder de equipo sabe cuándo involucrarse y cuándo dar un paso atrás:

Punto de control	Lo que hago yo	Lo que hace la IA
Requisitos	Alinearse sobre el problema, aclarar el alcance	Investigar la base de código, recopilar contexto
Dirección	Revisar hallazgos, aprobar enfoque	Proponer 2-3 enfoques, evaluar compromisos
Aceptación	Revisar PR, verificar calidad	Implementar, probar, corregir CI

Esto refleja cómo operan los equipos de software efectivos. No microgestiono a los desarrolladores, sino que establezco requisitos claros, reviso decisiones clave y verifico el resultado final. El mismo principio se aplica al gestionar agentes de IA.

El flujo deep dive fuerza un pensamiento estructurado y pausado

El flujo de trabajo deep dive obliga a un pensamiento deliberado antes de la implementación. A veces Claude llega a un callejón sin salida. Cuando eso sucede, forzamos a Claude a detenerse y pensar, y luego lo discutimos juntos. Tiene tres fases:

Fase	Comando	Propósito	Resultado
Research	/deep-research	Recopilar hechos, entender contexto	research.md
Innovate	/deep-innovation	Explorar múltiples enfoques	innovate.md
Plan	/deep-plan	Definir pasos concretos	plan.md

Cada fase tiene límites estrictos.

• Research: no se permiten sugerencias
• Innovate: no se permiten detalles
• Plan: no se permite implementación

Estas restricciones fuerzan a Claude a un razonamiento lento y deliberado en lugar de saltar directamente al código. Sin ellas, a menudo se pierden casos extremos y preocupaciones arquitectónicas.

Ejemplo de uso

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude investiga, analiza 12 archivos relacionados, encuentra 3 patrones similares]

/deep-innovate what are our options for fixing this?

[Claude presenta 3 enfoques con compromisos, tú eliges uno]

/issue-create let's track this fix

Para tareas simples, puedes omitir el deep dive e ir directamente a /issue-create.

Para tareas complejas con incertidumbre técnica, las fases de deep dive ayudan a asegurar que tú y Claude estén alineados antes de que comience la implementación.

Usar GitHub como memoria compartida

La mayoría de las herramientas de IA tratan el contexto como temporal. Cuando la sesión termina, la memoria desaparece.

VM0 usa GitHub como memoria persistente:

Funcionalidad de GitHub	Qué almacena
Cuerpo del issue	Requisitos y decisiones
Comentarios del issue	Investigación, opciones, planes
Comentarios del PR	Revisiones y resúmenes
Labels	Estado del flujo de trabajo

Esto también resuelve un problema humano: recuperación de contexto.

Cuando estoy gestionando más de 8 instancias de Claude, recibo notificaciones de que el trabajo está completo. Pero no puedo reconstruir a partir de la conversación de Claude qué estaba haciendo, qué decisiones se tomaron o cuál es el estado actual.

Los issues de GitHub resuelven esto. Cada issue muestra:

• Los requisitos originales
• Hallazgos de investigación (qué se descubrió)
• Fase de innovación (qué opciones se consideraron)
• El plan aprobado (qué se implementará)

Este formato estructurado hace que la revisión sea eficiente. Así puedo escanear rápidamente las fases, entender el enfoque y aprobar o solicitar cambios, todo sin necesidad de recordar la conversación original.

Cuando el trabajo termina, no necesito recordar qué sucedió en una ventana de chat. Puedo abrir el issue y ver la historia completa, estructurada y escrita.

Transferencia entre agentes

Dado que todo el contexto vive en GitHub, el trabajo puede moverse entre agentes sin problemas:

• Un agente crea un issue o PR
• Otro continúa más tarde usando /deep-research issue 123 o /issue-todo 123 o /deep-research PR 124

Para discusiones largas, /issue-compact consolida todo en un cuerpo de issue limpio. Esto hace que las transferencias sean fáciles tanto para humanos como para IA.

Resumamos los patrones del flujo de trabajo

Después de todo eso, déjame resumir algunos consejos prácticos.

Tareas simples

/issue-create → /issue-todo → /issue-continue → /pr-check-and-merge

Usa esto cuando los requisitos son claros y el trabajo es directo.

Tareas complejas

/deep-research → discusión → /deep-innovate → discusión →
/issue-create → /issue-todo → /issue-continue →
/pr-review-and-comment → /pr-check-and-merge

Esto previene el esfuerzo desperdiciado en el enfoque equivocado.

Trabajo en paralelo

Múltiples agentes pueden trabajar a la vez mientras el humano revisa los puntos de control completados. Aquí es donde el flujo de trabajo escala mejor.

Agent 1: /issue-todo #123
Agent 2: /issue-todo #124
Agent 3: /pr-review-and-comment #100
Agent 4: /deep-research new feature requirements

Referencia de comandos

Comandos deep dive

Comando	Propósito
/deep-research	Recopilar información, entender la base de código. No se permiten sugerencias.
/deep-innovate	Explorar 2-3 enfoques, evaluar compromisos. No se permite código.
/deep-plan	Crear pasos concretos de implementación. No se permite implementación.

Comandos de issue

Comando	Propósito
/issue-create	Crear issue a partir del contexto de la conversación
/issue-bug	Crear reporte de bug con pasos de reproducción
/issue-feature	Crear solicitud de funcionalidad enfocada en requisitos
/issue-todo	Ejecutar flujo completo de deep-dive, publicar resultados en el issue
/issue-continue	Continuar implementación después de la aprobación humana
/issue-compact	Consolidar cuerpo del issue + comentarios para transferencia

Comandos de PR

Comando	Propósito
/pr-check	Monitorear pipeline de CI, auto-corregir, reintentar hasta 3 veces
/pr-check-and-merge	Monitorear CI y fusionar cuando todas las verificaciones pasen
/pr-review	Revisar PR commit por commit contra estándares del proyecto
/pr-review-and-comment	Revisar y publicar hallazgos como comentario del PR
/pr-comment	Resumir discusión de conversación en comentario del PR

Empezando

1. Comienza simple: Usa /issue-create → /issue-todo → /issue-continue para tu primera tarea
2. Agrega deep dive para tareas complejas: Cuando los requisitos no están claros o son técnicamente complejos, comienza con /deep-research
3. Escala gradualmente: Agrega más instancias de Claude a medida que te sientas cómodo con el ritmo de revisión
4. Confía en el proceso: Deja que Claude trabaje de forma autónoma entre puntos de control

El flujo de trabajo está diseñado para adoptarse de forma incremental. No necesitas usar los 14 comandos desde el primer día. Comienza con el flujo básico de issues, luego agrega fases de deep dive y trabajo en paralelo a medida que ganas confianza.

Consideraciones de escalabilidad: Qué hacer cuando tienes más agentes

El flujo de trabajo ha sido probado con más de 10 instancias concurrentes de Claude. Nuestra recomendación:

• Hasta 10 agentes: Cómodo para colaboración profunda con cada uno
• Más de 10: No recomendado

El factor limitante no es el flujo de trabajo, es la atención humana y la calidad de las decisiones. Cuando gestionas más de 10 agentes, corres el riesgo de convertirte en un cuello de botella en los puntos de control de revisión, y la calidad de las decisiones comienza a degradarse.

El principio clásico del "equipo de dos pizzas" se aplica aquí. Las mismas restricciones que limitan el tamaño del equipo humano también limitan cuántos agentes de IA puede gestionar efectivamente una persona.

Actualmente estoy explorando una estructura de equipo de dos niveles 8×8 para escalar más allá de 10 agentes, pero aún no he desarrollado prácticas efectivas. Compartiré más cuando haya resultados concretos...

El flujo de trabajo de desarrollo VM0 cambia cómo pensamos sobre el desarrollo de software cuando la IA se convierte en parte del equipo.

Cuando tratas a los agentes de IA como miembros del equipo en lugar de herramientas, todo encaja en su lugar. GitHub se convierte en la memoria compartida de tu equipo. Los issues se convierten en elementos de trabajo. Los PRs se convierten en entregables. Y tú te conviertes en el líder del equipo, enfocándote en la arquitectura, dirección y calidad mientras tu equipo de IA maneja la implementación.

Así es como lanzamos 404 releases en 2 meses. Y así es como puedes escalar tu propio desarrollo con IA.