The AI-native SDLC won’t be one process
The New Stack Anirudh Ramanathan
Anthropic says AI coding shifts the bottleneck from writing code to everything around it. The twist: one fixed workflow won’t fit every change, and that’s the real problem.
Based on reporting by The New Stack, Anirudh Ramanathan — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Anthropic’s AI-Native SDLC Playbook starts from a blunt premise: code is no longer the bottleneck. If agents can spit out an implementation in minutes, the hard part moves elsewhere — planning, review, verification, deployment, and governance. That is the right diagnosis. It also raises an ugly one: you can end up shipping far more changes at the same quality per change, or worse, with no reliable way to spot the bad ones.
The playbook lands in the middle of a broader spec-driven push, alongside tools like Amazon’s Kiro and GitHub’s Spec Kit. These systems share a neat idea: written artifacts drive the work, policy is enforced by deterministic mechanisms such as hooks, agents check their own work before humans see it, and humans hold the approvals. The catch is that they also tend to hard-code a single route through that machinery. Adopting the tool means adopting its process.
That is where the article draws a sharp line. Real organizations do not run one process. A documentation fix, a dependency upgrade, and a schema migration in a payments service should not be treated like the same kind of change. They carry different risks, need different approvals, and in regulated settings they need different records. If the tool insists on one path, teams will either work around it or keep adding configuration until the thing turns into a workflow engine nobody fully understands.
The alternative is to treat each process as a state machine. The process becomes a set of rules stored as data and reviewed like code, with states such as reviewed, validated, or approved for production. Rules fire based on facts from the repository, CI, the cluster, or the tracker, not on a model’s self-report. A gate can be automatic, or it can stop for a human. And because the process definition itself is data, changing the policy for one class of change goes through its own guarded process.
That lets the path vary with the change. A docs fix can move from build pass to merge with no person involved. A dependency upgrade may need compatibility evidence against real dependencies. A schema migration in payments can demand review by a payments owner, validation against production-shaped data, and a release approval from someone accountable for that domain. The point is not to remove humans. It is to spend human judgment only where it actually matters, while keeping an audit trail that shows who approved what, and on what evidence.
My take — AI-written commentary, not fact-checked reporting
This is the part most AI tooling vendors keep dodging: one shiny workflow for every change is a toy, not a control system. The grown-up move is boring and better — classify risk, log the evidence, and stop pretending a prompt is governance. The industry loves “simplifying” until the first audit shows up with a flashlight.
Read more about this at: The New Stack
