By the time our code reviewer got to work, its context was 40,000 tokens deep (a token is roughly three-quarters of a word). It was one agent session on a GitHub Copilot project, and those tokens already held the ticket research, the arguments about the design, and every attempt at the code. Reviewing in that state, it treated early research notes as constraints and missed code-level issues that were obvious in isolation [1]. The stage whose whole job is to catch mistakes was the stage most polluted by everything that came before it.
We fixed that in March 2026 by giving every stage its own agent and its own file. The next agent reads that file cold, with nothing else in its head. In August, Anthropic published “The AI-native SDLC playbook,” its recommended way to run the software development lifecycle (SDLC, the process that takes software from idea to production) when agents write most of the code. Its central idea is the same: each stage commits one artifact, and the next stage starts by reading it [2]. We think that’s the right shape, and the useful lessons are in where the two versions differ.
Figure 1 - Two Loops, One Handoff: Anthropic’s 6-stage loop from August 2026 and our Copilot pipeline from March 2026 put the same thing at every stage boundary: a file that the next agent reads cold. Anthropic’s closes into a loop, and ours is an open chain that stops at documentation.
Review is where the pressure lands
Anthropic describes the pressure from the organization’s side. When agents write code quickly, the slow part moves to the steps on either side of the build: planning, review and test, and deployment, which “still run at human speed” [2]. Reviewing every line by hand made sense when a person wrote the code. The playbook says “it can’t keep up once agents write most of the diff” (the diff is the set of lines a change adds or removes) [2].
A workflow with several stages adds a second problem. Every time one stage hands work to the next, someone has to decide what the next stage needs to know. Our copilot-02 writeup put it plainly: “Manually deciding what context to carry forward between stages introduces cognitive overhead and context loss” [1]. A decision made during research can fall out of a handoff and never reach the reviewer.
The obvious fix: keep it all in one place
We tried the obvious thing first: keep the whole workflow in one long session. It looked efficient, with less overhead, no files to write, and everything in one place [1]. It also solved the handoff problem, since a decision can’t fall out of a handoff when there is no handoff.
What it left broken was the review. A context window is the text a model can see at once: your prompt, the files it opened, and every message in the conversation so far. In one long session it fills up with everything the agent has done, and more history sounds like better judgment.
It didn’t work that way for us. The project was a Servoy enterprise system (Servoy is a platform for building business applications) with more than 10,000 functions across 1,000 files and 22 modules [1]. By review time, the context was 40,000 tokens deep and held research notes, design debates, code attempts and revision history all at once [1]. Our writeup recorded it: “Review quality degraded” [1]. Early research notes read like constraints, and code-level issues that were obvious on their own slipped past [1]. The reviewer was judging the change against everything said on the way to it.
Figure 2 - The Reviewer Who Saw Everything: In our single-session attempt, every stage added to one context. By the time review started it was 40,000 tokens deep, code attempts included, and the reviewer treated early research notes as constraints.
We wrote then that a reviewer with 2,000 tokens of clean input did better than one with 40,000 tokens of accumulated noise [1]. That’s one system’s observation without a controlled test, and we’d still make the same call. The next design had to keep what the single session got right, with no decision lost between stages, without making the reviewer carry the whole history.
Our March fix: one file per stage, read cold
The design we published on March 23, 2026, in The Development Workflow: How Seven Agents Turn a Ticket into Reviewed Code, split the work into 5 stages, each with its own agent [1]. Each stage that produces a plan or a judgment writes a markdown file, and the next agent starts from that file and nothing else:
- The researcher writes
research/[ticket].md, the functions in scope. - The architect reads that and writes
plans/[ticket].md. - The developer reads the plan and writes the code.
- The reviewer reads the code and the handoff summary and writes
reviews/[ticket].md. - The documenter writes
docs/[ticket].md.
Our figure caption for that pipeline says “Each stage consumes the prior stage’s artifact as structured input” [1]. We called it mandatory context isolation.
“Reading cold” is the important part. A cold read means a fresh agent with an empty context window, given one file and one job. It can’t confuse an old note with a rule, because the old note isn’t there. If a stage produces bad output, you rerun that stage from the file still on disk.
Figure 3 - Our March Chain: The chain has 4 named files plus the code itself. Each agent reads only the previous stage’s output, which is what kept the reviewer’s input small.
In July we rebuilt the same pipeline on 5 more agent harnesses (a harness is the program around a model that gives it tools, files and rules). We published them on July 16, 2026, for Claude Code, Codex, OpenCode, Claude + Pi and Cursor. That’s 6 harnesses in total, counting the original Copilot build. The Claude Code page says it in one line: “state lives on disk, not in a conversation” [3].
None of this is a new idea in software. Teams have written design documents for decades, and Michael Nygard proposed architecture decision records (ADRs, short files that record one design decision and why it was made) in 2011 [4]. The difference now is who reads the file. The next person in the chain is an agent with no memory of the last stage, so the file is the only thing that crosses the gap.
The March design still left real gaps. It started at the research stage, with a ticket someone had already written, so nothing captured the original intent. It stopped at documentation, so nothing watched the change once it shipped. No regression suite reran past tasks when we changed the agents’ instructions. Our reviewer was a separate agent, but nothing stopped a reviewer from being as easy on the code as the author was.
KEY INSIGHT: If an agent needs to know what the last stage decided, put that decision in a short file and start the next agent fresh on it. In our Copilot build, a reviewer working from a 2,000-token brief did better than one carrying a 40,000-token session.
What Anthropic published in August
Anthropic’s playbook appeared on the Claude blog on August 21, 2026, written by Louis Claxton and drawn from the practices of Anthropic’s Applied AI team [2]. The same text runs as a 14-lesson Claude Academy course, “about an hour of reading, with no quiz or completion badge” [5]. It describes 6 stages: Plan, Design, Build, Test, Deploy and Maintain [2].
The thread through all 6 is the committed artifact. In Anthropic’s words, each stage ends by writing one to version control, “including intent.md, spec.md, plan.md, the diff and its tests, the PR with its review findings, and the incident record,” and “the next stage begins by reading it” (a PR, or pull request, is a proposed change submitted for review before it merges) [2]. Only 3 of those 6 are markdown files: intent.md (the problem and the outcome wanted), spec.md (the design) and plan.md (the build steps). Anthropic says markdown dominates the early stages because “a product owner and an agent can both read and act on the same file,” and that from Build onward “the artifact is code and its records” [2]. The chain of commits is also the audit trail: “who asked for what, what the agent produced, and who approved it” [2].
The stages trigger each other. An accepted intent.md starts the design pass, and an approved spec.md starts plan mode (a Claude Code mode in which Claude proposes a plan and cannot edit files until an engineer accepts it). A merged pull request starts the pipeline, and a breached control band (the normal range set for a monitored metric, explained below) in production “writes the next intent.md” [2].
Figure 4 - Anthropic’s Loop: 6 stages, each ending in an artifact that the next stage reads. A breach in production writes a new intent.md, so the loop restarts without anyone starting it.
Here are the dates side by side. Our copilot-02 article is dated March 23, 2026 [1]. Our 5 rebuilds went up on July 16, 2026 [3]. Anthropic’s playbook is dated August 21, 2026 [2]. That’s 151 days from our first writeup to theirs, about 5 months, and 36 days from our 5 rebuilds. Nothing in Anthropic’s pages suggests it drew on our work, and we don’t think it did. Two teams working on the same problem arrived at the same shape.
Figure 5 - The Dates, Side by Side: Our first writeup, our 5 rebuilds, and Anthropic’s playbook. The gap is 151 days to the first and 36 days to the rebuilds.
A third company got there from the opposite direction. Ryan Cooke, an engineer at WorkOS, told the AI Engineer conference that WorkOS first built the standard setup: sandboxes running agents. The results were “pretty indistinguishable” from engineers running Claude Code on their laptops [6]. Value only came once they built their own process documents into the loop. A dedicated product-manager agent drafts their PRD (product requirements document), which they call the hilltop document, from a short brief. Humans review it, and approving it is what starts the build agent breaking the work into tickets [6]. Since those are ordinary documents, engineers can also point a different agent, such as Devin or a local Claude Code session, at the same hilltop and tickets [6]. Our 6 harness builds showed the same thing, that the files carry the work whichever tool reads them. WorkOS got there with no connection to us or to Anthropic.
Where the playbook goes further than our pipeline
Anthropic’s loop is wider than ours at both ends, and on the review stage it is stricter. We’d adopt most of it.
Intent before the spec. The playbook starts with intent.md, a short proto-spec that the person with the idea writes with Claude, covering the problem, the outcome they want, who is affected, the constraints and open questions [2]. A product owner corrects it before it’s committed. Our pipeline started from a ticket someone had already written. An intent file means the earliest and cheapest mistake, building the wrong thing, gets a document a human can fix.
A rule for repeat mistakes. The Build stage has a working rule: “When Claude makes a mistake twice, the correction goes into CLAUDE.md” [2]. CLAUDE.md (the file Claude Code reads at the start of every session) holds the team’s commands, conventions and known pitfalls. The playbook applies the same rule at review: when a review flags a mistake for the second time, the fix goes into CLAUDE.md as part of that review [2].
A written rule has a ceiling, though: when The AI Automators ran Matt Pocock’s /retro skill, a reusable instruction file that reviews past agent sessions and proposes fixes, over 20 sessions from their own project, it caught a repeat. An agent had saved itself a note after a file-breaking edit hit it 4 times in one session. A couple of hours later, it made the same mistake. The retrospective proposed a hook or similar check on each edit [7]. A hook is a script the harness runs on every matching action, so it can’t be forgotten the way a note can. We covered where such a rule should live in Hooks Run Once. Mods Stay Resident [8]. The playbook says the same about its own skills: a skill is an advisory control, and “a policy that must always hold needs something deterministic behind the skill” [2].
Figure 6 - A Rule, and What Enforces It: The playbook writes a twice-made mistake into CLAUDE.md. A written rule can still be ignored, so a policy that must hold needs a hook or a gate behind it.
Review as its own stage, with its own policy. The playbook has the tech lead write REVIEW.md at the repo root, a review policy split into passes [2]. Its example uses 3: bugs, security, and compliance, where compliance means “the change matches spec.md, plan.md and our design principles” [2]. It also caps the noise: “Report at most five nits per review; summarize the rest as a count” (a nit is a style or naming comment that doesn’t change behavior) [2]. Then comes the rule we’d underline, separation of duties (the person who does the work is never the one who signs it off): “the agent that wrote the code has no way to approve it” [2]. Findings don’t approve or block a pull request on their own. At merge time, branch protection (a repository rule that blocks a merge until a required reviewer approves) still needs approval from a code owner, the person named as responsible for that part of the code [2].
Laurie Voss summed up the general lesson at the same AI Engineer conference: as teams took humans out of line-by-line review, review didn’t disappear but was rebuilt as a system that people designed [9]. Nicholas Carlini, a researcher on Anthropic’s Safeguards team, had 16 agents write a C compiler over nearly 2,000 Claude Code sessions [10]. In Voss’s reading, no human approved code as it was written, but Carlini himself built the test harness and the checks the agents ran against [9], [10]. He also warns that “it is easy to see tests pass and assume the job is done, when this is rarely the case” [10]. Carlini works at Anthropic, so this is an illustration from the same company, not independent support.
Cursor’s reviewer shows the other half. When Cursor rebuilt its Bugbot reviewer as an agent, it found the agent “was too cautious,” so the team “shifted to aggressive prompts that encouraged the agent to investigate every suspicious pattern and err on the side of flagging potential issues” [11]. Left to its defaults, Cursor’s reviewer went easy on code, and Cursor had to prompt it to go looking for trouble. A review agent needs its own written brief that tells it how hard to look.
The file that enters review matters too. In a recent video, Matt Pocock shows his /pr skill, a template for the pull request description. It has 4 parts: a summary, before-and-after evidence, whether the change is a one-way or two-way door (whether it can be easily reverted), and its blast radius (how much of the system the change could break if it goes wrong) [12]. That lets the reviewer read the risk before the diff.
Figure 7 - Review as Its Own Stage: A separate agent reviews against a written policy with 3 passes and a 5-nit cap. The authoring agent has no way to approve, and a human code owner makes the call.
Evals for the agent’s own setup. An eval here is a saved task with a known good result that you rerun to see whether the agent still does the job. The playbook asks a platform engineer to collect “20 to 50 real tasks from recent work” with their accepted outcomes [2]. The suite runs in CI (continuous integration, the checks that run on every change) on a schedule and “on any change to CLAUDE.md, skills or hooks,” and every production incident adds a new eval [2]. We gate each run on evidence, but we have no suite like this. When we change an agent’s instructions, nothing reruns last month’s work to check we didn’t make it worse.
A maintain stage that can’t push to main. The last stage watches one metric with a stable baseline, such as CI test failure rate, the post-deploy 5xx error rate or pull request cycle time. It compares that metric against its normal range, measured in standard deviations (sigma, written σ) [2]. Detection is a plain script, “entirely deterministic, with no model involved” [2]. The response tiers live in a config file, bands.yaml. At 1σ the script only logs. At 2σ it calls Claude read-only to diagnose. At 3σ Claude may act, “though only by opening a PR into the review gate or triggering a pre-approved runbook” [2]. A runbook is a scripted operations procedure, like a rollback, that people approved in advance. Claude writes its diagnosis as a new intent.md, and the loop starts again [2]. Our pipelines end at documentation, and the missing maintain stage is the biggest gap in our version.
Figure 8 - The Maintain Ladder: A deterministic script watches one metric. Claude only enters at 2σ, and even at 3σ it can only open a pull request or run a pre-approved runbook.
KEY INSIGHT: Give your review agent a written policy and a cap on nitpicks. Make sure the agent that wrote the code can’t approve it, so a human code owner signs off from the findings instead of two agents agreeing with each other.
Where our pipeline goes further
Ours puts more effort into what a run learns.
In the Copilot pipeline, the reviewer also harvested rules it found into knowledge-harvest/ files, and a skill-builder agent turned them into skill files that load for every later session [1]. One review caught a missing data-isolation filter in a sub-query. That rule went into the domain skill and now fires for every developer touching that module [1]. The Claude Code rebuild added skill-capture and knowledge-capture stages after review, and it lets them write only through a gate, either a human or a validator agent [3]. The gate matters: an agent that writes a wrong wiki page today reads it as fact tomorrow [3]. The playbook does say skills are how an organization makes its knowledge operational, and that review findings feed back into CLAUDE.md [2]. It doesn’t describe a gated stage that captures what each run learned.
Two more pieces are ours. The research stage reads a code graph (a database of which functions call which) to scope a ticket before any planning starts [1], [3]. We also made the definition of done a check in code. Our Deterministic Gate Harness lets a phase advance only after its gate passes and an evidence record is written. On a 6-document test corpus with seeded faults, 0 phases advanced without a passing, evidence-backed gate across 6 gated runs, while the same workflow ungated shipped 4 broken artifacts [13]. That’s a small, deliberately seeded corpus, not a rate for any real pipeline.
Figure 9 - Two Loops Compared: Both put a written artifact at every boundary and a separate agent on review. Anthropic adds intent, evals and a maintain stage. We add gated knowledge capture, a code graph and evidence gates.
Figure 10 - What a Run Learns: Review findings become proposed edits to skills and the wiki. The edits pass a gate before the next run reads them, so a wrong lesson doesn’t become tomorrow’s fact.
Why the file fixes the reviewer
The opening reviewer failed because it couldn’t tell the change apart from everything said about it. Giving each stage its own file removes that confusion.
The planner writes plan.md and stops. A new session starts with an empty context window and reads the plan, so it can only follow what the plan says. The reviewer starts fresh too, with the diff, the plan, and a written review policy. A rejected design option isn’t in its context, so it can’t pose as a requirement.
The file also gives a person a place to step in. The playbook says human attention concentrates at the gates, reviewing what the agent flagged instead of starting each stage from scratch [2]. A short plan is something a tech lead will actually read. A 40,000-token conversation isn’t.
The last piece is accountability. Each file is committed, so git shows who asked for the change, what the agent planned, and who approved it [2]. The playbook is honest that this is a preferred setup rather than the only one. It lets teams keep Jira, ServiceNow or a requirements tool as the authoritative record, with the markdown files as working copies [2]. We think the files belong in the repo, next to the code they describe.
KEY INSIGHT: Before adding another agent to a workflow, make the boundary in front of it a file. A stage that reads a committed file can be rerun, reviewed by a person and audited later, and a stage that reads a conversation can’t.
What the numbers do and don’t show
Anthropic has 3 published numbers that belong in this comparison, though none of them appears in the playbook itself. Jason Clinton, Anthropic’s Deputy CISO (chief information security officer), writes that “Claude authors about 80% of the code merged into our codebase today”. He adds that its engineers “ship 8x as much code per quarter as they did from 2021 to 2025” [14]. The 8x figure is code, not pull requests. Neither number comes with a method.
Anthropic’s launch page for its Code Review product says: “Before, 16% of PRs got substantive review comments. Now 54% do” [15]. The product launched as a research preview for Team and Enterprise plans [15]. That rise came from adding Code Review, a multi-agent review service, and Clinton credits growing confidence from “requiring the agents to write a proof that their finding is valid” [14]. Neither page ties it to review being a separate stage with its own file, so we won’t either. It’s a before-and-after figure with no control group, and “substantive” isn’t defined.
Cooke warns that counting PRs “can actually disguise how well these systems are working” [6], and the 80% and 8x figures are output counts of exactly that kind. The review-comment rate is closer to quality, but it still counts comments, not bugs caught.
Figure 11 - Anthropic’s Numbers, With Their Labels: About 80% and 8x are self-reported output figures with no method. The 16% to 54% rise came from Anthropic’s Code Review product, not from stage separation.
Where it stops working
A file at every boundary won’t save a bad plan. If plan.md is wrong, a fresh agent will build the wrong thing faithfully. That’s why the playbook puts a human on the early files.
A file only advises the agent. A rule in CLAUDE.md, a memory note, or a skill makes a mistake less likely, not impossible. Anything that must always hold needs a hook or a gate behind it.
The 40,000-token failure and the 2,000-token comparison come from one system, without a controlled test [1]. The gate harness numbers come from a seeded 6-document corpus [13]. Anthropic’s 3 numbers are self-reported [14], [15].
Our pipelines also lack two things Anthropic’s has: a maintain stage and a task-set eval suite. If you adopt our version, add both.
Conclusion
Three teams have now landed on the handoff file. We got there in March, Anthropic in August, and WorkOS from a third direction. Our reason hasn’t changed since March. In our pipeline, a fresh agent reading a short file did better review than one session dragging the whole history along. The file also gives people something to review and git something to record.
The two loops differ most at their ends. Anthropic’s shows how to start with intent and how to close with a maintain stage that can only propose. Ours shows how to feed what each run learned into the next one behind a gate. Neither loop does both yet.
Start small. Pick the boundary between planning and coding in your own workflow. Have the planning session commit a plan.md, start a new session that reads only that file, and have a third session review the result against a short REVIEW.md. Do that for a week and you’ll see whether your reviewer gets better when it reads less. For the single-job version of the same idea, handing an agent a whole task with a written brief, see The Recipe Card: How to Hand an Agent a Whole Job.
If your team would rather have this built than build it, we set up this workflow on the harness your team already uses, from the file contracts to the gates. We have built it on 6 harnesses so far.
References
[1] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Development Workflow: How Seven Agents Turn a Ticket into Reviewed Code,” dotzlaw.com, Mar 2026. /insights/copilot-02/
[2] L. Claxton, “The AI-native SDLC playbook,” Claude Blog, Anthropic, Aug 2026. https://claude.com/blog/the-ai-native-sdlc-playbook
[3] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Ultimate Agent Coding Workflow on Claude Code,” dotzlaw.com, Jul 2026. /projects/ultimate-workflow-claude-code/
[4] M. Nygard, “Documenting Architecture Decisions,” Cognitect Blog, Nov 2011. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions
[5] Anthropic, “The AI-native SDLC playbook,” Claude Academy, 2026. https://academy.claude.com/courses/ai-native-sdlc-playbook
[6] R. Cooke, “No, That’s Not a Software Factory,” AI Engineer, YouTube, Sep 2026. https://www.youtube.com/watch?v=HvboD89DyQ8
[7] The AI Automators, “Matt Pocock’s New Skill, Clearly Explained (with real sessions),” YouTube, Oct 2026. https://www.youtube.com/watch?v=7nNJZmyBlm0
[8] G. Dotzlaw, “Hooks Run Once. Mods Stay Resident: Where a Rule Should Live in Claude Code,” dotzlaw.com, Oct 2026. /insights/claude-code-22-mods-vs-hooks-resident-guardrails/
[9] L. Voss, “The Death of the Code Review: What the Data Actually Says,” AI Engineer, YouTube, Sep 2026. https://www.youtube.com/watch?v=_mi3alkqy4s
[10] N. Carlini, “Building a C compiler with a team of parallel Claudes,” Anthropic Engineering Blog, Feb 2026. https://www.anthropic.com/engineering/building-c-compiler
[11] J. Kaplan, “Building a better Bugbot,” Cursor Blog, Jan 2026. https://cursor.com/blog/building-bugbot
[12] M. Pocock, “New Skills! v1.3 brings /pr, /implement-spec, and /retro,” YouTube, Oct 2026. https://www.youtube.com/watch?v=BsJGo1wFTvQ
[13] Dotzlaw Consulting, “Deterministic Gate Harness,” dotzlaw.com, Jul 2026. /projects/deterministic-gate-harness/
[14] J. Clinton, “How Anthropic secures its AI-native software development lifecycle,” Claude Blog, Anthropic, Jul 2026. https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
[15] Anthropic, “Bringing Code Review to Claude Code,” Claude, Anthropic, Mar 2026. https://claude.com/resources/articles/code-review
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.