Understanding is the new bottleneck

Coding was never a bottleneck, except when it was, and when it was, it still is.

Understanding is not a new bottleneck, except when it is, and when it is, it always was.

Do other industries do this? When somebody brings a nail gun to a framing job do carpenters say: “hammering was never a bottleneck” or do they say: “measuring is the new bottleneck”? The answer is neither. And in fact my analogy is flawed, we are talking about cabinet makers who just went to IKEA bought a ready made set in flat packaging and are now proudly claiming that “assembly is the new bottleneck”.

There was no single bottleneck to programing, and there is no single bottleneck to programing. If you have to pick one, user demand is perhaps the only real bottlneck. Creating software that users saw value in using is just as hard with AI or without it (arguably harder with AI... when all you have is a hammer and all that).

TFA almost reaches this conclusion at the end when they claim (in speech pattern which is suspiciously AI-like): “The point was always to augment, not just automate.”. If we are augmenting the user experience we are doing a good job and people may actually use the software we write... if no, well it doesn’t matter how well we understand or how fast we write the code (or have AI write it for us).

On the one hand, if you really want to unlock the potential of coding agents you can get a whole lot more value from them if you don't force yourself to read every line of code they produce for you.

On the other hand, that's clearly a terrible idea! These machines make mistakes. Unreviewed code is the most obvious form of technical debt - sure, you'll get a boost in the short term but how much will you regret it later?

Something that's helped me a bit is thinking about how I've collaborated with other teams at large companies. If my team depended on some other team's product I wouldn't review every line of their code before using it - I'd start using it, then if I ran into problems I'd dig into the code to see if I could figure out the problem.

That works with human teams because humans can take accountability for their work. Agents can't.

And yet... the more time I spend with specific agents, the more I learn what kind of problems I can "trust" them with.

If I ask Codex or Claude Code to build me an API endpoint that queries a database and returns JSON, including with tests, they're going to get that right. I can glance at the shape of the tests, hit the endpoint with curl, and be confident that the job is "good enough" without me reviewing every line.

Over time, the pool of tasks like that which I'm confident they're not going to screw up has grown.

A big part of the craft of using these things is developing the instincts to know when you need to dive in to the details and when you can relax a little.

Having a lot of experience helps a ton here. I have 25+ years of experience to help me make these judgement calls. If it's security adjacent I know to review much more thoroughly. I have a good idea for the kind of mistakes that can be made. I know what shape I like my tests in, and how to both manually and get-the-agent-to-manually test things.

Coming up with ways to help the agent prove that the code works is another interesting challenge. I've experimented with a few projects around that now: https://simonwillison.net/2026/Feb/10/showboat-and-rodney/ and https://simonwillison.net/2026/Jun/30/shot-scraper-video/

I think "when should you review the code" is the most interesting question, and the answers are still very much being figured out.