Workflow Patterns

A team ships a fix to a reconciliation job nobody has touched in eight months. The engineer opens a session, describes the bug, and the agent does what it always does on this team: makes a change, runs the job, sees what breaks, adjusts. Two iterations in, the fix looks plausible. Three iterations in, it has quietly broken an invariant in a module the agent never read, because nobody read it — the team does not do that here. The bug gets fixed on the fourth pass, forty minutes and one production incident later than a session that opened by reading the reconciliation module first would have taken.

Nothing about that session was reckless. Iterate — attempt, observe, refine — is a perfectly good way to work, and this team uses it well most of the time. It was simply the wrong shape for this task: unfamiliar code, a real cost to a wrong guess, an entire module’s worth of context nobody had loaded. The team did not choose iterate for this bug. It never chose anything. Iterate is what this team’s sessions look like, full stop, the way a person has a dominant hand — and a session that would have been better served by exploring first never got a vote.

A workflow that already has a name

One of these shapes is already documented well enough to be an industry default. Anthropic’s own current guidance for Claude Code recommends a four-phase workflow — explore, plan, implement, commit — as the pattern that avoids solving the wrong problem: read the relevant code and answer questions about it first, turn that reading into an explicit plan, switch out of research mode to implement against the plan, then commit. That is a fully specified instance of what this chapter calls plan-first, and the fact that a major vendor’s best-practices document collapses straight into naming one specific archetype says something useful on its own — recurring shapes in how AI sessions get worked are real enough that the tool-makers have started prescribing one of them by name.

The same guidance immediately hedges its own recommendation: for a task small enough that the diff could be described correctly in one sentence — a typo, a renamed variable, a missing log line — it says to skip the plan and just make the change. That single caveat is doing more work than it looks like. It is an admission, from the source recommending plan-first as a default, that plan-first is not always the right shape. If the vendor documenting the most fully-formed of these archetypes builds in an explicit escape hatch, the other four archetypes deserve the same treatment: named, described honestly, and matched to the task rather than applied out of habit.

One habit, five situations

Most teams do not pick a workflow shape per task. They settle into one early — often whichever pattern the first few engineers who set up the tooling happened to prefer — and every session after that inherits it by default, the way a codebase inherits its original author’s naming conventions. A team that always plans first will plan first on the one-line fix, producing exactly the ceremony failure this Library’s Volume III names in its chapter on plan-mode thinking: a proposal nobody reads closely because reading it feels slower than watching the diff land. A team that always iterates will iterate on the unfamiliar reconciliation module, paying in wrong turns what an hour of reading would have avoided. Neither team is doing anything wrong in isolation. Both are running the same session shape on every task regardless of fit, because the shape was never named as a decision in the first place — it is closer to a house style than a choice.

The team did not choose iterate for this bug. It never chose anything.

DORA’s 2025 research on AI-assisted software delivery frames AI adoption broadly as an amplifier of whatever organizational habits already exist — strong practices get stronger, weak ones get worse, faster. A team’s default session archetype is exactly the kind of habit that gets amplified silently: nobody decided the reconciliation-job session should iterate blind through an unfamiliar module, and nobody will decide the next one should either, unless the choice is made visible enough to interrupt.

Five archetypes, not a maturity ladder

Naming the shapes is what makes the choice interruptible. None of the five below is more sophisticated than the others, and none is a default state a team should be graduating toward — a team that plans everything is not more mature than one that iterates on small, well-understood work, it is simply paying for ceremony it does not need. Plan-first opens with an explicit plan — the Flight Plan this volume’s second chapter names — before any file changes. Test-first writes or identifies the test the change must satisfy before writing the implementation. Iterate makes a rough first attempt and repeatedly refines it against feedback rather than planning extensively upfront. Explore-first spends a meaningful share of the session reading and mapping the code before attempting a change. Greenfield builds something with no existing module or established pattern in the repository to reconcile with. Every session that has ever run falls recognizably into one of these five, or some case where two blend at the seams — a plan-first session that also happens to be greenfield, an iterate session that turns explore-first once the agent gets lost.

When each is the right default

Test-first deserves the most caution of the five, because “the tests are unambiguous” is doing a lot of hidden work. It is a strong default for a bug fix with a clear expected output, or a well-specified API contract — the test is a genuine constraint the implementation must satisfy, not a guess dressed up as a spec. It is a weak default for exploratory or product-shaping work, where writing the test first just means encoding today’s best guess about the right behavior before anyone has actually seen the behavior in question, and then treating that guess as ground truth for however long the test survives.

Greenfield cuts a different way than the other four: the absence of an existing pattern is not free speed, it is a transfer of judgment. A session inside a mature codebase inherits hundreds of small decisions for free — naming, error handling, where a new module lives — simply by matching what already exists. A greenfield session has nothing to match, which means every one of those small decisions becomes a live judgment call the agent has to make on its own, with a person’s review as the only check. That can be genuinely faster. It is not automatically safer, and treating a greenfield session as low-stakes because “there is nothing to break yet” is how a young codebase inherits its first round of inconsistency before it has any users to notice.

What the evidence does and does not show

Being direct about the limits here matters more than it would in a chapter with cleaner data: no rigorous, publicly published study directly compares cost, duration, and quality across these five session archetypes head-to-head, for AI-assisted work or otherwise. What exists instead is a set of adjacent, real findings, each covering one slice of the picture and none of them the full comparison this chapter’s hook implicitly promises.

Test-first and iterate both have deep pre-AI lineage as general software-engineering practices — Kent Beck’s canonical account of test-driven development, and the Agile Manifesto’s explicit preference for short, feedback-driven delivery cycles over extensive upfront specification — but neither line of work was written with an AI agent as the one doing the implementing, and neither claims the other is worse. A 2018 field study of seventy-eight professional developers across seven real projects found they spent roughly 58% of their working time on program comprehension rather than writing code, which is the closest thing to hard evidence that explore-first’s upfront cost is a real cost teams already pay, AI-assisted or not — it does not, by itself, say when that cost is worth paying before an edit versus during one. And a 2026 empirical study of failed agent-authored pull requests found that rejected PRs skew toward larger diffs and more touched files, and that performance and bug-fix work fail to merge more often than documentation or CI changes — evidence that scope and task type predict trouble, not evidence that any one archetype in this chapter caused or prevented it.

The one study that measures test-first specifically for AI coding agents complicates the simple story further, rather than confirming it. Research on test-driven agentic development found that telling an agent to “follow TDD” as a plain procedural instruction, with no supporting tooling, made things worse — regressions rose from a 6.08% baseline to 9.94%. What actually cut regressions, down to 1.82%, was giving the agent a graph-based map of which tests a change could affect, so it could check the right ones before committing — a structural aid, not a discipline recited at the start of a prompt. The honest reading is not “test-first fails for AI agents.” It is that naming an archetype and actually equipping a session to execute it well are two different jobs, and this study is a rare, real data point on how far apart they can be.

The kind of telemetry this chapter’s claims should be checked against

Naming it is the intervention

1. Before opening a session, ask which of the five the task actually calls for — not which one this team always uses.
2. Treat “the codebase is unfamiliar” as an explicit trigger for explore-first, with a time-boxed reading budget before any edit.
3. Reserve test-first for tasks where the correct behavior is already known, not tasks where writing the test is really an attempt to invent the behavior.
4. On greenfield work, replace the review a mature codebase’s existing patterns would normally do for free with a deliberate architectural pass — the freedom is real, but so is the missing guardrail.
5. If a team can compute its own version of the field-data comparison above, watch whether the habitual default is actually the cheapest or most reliable archetype for the tasks it gets used on, and be willing to find out it is not.

None of this argues for ceremony. A team that names its archetypes and then runs a plan-first review on every trivial fix has re-created exactly the failure this chapter opened against, just with a fancier vocabulary for it. The point of naming plan-first, test-first, iterate, explore-first, and greenfield is narrower and more useful than that: it turns “how we always work” into a question that can be asked per task, which is the only way a team finds out that its default was actually costing it something on the tasks where it did not fit.