Benedict Evans’s recent essay, “AI Tools and Transformation”, takes issue with a prediction that resurfaces with every generation of developer tooling: that the new tools will make everyone a software builder, and that traditional software development will consequently become optional. Evans argues the opposite — the mechanism of software creation is changing, but the function of software and the judgment required to deliver it reliably are not.
He’s right. And the history of the last thirty years of tooling makes the case more plainly than the theory alone.
sequenceDiagram
participant Wave as Abstraction Wave
participant Pred as The Prediction
participant Out as What Actually Happened
Note over Wave: Visual Basic / RAD (1990s)
Wave->>Pred: Anyone can build software
Pred-->>Out: Developer demand rose
Note over Wave: No-code / Low-code (2010s)
Wave->>Pred: Developers are optional
Pred-->>Out: Developer shortage worsened
Note over Wave: AI coding tools (2020s)
Wave->>Pred: Everyone will build apps
Pred-->>Out: Systems judgment stays the constraint
The rundown
Evans published his piece on September 3, 2026, reacting to a cluster of predictions circulating around AI coding tools — the “everyone will build their own apps” thesis that has gained traction as tools like Cursor, GitHub Copilot, and similar environments have demonstrated real productivity gains for developers.
His argument is structural: software systems are not just code. They are integrations, data models, state management, failure handling, security posture, and evolution over time. The people who have always built and maintained software have done so not primarily because they could write the code, but because they understood the system — what happens when two components behave unexpectedly together, how a data model constrains what you can build three years from now, where a well-meaning shortcut becomes a multi-year remediation project. That judgment does not migrate to non-technical users just because the syntax layer becomes more accessible.
What Evans doesn’t say directly, but what the historical record supports: every abstraction wave has come with the same prediction. Visual Basic made GUI applications accessible to non-specialists in the 1990s. No-code platforms promised developer-free business applications in the 2010s. Each wave genuinely expanded who could do something. None of them shifted the core work away from people who understood systems.
For engineers: the abstraction layer moves up, the judgment stays with you
The immediate effect of AI coding tools on individual engineers is real and large. Boilerplate takes seconds instead of hours. Scaffolding that would have required an afternoon happens in a prompt. That’s not marginal — it’s a significant productivity shift, and engineers who learn to use these tools well are producing at a different level than those who don’t.
But here’s what doesn’t change: the questions that determine whether the software actually works. Where does state live? How does this interact with the existing authentication layer? What happens when the third-party API is down? What does this schema imply for data migration two years from now when requirements change?
Those questions require someone who understands the system. AI tools can help answer them — increasingly so — but they don’t eliminate the need for someone who can evaluate the answers. The leverage shifts upward: an individual engineer can now do what required a small team. The judgment required at each decision point doesn’t get cheaper.
For engineers, the practical implication is that the skills that become more valuable are not the syntactic ones. Architecture, integration design, technical leadership, and the ability to think about systems across time — those are now the scarce part of the work.
For business owners: don’t restructure around a prediction that hasn’t cleared the historical bar
The strategic risk for business owners is misallocating based on a prediction that hasn’t proved out across multiple prior generations of tooling.
If your planning assumption is that AI will let non-technical staff replace your engineering team — or substantially shrink it — you should know that this prediction has been made before, with Visual Basic, with RAD tools, with no-code platforms, and it has been consistently wrong in proportion to how ambitious the scope was. Simple tools got democratized. Complex systems stayed technical.
That doesn’t mean AI changes nothing. The realistic version: AI genuinely lowers the cost of building simple tools, internal dashboards, lightweight automations, and proof-of-concept applications. If those categories have been out of reach because of development cost, that changes. The non-realistic version: that this scales to the complexity of the systems your business runs on.
The smart planning assumption is to expect the same pattern as prior abstraction waves — genuine expansion at the simpler end, unchanged demand for technical judgment at the complex end — and to evaluate tool investments against that baseline rather than against the ambitious prediction.
My take
I worked as a contract enterprise architect at First American Title for two years beginning in 2009. At the time, the company had acquired more than 80 businesses over the previous decade and accumulated over 770 applications across 15 subsidiaries. They had 900 engineers and were stewards of what was then the world’s largest SQL Server database — roughly 850 million rows representing 100 million U.S. homes.
The number that stayed with me: 770 applications. This was after years of enterprise architecture investment, consolidation efforts, and tooling improvements. Every generation of better tooling had not reduced the application count — it had enabled more building. The constraint on software complexity was never the cost of writing code. It was the judgment required to design systems that integrate, scale, and hold up over time.
As part of my work there, I built the wall-sized enterprise technology roadmap that revealed the full integration picture across those 700+ applications and 8 business units. What that map made visible was not a code problem. It was a systems-judgment problem — decades of decisions about what to build, what to acquire, what to integrate, and what to let persist independently. Better syntax tools had been available the entire time. The complexity had accumulated anyway, because the constraint was always the quality of the architectural decisions, not the speed of the implementation.
Evans is describing something I saw in concentrated form there: as tools get better, the demand for technical judgment doesn’t go down. It intensifies. More applications meant more integration decisions, more questions about what was canonical and what was redundant, more architectural choices that compounded over time. The engineers in high demand were not the ones who could write code fastest. They were the ones who could think about systems across time.
The “everyone is a developer” prediction misunderstands what was ever hard about software in the first place. Writing the code was not the hard part.
