20:34Nate Herk | AI Automation · Review
Claude Code vs. Codex: An 8-Site Head-to-Head Design Test
Same prompts, same brand kits, two coding agents — one landing page built by each, eight times over, scored on design and on the bill.
August 26thThe argument in one line.
Anthropic's new AI-native SDLC playbook argues that agents already solved the build step, so the real work now is re-engineering every other stage, planning, testing, deployment, and maintenance, around one documented artifact chain (intent.md, spec.md, plan.md) that lets agents and humans hand off context without starting from scratch.
Read if. Skip if.
READ IF YOU ARE…
- You run a dev team, or a solo build, already using Claude Code, Cursor, or Codex and want a shared vocabulary for handing context between agents.
- You've had an agent get a task wrong because it started with no memory of an earlier conversation, and you want a documented pattern to fix that.
- You're deciding how much autonomy to grant agents (auto mode, hooks, permissions) and want a mental model before you flip those switches.
SKIP IF…
- You're not using AI coding agents in any real workflow yet, this is a refinement layer on top of agentic development, not an intro to it.
- You already have a working intent-to-deploy pipeline (Superpowers, BMAD, or your own) and aren't looking to swap frameworks.
The full version, fast.
Anthropic just published a playbook arguing that code is no longer the bottleneck in software development, your process is. The video walks through its six-stage AI-native SDLC: an agent interviews you to write an intent.md file, that becomes a spec.md and then a plan.md detailed enough for a stranger to implement, auto mode lets Claude execute the plan under tuned guardrails, agents write their own tests and evals before a human reviews the pull request, and in the maintenance stage a monitoring script can invoke Claude with no human involved to diagnose and fix production issues. The creator frames it as a starting template worth adopting piece by piece, not a mandate.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:08
01 · The AI-Native SDLC Paradigm Shift
Introduces Anthropic's playbook and the thesis that agents solved the build step, so the process around it is now the bottleneck.
01:08 – 04:37
02 · Mastering the intent.md Discovery Phase
How an agent interviews the originator of an idea or bug and synthesizes the conversation into a human-readable intent.md file.
04:37 – 06:52
03 · Automating Spec Generation and Governance
Turning an approved intent.md into a spec.md automatically, applying org-wide skills and policies, and version-controlling the artifacts (includes a Neon sponsor segment).
06:52 – 13:46
04 · Optimizing the Build and Test Loop
Interrogating the plan.md, running Claude in auto mode under tuned guardrails, parallel sub-agents with worktrees, self-testing, evals, and the pull-request review stage.
13:46 – 16:21
05 · The Future of Autonomous Maintenance
How a metric breach or ticket can invoke Claude headlessly to diagnose and fix production issues, closing the loop back to a new intent.md.
Lines worth screenshotting.
- Anthropic's new AI-native SDLC playbook argues that once agents make code cheap to produce, the software development process itself becomes the real bottleneck.
- The playbook formalizes one artifact chain, intent.md, then spec.md, then plan.md, that carries context between every stage and every agent instead of relying on tribal knowledge.
- An intent.md file can be written by anyone, a customer reporting a bug, a product manager, or a developer, not just a specialist, because the agent interviews the originator until it has a full picture.
- A good plan.md should be detailed enough that an engineer who never saw the underlying conversation could implement it correctly from the document alone.
- Auto mode lets Claude apply every change in a plan without a per-edit prompt, but it only becomes safe once an organization has tuned guardrails like CLAUDE.md, hooks, and a locked-down permission set.
- Because agents don't share memory between sessions, planning documents like intent.md and plan.md exist specifically to hand full context to sub-agents that start from zero.
- Continuous evals, roughly 20 collected real tasks with expected outcomes, are meant to run automatically whenever a model, skill, or core workflow file changes, to catch regressions before they hit production.
- In the AI-native maintenance stage, a monitored metric breach, a support ticket, or a scheduled trigger can invoke Claude with no human in the loop, generating its own intent.md from the incident and proposing a fix.
- A deterministic script watching production, not the agent itself, decides when a breach is severe enough to invoke Claude, keeping the trigger logic auditable and version-controlled.
- Governance in this workflow means version-controlling every plan, intent, and spec file and logging who approved each one, so teams can actually measure whether AI is speeding up delivery.
- Worktrees let multiple agents work on different parts of the same plan in parallel instead of serializing every change through one context window.
- There is no universal AI-native SDLC, teams already running frameworks like Superpowers or BMAD, or their own home-grown version, don't need to replace it just because Anthropic published this one.
Anthropic's playbook for handing agents your process, not just your code
AI WORKFLOW DESIGN
The gap agents haven't closed is context handoff between planning, building, testing and deployment, and Anthropic's playbook proposes one paper trail, intent.md to spec.md to plan.md, to close it.
- Write your intent as a standalone document, not a chat thread, so any agent or engineer can pick up the task with zero prior context.
- Let the agent interview you before it writes anything. A synthesized intent.md from a real back-and-forth beats a one-line ticket description.
- Judge a plan.md by whether a stranger could execute it correctly without reading your original conversation. If it can't stand alone, it isn't done.
- Only grant auto-accept autonomy after you've actually tuned the guardrails, CLAUDE.md rules, hooks that block risky actions, and a real permission boundary, not before.
- Build a small eval set, roughly 20 real past tasks with known-good outcomes, and rerun it whenever you change a model, skill, or core workflow file.
- Push testing earlier: have the agent write and run its own tests, lint, and even browser-driven checks before a human ever looks at the diff.
- Version-control every intent, spec, and plan file alongside the code. It's the only way to later prove whether the AI workflow actually sped anything up.
- Treat maintenance as a stage an agent can run headless, triggered by a metric breach or a ticket, as long as a deterministic script, not the agent, decides when to invoke it.
Terms worth knowing.
- intent.md
- A human-readable, machine-actionable file that captures the pain points, goals, and context behind a feature or bug, written collaboratively by an agent interviewing the person who spotted the need.
- spec.md
- A requirements and design document generated from an approved intent.md, meant to apply an organization's skills and brand/style guidelines before any code is written.
- plan.md
- A build-ready implementation plan listing the files to change, the order of work, risks, and success criteria, written to be executable by an engineer or agent with no prior context.
- Artifact chain
- The linked sequence of documents (intent.md to spec.md to plan.md) that Anthropic proposes as the paper trail carrying context through every stage of the AI-native SDLC.
- Auto mode
- A Claude Code mode where an approved plan is executed end-to-end without a per-edit approval prompt, relying on pre-tuned guardrails instead of manual review of each change.
- Blast radius
- The scope of damage an autonomous agent could cause if it goes wrong, used as a safety framing for how much unattended access to grant before enabling auto mode.
- Worktree
- A Git feature that lets multiple working copies of the same repository exist side by side, letting several agents build on different branches of a plan at the same time.
- Evals
- A regression test suite made of real past tasks with known-good outcomes, rerun whenever a model, skill, or core workflow file changes to check that quality hasn't dropped.
- Closing the loop
- Anthropic's term for the maintenance stage running fully autonomously, where a triggering event invokes Claude to diagnose and fix an issue with no human required to start the process.
- Originator
- The person, developer, customer, or product manager, who creates an intent.md, regardless of whether they have technical or specialist authority over the eventual solution.
Things they pointed at.
01:19toolSwitch Dimension Discovery (Rob's own skill)
01:19toolGrillMe (Matt Pocock)
01:19toolRequirements Discovery (Cursor)
09:50channelGit & Git Worktrees (Rob's own video)
Lines you could clip.
00:46
“Code is no longer the bottleneck. It's your process.”
04:05
“There really isn't a one size fits all here.”
09:18
“You've got to have a tight blast radius for your agent.”
15:53
“From loops to graph engineering, fully automated loops, large orchestrated systems, all the way to civilization engineering.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphor
So this is Boris Cherny and he's the creator of our friend Cloud Code. And these guys have just released their AI native SDLC playbook. So if this is a new concept to you, SDLC is the software development lifecycle.
Typically in a human workflow, it looks something like this. You plan, you design. You build it, you test it, you deploy it and put it into production, depending on what type of an app it is.
And then you need to look at maintenance. And then you go right back to the start for the next feature, bug or release. So this new document from Anthropic is all about how the team there, including Boris, work in terms of their new AI native software development lifecycle.
So let's give it a rapid breakdown. So the big idea here is . It's your process.
So before agents came along, this is pretty much how an SDLC looked. We had the planning stage. design, build, test, deploy, and maintain.
The part that took the longest and was typically the most expensive was the build stage. But that all changed with agents. This part here has been squashed down to this part here.
Look at all this time here we've reclaimed. So essentially what Anthropic are saying, we've done great to shrink this, we're two times faster, but how do we improve all these other steps with agents as well? So traditionally in our planning stage, we would sit down, gather requirements, create PRDs, have workshops, talk to stakeholders, pulling it all together.
In this new world, we start by getting the agent to interview us about the feature, the bug or the product that we're building in order to build up context. I use my own discovery skill called Switch Dimension Discovery. You could use GrillMe from Matt Pocock or you could use something like Requirements Discovery from Cursor.
So what you want to do is make sure the agent asks you repeated questions until it has a complete understanding of the feature you're building or the bug you're trying to solve. You're dumping as much of your experience, domain experience and context into this conversation. agent synthesizes pain points straight from the sources and then captures them in this intent .md file which is human readable and machine actionable.
So Anthropic is formalizing this idea around an intent .md file. So in the traditional SELC, the idea passed through a backlog of user entries, user stories, story points, ownership transfers, handoff. What we're talking about in the AI native world is the originator of the issue, the feature, the product, whatever, brainstorms with Claude and writes the result down as the intent .md.
So for each one of these steps, as we move through, we're going to be developing what's called an artifact chain. First, we start with an intent .md file. Then we're going to have a spec, et cetera, as we go through the steps.
That's building the artifact chain. So in your project, using cursor, cloud code, codex, whatever you want, you're just creating a folder called intent. And within that, that's where you're going to save your intent .md file.
So in my planning stage here I might have a chat with my agent about adding dark mode as a feature and I talk about what I want, how I want it to operate and then we go and create an intent .md file from that. Then I get the agent to save that as the intent .md file in the intent folder as proposed by Entropic. And of course, with any of these artifacts, your team can do whatever they want in terms of a workflow.
I think what's important here is that you start to standardize it and not chop and change it too often. That way, the team, the agents, the skills all work on the same workflow and you can grow from there. Now, once that intent .md file is created, it doesn't stop there.
It's suggested that the originator of the intent goes back over what the agent has written to correct anything and make sure that both of them are happy. Now, the person that creates this intent .md file is called the originator and that doesn't have to be a specialist on the team. That can be anybody who wants to create the intent.
It could be a customer who's putting in a bug request. It could be a product manager who has an idea for a feature. It could be a developer who wants to capture a process improvement so you might have your own intent capture skill that produces something similar to this what you might do over time as you're collecting more forms of intent you might prefix the name of the intent before your intent .md file this is something i've been doing myself and teach on my course i call it discovery not intent but again it's the same idea so the intent really can be captured by anyone could be a developer a customer submitting a bug they're basically just dropping their thoughts into this intent .md file but then it is the product owner that should review these in the form of a backlog.
These could simply be ordered files in a markdown file. All these ideas could be captured in Notion or Linear and then organized by either a product owner or in some cases, I'll actually use my agents to triage the backlog of issues. You can see they can assign tags like front end, small or large tasks, whether it's a feature and even the priority level.
So then we're moving from the intent artifact to the spec artifact. And Tropic is suggesting that once the intent is committed or signed off in some way that you create a hook or a process that the spec is automatically generated.
So Entropic gives us a sample prompt we might use to take our intent and turn it into a spec. They're not giving us specific skills here, but we could certainly create a skill around this. So essentially, read the attached intent MD and produce a requirements and design spec, apply skills available to you to plan and conform to brand guidelines, and then document the spec fully in a spec .md.
Depending on your workflow, your organization, you could just use the vanilla plan mode within Cursor or Cloud Code or Codex or... you could just go and create a skill that creates bespoke specs specific to how your team likes to work. There really isn't a one size fits all here.
Now, when that spec is created, it could just be through a vanilla agent, or you might also have a set of guidelines or policies or even skills that make sure that style guides are applied and however the spec is generated is based on the best practices of your organization. This might be in an agents .md file. It could be encoded into a set of skills.
You want to make sure that those skills and policies are adhered to in your governance considerations for when the spec is being generated. And that applies to all of the artifacts in this. chain.
A quick diversion to talk about our sponsor Neon. If you're using agents heavily in your SCLC I highly recommend you check them out. I've been using Neon for years for all my database needs.
I've talked loads about how Neon is ideal for agent workflows with their awesome branching feature. What I love about Neon is they're totally agent first. So in all my agents, here's an example of Cursor.
I've got their MCP and the CLI and their set of skills plugged in. So I never even have to touch the dashboard. The agent knows what to do with all their services.
If you haven't checked in on Neon lately, it's now a full -fledged platform. It has managed better auth included, which links to your database. You've also got long running functions with no timeouts.
s3 compatible object storage for all your files and your projects if you're building projects and working with agents i highly recommend neon for an easy life channel subscribers can check them out via the link in the description down below so let's get back to the sdlc so next up we're moving into build mode so it starts essentially by the engineer involved in the process pulling in the intent and the spec and feeding it into cloud code either in or in cursor in plan mode or something like that basically feeding the intent and the spec So what we get then is a plan .md file.
So what Entropic are suggesting is you interrogate the plan by asking what changes could break. Essentially, you want to get to a point where if you were just to hand over this plan .md file to an engineer, they could go and implement the changes without. reference to the intent or spec documents.
Now that's actually an important point because we're not going to have one agent carry out all of these different stages in the software development lifecycle. We're going to have a context window. We're going to have a thread of conversations.
Independent agents, sub -agents are going to handle this process. So in that world, and here's just an example from one of my own workflows, you've got multiple different agents working on the problem. You want to hand off your planning, your intent as documents to each one so it can start.
from scratch without an understanding of the previous conversation that happened so when the engineer is happy they go and proceed with the plan you've probably seen 50 ways to write a plan but essentially what Amtropic are saying is you break it down into the files that need to be changed the order of work or a type of to -do list any kind of risks constraints and then proof so you want some kind of success criteria and checks inevitably to make sure that the work was done correctly This could come in a deterministic form of linting and tests.
A big part of the process in an enterprise company is going to be governance. So what Entropic suggests is that you're saving versions of your plan, your intent, your spec .md, who touches them and how they are evolved. Companies I've worked with find this part particularly hard, but it's really important if you want to track the leading and lag indicators for your projects and really prove out your DORA metrics or see how effective AI actually is becoming in your workflows.
So in terms of making your build mode fast, Entropic suggests you use auto mode. It really does depend though on your own organization. What I suggest is that when you've got a locked down environment that you're working in, that you actually start to work in the repository with a set of dialed in permissions and that you're accepting them as you go.
Once you've built up a policy of what's fair use, what tools the agents can access, what web sources, what packages they're pulling. and you lock that down in terms of cursor or cloud permissions you're going to be able to have your agents move a lot faster without you involved there are a lot of elements in making sure auto mode runs smoothly and you've got a not for the context of this video but hopefully i'll cover more on that again the team also suggests work trees so you can have multiple agents work on multiple things at the same time if that's completely over your head I've got a full video on my channel covering Git and Git work trees if you're just getting used to them when it comes to working with agents.
So a big part of keeping this process autonomous, keeping things updated and keeping things on rail are the usage of hooks. So as an example in the build phase, we might update the plan once the implementation is complete. We might block the agent from working on certain folders or prevent it from upgrading an NPM package that we haven't signed off on yet.
Linting has been around for a long time. It's essentially a deterministic or a coded way of running through our code or our documents and checking that certain criteria are there or not there, or that we're matching a particular syntax. It's going to run through the files.
The test will pass or not. It's going to be a binary yes or no. Something you'll get in a good agent harness is the ability to run sub -agents.
So once the plan is in place, this is actually baked into Cursor Cloud Code Codex. It divides the plan into various different tasks that can be done independently. And if some are in parallel, it can use Worktree.
So we end up having multiple agents and sub -agents working on the build step. So after we're finished building, we move into the test phase. In the traditional software development lifecycle, this can be a step that really holds things up.
I might have finished a piece of work, pushed it into development, and then I have to wait a couple of days for a tester to come along or a QA. Then there's some changes, feedback, etc. The whole cycle takes quite a lot of time.
In the AI software development lifecycle, we want the agent to do as much testing as possible before a human engineer or QA gets near it. Now, sorry if this diagram diverges a little bit from Anthropic are talking about, but this is the workflow I've been teaching on my course at Switch Dimension, which is really similar.
So essentially, once we finish the build step here, we move into testing, linting, end -to -end review. The agent write tests to make sure nothing is breaking when developed and make sure those tests pass. It's going to lint and build the project to make sure there's no errors.
and if you're advanced enough and you're using something like playwright test sprite cursor browser you can actually get the agent to test the software and take screenshots this is actually something that cursor cloud agents do really well they'll actually spin up a server and test the software for you and give you a screen recording so theoretically once the testing is complete and it's fairly rigorous it's going to save you a whole lot of time when it comes to the human review stage Anthropic also suggests that you apply evals to any skill change or any model upgrade.
Now this really is optimizing, but the idea is that you have continuous evaluations in your continuous integration. So basically you might collect 20 or so issues or things that you might have solved in the code base. You have a set of expected outcomes for those.
and whenever you have a new model a new skill or a new fundamental change to how you do your work you can run this to see if your software development life cycle regresses or not so now we're getting to the deploy stage essentially we've done our human review we're going to get the agent to merge or we're going to get it to create a pull request to the main repository based on whatever changes it made so essentially we have a development branch or a production branch and our agent is after making some changes on its own branch or in a work tree so it's made something called a pull request where it's saying hey i've made some changes you to take a look at them and if you're happy you can go and add them into the main code base so entropic is suggesting as part of your continuous integration or whenever a pull request is made that you get claude to jump in and review it against your policies and your security protocols and all this is done asynchronously now the agent might have its own comments on this pr saying it doesn't accept it or it wants some changes made
And in Anthropix SDLC, you've got a separate instance of Cloud Code reviewing those comments. And of course, it might have different policies based on what agents .md, what scales .md, what hooks, what linting it has in place. In terms of governance, you might even have a hook in place here that would block deployment unless a specific permission has been granted, unless a specific person approves or a release gate is met.
Here's an example of a set of permissions that might be used as part of that stage. So once the pull request is complete, you have another agent that runs the security, the CI preview. This could be deterministic with some form of linting and gate checking, as well as just having an agent like Cursor, Bugbot, or Cloud Security Review come in and check for any errors.
And that finally brings us to the maintenance step. So I think this is where the workflow gets really aspirational. So we look at our whole workflow here.
We've moved to planning, design, building, testing, deploying, and now we've reached maintenance. So at this point, either our issue is, fixed or our feature is built and it's sitting within the code base.
So in a traditional software development lifecycle, maintenance can be a reactive phase. You're out for lunch, you're on call, or maybe it's 3am in the morning and you get an alert to say that your server has fallen over. A ticket is sitting in a backlog and it gets completely ignored because there's just too much in the backlog.
In the AI SDLC, a breach, a new ticket, a channel message in Slack or some kind of a schedule invokes Claude without any kind of a person involved to perform maintenance. cloud asynchronously goes ahead and diagnoses and acts on that in and in this case it's generating its own intent .md file based on the logs that it's discovered or whatever ticket or message it's been sent now how this works in practicality is you might decide that you have certain metrics that you want to uphold to so maybe in your testing a page falls over or your api rate limit rapidly increases that might trigger an agent to go and diagnose create an intent to diagnose a problem and offer a set of suggestions all before you've even got to your computer so the whole premise of this document is we're moving past agents just being involved in the build step to being employed in the whole software development life cycle how can we start to reduce the amount of human time involved in each one of these steps but importantly keeping humans in the loop for the important review steps
It depends on your workflow and your need and your team, but you can have as many humans involved in each step or agents or purely just agents on their own if there's low criticality. I've worked in a lot of companies and I've worked with a lot of companies with their AI SDLC. And the thing is, there really is no one size fits all.
If you're using something like superpowers or BMAD or you develop your own version of this, I wouldn't throw it completely out the window to adopt what Anthropic is doing here. There are so many different ways to approach this. From loops to graph engineering, fully automated loops, large orchestrated systems, all the way to .
I'd love to hear how you're working your software development lifecycle, even if it's as simple as plan mode or complete vibe code YOLO. If you want to learn how to make yourself or your development team AI native in terms of software development lifecycle, highly recommend you check out Switch Dimension. You can sign up the waitlist there for the next cohort.
Thanks so much for your time, guys. See you next week.
The Hook
The bait, then the rug-pull.
Anthropic's own team, including Claude Code creator Boris Cherny, just published a document that reframes the entire software lifecycle around agents. Rob Shocks pulls it apart stage by stage: what an intent.md actually is, when to trust auto mode, and which parts of this playbook are worth stealing today.
Named ideas worth stealing.
02:20list
The Artifact Chain (intent.md to spec.md to plan.md)
- intent.md
- spec.md
- plan.md
- PR + review
- production monitoring
Anthropic's proposed sequence of documents that carries context from a raw idea through to a merged, monitored feature, so no stage requires re-explaining the problem from scratch.
Steal forany team handing tasks between multiple agents or people who don't share chat history
07:07list
Interrogate the Plan (plan.md checklist)
- List the files that will change
- Order of work / to-do list
- Note risks and constraints
- Define proof / success criteria
- Ask what the change could break
- Iterate until an engineer with no prior context could implement it
- Commit plan.md and update it if implementation departs
Anthropic's bar for a build-ready plan: a stranger with zero conversation history should be able to execute it correctly.
Steal forany spec or plan template used to brief a fresh agent or a new hire
11:07model
Rob's Multi-Agent SDLC Pipeline
- Agent 2: Prototype
- Agent 3: Plan (writes PLAN.md / TODO.md)
- Agent 4: Build (worktree sub-agents)
- Agent 5: Test, Lint, e2e Review
- Human Review
- Agent 5: Pull Request / Iterate-Merge
The creator's own adaptation of the playbook: numbered agents each scoped to one stage, running inside sandboxed permissions and Git worktrees.
Steal forstructuring a real multi-agent build pipeline instead of one long agent session
15:50model
The Basic Loop
- Agent 1: Write Code
- Agent 1: Review Code
- Pass/Fail gate (unit, integration, e2e, visual tests)
- Agent 1: Commit + Push
A minimal deterministic loop with one conditional-routing decision point between review and commit.
Steal fora lightweight starting template for teams not ready for the full six-stage playbook
How they asked for the click.
VERBAL ASK
15:42product
“If you want to learn how to make yourself or your development team AI native in terms of software development lifecycle, highly recommend you check out Switch Dimension. You can sign up the waitlist there for the next cohort.”
Single soft end-card plug for his own paid course/community, placed after a full value-first breakdown rather than interrupting it; brief and not pushy.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
