The SDLC was built for human throughput

Software delivery has always assumed that change is scarce.

A person writes the code. Another person reviews it. A pipeline runs a fixed set of checks. The team schedules the release, watches production, and learns what it missed. Every step was designed around the speed and attention of people.

Agentic coding breaks that assumption. A small team can now produce a torrent of changes. The bottleneck moves away from typing code and into understanding what changed, what it can affect, whether the evidence is good enough, and who should accept the risk.

A torrent of changes thrown against a system built for human throughput will crack it.

Adding another AI reviewer to the same pull request flow will not fix the underlying design. We have to rethink what a pull request is, what code review is for, where human judgment belongs, and how quickly different kinds of change should move.

Code review becomes verification

Traditional review mixes several jobs together: understanding intent, checking the implementation, spotting bugs, enforcing conventions, sharing context, and approving risk. That made sense when a human author produced a small number of changes.

At agent speed, that bundle does not hold. Reviewers cannot read every generated line with equal care. More importantly, they should not. A change to a low-risk internal page and a change to authentication should not pass through the same process at the same speed.

The delivery system has to assemble evidence around the change:

• What intent and acceptance criteria led to this code?
• Which systems, data, and customer surfaces can it reach?
• How much of the affected area is understood by tests and runtime evidence?
• Does the change touch a complexity hotspot or a defect-prone file?
• Which security, privacy, and policy controls apply?
• Who owns the affected domain and who can accept the remaining risk?

The reviewer’s job becomes judging the evidence, challenging weak assumptions, and resolving ambiguity. That is a better use of human attention than reading generated boilerplate line by line.

Move the human earlier

Many teams put the human at the end. An agent gets a ticket, writes code, opens a pull request, and asks for approval. By then, the agent may have made dozens of decisions about scope, architecture, data, and tradeoffs.

Human judgment is more useful before those decisions harden into code. The person should shape the problem, define the boundaries, identify the dangerous assumptions, and decide what evidence will count before the agent starts.

This changes the work from reviewing an answer to designing the conditions under which an answer can be trusted. The agent can then work quickly inside clear constraints, ask for help when it crosses them, and return evidence tied to the original intent.

Let changes move at different speeds

A single approval path treats every change as equally risky. Teams compensate with broad rules, mandatory reviewers, and long checklists. Safe changes wait too long. Dangerous changes can still slip through because the process measures completion instead of risk.

I have been working toward a policy-based delivery model where release speed depends on the change itself. The policy can consider:

• Customer and operational surface area
• Blast radius and dependency reach
• Security and data sensitivity
• Code complexity and historical defects
• Test quality and runtime observability
• Domain ownership and reviewer expertise
• Reversibility and rollback time
• Severity if the system is wrong

A low-risk, reversible change with strong evidence can move quickly. A change to identity, payments, or a poorly understood dependency should collect more evidence and bring in the right person. The policy explains why.

The tools have to understand more than syntax

Linters, tests, and SAST tools still matter, but agentic delivery needs deeper context. A changed function may be syntactically fine and fully tested while sitting in the center of a high-churn dependency cluster. The risk is in its position, history, and reach.

That is why I built Omen around code intelligence for agents. It gives an agent and the delivery system access to complexity, hotspots, coupling, blast radius, and technical debt. The goal is not another score on a dashboard. The goal is to change agent behavior before code is written and to help the verification system decide what evidence a change requires.

The same idea applies to infrastructure. A routine, reversible change should not wait behind a blanket approval rule. A change that can expose data or reshape production networking should have a very different path.

Test the system with agents that disagree

Most automated testing assumes one expected behavior. Agentic systems add goals, interpretation, tool use, memory, and different ways to fail. A friendly test persona will miss problems that a skeptical security reviewer, a hurried operator, or a privacy-conscious customer will find.

A stronger approach tests the system through agents with different concerns. Each persona approaches the system from a different position, asks different questions, and pushes on different boundaries. The disagreement is useful because it exposes assumptions hidden by the happy path.

This is especially important for AI governance. A model gateway can inspect prompts and responses, but governance also has to cover identity, delegated authority, data access, tool use, approvals, and the record of what an agent did on someone’s behalf.

Throughput without losing the record

The point is not to remove people from delivery. It is to stop spending their attention on work a machine can verify and reserve it for judgment, ownership, and consequences.

A delivery system built for agents should be able to answer a few plain questions:

• Why did this change exist?
• Who or what made each decision?
• Which evidence supported the release?
• Which policy allowed it to move at this speed?
• Who accepted the remaining risk?
• What happened after it reached production?

Massive throughput is useful only if the organization can still explain, secure, and operate what it ships. That requires a different SDLC, designed around the volume agents produce and the judgment people still own.