How much of the AI-native SDLC are we actually doing?

Our cofounder sent me Anthropic’s AI-Native SDLC playbook last week with one question attached: how much of this are we doing today?

I did not have an answer ready. The way I work has changed a lot this year, and I had never stopped to look at it. So I took an afternoon and went through the playbook’s six stages, one by one, against what I actually do.

First, some context, because it shapes my answer. A year ago I was at Freshworks, where the process looked like what the playbook calls traditional: defined roles, defined stages, work moving between them through documents and sign-offs. Now I am on a small team and I own a feature from design to production. There is nobody to hand anything to.

So the playbook’s main argument, that code is no longer the bottleneck and the process around it is, does not quite apply to us. We never had that process. What surprised me is that we still ended up with similar gaps.

Everything below is my own way of working, not a team standard. Everyone works differently.

Stage	Where I think I am
Plan	The biggest change of the six
Design	Far fewer rounds to get something I like
Build	Two methods, picked by how much I trust the plan
Test	Fine at the code level, still thinking about the rest
Deploy	Not a priority, and not much changed
Maintain	Our weakest stage, and we know it

Plan

Planning a feature in a service I did not write used to be the hardest part of my job. Not the writing. The problem was that I could not see every place a change would touch. I would scope the work from what I knew, feel fine about it, and find something later that I had no way of knowing about.

That risk is bigger for me today. Most of what we build is for marketing, which was a new domain for me, so a plan has to get two things right at once, the domain and the code. Later stages can iterate. The plan has to be right first.

What changed is that models read code well now, with no special setup. They follow a call through the codebase, see what a change will touch, and trace a bug back to its cause. I also use LSP, the Language Server Protocol, which is what your editor uses for go-to-definition and find-references. It gives the agent that same navigation, while MCP tools cover everything outside the code. Being on a monorepo helps, because it is all in one place.

Seeing the touch points, the part I used to be worst at, is now the part I trust most.

Design

I am hard to satisfy on design.

I started designing a couple of years ago with a friend who got me interested in it. We reviewed each other’s work, and from her I picked up the habit of looking at the details, shadows, borders, spacing, and at UX and accessibility rather than only the surface. The cost of that habit is that getting to something I liked used to take a lot of rounds.

I use Claude Design for mocks now. I tried Figma over MCP and could not get it working well, which may be my setup rather than the tool.

This is the stage I expected least from and got the most out of. A basic layout arrives in a couple of minutes and it is good. It does not replace a designer, and it is not close. What it removes is the blank canvas, and from a decent structure it is much easier to steer towards what I wanted. By feel rather than by count, I would say I need about a tenth of the rounds I used to. It does use a lot of tokens.

It can also read a design system. If you have a proper one defined, mocks for new features come together quickly. The review loop is the piece still missing.

Build

This is where AI is strongest. I am not sure when I last wrote code by hand.

Last year, with Cursor, I worked as an adviser. I prompted, it wrote, I corrected. That worked, but it was one long conversation rather than a process. Now the build starts from an approved plan, and that is most of what changed.

I use two methods, neither of them mine. I picked them up from other people’s skills and posts.

Sub-agent driven. For when I trust the plan and the feature is small. The plan already has the schemas, the decisions, the error cases and the task order. An orchestrator, currently Opus 5, spins up a git worktree and works through the tasks without interrupting me, mostly one after another. When the code is done, the orchestrator spawns reviewer agents that check the work from different angles, and a separate sub-agent writes the tests.

Inline checkpoint. For when I am less sure of the plan, or the feature is large. Claude splits the plan into tasks and I review each one before the next starts. Tests at the end, then push.

The rule is simple. The sub-agent method needs a plan good enough that I do not have to watch it. If I am not sure it is that good, watching in small pieces is cheaper than finding out at the end.

Test

A senior at my last company kept telling me not to trust code coverage. Then I saw it for myself. A feature went out with full coverage. Unit, integration, end to end, all green. It still broke in production. Coverage tells you the code ran. It does not tell you the business case was right. That is why I still check things by hand.

At the code level we are fine. Models spot edge cases and write unit, integration and Playwright tests well. Writing tests is not our problem any more.

I did move test writing to the end, though. Asking for tests from the first task onwards meant every change after a review broke them, and paying to rewrite tests against behaviour that has not settled is the most expensive habit I have dropped this year.

What I have been changing is the manual layer. Playwright covers the structured path. Next to it I use Claude’s Chrome MCP, which drives the browser the way a person would. For anything that needs my attention I still verify it myself. For smaller work, the sub-agent that writes the tests now runs a manual pass through Chrome MCP before the work reaches me.

So my role has moved up a level, something like the supervisor’s supervisor. I review the review, and the time that frees goes into thinking about what to build next.

I am not settled here. Chrome MCP is a good answer for now, not a final one. I think an AI-native workflow needs a different shape of testing than the one we inherited, and I do not know yet what that is.

Deploy

Not a priority for us. Small team, monorepo, fairly monolithic architecture, so there is not much deployment complexity, and the basics including automated rollback are in place.

The one real gain is recovery speed. Deployments still fail, and fixing them is faster now, because an agent with current documentation is good at finding the cause and the fix. That is a smaller change than the other stages and I will not dress it up.

Maintain

Our weakest stage, and we knew that before I read the playbook.

The first gap is product feedback. We have analytics, which I treat as a first step rather than the answer. What we do not have is a reliable way to hear from the marketers using the platform, feature by feature, and get that back into planning. Today, everything production teaches us reaches the next sprint because a person remembered it.

The second is organisational context, which is not on the playbook’s diagram. Conventions, architecture decisions, review guidelines, feature background, written as markdown that agents read, in AGENTS.md and CLAUDE.md. It helps a new person get up to speed, and it saves re-explaining the same context to an agent in every session. I think that does more for output quality than any model upgrade in the same period.

So, how much of this are we doing today?

So here is the answer I gave him. Plan, Design, Build and Test have all really changed. Deploy has not, and it does not need to yet.

That is more than “we use AI for coding” and less than the full loop in the playbook. What is missing sits at the end. Closing the loop from production back into planning is the frontier, and making the manual side of testing systematic is the step before it.

Almost everything I changed this year came down to the same trade-off, between my time and tokens. Not picking a method because it is correct in principle, but moving when the balance is clearly wrong.

If you do any of this differently, or think I have a piece of it wrong, I would like to hear it.