• The AI-SDLC at a High Level
• Scaling Ourselves with Skills
• Can We Get Rid of Code Reviews Altogether?
• Can We Get Rid of On-Call as Well?
• Conclusions

Earlier this week I read The AI-Native SDLC Playbook from Anthropic.

It should be mandated reading in Engineering orgs, and even more so for Security people, at every level of seniority.

Read the post. Take the time to think each concept through. I truly think we, as an industry, should have the courage to throw away the playbooks we’ve been working on for the past 20+ years and create new (and better) ones for the AI era.

Below are some notes I consider useful for our industry.

The AI-SDLC at a High Level

The playbook opens by naming two assumptions baked into the traditional software development lifecycle:

The traditional SDLC was designed to maximize efficiency in an era where the most time-consuming and expensive stage was writing and implementing code, which is no longer the case […]

The traditional SDLC also features controls that assume every step is performed by humans.

Both assumptions are gone. Writing code is now the cheap part, and agents perform a growing share of the steps.

The playbook’s answer is to rethink the six traditional stages as a loop, with Claude embedded at each one and version-controlled files (intent.md, spec.md, plan.md, the diff, the review findings) carrying the handoff between stages:

Instead of a linear flow, the process becomes a loop, and AI is embedded at each point. The AI-native SDLC promotes automated handover and triggering of subsequent plays, helping to address the manual and clunky nature of handoff between the phases of the traditional SDLC.

I won’t re-hash the steps here. Go read the Anthropic post.

Scaling Ourselves with Skills

The section on skills is the one I’d point security teams to first:

Skills are how an organization makes its institutional knowledge operational. The instructions are explicit, version-controlled, applied broadly, and updated centrally when policy changes

With skills, policies are applied at design time, while the agent writes the spec:

Instead of being discovered in a review weeks later, the live policy is read and applied while the spec is written. The organization’s skills are applied as constraints on the spec. The spec, the prompt that produced it, and the skill versions in force are all logged in version control.

And again at implementation time, since the workflows that write the code invoke the same skills.

The playbook’s example is a secure-api-review skill, living at .claude/skills/secure-api-review/SKILL.md:

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

Skills alone are not enough though. A skill is advice the agent is likely to follow, but nothing forces a session to comply with it:

A skill is a control, though an advisory one. It makes Claude likely to apply the policy while the code is written, and nothing forces a session to comply with it. A policy that must always hold needs something deterministic behind the skill, such as a hook that blocks the action or a review pass that re-checks the policy at the PR. The skill makes violations rare and the hook makes them close to impossible.

This is where hooks come in:

A skill is an advisory control while a hook is the deterministic layer behind it. […]

Back any skill whose policy has to hold without exception. A hook runs on each action that matches it, so build-phase hooks should be fast and scoped to the file that changed. Heavier checks such as the full test suite belong at the commit or the PR.

If you’ve read My Claude Code Setup  , this is the same pattern I use: hooks block rm -rf, pushes to main, and terraform apply, regardless of what any skill or prompt says. Same thing at the organisation level: skills for the policies you want followed, hooks for the policies that cannot be broken.

Can We Get Rid of Code Reviews Altogether?

Let’s be honest: how many people still review PRs line by line? Or do you skim the main files changed and point your own agent at the rest?

That is exactly what the playbook proposes:

Claude both gives and receives reviews. It reviews incoming PRs against the organization’s policies and addresses review comments on its own PRs. This allows engineers to focus on behavior in their PR review, which boils down to judging intent and risk.

If the agent writes the PR, reviews the PR, and addresses the review comments, why keep humans in the ping-pong at all?

Two things happen when agents take over the ping-pong. Humans move up a level, and every PR gets the same treatment:

All PRs get an identical set of review passes, with findings ranked by severity. Human attention moves up a level, to whether the change does what the plan intended and whether the risk is acceptable.

The value here is in the word identical. Every PR gets checked for security and conventions through the same skills, instead of leaving it to a judgment that varies by reviewer.

And it does vary. Most of us have, at some point, asked for a review from the buddy who rubber-stamps instead of the engineer who nitpicks everything. So why not removing any discrepancy and uniform the review itself?

The main obstacle I’m afraid is compliance. Many certifications mandate a two-person peer review on every change, and that control has not kept up with the times. That’s also why at the beginning of the post I said that we should throw away the 20-year-old playbooks and write new ones.

To be fair, I’m not the only one thinking about this. Here are other two pieces published a day apart earlier this month:

• Maybe We Shouldn’t Be Reviewing All This Code
• The End of Code Review? Or an Opportunity to Rethink it?

Can We Get Rid of On-Call as Well?

On-call is probably the task security people dread most. Can we then institutionalise our internal knowledge so that the first responder is an agent?

An alert invokes the agent, with no person in the path, and what the agent may do depends on the severity: log, diagnose read-only, or act (open a PR, trigger a runbook). In the incident channel, Claude joins as a team member and responds before the human on-call has picked up the page.

A lot has already been written on this. If you subscribe to CloudSecList you’ve seen close to one post a week on automating the SOC. That’s because, of everything in the playbook, this is likely the lowest-hanging fruit for a security team.

Conclusions

I don’t have answers here. The industry is early on this, and most of what I’ve seen so far is one person wiring skills and hooks for themselves. I have yet to see a security team run this at the organisation level, with auditors in the room.

A few questions for anyone who has run this inside an organisation:

• Has your team replaced line-by-line human review with agent review passes, and what did your auditors say?
• Is an agent the first responder for your security alerts in production, and where did it break first?
• Have you encoded a security policy as a skill backed by a hook, and did it hold across an entire engineering org?

I hope you found this post valuable and interesting, and I’m keen to get feedback on it! If you find the information shared helpful, if something is missing, or if you have ideas on improving it, please let me know on 🐣 Twitter or at 📢 feedback.marcolancini.it.

Thank you! 🙇‍♂️