The half of software that didn't get cheaper

Something flipped this year, and most of the conversation is still pointed at the wrong half of it.

The cost of producing code collapsed. A feature that used to eat a day now takes an hour. We all feel it. What almost nobody is pricing in is that the cost of the other half — understanding what the code does and being sure it's right — didn't move at all. If anything, it went up.

That's the whole thesis: writing got cheap, reading and trusting did not. And that gap, not the speed of generation, is the thing that now decides whether you can actually ship.

Why reading got harder, not easier

When a teammate opens a pull request, every line carries intent. You can ask "why did you do this?" and get a real answer, because a person made a decision there. You review against that intent.

Generated code has no intent behind any single line. It's locally plausible everywhere — each line looks like something a competent developer might write — but there's no reasoning underneath to lean on. So you can't review it the way you review a human diff. You can't ask the author why, because there was no author and no why. You're left checking behavior directly, which is slower and far less forgiving.

This is also why the line-by-line diff, the unit we've reviewed software in for twenty years, quietly stopped working. The diff assumes each changed line was a human choice worth scrutinizing. When the lines are generated, the diff tells you what changed but nothing about where the risk is. The dangerous failures aren't in the lines that changed — they're in how those changes interact with everything that didn't.

The bottleneck moved from typing to judging

For most of the history of this craft, the scarce skill was production: can you build the thing. That's no longer scarce. The

scarce skill is now judgment: can you look at a working-looking pile of code and tell whether it's actually correct.

And the surveys keep drawing the same shape. Reviewers rate AI-assisted code highly at review time — clean, readable, idiomatic. Then it ships, and incident counts go up, senior engineers spend more time firefighting, and a meaningful chunk of that code needs significant rework. "Looks reviewed" and "is correct" came apart. Readability — the thing the code optimizes for — is exactly what lowers a reviewer's guard. Rough code makes you slow down; beautiful code makes you sign off on behavior you never checked.

The imbalance nobody's fixing

Here's what bothers me most. We spent a year building incredible tools for the half that got cheap: autocomplete, agents, parallel PRs, generate-more-of-everything. We built almost nothing for the half that stayed expensive.

Everyone now has a way to produce more code. Almost no one has a way to get better at judging it. There's no gym for the skill that suddenly matters most. You're expected to develop it by accident, in production, on code you didn't write — which is the worst possible place to learn it.

That asymmetry is the gap I keep coming back to, and it's the reason I'm building theloupe.dev: a place to practice the half

that didn't get cheaper — reading code you didn't write and deciding, with reasons, whether it's actually right.

I'll get into how you even practice that — how you make something feel like a real production failure instead of a toy — in the next post. For now I just want to put the thesis down plainly: the cost of writing fell off a cliff, the cost of being sure didn't, and we've been building almost entirely for the wrong one.