# Three Workflows for Agentic Development: Choosing the Right Weight for the Task
> Three workflows for agentic development: lightweight plan-and-execute, spec-kit, and BMAD-Method, with guidance on matching the right weight to the task.

*14 August 2026* · Jamie Taylor


In [Part 1 of this series](/blog/agentic-development-foundations) I covered the foundation of agentic development: how to get the agent onto a project so it has a shared understanding of what you are working on, how to give it context within a conversation, and how to keep that shared understanding honest as the codebase evolves. That foundation matters because without it, every conversation starts from zero; with it, every conversation starts from where the last one left off.

This is the second of three posts in the series, and the question I want to address here is the one most readers of Part 1 have asked next: *now what?* You have a CLAUDE.md. You know how to brief the agent. But the conversation you have with the agent for a one-line bug fix is not the conversation you have for a substantial new feature, which is in turn not the conversation you have when you are working solo on a project where you wish you had a Product Manager (PM), a Quality Assurance (QA) engineer, and a Scrum Master to bounce ideas off. The shape of the work changes; the shape of the workflow has to change with it.

The single most useful piece of judgement I have built up over four years of using these tools on real work is this: match the weight of the process to the weight of the task. The workflows below are the three weights I actually reach for. None of them is universally correct; each is appropriate for a band of work, and the engineering judgement is in picking the right one for whatever is in front of you.

I will walk through them in order of weight. The first is the lightest: a conversation-driven plan-and-execute approach that needs no extra tooling. The second is a medium-weight workflow built around GitHub's spec-kit, which adds structure and produces a queryable artefact trail. The third is the heaviest: BMAD-Method, which adds full multi-agent personas and a richer set of planning and implementation artefacts, and which I reach for mostly on solo or underbacked work.

In Part 3 I will cover hardening the setup: rules, permissions, secure coding guidance, and why I have never once run Claude with `--dangerously-skip-permissions`. For now, three workflows.

## The Conversation-Driven Plan-and-Execute Workflow


The lightest workflow I use needs no extra tooling beyond Claude itself and a directory called `plans/` at the root of the repository. It is the right reach for tasks bigger than "change the colour of a button" but smaller than a feature that warrants spec-kit's overhead. Most of the engineering work I do falls into that band, so this is the workflow I reach for most often.

The shape is straightforward. I have a full conversation with the agent first, asking it to investigate the relevant parts of the codebase, gather the context it needs, surface the questions it has, and ultimately propose a plan. The plan must be split into phases, with one or more tasks per phase. It must include a short summary of the background context we discussed, so that the plan is comprehensible without the conversation that produced it. And, critically, it must be written to disk.

Writing the plan to disk is the part of this workflow that makes everything else possible. The plan becomes an artefact that survives the conversation that produced it. When I clear the context and start a fresh conversation to execute the plan, the agent can pick up the plan from disk and have everything it needs to do the work, without me re-explaining the background. As it works through each phase, it updates the plan with progress. If the conversation runs long enough that I need to clear it again mid-execution, the plan on disk tells the next conversation exactly where the previous one left off.

I keep these plans in a `plans/` directory at the root of the project. Most are never committed; some are. A plan file from this workflow is just a plan file, and the discipline it represents is good engineering practice regardless of whether an agent helped write it. The most recent one I have made public lives in the [OwaspHeaders.Core repository](https://github.com/GaProgMan/OwaspHeaders.Core/blob/main/plans/vsts-to-mtp-migration.md), where it covers a possible migration from the older VSTest runner to Microsoft Testing Platform (MTP).

That particular plan is worth a look if you have never seen one of these documents before, because it illustrates something specific about the workflow. The plan's own recommendation is *"don't execute this plan yet"*; the analysis is preserved against the day when MTP becomes the `dotnet test` default and the supporting ecosystem has fully settled. The plan is the artefact, and execution is optional. A vibe-coding session would not produce that line, because vibe coding does not separate the work of deciding from the work of doing. This workflow does.

The workflow is essentially **task onboarding**, in the same way Part 1's `CLAUDE.md` is **project onboarding**. The `CLAUDE.md` introduces the agent to the project; the plan introduces the agent to a specific piece of work within that project. The two ride on top of each other and reinforce each other.

When to reach for the plan-and-execute workflow:

- ✅ The task is non-trivial but does not need a feature specification
- ✅ You want the option to clear context part-way through and resume cleanly
- ✅ The work warrants an audit trail of why you did it this way, but not the overhead of full spec-kit
- ✅ You may want to defer execution and preserve the analysis for later

## Spec-Kit: Structured Workflow for Substantive Features


The middle weight in my toolkit is [GitHub's spec-kit](https://github.com/github/spec-kit), an open-source toolkit that imposes a specification-driven structure on the work and produces an artefact trail you can come back to later. I gave the long-form explanation of how I use spec-kit when I appeared on [episode 640 of Coder Radio](https://coder.show/640) with Michael Dominick; we also cross-posted a snippet of that conversation as [a bonus episode of The Modern .NET Show](https://dotnetcore.show/season-8/bonus-coder-radio-episode-640-snippet/) with Michael's permission. If you want the full walkthrough, both are worth your time; what follows is the shorter version focused on what makes spec-kit worth reaching for in the first place.

The shape is roughly this. You run `specify init` (or whatever command your particular agent's spec-kit integration uses) in a repository, and it sets up a directory structure that gives the agent a place to put specifications, plans, tasks, and a project-level "constitution" that survives context-clear. The constitution is a Markdown file that sets the rules of the game: the coding standards in use, the testing approach, the rules about which packages you will and will not accept, anything else that should ride along with every subsequent piece of work in the project. Once the constitution is in place, the agent treats it as the operating environment for everything it does.

From there, the workflow is back-and-forth. You give the agent a specification at the project-manager level of detail (*"build me a checkout system that does X, Y, Z"*) and it does not start writing code. It interrogates the specification, asks you the questions a careful engineer would ask before starting, checks the spec against the constitution, and surfaces ambiguities. Eventually, when the specification is detailed enough to act on, it produces a plan; from the plan, it produces tasks; from the tasks, it does the work. That entire trail is checked into the codebase as Markdown files, alongside the code the specification produced.

That last point is where spec-kit's central novelty lives, and it is the argument I would most like working engineers to internalise.

**The specs are version-controlled, in-repo, agent-queryable engineering memory.**

Most decision histories rot outside the repository. They live in JIRA tickets that get archived, in Slack threads that get pruned, in the heads of the engineers who made the calls, in architecture decision records (ADRs) that nobody updates after the first six months. The result is what most working engineers spend most of their time doing: reconstructing context that someone, at some point, definitely had, but which has since evaporated. Spec-kit's specifications are different. They live next to the code, in standard locations the agent knows how to find. They are not automatically loaded into the agent's context, so they do not burn always-on context budget, but they are discoverable by explicit prompt:

> *"Claude, we use spec-kit, and the specifications are in the `/specs` directory. Please read through them and tell me when feature X was implemented, and what context produced it."*

That prompt is the unlock. It is, in effect, a conversation with the developer-plus-agent pair who did the original work, conducted years after the fact, mediated by the specification history they left behind. I do not know of another commonly-available software-engineering practice that gives you that capability.

The reason this matters more than it sounds is that teams turn over. The developers who knew why a feature was built this way and not that way are usually not the developers maintaining it five years later. I made the case in Part 1 for *reconstructing* this kind of understanding after the fact, when the original developers had long since moved on; that was the progressive discovery work I did on the twenty-plus-year-old codebase at Ligentia. The specification history is the version of that documentation you write *while the institutional memory still exists*, rather than years later, when reconstructing it has become an archaeology project. It is a preventative measure, not a curative one.

> [!NOTE]
> There is a real question, sitting underneath all of this, about what should and should not live in the public repository. Spec-kit's outputs read unmistakably as artefacts of AI tooling, and the technology industry's current reaction to visible AI tooling is, charitably, uneven.
> 
> The Rsync project had to litigate this exact conversation [twice in a single week](https://github.com/RsyncProject/rsync/issues/929) earlier this year ([the second issue](https://github.com/RsyncProject/rsync/issues/934) was the follow-up).
> 
> The original developer felt the need to step forward and explain their choices in [a blog post published](https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0) shortly after the outrage. Should they have had to explain themselves? I don't think so, but time will tell.

On client engagements with private repositories, I recommend committing the spec-kit outputs without hesitation; the audit-trail value is high, the audience is internal, and the discipline is exactly the kind of thing engineering teams should be able to point at. For my own open-source work on OwaspHeaders.Core, I currently do not commit the constitution or the per-specification output files, because the reputation calculus in the open-source .NET community right now points the other way. The plan file I linked earlier is in the public repository because a plan reads as engineering practice; the spec-kit constitution would read as something else. That is the same principle applied to two different rooms, rather than two different principles. I will return to this kind of judgement in more depth in Part 3.

> [!NOTE]
> I want to make it very clear that I do not vibe code when it comes to OwaspHeaders.Core or any other repo.
>   
> I use the processes I'm writing about in this very blog post, and perform my own code reviews before raising the public PRs. I then walk away for a few days (my own context clearing action) before approaching the public PR and reviewing it again. I do this regardless of whether I manufacture the code or whether I ask an agent to.
> 
> You can literally see this process by reading through [the closed PRs](https://github.com/GaProgMan/OwaspHeaders.Core/pulls?q=is%3Apr+is%3Aclosed).

I trained the developers at Ligentia in spec-kit, and the commit-the-outputs argument was one I made explicitly during that training. Some of the team came around to it. By the end of the engagement, a handful of them were using spec-kit on their own work and committing the outputs to their internal repositories. The audit trail they have now will pay them dividends the next time someone asks why a particular feature was built the way it was.

When to reach for spec-kit:

- ✅ The work warrants a real specification, not just a plan
- ✅ You want a queryable record of why the codebase is the way it is
- ✅ You are working in a context where the audit trail is more valuable than the AI-tooling-visibility cost
- ✅ The team benefits from a consistent operating environment (the constitution) across many pieces of work

## BMAD-Method: Multi-Agent Personas for Solo and Underbacked Work


The heaviest workflow I use is [BMAD-Method](https://docs.bmad-method.org/), which I reach for when I am working solo, or on a project where I do not have the colleagues a feature would normally pass through. Most engineering work goes through more hands than just the developer's: a product manager to make sure the work is actually worth doing, a QA engineer to think about how it will fail, a Scrum Master to track the work and surface risks. On a small team, or on a personal project, those roles are absent; the developer is doing all of them, sometimes badly and always in their own head. BMAD provides a structured way to do them less badly and more deliberately.

The shape is this. BMAD spins up several agent personas, each playing a distinct role; developer, QA, product manager, Scrum Master. You converse with each of them in turn, depending on what the work needs at that moment. The personas have specific responsibilities and, more usefully, specific *questions*. The QA persona asks how you would know if the feature were broken. The product manager wants to know why this feature, why now, and who benefits. The Scrum Master is interested in what would block the work and how big it actually is. None of these questions is particularly novel; what is novel is having something on the other end of the conversation that consistently asks them, even when you would rather skip ahead to writing code.

That is the [Socratic value](https://en.wikipedia.org/wiki/Socratic_method) of BMAD. The personas force you to articulate context you would otherwise leave implicit. The conversations are usually short, but they shape the work in ways an unmediated conversation with a single coding agent does not. They are particularly useful for the kind of half-formed idea you have at the start of a project, when you know you want to build something but have not yet worked out what *something* actually is.

What BMAD produces, in practice, is a structured set of artefacts that live in the repository alongside the code. The planning artefacts include the architecture document, a product requirements document (PRD), a User Experience (UX) specification, an epic-and-story breakdown, and a directory of architecture decision records. The implementation artefacts include per-story specifications, a sprint-status file that tracks what is being worked on and what is blocked, and per-epic retrospectives that capture what you learned at the end of each major chunk of work. Most of these are documents you would normally only see on a serious commercial product; BMAD makes them tractable on a solo project, because the personas help you produce them in the first place.

The discipline BMAD imposes on the implementation side is the part I find most useful. Stories have codified exit gates: the regression suite passes, the linter is clean, the file list in the story is verified against `git status`, the sprint-status entry is flipped to `review`. Before a story is marked `done`, it has to pass two review passes: at least one same-language-model code review pass produced by BMAD's own review workflow (albeit in a completely separate context), and at least one external human review pass. On a solo project, the "external human" is just future-you reviewing the work after a context-clear, but the discipline of separating the writing pass from the review pass is what catches the mistakes that the writing-and-reviewing-in-the-same-conversation approach lets through.

BMAD is distinct from spec-kit in two important ways. Spec-kit is artefact-centric: the specification is the canonical record, and the workflow is about producing specifications and turning them into code. BMAD is role-centric: the personas are the perspectives, and the artefacts are what fall out of conversations with them. BMAD also produces a richer artefact set than spec-kit, because it covers the full planning surface (the product requirements, the UX specification, the epics) that spec-kit assumes already exists. They can be combined; you can use BMAD's PM persona to produce a richer specification, then feed that specification into spec-kit for the implementation phase.

When to reach for BMAD:

- ✅ You are working solo or on an underbacked small team
- ✅ You want the discipline of separating roles even when you are playing all of them
- ✅ The project warrants a full planning artefact set (architecture, product requirements, UX specification, epics)
- ✅ You want codified story exit gates and a structured review pass

When NOT to reach for BMAD: if you have real human colleagues filling the PM, QA, and Scrum Master roles, the personas add overhead without adding perspective you are not already getting from your team. Use the humans you have where you have them.

## Where This Leaves Us


Three workflows, three weights. The lightweight conversation-driven plan-and-execute approach for typical engineering tasks: the bug fixes, the small features, the migrations that need to be planned but not specified. Spec-kit for substantive feature work where the audit trail of why the codebase looks the way it does is worth the structure: anything that future-you, or your successor on the team, will need to understand the reasoning behind. BMAD-Method for solo and underbacked work, where the personas play the colleagues you do not have, and the artefact set forces the planning discipline that a working team would normally provide.

The judgement is in the matching. There is no single "right" workflow, and there is no shame in mixing them; I have used BMAD's PM persona to produce a richer brief, then fed the brief into spec-kit, then used the lightweight plan-and-execute pattern for the small refactors that came out of the implementation. The workflows are tools, not religions. Pick the one that fits the work in front of you, and switch when the work changes shape.

The thread that runs through all three of them, the one that ties Part 1 and this post together, is that the agent is a collaborator and not a magic box. The `CLAUDE.md` onboards it to the project; the plan, to the specific task; the specification, to the feature; the personas, to the role expectations of a team. At every level, you are doing the same kind of work you would do to bring a new engineer up to speed; the difference is that you are doing it on a schedule the new engineer can keep up with, and at a depth the new engineer can actually consume.

Once you have picked a workflow, the next conversation is about what the agent is allowed to do within it. Rules, permissions, the discipline around what gets committed and when, the secure-coding guidance you put in place to keep the work from accumulating a category of mistake that is hard to catch at review. That is the territory I will cover in Part 3.

Choosing the right workflow for your team and codebase is part of what real Artificial Intelligence (AI) adoption strategy looks like; less about which tool to buy, more about how your engineers actually work with it. If you would like help making that decision for your team, [get in touch](/schedule-consultation/) and we can talk through what your work actually needs.