Thorsten Ball's predictions and the data we test them against
On 19 September 2026 Thorsten Ball posted a short message on X: most predictions he sees are, in his view, still far too cautious, so he offers his own. He attached a note titled “What I believe about the future of software development” with 16 theses. Ball is a co-founder and co-creator of Amp. Before that he worked at Sourcegraph and at Zed, and he self-published two books on programming. This is not a voice from outside the industry.
The theses are sharp: code review will die, unit tests might die, the terminal is dead, open source in its current form makes no sense. We answer each one separately, with a verdict: we agree, we partly agree, or we disagree.
Our evidence comes from one place we know closely: the AI agent pipeline that is expanding the content of this site in October 2026. Writing agents work in parallel and handle up to 15 article groups in six languages per wave. According to the repository history, wave 20 on 15 October covered 14 groups and 85 files. Independent reviewing agents check parity between language versions, style and structured data, and a separate agent fixes what they report. At the end, gates run on the built HTML decide whether a change can move forward at all. The diagram at the top of the page shows the setup.
The pipeline runs on a live site with thousands of pages, so an agent error nobody catches goes straight to the search engine. That is why our view of the future of software development is narrower than Ball’s, but it rests on what we saw ourselves in the past week.
Future of software development according to Thorsten Ball
Below are all the theses from the note in the author’s order, with our verdict. Each one is covered in more detail further down.
| Thorsten Ball’s thesis | Our verdict |
|---|---|
| Code review will die | We disagree, review changes its object |
| Unit tests might die | We disagree |
| The craft of writing code will disappear | We partly agree |
| The craft of building software will be more important than ever | We agree |
| Most bugs will be “you asked for the wrong thing” bugs | We agree |
| Open source in its current form makes no sense | We disagree |
| Human performance contributions will stay an edge case | We partly agree |
| The terminal is dead | We disagree |
| Tokens are the new computing paradigm | We partly agree |
| The PM, design, engineering triad will disappear | We partly agree |
| The gap between large and small companies will grow | We partly agree |
| There is no proof that “good code” will matter | We partly agree |
| Some people will be priced out of producing software | We partly agree |
| It is questionable whether cheaper models will be used | We agree |
| UI will be generated on the fly | No data on our side |
| It will take a generation | We agree |
The tally: on four points we side with Ball, on four we disagree, on seven we see the direction but not the scale, and on one we have no data.
Is code review dead with AI
“Code review will die. I mean: it’s already dead. But in the future, humans won’t find a bug or an issue with the code produced by a model, at least not in a reasonable time. Humans will only review the system and its composition, but it won’t be in PRs and it won’t be by looking through every line of the code.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we disagree, although the second half of the thesis is right.
Ball is right about one thing: a human reading hundreds of files line by line per wave has no chance. The conclusion is wrong. Review does not die, it changes its object. In our pipeline nobody hunts for a missing semicolon anymore. The reviewer looks for a false claim that is syntactically correct.
A list from one week of October 2026, caught by the reviewers:
- Agents cited wrong article numbers in texts about regulation: Article 16 of DORA where Articles 17 to 19 applied, and Article 13 of the CRA where Article 14 applied.
- An agent built a “case study with a 23 percent result” out of nothing more than the title of a WordCamp talk. No such study existed.
- The Wikidata identifier given for Astro pointed to a person, and the one for Composer pointed to a church.
- An agent wrote MCP server code against an SDK API that does not exist, and credited the MCP protocol with “built-in idempotency” it does not have.
- A text about links used a
rel="follow"attribute that no specification defines.
None of these is a coding bug in the classic sense. Each would pass compilation, the YAML parser and a Markdown validator. Each would have been published if review had died. Worse, several are claims a reader takes on trust, because they read like facts from documentation.
The second half of Ball’s thesis holds: review moves from PRs to the system. Our reviewers do not read diffs. They compare claims against sources and language versions against each other. The question shifts from “is this line correct” to “is this sentence true and does the whole hold together”. That does not happen in a pull request window, but it still happens, and the decision whether a change reaches production stays with a human.
Are unit tests still needed with AI
“Unit tests might die too. Why have training wheels if you never fall over? I’ve had models write 900 lines of Arduino C, compile it without a single error, and send it to the device, where the program ran perfectly. 900 lines will be nothing in the future.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we disagree.
The Arduino example is real and impressive. It proves something other than what the thesis suggests, though. A program that compiles and runs meets one criterion: it does something without crashing. It does not tell you whether it does what the author wanted for every input, or whether it will still do so after the next change.
On this site the most valuable tests turned out to be the ones that check the build output, not the source code. Gates that run on the dist directory count H1 headings on every page, check that no Markdown marker leaked out as text, and check that structured data matches the canonical URL. These gates caught regressions in changes that compiled without a single warning. The compiler does not know a page was supposed to have one H1 and now has two.
A test is not a training wheel. It records an expectation in a form a machine checks on every later change, including one an agent makes six months from now. The more code models write, the more that record pays off, because no human will read everything they generated. What changes is the level of testing: fewer tests of a single function, more tests of how the whole system behaves and what it outputs.
Should I still learn to code in 2027
“The craft of writing code will disappear. Yes, there are still Italian shoe makers around. But look at your feet.”
“The craft of building software will be more important than ever. Knowing how to solve business problems with software, how other software did it and why and why not, when and how to ship it, how to get feedback on it — that’s the new game.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree with the first thesis and fully agree with the second.
Writing code line by line really is losing weight. In our pipeline agents write content, fixes and helper scripts faster than any of us. But to judge whether MCP server code calls an API that exists, someone has to be able to read that code and know where to check the SDK. Reading code does not disappear along with writing it. The shoemaker in Ball’s metaphor no longer has to stitch the shoes, but someone still has to notice that the sole is glued on crooked.
The second thesis is the sharpest sentence in the whole note. Knowing what to build, how to split it, when to ship and how to measure the effect is the bottleneck today. Our repository has a separate document of product principles for exactly this, and it opens with the point that the problem is no longer “how to implement it” but “what should exist in the first place”.
So our answer to whether to learn to code: learn to build software, and treat writing code as the way to understand what an agent produces. We cover whether AI will take work from web developers in will AI replace WordPress developers, and working with agents in a team in the article on agentic engineering.
AI coding bugs often come from the wrong request
“Most bugs won’t be ‘coding’ bugs. They’ll be ‘you asked for the wrong thing’ bugs.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we agree.
Our most expensive lesson confirms this one. Earlier batches of agent tasks asked for articles to be expanded to a set word count. The agents did exactly what they were told: they added text that raised the counter and added no substance. The script code was flawless. The request was wrong. Today a repository rule bans scripts that pad content to a word count, and a separate gate catches repeated blocks of filler.
The invented case study with the 23 percent result shows the same mechanism. The agent was told to “add a section based on sources” and was given a source that was only the title of a talk. The model filled the gap with a number. The request never said what to do when the source is too thin.
The practical takeaway: most of the time spent working with agents now goes into writing the task, meaning a description of what the output is, what is forbidden and what to do when data is missing. That is a specification, just shorter and written more often than before.
Will open source survive AI
“Open source in it’s current form doesn’t make sense anymore. ‘Given enough eyeballs, all bugs are shallow’ is still true but now we have artificial eyeballs.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we disagree.
Ball refers to Linus’s law, as formulated by Eric S. Raymond: with enough participants, bugs are found quickly. The thesis is that if models can look at code instead of people, the open contribution model loses its point.
Data from one of the most important open source projects shows the opposite effect. Daniel Stenberg, the author of curl, ended the project’s bug bounty programme on 31 January 2026. Since 2019 the programme had produced 87 confirmed vulnerabilities and over USD 100,000 in rewards for researchers. According to Stenberg, in earlier years over 15 percent of reports turned out to be real vulnerabilities, and from 2025 the share fell below 5 percent under a flood of AI-generated reports. Not even one in twenty was real.
Artificial eyeballs exist, but in this form they produce reports rather than fixes, and they load the same human maintainers who were supposed to benefit. So open source changes its intake filters, not its principle. WordPress, which we work on every day, still lives on open code and on the people who decide what goes into core. That choice does not disappear when there is more code. It gets more important.
Does code performance still matter with AI
“Performance critical contributions by humans will stay what they are: an edge case. In 99% of software it does not matter that you could’ve written a faster algorithm or picked a better data structure. […] When it matters, the models can fix it.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree.
The first part is hard to argue with. Most code is not a bottleneck and never will be. The dispute is about “the models can fix it”. A model will fix performance if someone knows where it leaks. In our build the trouble was not in an algorithm someone could have written better, but in a step nobody thought about until we measured how long each stage took. A human did the measuring; a model could then write the fix.
In WordPress work it looks similar: a slow store rarely has one bad algorithm. It has too many plugins, queries without an index, or caching set up in the wrong place. Deciding what to remove takes an understanding of the client’s business, not just a profiler.
Will AI agents kill the terminal
“The terminal is dead. Most developer tooling will be washed away by tokens. Shells, text editors, CLI tools won’t be used by humans anymore.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we disagree, although we understand where the thesis comes from.
Ball notes that he writes this as someone who loves the terminal. He is right that people remember jq flags less and less. Our pipeline shows, though, that the terminal does not disappear, it changes users. Agents work in the shell: they run npm run gates:run, read files, call git. Every gate that catches their mistakes is a command-line script.
The terminal becomes the interface for agents and for the human who checks what an agent did. When a reviewer reports an error, the fastest way to verify it is a single grep on the file. People type fewer commands, but they read more of them.
Tokens as the new computing paradigm explained
“Tokens are the new computing paradigm. Everything will be re-made on top of it. […] We’re entering the post-binary era.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree.
Ball observes that for 80 years we have had deterministic computers, and we confuse how they worked with how they must work. That is a fair point. Our experience adds one caveat: the more work non-deterministic models do, the more valuable the deterministic gates around them become.
In our pipeline an agent can write the same sentence ten different ways, but the gate counts headings the same way every time. The combination works: the model generates, the script checks. The post-binary era, if it comes, will stand on a binary foundation of control. We find it hard to picture a responsible deployment in which a model checks itself without a hard criterion.
Will AI replace product managers and designers
“The triad of PM/Design/Eng will disappear. […] ‘Engineers’ who act as ‘meat proxies’ and shove tickets into agents and report back to humans will no longer be valuable.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree.
The “meat proxies” point is accurate. A role that consists only of passing tasks between a human and an agent has no value, because the agent will take the task directly. In our pipeline there is no intermediary between the owner and the agents.
The decisions the triad used to share do not disappear along with the split of roles, though. Someone still has to decide what we build and what we do not, what the interface should look like and whether a change is ready. For us those decisions concentrated in one person rather than dissolving. It is more a merging of roles in one head than their end. That sets a requirement: the person running the agents needs skills from all three areas.
AI in small companies vs big tech
“The difference between software engineering at large corporations and small ones will increase.”
“Some people will be priced out of producing software. […] if you can’t get enough tokens, you’re playing second league. You need to get to the tokens.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree with both theses.
Ball writes that startups copying Google’s practices will look even sillier, because they can build faster and with fewer constraints. From a small team’s perspective that is true: our agent pipeline has no architecture committee, and a wave of changes across dozens of files goes through in a day. But what protects us from errors is exactly the practice known from large companies: automated gates, independent review, a single owner of decisions. A small company can drop process, but not control.
On token costs: access to strong models does cost money, and that cost grows with the number of parallel agents. The dividing line, however, does not run between rich and poor, but between those who can turn tokens into a verified result and those who pay for text that gets thrown away. Filler written for a word counter also cost tokens.
Cheap vs smart AI models for coding
“It’s questionable whether cheaper models will be used. […] a smarter model makes less mistakes, needs fewer turns. When do you really think ‘I’m okay with it being wrong a few times?’”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we agree.
Our pipeline has this rule written into the repository instructions. The agent that writes prose and translations runs on the default, stronger model. A cheaper model handles only read-only reviews, and every finding it reports is checked in the file before anyone makes a fix.
This split answers Ball’s question directly. A cheap model is acceptable where a mistake costs one check. Where a mistake lands in production text in six languages, saving on tokens turns into longer review and more fixes. What counts is the cost of the whole cycle, not the price of a single call.
Does clean code matter with AI
“There’s no proof that ‘good code’ will matter in the future. The notion of ‘good code’ itself is mostly based on the idea that it’s easy/cheap/efficient for humans to work with. But humans won’t modify the majority of code.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we partly agree.
An 80-column width really does not matter to an agent. Some “clean code” principles will survive, though, for a reason other than human comfort: code has to be checkable. Our gates work only because the output has a predictable structure. Frontmatter with a clear field contract, one owner for each identifier in structured data, one function that builds a service URL. When two places in the code emitted the same schema identifier, the problem was not ugliness, it was that no gate knew which of them was the source of truth.
“Good code” stops meaning “pleasant to read”. It starts meaning “code whose correctness can be verified automatically”. That is a shift, not an end.
AI generated UI on the fly
“Models will become so fast that UI will be generated on the fly. A lot of UI exists because software can’t understand what you want.”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we have no data that confirms or refutes this thesis.
Ball writes that menus, settings screens, dashboards and filters are largely an interface for a human talking to a “dumb machine”. The observation is interesting. We do not generate interfaces on the fly, and we have no measurement that would let us judge how such an interface handles accessibility, predictability and user trust. We would rather say so than guess.
One observation from our own work: users of the sites we build still expect a button to be in the same place on their second visit. An interface that changes on every visit would have to meet that need somehow.
How long will AI take to change software development
“It’ll take a generation for the ‘new software’ to replace the ‘old software’. […] there will be people employed to write code in 10 years. But do you want to have that job?”
(Thorsten Ball, post on X, 19 September 2026)
Verdict: we agree.
Even measuring how much AI gives developers turns out to be hard. In 2025 METR ran a randomised controlled study with experienced open source developers working in their own repositories. With AI tools, tasks took them 19 percent longer. In February 2026 METR described a second study: for developers from the first round, the estimated change in task time was minus 18 percent (confidence interval from minus 38 to plus 9 percent), and for new participants minus 4 percent. METR itself, however, called this data an unreliable signal, because more and more developers declined to take part since they did not want to work without AI.
That is a good picture of the transition period: the tools are already so embedded in the work that a control group is hard to find, and at the same time there is no hard number for what they deliver. A generation is a reasonable timescale for a change like this. We leave Ball’s closing question to the reader.
What this means for companies buying software
From the 16 theses we draw four practical conclusions for companies that commission websites, stores and integrations.
- Ask who reviews the claims and how, not just the code. AI-generated code compiles correctly. The errors sit in facts, regulation article numbers, API names and business assumptions.
- Require automated gates on the output. A test that checks the built page or how an integration behaves will catch a regression that is invisible in the source code.
- Invest in the task description. Most bugs are bad requests. A good specification costs less than fixes.
- Do not save on the model where the output reaches production. A cheap model for review with verification, a strong model where content or code gets written.
If you have a site or app built quickly with AI and do not know what is inside it, we handle AI-built website rescue. If you want to bring agents into your own processes with the kind of control described above, see AI implementation and MCP server development. For the wider background on why AI gains arrive more slowly than vendors promise, read our piece on the AI productivity paradox.
Last updated: 15 October 2026
