For as long as software has existed, we have measured the bottleneck. When output was scarce, we counted output. That made sense.

Story points. Velocity. Pull requests merged. Tickets closed. Each one a new vocabulary for the same instinct — count what gets produced, because production is what you can see.

It goes back further than that. IBM was counting K-LOC (thousands of lines of code) in the 1960s. The assumption was simple: more code meant more work, more value, more progress. Never mind that the best engineers wrote less. Never mind that every line added was a line someone would have to read, debug, and maintain forever. Output was visible. Quality was not.

Now comes the next iteration: tokens in, tokens out. A reasoning model generates ten thousand lines before lunch. Management sees the number and feels progress. The dashboard is very green.

But here's what the dashboard doesn't show: whether anyone actually understands what was produced.

Before computers were machines, they were people — hired to execute, not to reason.

Through the 1930s, 40s, and 50s, rooms full of women sat at desks performing calculations by hand. Mathematicians, many of them — and brilliant ones. The constraint wasn't their capability. It was the job. At NASA, at Los Alamos, at the Bureau of Standards. Katherine Johnson computed orbital trajectories. Dorothy Vaughan managed entire teams of them. They were called computers. That was the job title, and the job description was simple and absolute: receive a specification, execute it precisely, return the result. No judgment, no interpretation, no deviation. They were valued for exactly one quality: the ability to suppress their own reasoning in service of perfect fidelity to the specification.

When the machines arrived, they inherited the job description wholesale. Alan Turing defined the digital computer as a machine intended to carry out any operation a human computer could perform.

Originally written in 2022 and revised in 2026. The assumptions have been updated. The curiosity hasn't.

Every technology choice, every framework, every diagram is a compressed representation of reality — architects build abstractions that other people have to live inside.

Architecture externalizes assumptions. The job is deciding which assumptions to externalize, and whether they're still true.

This blog lives in that question.