The Compiler Was Supposed to End Programming Too: What the 2026 Data Says About AI Coding Agents

The short version

AI coding agents will not end programming; they will automate another layer of it, the same way FORTRAN automated formula translation in 1957. That is the argument of a widely discussed essay published on hrih.si and submitted to Hacker News, where it reached 150 points and 197 comments. The essay's own evidence cuts both ways: adoption of AI coding tools rose from 70% of developers in 2023 to 84% in 2025, yet favorable sentiment fell from 77% to 60% over the same period, and a randomized controlled trial by METR found that experienced developers using AI on their own repositories took 19% longer while believing they had been 20% faster.

The essay's central claim is that the bottleneck in software work has moved from writing code to reviewing it, and that the hard part of programming — deciding what should exist — remains human work. Hacker News commenters largely rejected the compiler analogy, arguing that a compiler produces precise, repeatable output from precise input while an LLM does not.

The 1954 FORTRAN report promised to eliminate coding and debugging

On 10 November 1954, IBM's Programming Research Group finished a preliminary report on a new language called FORTRAN. The report stated that FORTRAN "should virtually eliminate coding and debugging" and that problems would be solved "for less than half the cost" of doing the work without it. Assemblers and compilers of that era were collectively called automatic programming.

FORTRAN shipped in 1957. It did eliminate a kind of coding — almost nobody translates formulas into machine instructions by hand anymore — but debugging survived. The essay's author notes chasing a bug in his own project that traced back to a bookmark saved only every twelve hours.

The pattern the essay identifies is consistent: something gets automated, the people doing that work stop doing it by hand, and the field keeps growing. GitHub's 2025 report counted more than 180 million developers, with more than 36 million joining in the previous twelve months.

The ladder of abstraction, as the essay lays it out

The essay presents a timeline of rungs, each of which removed something from a programmer's plate:

1947 — Assembly language. Programmers stopped writing instructions as raw numbers. Attributed to Kathleen Booth, "Coding for A.R.C."
1957 — FORTRAN. Programmers stopped translating formulas into machine instructions by hand.
1972 — C. Programmers stopped rewriting the same program for every new machine.
1981 — The Last One. A BASIC program generator from a British company called D.J. "AI" Systems, sold on the premise that it would be the last program you would ever need to buy. Reviewers found it useful for some business programs. It was not the last one.
2008 — Stack Overflow. Programmers stopped solving every error message alone.
2010 — npm. Programmers stopped writing their own everything.
2021 — GitHub Copilot. Programmers stopped typing the boilerplate.
2025 — Coding agents. Programmers stopped typing most of the code.

The essay argues this rung differs from the others in speed rather than in kind: GitHub Copilot's preview shipped in June 2021, and by 2025, 84% of developers in Stack Overflow's survey were using AI tools or planning to. Four years from novelty to default.

What the 2026 data actually shows

Adoption is high and sentiment is not. Stack Overflow's developer survey, the largest regular check-up cited in the essay, shows adoption rising from 70% of developers using AI tools or planning to in 2023 to 84% in 2025, when half of professional developers reported using them every day. Favorable sentiment moved the other way, falling from 77% in 2023 to 60% in 2025 before ticking back to 62% in 2026.

In 2025, more developers distrusted the accuracy of AI output (46%) than trusted it (33%). The single most-picked frustration, chosen by 66% of respondents, was "AI solutions that are almost right, but not quite." 45% said debugging AI-generated code takes longer.

The essay notes a methodological caveat: the 2026 Stack Overflow survey dropped the "use or plan to" question and rewrote the trust question, so those two trend lines stop at 2025. Roughly 90,000 developers answered in 2023 and more than 30,000 in 2026.

Andrej Karpathy coined "vibe coding" in February 2025 for the practice of "fully give in to the vibes." When Stack Overflow asked about it that year, 72% of developers said it was not part of their professional work, and another 5% said emphatically no.

METR's randomized trial: feeling faster is not a measurement

The essay calls METR's 2025 randomized controlled trial its favorite study of the AI boom. Sixteen experienced open-source developers worked on 246 real issues in their own repositories — projects they had worked on for years — with each issue randomly assigned to allow or ban AI tools.

Before starting, the developers expected AI to cut their time by 24%. After finishing, they believed it had cut their time by 20%. The clock showed they took 19% longer with AI. The slowdown has a wide margin, somewhere between 2% and 39%. The setup was mostly Cursor with Claude 3.5 and 3.7 Sonnet. Expert forecasts in the paper were far more optimistic: economists predicted 39% less time and ML researchers predicted 38% less time.

METR attempted a larger replication starting in August 2025 with 57 developers and more than 800 tasks. In February 2026, METR said the data was too unreliable to lean on, largely because developers kept declining to participate since they "do not wish to work without AI." Early numbers hinted at an 18% speedup for returning developers, with a range wide enough to include no speedup at all.

The essay's takeaway is deliberately narrow: how fast you feel is not a measurement. Teams that want to know whether AI makes them faster should measure it the way they would measure anything else.

METR's time-horizon curve: doubling roughly every six months

METR's other major project tracks how long a task an AI agent can complete on its own. The method times human experts on a suite of software tasks, then finds the task length at which an agent succeeds half the time.

2019 — GPT-2: tasks taking a person about three seconds.
2023 — GPT-4: about four minutes.
February 2025 — Claude 3.7 Sonnet: one hour.
A year later — Claude Opus 4.6: about twelve hours.

Across the series, that number has doubled roughly every six months; since 2023, closer to every four months. METR states that anything above 16 hours is unreliable with its current tasks, so a 17-hour measurement for Claude Mythos Preview in May is not plotted on the line. METR stopped updating the page in September.

The essay is explicit about the limits of this projection: "half the time" does a lot of work in the definition, benchmark tasks are cleaner than real codebases, and a log-scale chart with a dashed line is how a lot of bad predictions start. If the trend continues even roughly, agents would handle a month of human work half the time around 2028.

What the labs report about their own code

Google said in October 2024 that more than a quarter of its new code was generated by AI, and "well over 30%" six months later.
In March 2025, Anthropic's Dario Amodei predicted AI would write 90% of code within three to six months. The essay notes that was too soon.
By May 2026, Anthropic said more than 80% of the code merged into its own codebase was written by Claude.

When code gets cheap, the queue moves to review

The essay's core mechanism is a queueing argument: speed up one step of a process and work piles up in front of the next slowest step. Faros AI's telemetry data supports it.

In 2025, Faros AI looked at telemetry from more than 10,000 developers on 1,255 teams. Developers on teams with high AI adoption finished 21% more tasks and merged 98% more pull requests, while their review time went up 91%.

Faros ran the analysis again in 2026 with 22,000 developers. Task completion per developer was up 34%, but median review time had grown five times, 31% more pull requests were merging without any review at all, and the ratio of incidents to pull requests had more than tripled.

Quality data points in the same direction:

Veracode tested more than 100 language models on 80 coding tasks in 2025, and 45% of the results had a security flaw.
GitClear found copy-pasted lines rose from 8.3% of changed code in 2021 to 12.3% in 2024, while moved code — the kind produced by refactoring — fell from about a quarter to under 10%.
Daniel Stenberg, who leads curl, began banning people who submitted "AI slop" bug reports in May 2025, writing that the project was "effectively being DDoSed." In January 2026, curl shut down its bug bounty.

Fred Brooks already split the problem in 1986

The essay grounds its argument in Fred Brooks's 1986 paper "No Silver Bullet," which borrowed Aristotle's terms to divide the difficulty of software into two piles. The accidents are the trouble our tools cause us: syntax, boilerplate, fighting the build. The essence is "the specification, design, and testing of this conceptual construct" — working out what the thing should do.

The essay's illustration of essence is a fictional agent that stops at 2:13 a.m. and asks a question instead of proceeding:

The spec says refunds go back to the original card. This customer's card expired in March. What should happen?

The agent can write refund code all day, the essay argues, but it cannot decide what the company owes a customer whose card has expired. AI is getting very good at the accidents. The essence is still on a human's desk.

The junior hiring collapse is the part the essay likes least

In August 2025, Erik Brynjolfsson and two colleagues at Stanford's Digital Economy Lab used ADP payroll data to examine who was getting hired. Employment for software developers aged 22 to 25 was down nearly 20% from its peak in late 2022. Older developers showed no noticeable change.

An update published the following August, with data through June 2026, found young workers in AI-exposed jobs 19% below where they would be if they had kept pace with less-exposed peers. Experienced workers showed no comparable gap. Most of the effect comes from companies hiring fewer young people in the first place.

Indeed's index of software development job postings sits about 21% below February 2020, after bottoming out 39% below in May 2025. The essay notes the Stanford authors call their findings descriptive, not causal, and that other factors are in play: interest rates rose, and many companies over-hired during the pandemic — Indeed's index peaked at more than twice its 2020 level in early 2022.

The essay's concern is apprenticeship. Senior engineers are made on the job, mostly by being juniors on real teams: doing the boring tickets, breaking production once, and having someone kind explain why. If agents take the boring tickets, the essay asks where the next senior engineer comes from, and notes it is hard to review code well if you have never written much of it. Its proposed answer is a different apprenticeship — reviewing agent work with a senior beside you, owning one small system end to end, and writing the specs and tests the agents build from.

Five guesses for 2031

The essay closes with explicit predictions, framed as guesses to be revisited:

Teams get smaller, and there are a lot more of them. According to Y Combinator's Jared Friedman, a quarter of the Winter 2025 batch had codebases that were about 95% AI-generated. In February, Block cut about 4,000 jobs, and Jack Dorsey pointed to AI tools and "smaller and flatter teams." The essay still does not expect fewer software jobs overall, citing the US Bureau of Labor Statistics projection of 10% growth for software developers, QA analysts and testers from 2025 to 2035, and invoking the Jevons paradox — William Stanley Jevons argued in 1865 that more efficient steam engines would make Britain burn more coal.
The spec and the tests become the source. Code becomes more like a compiler's output: inspectable, but rarely edited by hand.
Software for an audience of one. When a working tool costs an evening instead of a quarter, people will make software the way they make spreadsheets today.
Reading code becomes a career. The essay expects something like "verification engineer" on job boards, plus tooling that shows a reviewer the recording, the risky lines, and the tests the agent did not write.
Every change carries a label. A pull request will routinely state who or what wrote it, who checked it, and what was verified.

The Hacker News counterargument: a compiler is not an LLM

The most repeated objection in the discussion is that the compiler analogy fails on determinism. As one commenter put it:

A compiler is expected to take a precise input and reliably produce a precise output, repeatably. If LLMs could do that they'd be compilers, and we wouldn't be having this discussion.

Another framed the difference as authorship rather than translation:

If I write a novel, have someone translate it to French and publish it, that's a compiler. If I hand some brief notes to someone who writes the novel for me, that's the llm. These are fundamentally different things.

A third argued the scope of the change is broader than programming:

With compilers there is a (roughly, barring optimizations) 1:1 correspondence between input and output. With LLMs you take an idea and it will drive the whole thing from the beginning all the way to the end. This is unlike anything that we've done so far. It's also strange to focus on programming: LLMs are coming for all information related jobs.

The historical correction: "coding" did not mean what the essay implies

Several commenters argued the 1954 FORTRAN quote is being read out of context. One explained that the word coding originally referred to translating an abstract program written on paper into machine code, and that compilers were first called automatic coders:

The word compiling referred to something more like linking: producing an image containing multiple library routines. In other words, similar to compiling an anthology of works into a book. After compilers, the word coding changed to writing program code in any language. [...] While the terms reshuffled, the concrete reality was simply that people worked less in assembly language, not that fewer people worked or that programming ended.

Another commenter made the same point about FORTRAN specifically, noting it was viewed as transcribing mathematical notation, which was not considered coding, and cited IBM fellow Iverson's Turing Award lecture on notation as a tool of thought.

The "sufficiently precise spec is code" objection

One commenter pushed back on the essay's prediction that specs and tests become the source of truth:

Sufficiently precise spec is called code. It is the compiler story all over again.

The same commenter noted that visual programming and rapid application development — Visual Basic being the canonical example — are absent from the essay's timeline despite being all the rage in the 1990s, and argued that every project is unique in some way, which is why off-the-shelf components rarely fit and why code remains the most precise way to express intent. In that view, AI is most effective precisely when you do want what others already did — rewrites, ports, decompilation — which is translation work rather than programming.

A related comment agreed with the analogy but with a caveat: "Vibecoding maintainable code requires providing the LLM a specification. It's still coding, but you now have the liberty of just providing the spec as opposed to worrying about syntax. Since they are non deterministic and love to cheat you still need to review though."

Other threads in the discussion

One commenter observed that the compiler analogy is already vindicated in practice: "We do pretty much just use compilers now though. The last time I read disassembly to fix an issue was at least a decade ago."
Another compared the shift to the arrival of terminals, which moved programming out of shared computer rooms and into solitary offices, and noted that many programmers were women before terminals and left afterward.
One commenter predicted the profession narrows to design: "In my kids' lifetime, being a programmer will seem like being a cobbler. People will still wear shoes and be involved in making the shoes. But the job will be in the design not mass production."
A blunter assessment: "I think this is the bargaining stage of the grieving process."
One commenter noted the essay's own fictional premise may date quickly, responding to the 2:13 a.m. refund question with: "In 2031: Why on earth not?"
Another commenter described running a daily video call with agents to review overnight work, and linked a personal project that gives a voice, body, and etiquette instructions to a model.

A provenance caveat raised in the comments

One commenter alleged that the blog hosting the essay was created shortly before publication for the purpose of marketing AI-written books, pointing to placeholder text on its about page ("Sample introduction · Replace this with your personal bio.") and claiming the author blocked them on Reddit when asked how much AI was used in the writing. The same commenter acknowledged that the essay's scientific sources appeared well researched rather than hallucinated. This claim is unverified and is reported here as a comment, not as a finding.

The bottom line

The essay's own conclusion is that FORTRAN eliminated a kind of coding without eliminating coders, and that AI does the same thing faster and messier. In its telling, the developer of 2031 spends the day deciding what should exist, explaining it clearly enough for a machine to build, and checking that what came back is right — work that was always the hard part, and that programmers previously had less time for because they were busy typing.

The strongest evidence in the piece is not the analogy but the measurement gap: METR's developers believed AI made them 20% faster while the clock said 19% slower, and Faros AI's telemetry shows review time growing fivefold as pull request volume roughly doubles. Whether or not the compiler comparison holds, the queue has visibly moved.