It has been a while since my last post. A lot has happened. Becoming a father was a major change for one – and while I had taken a well-earned break to embrace some of the finest experiences that life has to offer, the world moved on. AI continues to reshape the software industry in ways that are both obvious and somehow both overemphasized and deeply underappreciated. Engineers and tech leaders everywhere are trying to work out what it means for them. For the last year I’ve been making my own predictions about how AI is going to impact software architectures. A futile endeavor, I’ll admit it. But a fun one.
My perspective has evolved. Some of it. The underlying principles, though – those have held firm.
Programming Becomes a Commodity
My audience doesn’t need a primer on how capable AI has become at writing code. That’s the given. What I want to examine is what it means, not for how we write software today, but for how we think about software as a discipline.
For as long as software has existed, programming has been a scarce and specialized skill. It is the act of translating human intent into machine behavior, and it has always required a particular kind of person who could live fluently on both sides of that translation. That scarcity shaped everything: how products get built, how organizations are structured, how decisions get made, how long things take.
When programming becomes a commodity, the entire logic of application development changes. Not gradually. Fundamentally.
We’re not there yet. But we’re closer than most architectural thinking has caught up to.
The natural instinct, and the one you see most commonly in the industry right now, is to apply AI as acceleration. Take what you already do, identify where AI can speed it up, weave it in. Stand up data initiatives to support it. Maybe go further and orchestrate agents end-to-end. This is valuable. It is also, I’d argue, the conservative reading of what’s possible.
The more disruptive reading goes like this: if programming itself is becoming cheap and abundant, then the ability to invoke programming becomes a feature. Not a role. Not a team. A feature – one that can be embedded into any system and offered to any user.
That’s the shift I want to talk about.
The Shape of What Survives
Before going further, it’s worth being precise about what commoditizing programming doesn’t mean. It doesn’t mean the end of software engineering as a discipline, or that traditional code disappears.
The systems that will matter most are those defined by their scale and the depth of their infrastructure, not by the flexibility of their interfaces.
Think about it this way: a payments network, a logistics platform, a data fabric at enterprise scale – these systems derive their value from reliability, reach, and the accumulated weight of what they can do. That core doesn’t become ephemeral. If anything, it becomes more valuable, because everything built on top of it can now be constructed and reconstructed continuously.
What does become ephemeral is everything at the periphery. The interfaces. The workflows. The micro-automations. The bespoke tools a specific team uses to interact with a specific capability. Today we build those things on quarterly roadmaps. We prioritize them in backlogs. We staff them with engineers.
In the near future, those things get assembled on demand, shaped by the people who actually need them.
Shifting Programming Left
A lot has been written about AI agents building software. About engineers becoming shepherds of automated systems, guiding context, reviewing outputs. It’s a compelling vision. It’s also, I think, missing the more interesting conversation entirely.
We have spent decades accepting a fundamental inefficiency as if it were a law of nature: the gap between the people who need software to do something and the people who build it. The PM in the middle, the backlog, the sprint cycle, the delivery, the “that’s not quite what I meant” – all of it. We’ve built entire methodologies around managing this gap rather than closing it.
The canyon between IT and business doesn’t have to be a permanent feature of the landscape. For the first time, we actually have the tools to close it, not with more process, but by moving the ability to define behavior closer to the people who understand what behavior they need.
What if we closed it?
I’m not talking about low-code tools or drag-and-drop builders. Something more fundamental: shifting programming itself all the way left to the user.
Traditional software gives users a fixed interface to a fixed set of capabilities. The shape of the product is determined long before the user ever touches it. The gap is structural.
The systems of tomorrow are not the ones where users consume capabilities and shape their experience. A user notices they run the same five-step workflow every day. Instead of filing a feature request (that may surfaces six months from now), they describe the workflow to the AI agent that they use on a regular basis. They go back and forth together and come up with ideas for automation. To make it real, this agent can interface with other agents. A planning agent that understands the larger system behind the scenes like what’s possible, what’s constrained, what already exists can work with the user to satisfy that need. The resulting automation gets encoded. It runs repeatedly. It becomes part of their personalized experience of the product.
That’s programming. The user just did it without writing a line of code.
The feedback loop changes completely. You get immediate response: here’s what’s possible, here’s what isn’t, here’s why. A planning agent that understands the full context of the system can tell you no with useful specificity, or offer a better version of what you asked for.
What Has to Be True
There are a few things that have to hold for this to work, and I want to be specific because I see too many people skip this part.
Traditional code is not going away. Reliable, repeatable, cheap execution of well-defined functions is still best served by traditional code. What changes is where the boundaries of that code sit and who gets to push on them.
Don’t build your own chat interface. This is a trap. Chat is its own sophisticated discipline. The reason people have strong preferences between Claude, ChatGPT, and Gemini has everything to do with years of nuanced design. Think of these platforms the way you once thought of browsers or operating systems. It’s infrastructure you build on top of, not something you compete with.
Expose your system with the right standards. MCP matters here. Not just for connecting data, but for exposing curated capabilities and even interface fragments that agents can work with. Agent-to-agent protocols like Agent2Agent matter too. The systems that win in this world will be the ones legible to agents that expose themselves in ways that make composition natural.
The product isn’t the fixed interface anymore. The product is the capability surface or what the system can do and the layer on top that lets users shape how that surface meets their specific needs.
The periphery becomes ephemeral. The core becomes more essential than ever. And the act of programming, that is of translating intent into behavior, moves from a specialized team to the edge of the system, where the user lives.
I don’t think enough people building systems today are thinking about what that means for their architecture. They should be.
Leave a Reply