Pangram verdict · v3.3
We believe this text is mainly AI, with some human-written content.
AI likelihood · overall
AIArticle text · 1,612 words · 31 segments analyzed
It’s 7:40 on a Tuesday morning in 2031, and you haven’t written a line of code yet. You probably won’t today, and that’s fine. While you slept, four agents worked through the backlog you sorted yesterday afternoon. Three of them finished. Their pull requests are waiting for you, each with the tests it added, a short recording of the feature working, and a note about the parts it wasn’t sure of. The fourth agent stopped at 2:13 a.m. and left you a question instead: The spec says refunds go back to the original card. This customer’s card expired in March. What should happen? The agent could write refund code all day long. What it can’t do is decide what your company owes a customer whose card has expired, so it stopped and asked, which is exactly what you’d want from a new hire too. Your morning goes like this: you read three pull requests, you go and talk to someone in support, and you write the rule down so clearly that nobody (human or otherwise) has to guess again. Imagined · Tuesday, 2031Agents1234You567891022:0002:0006:0010:0014:0018:0022:00Agents122:00 Three agents work through yesterday's backlog and open three pull requests, each with tests and a recording.222:00 A fourth agent stops and leaves a question: refunds go to the original card, but that card expired.313:00 Agents build the refund rule you wrote down, with the tests you wrote first.421:30 Tonight's runs start from the plan you approved.You507:40 Read the three pull requests and watch the recordings.609:00 Answer the 02:13 question. You can't, yet.710:00 Ask support what customers with expired cards expect.811:00 Write the rule down as a short spec and five tests.914:00 Read the agents' work on the one part that touches money.1016:30 Approve tonight's plan. Go home.A made-up day, drawn to scale anyway. The red marks are the only times the work waited for a person. I made that Tuesday up. None of it is science fiction, though. Agents that work unattended overnight exist today, and one of them runs on my own machine every night at ten. It invents a small project, builds it, tests it, and I find out what it made over breakfast. The first morning, I had no idea what it had built. That build is now Rule Safari, a live project on this site, with an article explaining how it works.
So is this the end of programming?
People have been asking that for more than seventy years.
I find that comforting.
I also find it a little suspicious. Programming has been ending since 1954 On 10 November 1954, IBM’s Programming Research Group finished a preliminary report on a new language called FORTRAN. One sentence in it says that FORTRAN “should virtually eliminate coding and debugging.” I love this sentence. It’s so sure of itself, and it even came with a budget: problems solved “for less than half the cost” of doing it without FORTRAN. The industry had a name for this kind of thing back then.
Assemblers and compilers were called automatic programming.
You’d describe what you wanted, and the machine would write the program. FORTRAN shipped in 1957, and it really did eliminate a kind of coding. Almost nobody translates formulas into machine instructions by hand anymore. Debugging survived just fine. (This month I chased a Scry bug that came down to a bookmark saved only every twelve hours, so I can confirm debugging is alive and well.) What FORTRAN actually did was take one tedious part of the job away and move the job up a level. People stopped thinking about registers and started thinking about bigger problems. Programs got cheaper to write, so everybody wanted more of them. That has happened over and over since. 1947Assembly languageYou stopped: writing instructions as raw numbersKathleen Booth, "Coding for A.R.C."1957FORTRANYou stopped: translating formulas into machine instructions by handThe 1954 report: it "should virtually eliminate coding and debugging."1972CYou stopped: rewriting the same program for every new machine1981The Last OneYou stopped: nothing, as it turned outA BASIC program generator, named as the last program you would ever need to buy.2008Stack OverflowYou stopped: solving every error message alone2010npmYou stopped: writing your own everything2021GitHub CopilotYou stopped: typing the boilerplate2025Coding agentsYou stopped: typing most of the code20??NextYou stopped: ?Every rung took something off a programmer’s plate. The dashed one promised that the climbing was over. My favorite rung is 1981.
A British company called D.J.
“AI” Systems (yes, really) sold a BASIC program generator named The Last One. The name was the whole pitch. It would write all your programs for you, so it would be the last program you’d ever need to buy. Reviewers found it useful for some business programs.
It was not the last one.
Here’s the pattern on every rung. Something gets automated, the people doing the work stop doing that thing by hand, and the field keeps growing anyway. GitHub counted more than 180 million developers in its 2025 report, and more than 36 million of them had joined in the previous twelve months. So I don’t think AI ends programming. I do think this rung is different in one way, and that’s speed. GitHub Copilot’s preview came out in June 2021. By 2025, 84% of developers in Stack Overflow’s survey were using AI tools or planning to.
Four years, from novelty to default.
What 2026 actually looks like The vibes are loud right now, so let’s start with numbers.
(Speaking of vibes: Andrej Karpathy coined “vibe coding” in February 2025, for the kind of coding where you “fully give in to the vibes.” Stack Overflow asked about it that year.
72% of developers said it isn’t part of their professional work, and another 5% said emphatically no. I love that they offered that option.)
Stack Overflow’s survey is the biggest regular check-up we have, and the adoption curve in it is steep: from 70% of developers using AI tools or planning to in 2023, to 84% in 2025, when half of professional developers were using them every day.
You’d think all that use would mean developers love these tools.
Nope.
Favorable sentiment fell from 77% in 2023 to 60% in 2025, and only ticked back up to 62% this year.
In 2025, more developers distrusted the accuracy of AI output (46%) than trusted it (33%).
The top frustration, picked by 66% of them, was “AI solutions that are almost right, but not quite.” I feel seen.
Almost right is an expensive kind of wrong, because you have to read every line to find the part that isn’t.
(45% of them said debugging AI-generated code takes longer.)
20%40%60%80%100%202320242025202670%76%84%use or plan to77%72%60%62%favorable42%43%33%trust accuracyStack Overflow Developer Survey, 2023 to 2026.
The 2026 survey dropped the “use or plan to” question and rewrote the trust question, so those two lines stop at 2025.
About 90,000 developers answered in 2023 and more than 30,000 in 2026. Then there’s my favorite study of the whole AI boom, mostly because it’s so rude. In early 2025, METR, a nonprofit research group, ran a proper randomized controlled trial. Sixteen experienced open-source developers worked on 246 real issues in their own repositories, projects they’d been on for years, and each issue was randomly assigned to allow AI tools or ban them. Before they started, the developers expected AI to cut their time by 24%. When they finished, they believed it had cut it by 20%. The clock said that with AI they took 19% longer.
Nineteen percent longer!
And they walked away sure it had helped. Economists predictedexpert forecast39% less timeML researchers predictedexpert forecast38% less timeThe developers expectedbefore the tasks24% less timeThe developers feltafter the tasks20% less timeThe clock measuredwhat happened19% more timeMETR, July 2025: 16 developers, 246 issues, mostly Cursor with Claude 3.5 and 3.7 Sonnet.
The expert forecasts are from the paper.
The slowdown has a wide margin, somewhere between 2% and 39%. Before anyone screenshots that for a hot take: it’s one study of sixteen people, using early-2025 tools, on codebases they knew better than any model could. And METR tried to run it again. A bigger study started in August 2025, with 57 developers and more than 800 tasks, and in February 2026 METR said the data was too unreliable to lean on. Mostly that was because developers kept declining to take part, since they “do not wish to work without AI.” The early numbers hinted at an 18% speedup for the returning developers (with a range wide enough to include no speedup at all). I think that’s the most 2026 way an experiment has ever failed. People refused to be in the group without AI. What I take from METR is narrower than any headline, and more useful: how fast you feel is not a measurement. If you want to know whether AI makes your team faster, measure it the way you’d measure anything else. The line that keeps going up METR’s other big project tracks how long a task an AI agent can finish on its own. They time human experts on a suite of software tasks, then find the task length where an agent succeeds half the time. In 2019, GPT-2 managed tasks that take a person about three seconds. GPT-4 got to about four minutes in 2023. Claude 3.7 Sonnet reached an hour in February 2025, and Claude Opus 4.6 reached about twelve hours a year later. Across the whole series, that number has doubled about every six months. Since 2023, it’s been closer to every four months.
1 min1 hour1 workday1 work week1 work month2019202120232025202720292031if the trend holdsGPT-2GPT-4Claude 3.7 SonnetGPT-5Claude Opus 4.6METR’s time horizons (version 1.1): the length of task, in human expert time, that each model finishes half the time.