AI-Driven Development Needs Flexible Processes, Not One-Size-Fits-All Workflows

Anthropic's recent AI-Native SDLC Playbook makes a compelling observation: code is no longer the bottleneck. When AI agents can generate implementations in minutes, the real constraints shift upstream and downstream—to planning, review, verification, deployment, and governance. Yet this creates a new problem: the traditional approach of having humans manually review each change breaks down when the volume of changes multiplies tenfold.

The risk… is producing ten times the changes at the same quality per change or worse, with no way to identify which changes are the bad ones.

The playbook's foundations are sound, but it overlooks a critical reality: organizations do not operate under a single process. Instead, they run a collection of processes, each calibrated to the specific risks and accountability demands of different types of changes. A documentation update, a library version bump, and a database schema change in a payments system should not follow identical approval paths.

The Spec-Driven Tooling Landscape

Anthropic's playbook sits within a broader movement toward spec-driven development tools, alongside offerings like Amazon's Kiro and GitHub's Spec Kit. These platforms share a common architecture: written specifications drive the workflow, producing plans, diffs, and review findings that flow through version control. Policy enforcement relies on deterministic mechanisms—hooks and similar controls—rather than model instructions. Agents validate their own output before humans see it, and humans retain final approval authority.

The drawback is that each tool enforces a particular process: a fixed sequence of stages that every change must traverse. Adopting the tool means accepting its prescribed workflow.

Organizations Need Multiple Processes

In practice, no organization operates with a single process. The appropriate path for a change depends on its risk profile and the accountability it demands. Documentation corrections, dependency updates, and payments schema migrations require different verification rigor, different approvers, and different audit records. In regulated industries, the process itself becomes part of the compliance record—auditors require evidence of who approved each change and the basis for that approval. The specifics of what must be documented vary by change type.

When a tool prescribes one process, teams route around it for changes that don't fit, which is the worst outcome because the real process becomes invisible.

When a single process is mandated, teams circumvent it for changes that do not fit the mold—the worst possible outcome, since the actual process disappears from view. Alternatively, vendors add configuration options until the tool evolves into a workflow engine that no one fully comprehends. The solution is for tools to enable organizations to define their own processes rather than imposing one.

State Machines as a Process Model

A superior approach treats each process as a state machine. States represent facts about a change: it has been reviewed, validated against dependencies, approved for production. These facts reside in systems outside any single tool's control—repositories, CI systems, clusters, issue trackers. A process therefore cannot be a sequential program. Instead, it is a collection of rules that respond to observations across these systems. Each rule specifies:

1. The conditions that must exist before the rule can activate.
2. Its gate: whether it fires automatically or requires human approval.
3. The permission it grants when activated, such as merge or deploy rights.

This rule set, stored as data and reviewed like code, defines the process. An organization maintains many small machines, each corresponding to a risk category.

At runtime, this model operates nothing like a traditional workflow engine. No component tracks progress through numbered steps. Instead, the process advances when a fact appears in the system that owns it, and rules respond accordingly. Events that arrive late, arrive multiple times, or arrive after a system restart are handled uniformly, because rules only look at current state. A gate is simply one of a rule's conditions, so you can pause execution during an incident or release freeze without modifying any definition.

Enforcing gates requires determinism. A gate implemented as a prompt instruction depends on the model's compliance. The agent harness can provide the determinism needed to execute the state machine and enforce its gates, halting the agent between actions until a gate is resolved, while infrastructure handles the rest.

Routing Changes Based on Classification

A single process definition per repository remains insufficient—all changes would still follow the same path regardless of risk. The route a change takes should reflect what the change actually is, determined through classification rather than author selection. Organizations classify changes using signals already available: which file paths are affected, which repository contains the change, labels on tracking issues, and similar metadata.

Process definitions themselves must evolve safely over time. Since a process definition is data, modifying it constitutes a change that goes through its own gated approval process. Relaxing an approval requirement on the release process receives the same scrutiny as a schema migration, not the casual treatment of a configuration file edit.

Consider three changes to the same service:

• A documentation fix is classified by the file paths it modifies. Its process contains two states: the build succeeds, and it merges. No human involvement is required.
• A dependency upgrade bypasses design review but requires compatibility evidence: the upgraded service must pass integration tests against actual dependencies. A major version change demands approval that a patch version does not.
• A schema migration in the payments service is classified by the component it touches, regardless of how the change is labeled. Its process includes states others never reach: review by a payments domain owner, validation against production-like data, and release approval from someone accountable for that domain.

Every transition, across every path, is recorded with the approver's identity and the evidence supporting the decision.

Core Principles

Processes designed this way should adhere to these principles:

• Autonomy expands incrementally per action. Each transition can be set to fire automatically, require approval, or hold. As agents demonstrate reliability on a category of change, that setting loosens, allowing the process to benefit from agent improvements without redesign.
• Human effort concentrates where judgment matters. Agent costs continue falling; human supervision hours do not. People enter the loop only when a decision requires human judgment, equipped with the context needed for rapid decisions.
• Evidence originates outside the agent. An agent's self-report never advances a change. Transitions fire based on facts from systems the agent cannot modify—test results, validation in realistic environments, and similar external signals.
• The process log serves as the audit trail. The definition captures written policy, and the transition log documents who approved each step, what evidence they reviewed, and which policy version was in effect.

Scaling Quality with Flexible Processes

The playbook and similar tools establish the right foundations. What remains absent is the capability for organizations to define their own processes, differentiate them by change risk, and update them safely. The objective is not to remove humans from decisions. Rather, it is to deploy human judgment precisely where it adds value, supported by evidence agents cannot generate about themselves, so quality persists even as throughput scales.

Source: The New Stack