Programmers Were the Compiler

Toledo, 1903. Michael has blown glass for twenty-six years and can hold a gather at the exact temperature where it stops fighting him, which is something you learn with your forearms and not with your head. The new machine in the corner makes four bottles a second and not one of them is beautiful. He tells the foreman, correctly, that no machine will ever learn what his hands know. The foreman agrees with him completely and sincerely, and then asks whether the neck on the medicine bottles should be wide enough for a cork or narrow enough for a dropper, because the machine will have made two hundred thousand of them by Friday and nobody in the building knows the answer.

Senko Rašić published a piece on August 8 titled Code was never the hard part is an insult to all programmers, and I want to start by giving him everything, because the post deserves it. He is right that the slogan is historical revisionism. Programmers were paid well and fought over because the skill was scarce. SICP and The Art of Computer Programming are not casual reads. Carmack and Bellard exist, and the gap between them and a competent ordinary developer is not a rounding error. And after fifty years of methodology, tooling and process, software is still riddled with bugs, which is a strange fact to explain if the work was always trivial. He is also not the strawman that the AI crowd likes to argue with. He says outright that we are in the middle of an industry wide tectonic change, tells engineers to learn the business and the users rather than hiding behind the keyboard, and closes with a line I would happily nail above a door: don’t outsource your understanding, judgement, empathy and taste to AI, and don’t be a meat proxy. I agree with all of it.

The problem is the inference, not the history. Senko takes the evidence that coding was hard and treats it as evidence about where the scarce work will be, and those are two different questions wearing the same coat. High salaries and low unemployment tell you that the profession was valuable and hard to staff. They do not tell you which activity inside the profession was doing the work of being scarce, because nobody was ever paid separately for the four things a programmer did at once: understand the problem, build a mental model of it, translate that model into executable detail, and then debug the model and the translation together without always knowing which of the two was wrong. That bundle was genuinely difficult. Michael’s forearms were genuinely skilled. Neither fact survives as an argument about what happens after part of the bundle becomes machine work.

There is an older version of this exact confusion, and it is worth remembering because nobody defends it anymore. For most of the nineteenth century and a good part of the twentieth, computer was a job title held by a person. Teams of human calculators produced navigation tables, ballistics tables and astronomical ephemerides, and the work was specialized, exhausting, error prone and genuinely hard to learn. Then the machines arrived and the occupation stopped existing, and not one sane person concluded from that that calculation had never been difficult. What the machines demonstrated is the far more interesting thing: an activity can be cognitively expensive for a human and nearly free for a machine, and the price of the human version tells you nothing about which of those two worlds you are about to live in.

The library argument has the same shape. Senko asks why, if coding were easy, we would have produced The Art of Computer Programming, SICP, Clean Code and The Pragmatic Programmer, plus degrees and bootcamps and an entire publishing subgenre, and he is right that a trivial activity does not generate that much literature. But look at what those books were actually for. The knowledge had to be written down, read by a human, internalized over years, and then applied by hand on every project, forever, because the only route from a principle to a codebase went through somebody’s fingers. That last step is the expensive one, and that is the step being automated. The knowledge did not become worthless. The cost of applying it repeatedly did, which is a very different event and a much more disruptive one.

The weakest argument in the post is the one about status. Senko asks why, if figuring out what to build were the hard part, product managers, business analysts, UX researchers and customer success people were not the ones getting rockstar salaries and keynote slots. I understand the intuition and it is wrong for a boring reason: pay and prestige track scarcity, substitutability and proximity to revenue, not cognitive difficulty. Nobody believes nursing is easier than day trading. What actually happened in this industry is that specification was never a separate labor market, because engineers were doing most of it themselves, in meetings, in tickets, in the shower, and then invoicing it as implementation. You cannot use the price of a role that barely existed as evidence about the difficulty of the work it was supposed to cover.

It also helps to notice that the specification argument is not something invented last year by people selling agents. In 1987, in No Silver Bullet, Fred Brooks wrote that the hardest single part of building a software system is deciding precisely what to build, and he built the whole essay on the distinction between accidental complexity, which comes from the machinery we use to express solutions, and essential complexity, which comes from the thing being modeled. His point about high level languages was exactly that they were powerful because they deleted accidental complexity, which is to say that the industry has been eating its own implementation labor since Fortran. Two years earlier, Peter Naur argued in Programming as Theory Building that the real product of programming is not the program text at all but a theory in the programmer’s head about how the problem is solved by execution, and that this theory is what makes the system extensible by humans. So when somebody says the hard part was never the code, they are not laundering a new sales pitch. They are repeating, badly and without attribution, something the field settled forty years ago.

For most of software history, programmers were the compiler between ambiguous human intent and executable machinery. That is the metaphor I keep coming back to, and Naur is the reason it needs a caveat: unlike an actual compiler, the programmer never received a complete specification. The input was a conversation, a screenshot, a contradictory pair of requirements and a sales promise, and the programmer discovered the missing requirements, built the domain theory, made the design decisions, and repaired the contradictions on the way through. We called all of that coding because it came out of the same person’s hands at the same desk, and because the artifact at the end was a diff.

What changed is that the artifact at the end is still a diff, and the hands are increasingly not ours. A coding agent today reads a repository, searches it, plans an edit across several files, runs the build, runs the tests, reads the failure, revises, and hands back a candidate change. That is a categorically different object from autocomplete, and Anthropic’s study of agentic coding, published in June across roughly 400,000 Claude Code sessions from about 235,000 people, gives us the closest thing to a measurement of the split. Humans made around 70% of the planning decisions, meaning what to build, which approach to take, and what counts as done. Claude made around 80% of the execution decisions, meaning which files, which code, which commands. Expert sessions pulled about twelve agent actions per prompt against roughly five for novices, and produced several times the output, which is the opposite of the story where AI flattens everybody to the same level. It is a vendor study of its own users and it cannot tell you anything about the economy, but as an operational picture of who is doing which half of the job, it is hard to ignore. The detail that matters most in it is that the delegated half is no longer typing. The agent investigates, chooses an approach at the local level, implements, runs the thing, reads what happened and corrects itself, which means the unit being automated has quietly stopped being code generation and started being a software engineering task.

None of which means coding is solved, and I have no patience for people who read that paragraph and conclude it does. METR ran a randomized trial with sixteen experienced open source maintainers working real issues in repositories they knew intimately, and early 2025 tooling made them 19% slower while they believed it had made them 20% faster, which is the most humbling result in the literature and should be printed on the inside of every AI vendor’s eyelids. Birgitta Böckeler’s autonomy experiment at Thoughtworks generated fifteen to twenty Spring Boot applications and watched the pipeline invent unrequested endpoints, silently change its own assumptions about an underspecified field, delete a validation rule while refactoring something else, and cheerfully report that the build and tests passed when they had not. And the benchmarks we use to argue about any of this are in worse shape than the models: OpenAI stopped reporting SWE-bench Verified in February after finding that at least 59.4% of the failures it audited came from broken tests rejecting correct code, with contamination on top, then audited the recommended successor and reported in July that roughly 30% of SWE-Bench Pro is also broken.

Read that list again, though, because it is not a list of coding failures. Inventing behavior for an unspecified field is a specification failure. Deleting a validation rule nobody wrote down is a context failure. Declaring victory on a red build is a verification failure. A benchmark that rejects functionally correct code is a failure to define correctness. Every one of those is a failure in the layer that is supposed to be cheap, exposed by making the expensive layer cheap. DORA’s qualitative work on 1,110 open ended responses from Google engineers says the same thing from the inside, and my favorite quote in it is an engineer explaining that he writes less code now and spends more time babysitting the AI. Reviewing code has always been harder than writing it, and we have just handed authors a machine that produces reviewable material faster than reviewers can absorb it. The 2025 DORA report found higher AI adoption associated with more throughput and less stability at the same time, which is what an amplifier does to a delivery system that was already fragile.

Here is the shape of it in the only terms I really trust, which is work I have had to ship. Somebody writes down that guardians can send messages to teachers. That sentence has the calm confidence of a specification and it specifies nothing at all. One to one or groups? Can a teacher open a conversation or only reply? Can a guardian write to any teacher in the school, or only the ones who actually teach their child? What happens when the student changes class in March? Is there history, can messages be deleted, who moderates them, what happens to the thread when an account is deactivated, what does the retention policy say a court can request two years later, do any of these turn into emails, and what happens to every relationship in the system when the nightly import from the school’s management platform reshuffles them? An agent will answer all of those questions. It will answer them confidently, in whichever way looked most plausible from the surrounding code, and every single answer is a business decision that a human being in that building is accountable for. The hard part was never async sendMessage(). I wrote last week that we are heading toward software with no bugs left, only undocumented business cases, and this is the mechanism behind it. The better the machine gets at building exactly what you asked for, the more the surviving defects are simply the things you never said.

The economics here do not require anything dramatic. Delivering software costs you problem discovery, plus specification, plus design, plus implementation, plus verification, plus integration, plus running the thing afterward. Implementation does not have to become easy in any absolute sense for the profession to be reorganized. Its marginal cost only has to fall faster than the other terms, at which point the other terms are the cost, and any increase in generated volume pushes verification up rather than down. We have seen a small version of this movie already. The GAO reported in 2006 that computer programmer employment fell 22.4% from 2001 to 2005, the only computer specialist occupation to lose jobs, while software engineering categories grew between 22.6% and 26.1%, and it named two causes: routine programming could be done anywhere and shipped over a wire, and progress in programming technology let people produce basic code without a programmer involved. That was twenty years ago, with no model in sight. Today the BLS puts computer programmers at a $98,670 median and projects the occupation to shrink 6% through 2034, while software developers sit at $133,080 and are projected to grow 16%. You cannot hang that on generative AI, and I am not going to try. The point is narrower and older: the market has been quietly separating narrow implementation from broad system work for decades, and this is the largest push it has ever received.

So what actually gets more valuable. Knowing how concurrency, storage, networks, types and security really behave, not because you will hand write it, but because it is the only way to state a constraint the agent cannot infer and to smell a patch that is confidently wrong. Verification stops being the last step before shipping and becomes the production system itself, which means types, property tests, contract tests, deterministic environments and observability are no longer hygiene, they are the thing that decides whether cheap generation is an asset or a liability. Architecture matters more than it did, because an agent can safely modify a service with local tests and explicit schemas and cannot safely modify a ball of hidden state and undocumented invariants. And the person who knows why the retention policy forbids deleting that row, or which reporting query nobody has run since 2019 but finance checks every quarter, becomes the most useful engineer in the room, which is a genuinely strange inversion for an industry that spent thirty years treating domain knowledge as the boring part. What worries me in all of this is the juniors. We are automating precisely the bounded tasks people used to grow their system intuition on, and DORA calls this the expertise paradox: AI lowers the barrier and removes the struggle that used to build the expertise. Nobody has solved that. Most companies have not noticed they need to.

What all of this kills is not the programmer, it is the volume advantage. For my entire career, the way you got a large piece of software was to convert money into engineer months and then wait, and the ability to produce a lot of correct code was a real moat, which is why we built whole companies around hiring for it and whole interview rituals around detecting it. That moat is draining. Once output scales with agent capacity and supervision rather than headcount, what is left to compete on is having the right idea, stating it precisely, constraining it correctly, checking the result honestly and standing behind it in public. Which is why I would not defend the slogan Senko is attacking, and I would not accept his conclusion either. Implementation was expensive because humans were the mechanism that converted intent into working systems, and that mechanism is now being automated. Craft does not stop mattering when that happens. It stops being the scarce resource, and those are not the same claim, though the second half of his argument treats them as if they were.

Which brings me back to Senko’s closing line, the one about not outsourcing your understanding, judgement, empathy and taste, and not being a meat proxy. That is not a rebuttal of the bottleneck argument. It is the strongest single statement of it that I have read this year, because understanding, judgement, empathy and taste are exactly the four things that stay expensive when implementation goes to nearly free, and they are also the four things nobody can accept accountability for on your behalf. Michael was right about his hands. He was also the only person in that building who could have answered the foreman’s question, and the tragedy is that he spent the rest of the afternoon arguing about the machine instead.