In AI, tools and transformation, published September 3, 2026, Benedict Evans argues directly against a prediction that has settled into conventional wisdom in enterprise AI conversations: that AI will make everyone a software builder and render traditional applications obsolete. His argument is that this thesis misunderstands both how most people think and where software actually comes from.
He is right. And the way he is right has real consequences for how companies should be planning their software strategy now.
mindmap
root((Software in the AI era))
Non-technical users
Configure existing tools
Prompt-driven automations
AI-assisted forms
Power users
No-code integrations
AI-scripted one-offs
Software engineers
Custom applications
System integrations
Architecture decisions
The gap that stays
Data contracts
Failure mode design
Production reliability
The rundown
Evans’s essay makes two connected claims. First: most people do not want to build software — they want software that works. The creative and organizational effort required to define what a piece of software should do, handle all the edge cases, and maintain it over time does not disappear because AI can write the implementation. Second: the “apps are dead” prediction conflates the mechanism of software creation with the function it serves. The function — managing processes, storing and retrieving information, automating workflows — is not going away. What changes is how those applications get built and by whom.
This is a different argument from “AI will not affect software.” It is an argument about the realistic distribution of who will use these tools and what they will accomplish with them. The distribution shifts, but it does not flatten.
For the working software engineer
The “everyone is a developer now” narrative, taken seriously, implies that software engineering as a profession has a short shelf life. Evans’s analysis points in a different direction: the skills that remain scarce are the ones that require understanding what software should do in context, how systems interact, and what fails at scale.
Writing code is becoming less of a bottleneck. Understanding which code to write, in which architecture, for which users, with which error modes — that is not getting easier because AI can write the implementation. Those judgment calls still require someone with technical depth and systems context. The profile of what engineers spend their time on is shifting. The need for people who can exercise that judgment is not going away.
The engineers who will thrive in this environment are the ones who invest in specification, integration thinking, and architectural decision-making — not the ones who optimize for implementation speed. Speed is no longer the scarce resource.
For business owners and operators
The practical consequence of Evans’s argument: do not plan your technology strategy around the assumption that AI will allow non-technical employees to build the internal tools you need. That may happen at the margin — simple automations, single-purpose integrations with bounded failure modes — but it is not a replacement for a software strategy.
The more grounded expectation is that your existing tools will become more configurable, your processes more automatable within those tools, and the gap between “has software support” and “doesn’t” will narrow at the edges. Plan for augmentation of your existing applications and processes. Plan for the boundary between “business user can configure this” and “technical person must build this” to shift — but not to disappear.
Companies that plan for the disappearance of that boundary are going to be disappointed. The organizations that will be ahead are the ones that invest in the technical people who operate near that boundary — the ones who can make the judgment calls about what gets configured, what gets bought, and what genuinely has to be built.
My take
I have watched versions of this prediction cycle through the industry for decades. In the early 2000s, rapid application development tools and the no-code movement claimed similar territory: the right platforms would make professional developers unnecessary for most business software. What actually happened: the boundary of what non-developers could configure moved outward, the total demand for software kept growing faster than anyone projected, and the core building remained with technical people. The prediction was right about the tools; it was wrong about who would use them and what they would build.
The First American Title engagement is the clearest illustration I have seen of what software complexity looks like at scale. Nine hundred engineers, seven hundred applications, fifteen-plus subsidiaries — accumulated through eighty-plus acquisitions. The problem was not that no one could write code. Everyone could write code. The problem was understanding what all that code did, where it overlapped, which systems depended on which others, and how to consolidate without breaking the business. That is a knowledge and judgment problem, not an implementation problem. AI tools do not solve it.
When I personally investigated the data architecture behind a potential $100 million acquisition during that engagement, the analysis that led the company to walk away was not a code-generation task. It was the kind of contextual assessment — what does this system actually do, what are its structural dependencies, what would integration really cost — that requires someone who has built and broken systems in production and knows where to look. That work gets more important as the volume of AI-generated code grows, not less.
Evans’s argument lands because it distinguishes between the mechanism and the function. The mechanism of software creation is changing rapidly. The function — building systems that reliably do specific things for specific users in specific contexts — has not changed at all, and the judgment required to get that function right remains as scarce as it has ever been.
