The first time I said “code is cheap” out loud in a meeting, a manager waved at the budget — headcount, salaries, the tooling line — and asked which part of that looked cheap. He wasn’t wrong about the number — he was wrong about what it was buying.

“Code is cheap” is provocative on purpose, and most of the disagreement it provokes comes from collapsing two different costs into one: the cost of producing code, and the value of the code as an artifact. Producing code is not cheap — the salaries and the headcount are real. Whether the artifact is cheap is the actual argument, and it lives entirely in that distinction.

What the manager hears

What a manager hears when I say “code is cheap” is something closer to “your expensive team is overpaid” — and the flinch comes from a picture of what a programmer actually does. In my experience it’s one of two pictures, and both are wrong:

• The grinder. A programmer comes in early, bangs on the keyboard until late, and ships lines of code. Quantity is output; a quiet week is a wasted one.
• The whiteboarder. A knot of geeks argues for weeks in front of a whiteboard full of incomprehensible squigglies and calls it “design.” Process is output; motion is progress.

It’s neither. Most of the time the thinking takes longer than the typing does — and the thinking is what saves the debugging later. A programmer is not a glorified typist, and the budget isn’t buying keystrokes. It’s buying judgment.

Why “code is cheap” lands wrong

The phrase lands wrong because code is real to a manager in a way ideas just aren’t. It’s visible, demoable, accountable, line-counted, branch-merged, ticket-closed; it turns up in the standup and on the sprint board. Ideas don’t — and even written down, they don’t count the same way upstairs. So the cost-of-code framing rewards the artifact and files the thinking under overhead, which is inverted from where the leverage actually lives.

When I say code is cheap, here’s what I mean: the same idea can be expressed in many languages, in many frameworks, on many operating systems, and the expression is interchangeable. Swap Go for Python, one framework for the next, one OS for another — the artifact changes top to bottom and the idea doesn’t budge. The idea is the part you can’t swap out, and it’s the part worth paying for.

What programming actually is

• Problem framing. Choosing what to build.
• Designing the abstractions — picking the joints to carve at.
• Writing the code. (Yes, this part too.)
• Judging the output — does it do what I intended? does it do only that?
• Iterating on all four as the picture sharpens.

The first two and the last two are the load-bearing parts. Typing is the middle one and it’s the cheapest of the five — has been for decades, even before AI assistants.

I’m oversimplifying, of course: beyond the business logic, developers also have to think about performance, security, maintainability, reporting and monitoring, and plenty more. But “writing the code” is still cheap typing. (For a small, concrete case where the work is the transformation choice rather than the keystrokes, see Code linearization .)

The AI inflection

Now the cheapest of the five gets cheaper still:

• AI assistants are typists. Fast ones. Patient ones. They produce code by the bucket.
• If a programmer’s value was typing speed, the role would be done. It wasn’t, so it isn’t.
• What expands instead: creator, designer, UX specialist, problem-framer, judge of taste. The job moves upstream of the keyboard.
• Resharpens, not replaces. The programmer’s value redistributes toward the parts that were always doing the real work, and away from the artifact-production step that managers were measuring. (The metaphor is a knife getting a fresh edge — the role wasn’t dulled, it just got out of focus.)

Yes, AI can chip away at some tactical design decisions, but it can’t replace creative design: it has no first-hand experience and no real motivation or passion. Being a subject-matter expert isn’t just dry knowledge you can read out of a textbook.

Mitchell Hashimoto — the developer behind Terraform, Vagrant, and the Ghostty terminal I’m typing this into, and someone who reaches for AI every day — tried this directly . He wrote the simplest renderer he could in Go, then put an agent in a loop to optimize it as hard as possible: 88ms down to 1.5ms, 150,000 allocations down to about 500. Impressive — until you see that the hand-written renderer he’d ported ran the same benchmark in 20 microseconds with zero allocations, some 75× faster. That gap is subject-matter knowledge and experience.

The agent optimized brilliantly from the starting point it was handed and never saw the better design. The typing got automated; the judgment that knows the better answer exists did not.

And the gap will shrink — I’d bet on it. The first compilers were crude; any assembly programmer could out-code them by hand. Then optimizing compilers got better year after year, until today almost nobody writes assembly: you can still beat the compiler, but the effort is enormous and the win is usually small. Agents will ride the same curve — asymptotically better at wringing speed out of whatever design they’re handed. But the compiler never picked your algorithm, never decided what to build, never noticed the real 75× was waiting in a different design. It automated the translation, not the idea. Every time the expression layer gets cheaper, the work doesn’t vanish — it moves up a level. That’s the level worth standing on.

What this changes

• If you’re a programmer: stop measuring yourself by output volume. Start measuring by problem clarity and design quality. (Easier said than done — the muscle memory of “lines committed today” is hard to drop.)
• If you’re hiring programmers: stop optimizing for typing speed under interview-room pressure. Optimize for the upstream skills — problem decomposition, taste, judgment, the ability to know when not to write code.
• If you’re managing programmers: the budget pays for thinking. The code is the receipt, not the product.

Let me expand on that last one:

• I’ve read about the days when programmers were judged by how many lines of code they shipped — literally, “every programmer should ship 100 fully debugged lines a day, documented to corporate standards.” As a project manager, I was once asked to report line counts for my projects.
• I’ve worked at companies where a programmer’s “velocity” was measured by how many tickets they closed in a day, a week, or a month — with no regard for how hard the individual tickets were.

What should be measured instead is how useful the product is: how well it helps customers, and the company, meet their goals. Who cares how many lines were written or how many tickets were closed, if customer satisfaction is dropping and the company is losing money and customers?

Summary

Three sentences:

• Code is cheap; ideas are not.
• AI makes that gap wider, not smaller.
• The programmers who get the next decade right are the ones who already worked upstream of the keyboard — and the ones who learn to.