PulseFlow Tecnologia
← Insights
·7 min de lectura·guia-tecnica·spec-driven-development·coding-agents·code-review
PulseFlow Tecnologia

Cómo diseñar un coding agent workflow con especificación, rama, pruebas y revisión

Un coding agent workflow bien diseñado combina tres piezas que ya existen por separado en productos reales: la estructura de especificación del Spec Kit de GitHub, el flujo de PR del Copilot coding agent, y el modelo de ejecución aislada de Codex de OpenAI. Juntas, forman un workflow completo - de la idea al merge.

La issue o el requisito se convierte en especificación, no en un prompt suelto

El Spec Kit de GitHub separa esto en cuatro fases explícitas. La primera, "Specify", describe "user journeys, experiences, y qué significa el éxito" - no detalles técnicos de implementación. Esa es la diferencia fundamental entre el spec-driven development y lo que el propio GitHub llama "vibe coding": describir un objetivo y recibir un bloque de código, con un resultado a menudo impreciso, frente a proporcionar una especificación clara que fuerza "claridad sobre cómo debe interactuar con los sistemas existentes" antes de escribir una sola línea.

El plan del agente antes de la ejecución

La segunda fase del Spec Kit, "Plan", define el stack tecnológico, la arquitectura y las restricciones. La tercera, "Tasks", divide la especificación en "trabajos pequeños y revisables que resuelven piezas específicas" - el equivalente a dividir un requisito grande en unidades que caben en un solo PR revisable.

Rama aislada y ejecución

Aquí es donde encaja el flujo del Copilot coding agent: el agente abre un pull request en borrador, marcado como [WIP], en una rama dedicada (copilot/*), aislada de la rama principal. La ejecución en sí sigue el modelo que OpenAI documentó con Codex - corriendo dentro de un entorno aislado, leyendo y editando archivos, con acceso restringido a lo que la tarea necesita.

Pruebas automatizadas como parte de la ejecución, no como paso posterior

Tanto el Copilot coding agent como Codex ejecutan pruebas y linters como parte del propio ciclo de ejecución - el agente "explora el repositorio, hace los cambios, ejecuta pruebas y lint" antes de considerar el PR listo para revisión. Eso corresponde a la cuarta fase del Spec Kit, "Implement": el agente ejecuta tareas aisladas, lo que "permite una revisión enfocada" en vez de revisar un PR gigante y difícil de auditar.

Revisión de código humana y chequeo de seguridad

El PR llega para revisión solo después de pasar por el propio filtro automatizado del agente - título, descripción y pruebas ya completados. El equipo revisa y puede iterar comentando directamente en el PR (@copilot, en el caso de GitHub). El chequeo de seguridad en este punto incluye detección de secretos y alertas de escaneo de código, ya integradas en la capa de Remote MCP Server de Copilot.

Observabilidad y merge controlado

Cada etapa del proceso - desde abrir el PR hasta los comentarios de revisión - queda registrada y visible para el equipo, no escondida en una caja negra. El merge sigue siendo una decisión humana, el filtro final después de que specs, plan, ejecución, pruebas y revisión hayan pasado.

El workflow completo, en orden

  1. Issue o requisito
  2. Especificación inicial ("Specify": jornada del usuario, criterio de éxito)
  3. Plan del agente ("Plan": stack, arquitectura, restricciones)
  4. División en tareas ("Tasks": unidades pequeñas y revisables)
  5. Rama aislada, dedicada al agente
  6. Ejecución en entorno aislado
  7. Pruebas automatizadas y lint como parte de la ejecución
  8. Revisión de código humana
  9. Chequeo de seguridad (secretos, escaneo de código)
  10. Merge controlado

Fuentes