Stop Starting With Code. Anthropic's New First Step

Author: Hyperautomation Labs · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Stop Starting With Code. Anthropic’s New First Step · Channel: Hyperautomation Labs · 13:00 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI evaluation and benchmarks, Claude Code, Software engineering with AI

Summary

Anthropic’s AI Native SDLC playbook describes how software teams can adapt when AI makes coding faster but planning, review, and release remain bottlenecks. It organizes development into six stages—plan, design, build, test, deploy, and maintain—with each stage producing a file that the next stage can use. The course emphasizes human approval, reliable ways for agents to verify their work, and hooks that enforce rules more reliably than prompts. Teams can begin with small changes such as a concise claude.md, a test command, and a hook that blocks an unacceptable action.

Key points

AI-assisted coding shifts bottlenecks toward planning, review, and release.
Each stage commits a file to Git, creating an audit trail and giving the next stage a starting point.
The plan stage captures a problem, its intended outcome, affected people, limits, and open questions in intent.md.
During build, engineers can use plan mode, claude.md, skills, and parallel sessions to guide Claude.
Skills offer guidance, while hooks can allow, require approval for, or block actions.
Claude should have a way to check its own work, including tests, build commands, and screenshots where relevant.
Evaluation tasks can be run repeatedly to check whether changes to prompts, skills, or hooks improve results.
AI code review can help focus human attention, but a human code owner still approves merges.
Deployment actions should remain behind existing gates, with agents unable to push directly to main or pass the production gate.
The maintain stage can turn monitored issues into new intents, feeding findings back into the development loop.

Chapters

Start	Chapter	Summary
00:00	Why the software process needs to change	The video introduces Anthropic’s course and explains how AI coding shifts the bottlenecks from building code to the processes around it.
02:01	The file-based workflow: plan and design	The playbook connects its stages through committed files, beginning with an intent.md and then a requirements and design spec.
03:34	Build and test with Claude	The video covers plan mode, claude.md, skills, parallel sessions, and ways to verify code with tests and evaluations.
08:17	Deploy with review and approval gates	AI-assisted reviews, hooks, and CI workflows help automate work while keeping human approval and production safeguards in place.
10:21	Maintain the loop and choose where to start	Monitoring can produce new intents, and the video closes with reported Anthropic results and practical first steps for adopting the playbook.

Quotes

coding is no longer the bottleneck — 01:30

Every stage ends by committing one file to Git, and the next stage starts by reading that file. — 02:01

the skill makes violations rare, and a hook makes them close to impossible. — 05:39

If something needs to happen every time without fail, don’t put it in a prompt. Put it in a hook. — 09:20

Six stages, six files, one loop. And people still make every call that matters. — 13:00

Concepts and entities

Anthropic, AI Native SDLC Playbook, Claude Code, Fiona Fung, intent.md, spec.md, plan.md, CLAUDE.md, hooks, evals

Full transcript (original language)

00:00 Antropic just released a free course on how software gets built now, not the code part, everything around it. And it starts with a question from the person who runs engineering on cloud code. >> When coding is no longer the bottleneck, what changes? And so on the cloud code team, coding is really the slow part anymore. And so like that’s why all the upstream and all the downstream kind of like processes we felt like we’ve have to change a little bit.

00:30 >> That’s Fiona Fung who leads engineering and product for claude code. This course is anthropic answer to her question. It’s called the AI native SDLC playbook. 14 lessons about an hour and I went through every page. By the end of this video you’ll know all six stages. the one file each stage leaves behind and the sixth place you can start on Monday with nothing else in place. Here’s the

01:00 problem the course opens with. Teams now write code with AI at a speed nobody expected a year ago, but the process around the code hasn’t changed. Same approval gates, same reviews, same handoffs. Look at this diagram from the first lesson. Before agents, build was the long block. After agents, build shrinks to a sliver. So now the slow parts are everything around it. Planning, review, and release still

01:30 running at human speed because coding is no longer the bottleneck and also we’re doing so much more of it. These are some of the new bottlenecks that we’re seeing. So it’s really always us asking is this code correct? Who reviews this code? So the course turns the old straight line into a loop with Claude at every stage and people above it, starting it, steering it, and approving it. And here’s the idea that holds the whole thing together. Every stage ends by committing one file to Git, and the next

02:01 stage starts by reading that file. An accepted intent starts the design. An approved spec starts the plan. A merged pull request starts the pipeline. So your history of commits becomes the audit trail. Who asked for what? What the agent built and who approved it. >> Colleague of mine once said the markdown file is the lingua frana of the AI in nature of software development life cycle. >> Stage one is plan and the file is intent.md.

02:32 Someone has an idea. Instead of a backlog ticket and three meetings, they explain the problem to Claude in their own words. Claude asks what an analyst would ask, who it’s for, what’s in scope, and what success looks like. Then it writes this, the problem, the outcome, who’s affected, the limits, and the open questions. The person fixes anything Claude got wrong and commits it. The course says this should go from a few

03:03 weeks to a few hours. Stage two is design. Once the intent is accepted, Claude turns it into a requirements and design spec spec.md. This is the actual prompt from the course. And the last line is the clever part. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies. The company’s rules for brand security and design are loaded as skills. So

03:34 conflicts show up while the spec is being written, not in a review weeks later. The product owner reviews the spec, but doesn’t write it. And a human always decides if it goes to build. Quick one. If this is useful, hit subscribe. It’s free. And to back the work, hit join or the supporter button on Facebook. Now, stage three. Stage three is build and it has four plays. The first is plan mode. The engineer starts clawed code in plan mode, hands

04:05 it the spec and asks for a plan. Which files change in what order and which tests prove it works? >> If you take one thing away from cloud code, let it be this workflow. Explore, plan, code, and commit. >> Then you question the plan. What could this break? Which step is riskiest? What did you decide not to do? Keep going until an engineer who never saw the conversation could build it from the plan alone. Plan mode enforces this on

04:37 its own because Claude can’t edit a single file until you accept the plan. You commit it as plan MD and later the code review checks the final change against it. Play two is the claude.md file. Think of it as what a new hire needs on day one. The build and test commands the team’s rules and a section this example calls things Claude gets wrong. Run /init. Cut it to under a page and commit

05:07 it. Then follow one rule from the course. When Claude makes the same mistake twice, the fix goes into claude.md. It’s a markdown file that you add to the root of your project and Cloud Code reads it automatically every time you start a session. It’s like an onboarding script for your codebase. Play three is skills. A skill is a small folder that tells Claude when to use it and exactly what to do. Like this company’s API security standard. The policy owner signs off and everyone gets the new

05:39 version in their next session. But here’s the line most people miss. A skill is advisory. Claude will usually follow it, but nothing forces it to. In the course’s words, the skill makes violations rare, and a hook makes them close to impossible. >> If you find yourself explaining the [music] same thing to Claude repeatedly, well, that’s a skill waiting to be written. >> Play four is parallel sessions. One engineer runs two or three Claude sessions at once, each in its own work

06:10 tree, so they never touch the same files. jobs you repeat become sub agents, like this verifier, which runs the app and reports what it sees, but isn’t allowed to fix anything. And the limit isn’t your laptop. It’s how many streams one person can properly review. >> It’s going to be very tempting to use multiple clouds at once. And so I know people at Anthropic and a few customers that run four clouds at the same time. Stage four is test and it holds the most

06:41 useful rule in the whole course. Always give Claude a way to check its own work. One command for the tests, one for the build and a screenshot for anything on screen. For a bug fix, Claude writes the failing test first. You confirm it fails and you commit it. Only then do you ask for the fix. And this line goes straight into your claude.md. If a test fails, fix the code, not the test. The course even suggests a hook

07:13 that blocks edits to test files during a fix. So the agent can’t weaken its own check. >> Verification is so important because like I think we for our team especially, we have, you know, really paid a lot of attention to verification. And so >> when Claude creates a PR for me for cloud code, yes. >> Uh it tests it, it sends me screenshots for what it will look like. uh and then you kind of get confidence. concern. >> Play two is eval. Collect 20 to 50 real tasks from recent work, each with the

07:45 result you’d accept. Run them in CI every night and every time someone changes claude.md a skill or a hook. That setup steers the agent so it gets tested like code and every production incident becomes a new evil. So the same mistake can’t quietly come back. So when we think about changing the prompts, how do we make how do we know we made things better or the same and we didn’t totally ruin cloud code? >> Stage five is deploy and the first play is AI in code review. The tech lead

08:17 writes a review file with three passes bugs, security, and whether the change matches the spec and the plan. It also caps nitpicks at five per review. And here’s the governance point. The agent that wrote the code has no way to approve it. The findings inform a human and a code owner still approves the merge. >> Claude really helps human reviewers uh choose where to focus their time and

08:48 energy. You can have Claude figure out those little things and address them autonomously. So it’s like that’s not really the important part of human code review anymore. >> Yeah. Next, hooks as approval gates. A hook is a small script that runs before Claude acts and it can allow the action, ask a person or block it. In this one, any production deploy without a named release approval gets blocked and the reason goes straight back to claude. The hooks a team must never

09:20 switch off go into manage settings which the platform team controls and engineers can’t override. If something needs to happen every time without fail, don’t put it in a prompt. Put it in a hook. >> Then CI and deployment. Start with read only jobs like Claude reading a failed build and writing a threeline summary on the pull request. Then add jobs that write behind the gates you already have. Anything the agent writes arrives as a

09:51 pull request with no way to push straight to main. The course sums it up in one sentence. The agent may act up to the production gate and cannot pass it. >> And then headless automation. I think this is the thing we’re most excited about, but also we are still trying to wrap our heads around internally, which is how can we use Claude programmatically. We have that in GitHub actions. We want to figure out other creative places we can start using it. >> Stage six is maintain. And this is where

10:21 the line becomes a loop. A plain script with no AI in it watches one number like how often your tests fail. The rules live in a small file called bands.yuml. A little offn normal and it just logs it. Further off and claude investigates read only way off and claude may act but only by opening a pull request or running a roll back that was approved in advance. and whatever it finds, it

10:52 writes up as a brand new intent MD. That’s stage one. Again, the loop feeds itself. >> Proactive agents uh beat reactive agents. We want Claude to go from a tool to a teammate. Um you can move from an agent that is waiting for you to actually press enter and create a PR to an agent that reacts to problems um and opens a PR itself. >> So, does this work at scale? Anthropic’s security team team published their own numbers. Claude now writes about 80% of

11:24 the code merged at Anthropic. Their engineers ship eight times as much code per quarter as they did from 2021 to 2025. And the share of pull requests that get real review comments grew from 16% to 54. So where do you start? The course maps all 12 plays by what they depend on. And the top row needs nothing at all. Capture intent, claude.m MD, skills, the feedback loop, hooks, and plan mode. If you are one person, pick

11:58 three for this week. A claude MD under a page. One test command Claude has to run before it says done. And one hook that blocks the thing you’d never want an agent to do. >> But where I still definitely want a human is that expertise. It’s all about trust but verify. >> Real talk, 90% of you watching haven’t subscribed. On Facebook, subscribe is the supporter button. That is what keeps the lights on here. On YouTube, it’s

12:28 free and it tells the algorithm to send you more. Subscribe to support us. I put every file from this video into one free PDF called the six files filled in from a real run. intent, spec plan, claude.m MD with the hooks, the evals and review file and bands.yml plus the order to adopt them. Comment intent and my bot sends it to you. New to claude code? My beginner guides are

13:00 linked below. To support this channel directly, hit join under this video or the supporter button on Facebook and follow along on Instagram for the quick wins. Six stages, six files, one loop. And people still make every call that matters. See you in the next one.