The Amdahl's Law Problem in AI-Assisted Development

Written By Brian Conn

AI did not make the whole software delivery system faster.

It made one stage louder.

That is the part missing from most productivity conversations right now. A developer gets a coding assistant, the coding step accelerates, and everyone acts like the entire SDLC should accelerate by the same amount. Then review queues grow. Test failures pile up. Deployment gets riskier. Senior engineers spend more of their day reconstructing intent from code that looks plausible but does not quite match the system.

That is not a paradox. That is Amdahl's Law doing exactly what Amdahl's Law does.

Speed up one stage in a constrained system, and the bottleneck moves.

The Bottleneck Moved to Verification

In the pre-AI workflow, writing code was a meaningful constraint. Not the only constraint, but a real one. The time it took to turn intent into code naturally limited how much code arrived for review, testing, and deployment.

AI changes that balance. The generation stage gets cheaper. More code arrives sooner. The rest of the system does not automatically become cheaper with it.

The expensive work moves to verification: does this code do what we meant, does it fit the architecture, does it preserve the edge cases, does it fail safely, does it make production more or less operable?

That is the same shape I wrote about in AI-Assisted Development Changes What Matters in Framework Selection. When one part of the loop gets faster, the old bottleneck stops being the thing you should optimize. The constraint has moved.

AI-assisted development is doing that to the whole SDLC.

The Faros Data Has a Giant Asterisk

Faros' 2026 AI Engineering Report is useful because it looks beyond the individual developer feeling faster. It draws on two years of telemetry from 22,000 developers across more than 4,000 teams, comparing periods of low and high AI adoption.

The throughput numbers are real. Faros reports PR merge rate per developer up 16.2%. That is not nothing.

But the downstream numbers are the story.

In the same report, the incidents-to-PR ratio is up 242.7%. Median time to first PR review is up 156.6%. Average time spent in code review is up 199.6%. Pull requests merged without any review are up 31.3%.

That is Amdahl's Law with production consequences.

If generation gets faster and review capacity does not, the system does not magically become faster. It becomes congested. Some work waits longer. Some work bypasses the queue. Some work reaches production with less scrutiny than it should have received.

The local metric says more PRs merged.

The system metric says the verification layer is overloaded.

The Felt Speedup Can Be Wrong

The METR study is the cleanest warning against trusting vibes here.

METR ran a randomized controlled trial with 16 experienced open-source developers working on 246 real issues in repositories they already knew. Developers expected AI tools to make them 24% faster. After the tasks, they still believed AI had sped them up by 20%.

The measured result went the other direction. With AI allowed, developers took 19% longer.

The point is not that AI makes every developer slower. METR is careful about that limitation, and we should be too. The point is that perception is not measurement.

A developer can feel faster because the first draft appears quickly. That feeling can survive even when total task time goes up. The invisible part is the cleanup: rereading, correcting, re-prompting, rediscovering hidden requirements, and making code acceptable for the repository instead of acceptable for the prompt.

That is where the Intent Gap shows up in time accounting.

The code appears sooner. The verified change does not.

More Code Means More Review Surface

CodeRabbit's AI-vs-human code generation report found the same basic shape from a different angle. They analyzed 470 open-source pull requests, including 320 AI-co-authored PRs and 150 human-only PRs. AI-authored changes produced about 1.7x more issues overall: 10.83 issues per PR versus 6.45 for human-only PRs.

Again, do not overread it. The dataset is not every company, every repo, or every model. But the direction matters because it matches the operational pattern.

AI-generated code often looks fine at a glance. That is what makes it expensive. The reviewer cannot just scan for obvious syntax mistakes. They have to reconstruct the problem, compare the implementation to the intent, check the local patterns, and reason through failure paths.

That is senior-engineer work.

If you increase the amount of code entering review and also increase the amount of reasoning required per review, you have not automated engineering delivery. You have moved the load onto the people least able to absorb more random work.

That is why Risk Evaluation in the Age of AI-Aided Development matters. The question is not "did AI make coding faster?" The question is "which risk tier did this change enter, and what verification does that tier require?"

The New Leverage Is Upstream and Downstream

If generation is no longer the scarce resource, optimizing generation harder is the wrong move.

The leverage moves upstream to specification and downstream to verification.

Upstream means the work is shaped before the agent starts writing: clearer acceptance criteria, architectural constraints, examples of local patterns, explicit non-goals, and known failure modes. Not ceremony. Context.

Downstream means deterministic checks catch what reviewers should not have to catch manually: tests that encode behavior, lint rules that encode style, type checks that encode contracts, policy-as-code for security and operational defaults, and review checklists that target known AI failure modes.

That maps directly to The Three Levels of AI Product Integration. The value is not in sprinkling AI over an existing workflow and hoping the workflow scales. The value is in changing the surrounding system so AI output can be constrained, checked, and safely integrated.

Otherwise you get more output and less confidence.

What to Measure Now

Do not measure AI productivity only at the point of generation.

Measure the queue behind it.

Track PR review time, not just PR count. Track rework, not just merge rate. Track incidents per PR, not just deployments. Track how many PRs merge without review. Track how often senior engineers get pulled into cleanup after the first implementation is supposedly done.

Most importantly, separate local speed from system throughput.

A developer completing a first draft faster is useful only if the verified change reaches production with equal or lower risk. If review time doubles, incidents climb, and deployment confidence drops, the system did not get faster. It got noisier.

Open your last twenty AI-assisted pull requests. Do not ask whether they were impressive. Ask where the time went after the first draft appeared.

That is where the bottleneck is now.

Related Content

Featured
The Amdahl's Law Problem in AI-Assisted Development
The Amdahl's Law Problem in AI-Assisted Development

AI did not make the whole software delivery system faster.

It made one stage louder.

That is the part missing from most productivity conversations right now. A developer gets a coding assistant, the coding step accelerates, and everyone acts like the entire SDLC should accelerate by the same amount. Then review queues grow. Test failures pile up. Deployment gets riskier. Senior engineers spend more of their day reconstructing intent from code that looks plausible but does not quite match the system.

That is not a paradox. That is Amdahl's Law doing exactly what Amdahl's Law does.

Speed up one stage in a constrained system, and the bottleneck moves.

Concentric Feedback Loops: How AI Agent Teams Actually Ship Code
Concentric Feedback Loops: How AI Agent Teams Actually Ship Code

I've been rebuilding one of my Claude Code workflows because the old version was too linear.

That sounds like a small implementation detail. It isn't. It points at the part of AI-assisted development that most teams are about to run into: once agents can do real work for hours, strict phase gates start getting in the way of the feedback loops that make the work safe.

The normal development cycle is familiar: requirements, plan, plan review, implementation, tests, peer review, more implementation, more tests, security review, architecture review, integration testing, end-to-end testing. We pretend this is a clean sequence because it is easier to write down that way.

It has never been that clean.

The work has always been loops. AI agent teams just make the loops visible.

Your Team's AI Metrics Are Lying to You
Your Team's AI Metrics Are Lying to You

Your engineering team adopted AI coding tools six months ago. Deployment frequency is up. Lead time is down. PRs are flying through the pipeline. Everyone feels faster.

But are they?

I've been digging into the data across multiple client engagements, and there's a growing gap between what AI-assisted engineering teams perceive and what the numbers actually show. The metrics most teams celebrate are painting an incomplete picture, and the metrics that would tell the real story are the ones nobody's watching.

Start Fresh - Why Fixing AI Agents Mid-Chat Never Works
Start Fresh - Why Fixing AI Agents Mid-Chat Never Works

You're four steps into an AI agent workflow. Steps one through three went perfectly. Step four goes sideways. So you start correcting. "No, do it this way." "Try again." "No, like this." Five corrections later, the output is worse than when the problem first appeared.

The instinct to fix things in place is deeply human. It's also exactly wrong when working with AI agents.

Why Every AI Workflow Converges on the Same Architecture
Why Every AI Workflow Converges on the Same Architecture

Three AI agents. Three different problem contexts. Each time, the solution emerged with the same architecture.

The first was my own operational agent. A personal partner for research, drafting, and scheduling. The second was a marketing content bot I helped a client team build. The third was an analytics workflow for another team. Different domains, different users, different stakeholders. But when I stepped back and compared the three designs, the structural similarity was impossible to ignore.

I didn't plan it. I wasn't working from a blueprint. I was solving three different problems and each time, I ended up reaching for the same three layers: an immutable identity, compiled learnings, and a human approval gate.

One builder reaching for the same shape across three contexts isn't proof of a universal law. But the fact that I keep reaching for it without trying to is worth sitting with. Every production AI workflow I've built that survives contact with reality seems to pull in this direction. Not because anyone prescribed it. Because the problems keep forcing it.

The SDLC is Rediscovering Itself
The SDLC is Rediscovering Itself

AI is forcing software development back to first principles. The practices most teams abandoned as overhead, specs, formal verification, architectural review gates, are becoming essential again the moment humans stop reading every line of code.

I've watched this play out across my own work this year. The discipline I used to skip because it slowed me down is suddenly the only thing standing between a working system and a pile of plausible-looking garbage. The SDLC didn't die. It got hollowed out, and now it's being rebuilt in place, one abandoned practice at a time.

The Intent Gap
The Intent Gap

Your AI-generated code is degrading, and the degradation isn't a tooling problem. It's a translation problem, and every step of the chain is lossy.

I've fought against this degradation. I swap models. I rerun implementation prompts. The damage happens before the first line of code gets generated, in a chain of translations that no refactoring pass can reverse. This is a different problem than the one I wrote about in Risk Evaluation in the Age of AI-Aided Development, which is about deciding when AI acceleration is worth the technical debt. The Intent Gap is upstream of that decision.

I call the thing at the center of this the Intent Gap: the distance between what you meant and what the AI produced. The Gap is where everything fails. And once you see it, you can't unsee it.

Tests as Ceremony: When AI Breaks the Safety Net
Tests as Ceremony: When AI Breaks the Safety Net

AI-generated tests pass. That's the problem.

Passing is not a useful correctness criterion. Mark Seemann makes this argument sharply: AI-generated tests have "little epistemological content." They skip the critical step of seeing a test fail before writing code. The test exists, the coverage number goes up, and everyone moves on. But the test never proved anything. It never caught a bug, because it was never designed to catch one.

SDLC is Dead, Long Live the SDLC
SDLC is Dead, Long Live the SDLC

The software development lifecycle isn't dead. It just lost its center of gravity.

For decades, the bottleneck in software development was writing code. Requirements flowed downhill through design, architecture, and planning, all funneling toward the expensive part: turning ideas into working software. The entire SDLC was organized around this constraint. We optimized hiring, tooling, and process around the assumption that code production was the hard part.

AI changed that equation. Code writing is now commoditized. AI can produce syntactically correct, functionally reasonable code at a pace no human team can match. The bottleneck didn't disappear. It moved.

The Three Questions That Tell You What to Automate
The Three Questions That Tell You What to Automate

Not every repetitive task is worth automating. Some tasks feel tedious but resist automation because they require subtle judgment at every step. Others feel complex but are actually just long sequences of mechanical steps. Knowing the difference saves you from building automation that never delivers, or manually grinding through work a script could handle. I've found that three questions reliably separate the automatable from the not-yet-automatable. They work whether you're evaluating a candidate for AI assistance, a custom script, or a full workflow tool. This framework also applies to choosing what to build versus what to shed, as I explored in Tactical Work Shedding.

Brian Conn https://connsulting.io
Next

Concentric Feedback Loops: How AI Agent Teams Actually Ship Code