The AI-native SDLC won’t be one process

Anthropic's AI-Native SDLC Playbook argues that code is no longer the bottleneck in software development. When AI agents can produce implementations in minutes, the bottleneck shifts to planning, review, verification, deployment, and governance. The main risk is that organizations may produce ten times more changes with the same quality or worse, without a way to identify which changes are problematic.

The playbook correctly identifies this issue but fails to account for the nuanced nature of an organization's process. It presents process as a single, linear flow, when in reality it is a family of processes that vary depending on the specific change being made. Tools like Amazon's Kiro and GitHub's Spec Kit follow a similar pattern, using written artifacts to drive the work and deterministic mechanisms to enforce policy.

However, they also prescribe a specific process that must be adopted, limiting flexibility. Real organizations do not run a single process; the appropriate process for a given change depends on its risk and accountability requirements. A documentation fix, dependency upgrade, or schema migration in a payments service should each have different verification levels, approvers, and recording requirements.

When a tool enforces a single process, teams often find ways around it for changes that don't fit, which is the worst outcome because the true process becomes hidden. Alternatively, vendors may add more configuration until the tool becomes an opaque workflow engine. Instead of prescribing a process, the tool should provide a way for the organization to define its own.

A better approach is to model processes as state machines, with states representing facts about the change such as reviewed, validated, approved, and production-ready. These states live in various systems like the repository, CI, cluster, and tracker. Processes are then defined as rules that react to observations in these systems, specifying the conditions under which they can fire, whether they require human approval, and what permissions they grant (e.g., merging or deploying).

This approach allows processes to adapt to changes in real-time, without relying on a predetermined linear flow. Classification of changes based on signals like the paths they touch, repository location, or labels on tracking issues determines the specific process to follow. As processes are defined as data, they can be edited through their own gated process, ensuring changes to the process itself go through a rigorous review.

By treating processes as state machines and allowing them to adapt to the specific change being made, organizations can avoid the rigidity of a single linear process and create a more flexible, adaptable approach to software development.