The new bottleneck (it isn't typing speed)
1. The old bottlenecks are gone
For decades, the speed of building software was bounded by how fast a human could type, how fast they could remember syntax, how fast they could look up the right function name. A faster typist could ship more. Someone who'd memorized more standard library could ship more. A 10x engineer was someone whose hands had less friction between intent and screen.
Those bottlenecks are gone. The model types at the speed of a thousand humans. It remembers every library. It doesn't get tired. None of that is what slows you down anymore.
2. What slows you down now
The new bottlenecks are upstream and downstream of the typing.
Unclear specs. You can't write a spec because you don't know exactly what you want. So you write something vague, the model produces something vague-shaped, you don't like it, and you go around again. The whole loop runs three times because the first spec wasn't sharp.
Slow verification. The model produced code in two seconds. It'll take you twenty minutes to read it carefully, run it, check the edges, and decide if you trust it. Verification is now the long step.
Missing taste. You can't tell if what came out is good. So you ship something mediocre, or you spend an hour fiddling with it without knowing what "better" looks like. Taste is what tells you when to stop.
Fear of shipping AI-generated code. This one is psychological. You didn't write it. You don't fully understand every line. So you stall — adding more tests, reading it one more time, asking the model to "make it more robust." The code is fine. You just don't trust yourself to know it's fine.
Distrust loops. Variant of the fear. The model writes it. You don't trust it. You ask the model to refactor. The model refactors. You still don't trust it. You ask it to refactor again. After three rounds you have worse code than you started with and you've burned an afternoon.
3. Old bottlenecks vs new bottlenecks
| Old bottleneck | New bottleneck |
|---|---|
| Typing speed | Spec clarity |
| Syntax recall | Reading speed |
| Boilerplate volume | Verification thoroughness |
| Looking up APIs | Knowing when output is wrong |
| Switching languages | Steering the model mid-generation |
| RSI and fatigue | Distrust loops and second-guessing |
The pattern: each old bottleneck was a physical constraint on the human. Each new bottleneck is a judgment constraint. The job moved from your hands to your head.
4. The bottleneck that surprises people
Out of the five above, the one that catches engineers off guard is verification.
People assume that if the model writes code in two seconds, they can ship in two seconds plus a quick glance. They cannot. A quick glance misses the off-by-one, the hallucinated import, the SQL injection. A quick glance also doesn't build trust — which means the next time, they'll either skip the glance (and ship a bug) or spend an hour over-verifying (and lose the speed gain).
The honest measure of your throughput with AI is: spec time, plus generation time, plus verification time. For non-trivial code, verification is the longest of the three. If you're not budgeting for it, you're either lying to yourself about quality or you're moving slower than you think.
5. Where to invest your hours
If typing isn't the constraint, training your typing is wasted hours. What's worth training instead:
- Writing specs. Practice describing what you want in fewer words, more precisely. Notice when your spec was ambiguous after the fact and fix it next time.
- Reading code fast. Read more code than you write. Open-source projects, your coworkers' PRs, the standard library of your language.
- Building taste. Look at code you admire. Notice what makes it good. Notice what makes other code worse. Name the differences.
- Catching errors. Every time the model produces something wrong, name the category (from the previous unit). After a hundred catches, you'll recognize the shapes instantly.
- Trusting yourself. When the code is fine, ship it. The model didn't write a bug just because it could.
The next unit is what this looks like when somebody's actually good at it.