By Mark Nguyen · August 2026
Anthropic published two pieces this year that together describe what happens to an engineering organization once agentic coding stops being a tool somebody uses and becomes the way the whole team works.
The first, published in June, was Fiona Fung’s talk writeup from Code w/ Claude SF. She runs engineering for Claude Code, and her piece is about people and process: the four team norms that stopped working once her team went agentic, and what replaced them. The second, published in August, was Louis Claxton’s AI-native SDLC playbook, which is the more prescriptive counterpart. It lays out six stages, a chain of committed files that runs through all of them, and a governance layer underneath.
Read together, they’re probably the best public description of this shift I’ve seen. They also share an assumption neither one really states: you own your roadmap. Anthropic can change direction when its own product, tooling, or team changes what makes sense. Agencies can’t. We’re an eleven-person agency, and most of our work arrives with a signed scope, a fixed date, and a client who agreed to a specific list of deliverables. That constraint changes which parts of the AI-native SDLC you can actually adopt, and most of what’s being written about this shift isn’t written for people working under it.
One disclosure before the rest. We build and sell CodeRaven, an AI code-review platform, so we have a commercial interest in one specific stage of this process. The data further down is published with its limitations attached, and you’re welcome to keep the numbers and discard our framing.
What an AI-native SDLC actually changes
The software development lifecycle is just the path a change takes from someone’s idea to something running in production. You plan it, design it, build it, test it, deploy it, and maintain it. Traditionally, each step belongs to a different role, and work moves between them through documents, tickets, meetings, and sign-offs.
A lot of that ceremony was built around one assumption: writing the code was the slow, expensive part. Requirements documents, estimation rituals, and design review existed to force agreement before anyone spent three months building the wrong thing. When building the thing takes an afternoon, a lot of that structure is guarding against a cost that no longer exists.
An AI-native SDLC keeps the six stages but changes what travels between them. Instead of relying mainly on tickets and meetings, each stage ends by committing a plain markdown file that the next stage reads. An idea becomes an intent file. The intent becomes a spec. The spec becomes an implementation plan naming which files change and which tests prove it worked. Then come the actual diff, the pull request and its review findings, and an incident record if production disagrees with all of it.
The files are readable by both a person and an agent, they live in git next to the code, and the chain of commits becomes an audit trail without anyone having to build a separate one. You’ll also see the same idea called the agentic SDLC or just the AI SDLC. Different labels, same basic structure.
The bottleneck moved, and three stages absorbed it
Fung’s point is straightforward. On her team, writing code, writing tests, and refactoring stopped being what slowed anyone down. The bottleneck didn’t disappear when the typing did. It moved to verification, review, and security, because those still run much closer to human speed regardless of how fast the diff shows up.
Claxton makes the same point structurally. Build collapses to hours while the stages on either side keep much of their original length. Your review queue was sized for the amount of code humans could write. Your security review was staffed around roughly the same assumption. Your approval gates still run on their existing cadence. None of that gets ten times faster because generation does, so either the queue backs up or work starts shipping under-reviewed.
The real question isn’t which AI tools to buy. It’s which of your existing processes were solving a problem you no longer have, and which ones just had a lot more work dropped on them.
The four norms Fung’s team rewrote
The tooling is only part of the change. Fung’s other point is that the way the team works has to change with it.
Planning went just-in-time. Her team wrote a solid six-month roadmap and it was obsolete by month three, specifically because of what their own tooling did to throughput. Planning moved away from long design documents and toward prototypes and discussion in pull requests. Build it, put internal users on it, and act on what they say.
Context gathering stopped starting with the author. When a person wrote the code, finding that person was usually step one when someone had a question. When nearly every pull request is agent-assisted, “who made this change” doesn’t get you very far. The better question is what you actually need to know. Ask the agent first, then ask whether that answer should be captured somewhere so the next person doesn’t have to go looking for it again.
Review became trust but verify. The agent handles style, linting, obvious bugs, and test coverage. Humans stay where judgment still matters: legal risk tolerance, trust boundaries, security-sensitive code, and product taste. Fung’s caveat here is important. The right split keeps moving as models improve, so the review policy needs to be revisited instead of written once and treated as finished.
Roles blurred. Product managers on her team write code now. Engineers pick up design and content work. What she’s stopped hiring for is raw throughput, because the models increasingly provide that. The value moves toward creative builders with product sense and engineers with deep systems knowledge.
Obsolete processes don’t remove themselves. Somebody has to have permission to kill them, and on her team that permission is an explicit principle rather than something everyone is expected to infer.
Where this breaks against a signed scope of work
Just-in-time planning is the right answer when the roadmap belongs to you. It’s a much harder sell when a client signed a statement of work that lists the deliverables and the launch date. We can’t always prototype our way toward whatever the project turns out to want. We’ve already committed to a scope, and the commercial relationship is built around delivering against it.
The same tension runs through the rest of the process. Fung’s advice to kill your noisiest process assumes you own the process. A lot of ours belong to clients: their approval cycles, brand review, change boards, security requirements, release windows, procurement rules, accessibility checks, and internal ticketing systems. Those aren’t processes an agency can simply decide are obsolete.
Claxton’s playbook has a sidebar about legacy systems and naming one source of truth per artifact, but for an agency that is the main event rather than a footnote. The cleanest version of the playbook has the repository holding the authoritative record. On client work, that option frequently isn’t ours to choose. Their Jira may be the system of record because their auditors, compliance team, or internal process already depends on it. We don’t get to replace it with a markdown file in our repo because the architecture would be cleaner.
None of that makes the AI-native SDLC unusable for agencies. It just means the split runs differently than it does at a product company. The stages where you control your own tooling port over almost completely. The stages where the client’s process is the gate often don’t, and pretending otherwise usually produces a plan nobody follows for very long.
What the AI-native SDLC gives you regardless of who owns the roadmap
Review does, and we have data on that one rather than opinion.
Since February 27, we’ve run every pull request in our active repositories through CodeRaven. Over the first 148 days, that came to 1,164 pull requests, 14,552 findings, and a total AI spend of $161.20. The full breakdown is in our five-month AI code review dataset.
Two findings matter here. First, 24% of pull requests got changes requested, and that rate stayed within a 72% to 81% approval band even while review volume nearly doubled from March to June. A reviewer that gets more permissive as the pile grows isn’t very useful, and we didn’t see that drift.
Second, across eight contributors, what predicted getting stopped wasn’t how many pull requests someone opened. Our highest-volume contributor by count had an 83.3% approval rate, near the top of the group. The contributor who moved the most code, 2.63 million lines added across 196 pull requests, had the lowest approval rate at 62.3%. Approval rate mostly tracked how much surface area a change touched.
That’s the sequencing argument. Agentic coding raises the amount of code a person can move in a week, and the amount of code moved is the thing that correlates with review pushing back. Turning on generation before the independent check means accelerating exactly the input most likely to create problems.
Two files port over too, and both cost very little to put in place. A CLAUDE.md at the repo root holds build, test, and lint commands, the conventions that actually matter, and a running list of what the agent keeps getting wrong. A simple rule works well: if the same mistake happens twice, it goes in the file. Anthropic’s memory documentation covers the mechanics.
Alongside it, a review policy defines which passes you care about, what counts as important versus a nit, how many nits one review should be allowed to report, and what should be skipped entirely. That last part matters because AI review can bury a team in low-value style comments until people stop paying attention to the reviewer altogether.
Plan mode ports over too, and for agency work it’s probably the highest-leverage thing on this list. The agent reads the codebase without touching it and produces a written plan naming which files should change and which tests should prove the work is correct. The engineer corrects the plan before code exists.
Catching a bad decision while it’s still a paragraph costs a text edit. Catching the same decision in a finished diff costs a rework cycle, and when the diff itself took four minutes to generate, that rework cycle becomes one of the most expensive parts of the change. Waterfall front-loaded planning because building was expensive. AI-native engineering front-loads planning because building is cheap and reviewing isn’t.
There’s also a second benefit that matters specifically when you bill clients. A committed plan becomes a scope artifact. When a client asks for something the plan doesn’t cover, the conversation about whether it’s in scope has a document attached to it.
What to measure, and the one metric we’d keep
Fung suggests tracking three things as these changes roll out: onboarding ramp time going down, pull request cycle time going down, and the share of agent-assisted commits going up. Her caveat is right: throughput is a metric, not the goal.
Her evidence for those three is the weaker part of an otherwise strong piece. Ramp time is described as much faster than a year ago. The commit metric is an anecdote about not having seen a non-assisted commit in four months. Those are useful directional signals, but they’re surprisingly directional for an article telling engineering leaders to start measuring.
If we kept one, it’d be approval rate, or whatever your equivalent measure of review strictness is. Ramp time and cycle time both improve naturally when generation speeds up, so they mostly confirm that the tool is doing what you expected. Approval rate is the one that can quietly go the wrong way while every other number looks great, and you won’t see that drift unless you record a baseline before changing anything.
What this can’t tell you
We have production data for one stage out of six. The 1,164 pull requests are review data. Our use of plan mode, context files, and scope artifacts is experience rather than measurement, and those sections should be read at that weight.
The sample is three active repositories and eight contributors on a single team. That’s our production reality, not an industry pattern. We also sell an AI code reviewer, and the section arguing you should sequence review first is the one place where our data and our commercial interest point in the same direction.
We also don’t have a clean baseline, because these repositories were never run without AI review during this dataset. We know that 24% of pull requests received changes requested, but we can’t tell you what that number would’ve been under human-only review.
What we’d do with this
- Sequence review ahead of generation. Churn predicts pushback, and agentic coding is a churn multiplier. The other order accelerates the problem before installing the check.
- Write the two files before anything else. A context file and a review policy change agent output immediately, and most of the remaining practices assume one or both already exists.
- Treat plan mode as both a control and a scope artifact. On client work, the second function can be worth as much as the first.
- Sort your processes by who owns them. The ones you own are fair game for Fung’s advice about killing what no longer serves you. The ones a client owns are a negotiation, not a decision, and planning as though they’re yours is how these initiatives stall.
- Record one number before you change anything. Ours is approval rate. Most of the speed metrics improve on their own and tell you less.
The practical version of the AI-native SDLC for an agency is narrower than the version you’d implement inside a product company. The file chain and review layer port over almost completely, the organizational norms port where you actually control the process, and just-in-time planning mostly doesn’t port when someone else signed for the scope.
That’s a narrower adoption than either Anthropic article describes, but it’s still most of the value.
If your codebase grew faster than its foundations, AI-generated or otherwise, that’s what our AI code rescue practice is for, with CodeRaven doing the systematic first pass. If you’re standing up agent workflows and want the review and evaluation layer designed in rather than bolted on later, that’s AI agent development and custom LLM development. And if what you actually need is someone to look at how your team works now, including the parts your clients control, and tell you which two or three changes are worth making this quarter, that’s where our AI consulting practice starts.
