The Future of AI — part 2
You are not writing code; you are shaping the agent's search through the space of solutions it already knows. One prompt at a time.
A few months after part 1, I read this piece in The Verge on the AI coding wars between OpenAI, Google and Anthropic, and realised the argument I was making there is no longer niche. The shape of the “make or buy” decision is moving again, and more people are saying it out loud.
That is worth a short follow-up.
The argument isn’t mine anymore — good
In part 1, published in mid-November 2025, I claimed that AI was pushing the make-or-buy line back toward make: custom software gets cheaper, SaaS’s structural advantage shrinks, integration becomes the real bottleneck. At the time it felt like a contrarian take.
A month later, Martin Alderson published AI agents are starting to eat SaaS (December 2025), making the same argument more crisply than I did:
The calculus on build vs buy is starting to change. Software ate the world. Agents are going to eat SaaS.
A month after that, AI Agents Are Starting To Eat SaaS (Really) landed with the consumer-facing version of the same point:
I’d rather spend 30 minutes building something personalized to my needs than pay $4.99 every month for a generic solution.
The Verge piece — and the direction the top three labs are pointing their coding products — says the same thing from yet another angle.
I am not claiming I saw it first. I am claiming I saw it early. The argument is now common enough that it is no longer mine to defend alone, and that is progress.
If you know of other good sources making this case from inside enterprises (not just from vendors), please send them to me. I want to stress-test the argument, not just collect agreement.
Sonnet 4.6 is a landmark
Claude Sonnet 4.6 is different. Past generations of AI coding were useful in narrow places — re-engineering an algorithm, untangling a regex, suggesting the next line. Helpful, but local. What is new is that the model is now strong enough to take on several parts of the job at once: the documentation-level knowledge of whatever stack you are in, most of the actual typing, and a reasonable first pass at picking the right pattern for the problem. That is a different kind of help.
When you write software, the work is really four things mixed together: domain and side-effect knowledge (what the business and the users actually need), tech-stack knowledge (the APIs, quirks, and corner cases), approach knowledge (which pattern fits this problem), and the typing itself. The first is the human’s, and stays the human’s — the agent has never met your users. The second the agent has decisively won; no human keeps that much detail loaded at once. The third and fourth it can now do most of, given the right framing. I still keep my hands in code — pet projects on evenings and weekends, because I genuinely enjoy it — and I watch the same pattern play out in the engineering teams I work with at the day job: the shape of the day changes.
You are not writing code; you are shaping the agent’s search through the space of solutions it already knows. One prompt at a time.
That is not “more productive.” That is a different mode of working. I will unpack the four-way split in a later post.
The full post continues with two more sections: The next shift: prompts replace code (with two concrete examples and a Simon Willison provocation) and We’ve seen this movie before (from the Vic-20 to today, with a question about the junior-senior pipeline nobody has answered yet).