PulseFlow Tecnologia
← Insights
·7 min read·technical-guide·spec-driven-development·coding-agents·code-review
PulseFlow Tecnologia

How to design a coding agent workflow with spec, branch, tests, and review

A well-designed coding agent workflow combines three pieces that already exist separately in real products: the spec structure from GitHub's Spec Kit, the PR flow from Copilot coding agent, and OpenAI's isolated execution model for Codex. Together, they form a complete workflow - from idea to merge.

Issue or requirement becomes a spec, not a loose prompt

GitHub's Spec Kit splits this into four explicit phases. The first, "Specify," describes "user journeys, experiences, and what success looks like" - not technical implementation details. That's the fundamental difference between spec-driven development and what GitHub itself calls "vibe coding": describing a goal and getting back a block of code, often imprecise, versus providing a clear spec that forces "clarity about how it should interact with existing systems" before a single line gets written.

Agent's plan before execution

Spec Kit's second phase, "Plan," defines the tech stack, architecture, and constraints. The third, "Tasks," breaks the spec into "small, reviewable pieces of work that solve specific parts" - the equivalent of splitting a large requirement into units that fit inside a single reviewable PR.

Isolated branch and execution

This is where the Copilot coding agent's flow fits in: the agent opens a draft pull request, marked [WIP], on a dedicated branch (copilot/*), isolated from the main branch. Execution itself follows the model OpenAI documented with Codex - running inside an isolated environment, reading and editing files, with access restricted to what the task needs.

Automated tests as part of execution, not a later step

Both Copilot coding agent and Codex run tests and linters as part of the execution cycle itself - the agent "explores the repository, makes changes, runs tests and lint" before considering the PR ready for review. That maps to Spec Kit's fourth phase, "Implement": the agent executes isolated tasks, which "enables focused review" instead of reviewing one giant, hard-to-audit PR.

Human code review and security check

The PR arrives for review only after passing the agent's own automated screening - title, description, and tests already filled in. The team reviews and can iterate by commenting directly on the PR (@copilot, in GitHub's case). Security check at this point includes secret detection and code scanning alerts, already built into Copilot's Remote MCP Server layer.

Observability and controlled merge

Every step of the process - from opening the PR to review comments - gets logged and visible to the team, not hidden in a black box. Merging remains a human decision, the final gate after specs, plan, execution, tests, and review have all passed.

The full workflow, in order

  1. Issue or requirement
  2. Initial spec ("Specify": user journey, success criteria)
  3. Agent's plan ("Plan": stack, architecture, constraints)
  4. Task breakdown ("Tasks": small, reviewable units)
  5. Isolated branch, dedicated to the agent
  6. Execution in an isolated environment
  7. Automated tests and lint as part of execution
  8. Human code review
  9. Security check (secrets, code scanning)
  10. Controlled merge

Sources