AI Didn't Make You 5x Faster. It Moved the Bottleneck.

There are two kinds of engineers right now: the ones who have already vibe-coded something, and the ones who are about to. The first time it happens, it feels like a magic trick. You type a prompt, wait a minute, and there's a working application with a UI that looks surprisingly decent.

That's the part every conference demo shows, and it's why product managers, CEOs, and investors all end up asking the same question: if AI can build software this fast, why isn't the team shipping five times faster? Engineers ask a harder version of it. A year ago, "how does the generated code actually look" had an easy answer - don't look. Today, with the current models, it's often genuinely good. Which raises the real question: if the code is fine, why does the team still feel only marginally faster?

The script that became a service

Picture the automation everyone's shipped at some point. A couple hundred lines of bash or Python, focused on exactly one problem, maybe with a README explaining how to configure it. Nobody opens a ticket for it, because it isn't a project - it's just a tool that made one person's week easier.

You mention it at standup and everyone loves it. Then someone asks the dangerous question: could this be an actual service? From that point, everything changes. It needs a repository, a CI pipeline, deployment, authentication, monitoring, logging, a real UI, an internal domain, firewall rules, a security review, documentation, and an owner. The script itself didn't get harder. Everything around it did. A hundred-line tool turned into software, and software is expensive - not because writing it is hard, but because everything surrounding it is.

Agents don't remove that - they inherit it

The obvious counter is that agents solve this too: spin up the repo, move the script, wire the build, open the first pull request. Fine, assume they do. Now put five backlog items in front of five agents working at once. Do those features depend on each other? Almost certainly. Will two of them touch the same file? Probably. What happens when one agent finishes in minutes but has to wait because another PR is still sitting in review, or because someone changed the API yesterday and half the generated code now targets a version that no longer exists?

None of that is a model-quality problem. It's the same coordination problem teams have always had, just arriving faster and in greater volume.

The bottleneck was a CI runner

This isn't hypothetical - it happened on a project I worked on. An agent generated a feature in a couple of minutes and then sat idle, not waiting on a reviewer, but on GitLab CI runners to become available. The AI produced working code faster than the pipeline could even start validating it.

That's the part no demo shows. Someone still has to review the change because policy says so. The linter fails, or the build fails, or an integration test catches something, or a reviewer notices the generated code ignores an architectural boundary that was never written down anywhere the model could read it. So it regenerates, and the cycle - review, merge conflict, CI run, approval - starts again. The code arrives in seconds. Everything around the code still takes hours, sometimes days.

Every real breakthrough has done this

Compilers didn't eliminate the need for software engineers. Neither did high-level frameworks, and neither did the move to the cloud. Each one removed a cost that used to be the visible constraint, and each time, a different constraint was already waiting underneath: architecture, review capacity, deployment process, organizational approval chains. AI is doing exactly the same thing to code generation. It didn't make software cheap. It made writing code cheap, which was never the same claim, and the gap between those two is exactly where the extra 4x is supposed to come from and doesn't.

Where the 5x actually is

Teams that end up meaningfully faster are the ones that go looking for where their new constraint actually sits instead of assuming it's still generation speed. Sometimes it's genuinely infrastructure - a CI system sized for a world where PRs arrived one at a time. Sometimes it's review: a reviewer's forty-five seconds per file doesn't stretch to cover code from an author who has no personal style to recognize, so review time goes up exactly when everyone expected it to go down. Sometimes it's ownership - nobody wrote down the architectural boundaries an agent needs to respect, so every generation round rediscovers the same violation.

None of those get fixed by a faster model. They get fixed by treating code review as an architectural check rather than a formality, by sizing pipelines for the volume AI actually produces, and by writing down the boundaries a team wants respected instead of expecting a reviewer to catch them from memory every time. The teams that do that will notice their real bottleneck moved and go fix it there. Everyone else will keep generating code five times faster while waiting in exactly the same pull request queue.