The Bottleneck Was Never the Code

Over the past two years, nearly every engineering organization has put AI to work writing its software — first as coding assistants, and now as autonomous agents that open pull requests on their own. By the measures that are easiest to collect, the results look spectacular: more code, more commits, more pull requests. Ask the harder question — are we delivering value to customers faster, and more safely? — and the answer is far less comfortable.

The research tells a consistent story. Google’s DORA program first linked AI adoption to lower delivery throughput and stability in 2024.¹ By 2025, throughput had recovered but instability had not, and DORA concluded that AI is an amplifier: it magnifies the strengths of well-run delivery organizations and the dysfunctions of struggling ones.² Its 2026 analysis is blunter still: higher AI adoption now brings more throughput and more instability.³ Two years of Faros AI telemetry across 22,000 developers show where the strain lands. On high-adoption teams, task throughput rose by a third — but median review time grew fivefold, bugs per developer rose 54 percent, and incidents per pull request roughly tripled.⁴

None of this would surprise Eliyahu Goldratt. His Theory of Constraints holds that a system’s output is set by its tightest constraint, and that “an hour saved at a non-bottleneck is a mirage.” Accelerating code generation does not, by itself, accelerate delivery. It moves work faster into the queue in front of the slowest step — and in almost every organization, that step is a person.

Having been accountable both for shipping software and for securing what ships, I see this as the defining delivery challenge of the AI era. It is also an opportunity. Applied deliberately, AI can relieve the human bottlenecks in the value stream in a way that leaves the organization more secure, not less. Applied carelessly, it scales your attack surface faster than it scales your business.

Where delivery actually waits

Map the value stream for a typical product change — from idea through refinement, build, review, verification and release to production — and a familiar pattern emerges. Work spends far more time waiting than being worked on, and the waits cluster in front of people.

• Intent. Ambiguous tickets bounce between engineering and product while the person who can resolve them sits in back-to-back meetings. AI makes this worse before it makes it better: an agent will build the wrong thing quickly, and with total confidence.
• Code review. Senior engineers are a fixed-capacity resource. As AI multiplies the number and size of changes — Faros measured average pull request size up 51 percent⁴ — queues lengthen, and reviewers respond the only way they can: by looking less closely.
• Security review. Application security teams are outnumbered by developers by one or two orders of magnitude, yet threat models, scanner triage and exception approvals all route through them.
• Testing. Coverage lags feature work, flaky suites erode trust, and manual regression passes stretch release cycles.
• Release approval. Change advisory boards persist long after the evidence turned against them. The research behind Accelerate found that external change approval was associated with slower delivery and no reduction in change failure rate.⁵
• Compliance and operations. Audit evidence still runs on screenshots and spreadsheets, on-call engineers drown in alerts, and critical systems are understood by one or two people whose calendars quietly gate every change.

Here is the point the CTO in me is tempted to skip and the CISO in me never will: most of these queues exist for a reason. A code review, a security sign-off, a change approval — each was put there because someone needed assurance that a change was correct, safe or compliant. The queue is the visible cost of that assurance. Remove the queue without replacing the assurance and you haven’t removed a bottleneck. You’ve traded a delay for an incident.

Why “just add AI” makes the bottleneck worse

The asymmetry at the heart of the problem is simple: generation scales elastically; verification does not.

Code is now cheap. Confidence is not.

Three forces compound the asymmetry.

Review is quietly hollowing out. In a 2026 Carnegie Mellon and Stanford study of nearly 200,000 pull requests, PR volume grew 3.1 times while the pool of reviewers grew only 1.5 times. The share of pull requests receiving any written human feedback fell from about 39 percent to 21 percent, and each reviewer’s silent approvals roughly doubled.⁶ Faced with diffs that, in a meaningful sense, nobody on the team wrote, reviewers slide into automation bias and a reflexive “looks good to me.” That is not a productivity problem. It is a control failure.

AI still introduces new classes of risk. Today’s models write syntactically correct code almost every time, yet Veracode’s 2026 testing found their security pass rate stalled at about 56 percent, with bigger and newer models doing little to close the gap.⁷ Models hallucinate package names that attackers then register — an attack known as “slopsquatting.” Source code and secrets leak into unsanctioned tools. And agents with access to repositories, pipelines and cloud credentials are exposed to prompt injection, still ranked first in the 2026 OWASP Top 10 for LLM Applications, which also moved “excessive agency” up to third.⁸

Perception diverges from reality. METR’s 2025 randomized trial found experienced open-source developers were 19 percent slower with AI tools, even as they believed they were faster.⁹ Its 2026 follow-up suggests newer tools likely do speed developers up — but METR cautions that its own new data is weak evidence and that self-reported gains remain unreliable.¹⁰ Leaders who judge AI adoption by sentiment or activity will misjudge both their returns and their risk.

None of this means AI fails to deliver value. It means its value is realized at the system level or not at all — which is where it must be designed in.

Five principles for relieving the bottleneck safely

Before applying AI to any queue, the CTO and CISO should agree on shared design principles. Here are the five I hold teams to.

1. Optimize the system, not the step. Measure end-to-end flow before and after every change. If you can’t show where work waits today, you can’t know whether AI is helping.
2. Move human judgment up the stack. People should spend less time inspecting every artifact and more time defining intent, setting policy and adjudicating the exceptions that genuinely need a human. Keep humans in the loop for high-risk decisions and on the loop — monitoring and sampling — for routine ones.
3. Make policy machine-readable. You can’t automate a control you can’t express. Coding standards, security requirements, approval rules and data-handling constraints belong in code and configuration, not in a wiki.
4. Verify; never trust. AI output passes through the same deterministic gates as human work — tests, static and dependency analysis, secrets scanning, policy checks — or stronger ones. AI review augments those gates. It never replaces them.
5. Treat every agent as an identity. An agent that can open pull requests, run pipelines or query production is a privileged non-human identity, and must be governed like one.

Applying AI across the value stream

With those principles in place, apply AI to each bottleneck in turn. The pattern is always the same: AI absorbs the volume, deterministic controls provide the assurance, and people keep the decisions that require judgment.

Intent: start with a better specification

Use AI to turn rough requests into structured specifications — clarifying questions, acceptance criteria, edge cases and test scenarios — before any code is written. Now that agents implement directly from tickets, the specification has become the most important prompt in the pipeline. It is also the cheapest moment to bring security in. AI can draft a lightweight threat model and security requirements for each feature, so the security conversation happens at design time instead of at the release gate.

Review: route by risk, not by habit

AI first-pass review has quickly become standard practice; Faros finds a quarter of pull requests are now reviewed by an AI agent.⁴ Run it on every change: summarizing intent, checking the diff against the specification, and flagging defects, missing tests and insecure patterns. Then route the change by what it touches. A copy fix and a change to the authorization layer should not travel the same path. Keeping changes small, a practice DORA identifies as amplifying AI’s benefits,² makes both machine and human review more effective.

Security: from gatekeeper to paved road

AI is well suited to the work that buries security teams: triaging scanner output, removing duplicates and false positives, assessing whether a vulnerable code path is actually reachable, and proposing fixes as ready-to-merge pull requests. Pair it with supply-chain hygiene — dependency allowlists, private registry mirrors, version pinning and a check that every suggested package actually exists.

Testing: generate from intent, not implementation

AI can close coverage gaps, generate integration and property-based tests, and diagnose flaky suites. The trap is tautology: tests written by the same model, from the same code, tend to share that code’s blind spots. Derive tests from the specification instead, and use mutation testing to confirm they fail when the code is wrong.

Release: replace the approval board with evidence

Replace the change advisory board with automated, evidence-based change approval. Score each change on blast radius, sensitivity, test and scan results, and the recent history of the affected services. Low-risk changes ship through progressive delivery — feature flags and canary releases — with automatic rollback when service-level objectives are breached. For the high-risk minority, AI assembles a concise risk brief so the approver can decide in minutes, not at next week’s meeting.

Compliance: continuous evidence, human attestation

Most compliance work is evidence collection, and most of that evidence already lives in your pipelines, cloud accounts and ticketing systems. Use automation and AI to collect it continuously, map it to frameworks such as SOC 2, ISO 27001 and ISO/IEC 42001, and draft responses to customer security questionnaires from an approved knowledge base.

Operations: make expertise searchable

AI-assisted triage can correlate alerts, summarize incidents in progress and draft post-incident reviews. Retrieval over code, architecture decisions and runbooks reduces dependence on the few people who carry critical systems in their heads.

Autonomy is earned, tier by tier

Risk tiers tie these patterns together: a small number of tiers, each with explicit roles for AI and for people.

Start conservatively. Promote a category of change to a more autonomous tier only when the data — change failure rate, rework, escaped defects — shows it is safe, and demote it just as quickly when it is not. Autonomy becomes something a team earns with evidence, not something it is granted on enthusiasm.

Securing the AI-enabled pipeline

The CISO’s job is to make sure the AI itself doesn’t become the weakest link. That comes down to six controls.

• Identity and least privilege. Every agent gets its own identity, the narrowest permissions its task requires, and short-lived credentials issued through workload identity federation — never a long-lived token borrowed from an engineer. Every action is attributable to both the agent and the human who sponsored it. NIST’s National Cybersecurity Center of Excellence has now taken up agent identity directly.¹¹
• Containment over detection. Prompt injection is not a solved problem. The UK’s National Cyber Security Centre warns it may never be fully mitigated the way SQL injection was, and researchers have shown adaptive attacks bypassing every published defense they tested.^12,13 Design for containment. Meta’s “Agents Rule of Two,” which builds on Simon Willison’s “lethal trifecta,” offers a practical test: within a single session, an agent should combine no more than two of untrusted input, access to sensitive systems or data, and the ability to change state or communicate externally.^14,15 An agent that reads public issue comments, holds deployment credentials and can push to production fails that test.
• Sandboxed execution. Agents that run code do so in ephemeral, isolated environments with restricted network egress and no ambient access to production secrets.
• Data governance. Use enterprise agreements with no-training and limited-retention terms, classify which code and data may reach which models, and apply data-loss prevention to prompts. Shadow AI is best defeated with a paved road: sanctioned tools that are easier to use than unsanctioned ones.
• Supply chain. Treat models, plugins, agent skills and Model Context Protocol servers like any other dependency: vet them, pin versions and maintain an allowlist. Agent marketplaces are already a target: in early 2026, researchers found 341 malicious skills in the public registry for the open-source OpenClaw agent, most installing an infostealer.¹⁶ Generate SBOMs and SLSA-aligned build provenance so you can show what produced every artifact.¹⁷
• Observability and audit. Log prompts, tool calls and actions in a tamper-evident store your security team can query. If you can’t reconstruct what an agent did and why, you can’t investigate it — or defend it to a regulator.

None of this requires a new bureaucracy. The NIST AI Risk Management Framework and its Generative AI Profile, NIST’s Secure Software Development Framework and its generative AI supplement (SP 800-218A), the OWASP Top 10 lists for LLM and agentic applications, and ISO/IEC 42001 together form a mature, well-mapped foundation.^18–22 Fold them into the SDLC and security management system you already run, not a parallel AI governance process teams will route around.

Measure the system, not the activity

Lines of code and suggestion-acceptance rates are vanity metrics. To know whether AI is relieving your bottleneck — and not merely relocating it — measure the system:

• Delivery: DORA’s measures of lead time, deployment frequency, change failure rate, recovery time and rework rate.
• Flow: lead time split into active and waiting time, review queue depth, and the share of sensitive changes that receive substantive human review.
• Security: vulnerabilities escaped to production, time to remediate, and the volume and age of open risk exceptions.
• Autonomy: the share of changes in each tier, and each tier’s failure rate.
• People: developer experience and reviewer load. The human bottleneck is also a burnout risk.

Beware activity targets. In the Carnegie Mellon and Stanford study, a mandate to double merged pull requests per engineer hit its goal while substantive human review nearly halved.⁶ If throughput climbs while change failure rate, rework or remediation time climb with it, the bottleneck hasn’t been relieved. It has been converted into risk.

A pragmatic path forward

1. Map and baseline. Trace a handful of recent changes through the value stream, measure where they waited and why, and identify the true constraint.
2. Build the paved road. Approve tools, define data-handling rules and an acceptable-use policy, and establish the identity model for agents before usage scales.
3. Pilot at the constraint. Pick one team and one bottleneck — usually review or security triage — and introduce AI with risk tiers and deterministic gates from day one.
4. Automate the evidence. Replace manual approvals and compliance screenshots with policy as code and continuous control monitoring.
5. Expand autonomy deliberately. Promote change categories between tiers only as your metrics justify it, and make those decisions jointly across engineering and security.

Speed and security, designed as one system

The organizations that win the next few years won’t be the ones that generate the most code. Code is becoming a commodity. They will be the ones that turn ideas into trusted, running software fastest — and can prove it was done safely.

That is a system-design problem, not a tooling decision, and it belongs to the CTO and the CISO together. Design speed and security as one system and they stop being a trade-off. AI will not remove people from product delivery, nor should it. Used well, it makes sure every hour of human judgment is spent where it matters most.