The bottleneck moved: what actually changed when AI started writing code

TL;DR: Software teams used to be limited by how fast people could type. Then AI coding tools showed up, code started arriving faster than humans could read it, and the work itself moved. This post walks through three acts: how the old shop floor worked, the day the rhythm broke, and where the craft is heading next.

If you run or hire for a software team, you have probably felt it: tickets still move, but something about the rhythm is off. The old scoreboard (commits, story points, lines in a pull request) still lights up. It just measures the wrong fight.

Here is the simplest way I can draw the shift I keep seeing:

  Before                Now                   Ahead
  typing code   ->   reading volume   ->   writing intent
  (LOC wins)         (review breaks)        (specs + tests win)

Three acts. Let's walk them in order.

Act I - How the old shop floor worked

For most of my career, the expensive part of building software was turning a vague idea into working code. You hired people who could turn tickets into features. You measured output by what they committed. Code review was the quality gate; if it passed review, it shipped.

It worked because humans share a lot of context without saying it out loud. "I want to upload a photo" carried a whole invisible spec: JPEG or PNG, a progress bar, a retry when the network drops, a preview after upload. Nobody wrote that down. The team just knew.

Training followed the same logic. A junior joined, shadowed a senior, read the code, broke things in staging, and became productive after about six months. Slow, but predictable. That pace was the natural limit of the system: a human can only read, type, and absorb a codebase so fast.

For decades, that was the job. Code was the asset. Shared culture was the shortcut. Six months was the runway.

Act II - The day the rhythm broke

Then AI-assisted coding hit daily work, and code started arriving faster than people could read it. I have watched this play out in more than one team. Three scenes say most of what I need to say.

Scene one: the review that nobody could finish

A senior sits down to review a pull request from a junior who used an assistant. Thousands of lines. The app works. Three days later, the senior closes the tab and admits they did not read every line. They could not. There was too much of it.

That is the moment the old quality gate stops working. Review was never really about catching typos; it was the last place where a human decided whether a change fit the system. If the reviewer cannot read the change, the gate is a rubber stamp with extra steps.

Scene two: the notification system that sent 50,000 emails

A team asks an assistant to build a notification service. Simple request. It works in testing. It ships. Then in production, something triggers a loop and it sends tens of thousands of emails in a few minutes, because nobody specified a rate limit.

The rigour we used to apply during review now has to apply before a single line of code gets generated. Models do not inherit your product culture. They do what the spec says, and they fill the gaps with whatever is most likely in their training data. Leave a gap around rate limits and you get a mail bomb.

This is why structured requirements are making a quiet comeback: state machines, decision tables, PRDs with enough edge cases spelled out that a literal reader cannot "helpfully" guess wrong. Not because anyone missed writing them. Because they work.

Scene three: the 503 loop

Two in the morning. A service is returning HTTP 503. The on-call engineer pastes the error into an assistant and asks what to do. The assistant reads the vendor docs and says: restart the service. The engineer restarts. A few minutes later, it falls over again. The engineer asks again. Same answer. Restart.

By the time a senior is paged in, the server has been restarted six times. The senior reads the logs for thirty seconds and sees it: a batch job is exhausting the database connection pool. Nothing in the vendor docs told the assistant that. Nothing in the repo either. The fix lived in one person's head.

The assistant was not evil. It was under-informed. "Self-healing systems" is a fantasy until you treat institutional memory as a first-class input, sitting in the agent's context alongside the error message.

Throughput physics

None of this is a morality play about generations. It is throughput physics. Generation got faster. Review did not. The queue forms at review and architecture.

You can see it on the team chart. Seniors drown in other people's diffs and stop building. Juniors thrive because they are not fighting old muscle memory; they treat the assistant like a teammate and ship useful code in a week instead of six months. The awkward band is in the middle: mid-level engineers who were perfectly good at the old craft, and who now have to unlearn typing as the centre of gravity and retrain around intent, constraints, and verification. That takes time.

Act III - Where the work is heading

If Act II is where the pain is, Act III is the boring part that actually fixes it. The work is not disappearing; it is moving one layer up. Here is what that new shop floor looks like.

Specs and tests become the asset

The product of a team used to be its code. The honest version now is narrower: the specification and the test suite are the asset. Code can be regenerated. Behaviour has to be pinned by tests you trust.

  User story ("upload a photo")
           │
           ▼
  ┌────────────────────┐
  │  Spec + acceptance │  ◀── rigour moves HERE
  │  criteria + tests  │
  └─────────┬──────────┘
            ▼
  ┌────────────────────┐
  │  Model / agent     │  writes code faster than
  │  generates code    │  humans can hand-type
  └─────────┬──────────┘
            ▼
  ┌────────────────────┐
  │  Human supervision │  architecture fit, security,
  │  + review          │  edge cases tests missed
  └────────────────────┘

Once you believe that diagram, a lot of old arguments get cheaper. Want to move from Node.js to Rust? If your tests really do define correct behaviour, point the agent at them and ask for a rewrite that keeps them passing. You are not rewriting code; you are reprinting it from a stable source.

Institutional memory, written down

The 503 story keeps replaying until teams stop treating tribal knowledge as culture and start treating it as infrastructure. Every incident becomes a short note: what broke, how we fixed it, and what a senior would have checked first. That note goes somewhere the next on-call engineer (or their assistant) will actually find it.

Pair that with healthy scepticism about agents. They are trained to be helpful, which looks a lot like being agreeable. During an outage, agreeable is expensive. Some teams are wiring in sceptic prompts on purpose: a second voice whose only job is to poke holes in the plan before anyone acts on it. The human and the agent nodding along while the server burns is a failure mode worth designing out.

Hiring shifts

If a job description still optimises for raw coding speed, it is optimising for the old bottleneck. The questions worth asking now are different:

• Can this person write a spec another human or model cannot misread?
• Can they design tests so the suite encodes real behaviour and catches regressions?
• Can they debug systems they did not write, including generated code?
• Will they document architectural decisions so the team does not become a stranger inside its own repo?

Those are adjacent skills to the old ones, but they are not the same. Most developers do not have them yet, which is the opportunity.

The GPU precedent

If this all feels unprecedented, it is not. In the early 1990s, graphics programmers hand-plotted polygons, calculating pixel positions directly. By the mid-90s, hardware pipelines took over the repetitive part. Hand-plotting a triangle in 1995 did not make you a specialist; it made you obsolete. Those programmers did not disappear. They moved up a layer, into lighting, materials, physics, gameplay. Nobody today earns points for hand-drawing a triangle, and nobody mourns it.

Software engineering is mid-transition through the same doorway. The craft is not dying. It is moving up.

What this looks like in my week

I got to see this shift up close when I joined BKEY earlier in 2025. Shared Cursor account, colleagues who treated prompting as a real skill. At my previous job, my "AI workflow" was sometimes pasting a function from a chat model into an editor. It worked, but it was narrow.

The difference at BKEY was watching people write a plan before they asked for code, challenge the model the way a reviewer would, and only then push the work to GitHub for a human to sign off. After a few weeks it stopped feeling like a gimmick and started feeling like where the work is actually headed: less heroics about syntax, more clarity about intent, context, and the algorithm you can explain out loud.

If you cannot picture what you want clearly enough to brief another person, no tooling will stop the hallucinations. The model fills gaps. Your job is to shrink the gaps until what is left is a product decision, not a guess.

---

The bottleneck moved. If you are still measuring developers by how fast they type, you are holding a ruler in a world that just started weighing things.

---

Themes in the earlier scenes draw on public commentary from engineering leadership and industry discussions about AI-assisted development; the closing section is my own experience on the ground.