Photo by Karola G: https://www.pexels.com/it-it/foto/6229/
A few nights ago I read an article. It’s called The Death of Software 2.0 and uses a metaphor that stuck with me: it compares the software of the future to a computer’s memory hierarchy. Fast, ephemeral memory—what we call DRAM—would be artificial intelligence processing non-deterministically. Persistent memory—NAND—would be structured data, APIs, what we call the single source of truth. The author’s conclusion is brutal: interface-oriented software is becoming obsolete. What will have value is the data and the APIs through which AI agents access systems.
Reading that piece, something clicked in my head. Not because it was a fascinating theory. Because it described exactly what I’m starting to do in my work, what I feel necessary to do, even if a part of me still resists.
I’ve spent fifteen years building software with a simple value logic: interface first, API second. From the client’s point of view the UI was the product, the API was an add-on, a complement for integrators, something to document when there was time left over. That model worked because software had to be used by people. Now it isn’t, or at least it isn’t only that.
Agents Don’t Click
Claude, ChatGPT, Gemini, AI agents, agentic tools in general—they don’t use software the way a human does. They don’t click buttons. They don’t follow UX flows. They don’t get confused by the seventeen edge cases in the checkout form I spent weeks handling. They need three things: structured data accessible via well-designed APIs, persistent context they can grasp in a conversation, deterministic and repeatable actions they can orchestrate without errors. If the product you’re building isn’t designed around those three pillars, you’re building it for 2015.
And here I have to be honest with myself. For years I poured my soul into interfaces. I argued for hours about the right colour for a button, about how to organise a menu, about which microinteraction would make the experience smoother. It wasn’t wasted time, far from me to say that. But I wonder whether I wasn’t building cathedrals on foundations that were already starting to tremble.
MCP as the Bridge
The Model Context Protocol is the standard Anthropic released in November 2024. OpenAI and Google adopted it immediately. It’s the standardised bridge between an artificial intelligence and enterprise systems. Until now, every AI integration was a custom project: raw API calls inside the app, fragile RAG pipelines, bespoke tool calling, no reusability, no governance. With MCP the paradigm changes. You expose your system as an MCP server. The AI consumes it as a standardised client. You authenticate once. You govern once. You monitor once.
That isn’t a small thing. It’s the equivalent of how HTTP standardised communication on the web in the 1990s. And like HTTP, it will change everything without most people noticing.
The Flow Rewritten
Let me try to imagine what it would actually mean for the clients I work with.
Today the flow is this: the client opens the UI, clicks for eight or ten different actions, exports data to CSV, pastes it into another app, gets the result. It’s a process that works, that we’ve optimised over years, that clients know. But it’s also a process that takes time, attention, specific competence on how that particular software works.
The future flow could be this: the client talks to Claude/ChatGPT/Gemini/whatever and says “process this data and give me the report”. Claude connects directly to the system via MCP, reads the data, processes it, writes the result into the right table. All in ten seconds, no clicks. It isn’t AI that knows the software. It’s the software that becomes consumable by AI. And via tools everyone already uses daily.
Writing these words, I feel an internal resistance. Building interfaces was my work for years. There’s something human about designing an experience, about thinking how a person will interact with something you’ve created. There’s also, I have to admit, a form of control. When you design an interface, you decide the flow. You guide the user. You choose what they can and can’t do, in what order, with what constraints. Opening all of this to an AI agent means giving up that control. It means trusting the system will do the right thing even when you can’t predict exactly what the user will ask.
But maybe that’s the point. Maybe that control was always an illusion, a way to manage complexity by reducing options instead of really facing it.
The Governance Gap
The market data is clear. More than 80% of development teams already follow an API-first methodology. Estimates put active APIs at 1.7 billion in 2030, a 300% increase over the current baseline. API-first adopters see a 37% reduction in integration costs compared to traditional approaches. But the data point that struck me most: Gartner estimates that more than 40% of agentic AI projects will be cancelled by 2027 if they don’t have solid governance.
Here’s where everything gets complicated, where the technological vision collides with operational reality. MCP today has important gaps. There’s no authentication standard: every implementation is different. Sandboxing is weak: if an agent takes control, where do you stop it? There are prompt-injection risks: how do you guarantee the AI isn’t manipulated into doing unwanted actions? And there are auditing gaps: how do you trace who did what and when?
The European Commission and European central banks are already pushing toward APIs that are transparent, controllable, auditable. It isn’t only a technical choice. It’s a regulatory survival choice. And here a territory opens up that I know well, the balancing act between innovation and compliance, between what you could do and what you should do.
I often find myself reflecting on this balance. On one side there’s the push to move fast, to adopt new technologies before competitors, to be the first to offer clients something they didn’t even know they wanted. On the other there’s responsibility to those clients, to their data, to long-term sustainability. They aren’t always in conflict, but sometimes they are. And when they are, the choice is never obvious.
I’ve watched companies move too fast and burn client trust with AI implementations that weren’t ready. I’ve watched companies move too slowly and become irrelevant as the market shifted around them. The perfect trade-off doesn’t exist. What exists is the capacity to choose consciously, knowing what you’re sacrificing and why.
Value Doesn’t Live in the Work
What I’m exploring concretely is a backend layer that exposes client data as an MCP server. A set of instructions and configurations for AI that knows how to query that server. A governance interface where the client can decide what the AI can read and what it can’t, which actions it can perform and which it can’t. A complete audit trail that tracks every interaction, every decision, every error.
The result, if it works, is that the client won’t need us for three-quarters of repetitive tasks. They’ll need us to keep the system clean, to add new data sources, for governance and compliance, for problems that require human judgement. It’s a relationship shift: from doing the work to making the work automatable.
I write this sentence and realise how radical it is. I’m thinking about something that will reduce the amount of work clients ask me to do. From a short-term revenue point of view, it’s madness. From a long-term value point of view, I think it’s the only sensible road. Clients pay because of the love of paying? They pay because you have something they need. If we can give them the same value, or more, with less friction, why wouldn’t we? And if you don’t, someone else will.
There’s a phrase I keep saying to myself: value doesn’t sit in the work you do, it sits in the problem you solve. For years I measured my value in hours, deliverables, features released. Now I wonder if I shouldn’t measure it in problems eliminated, friction reduced, capacity returned to clients to do what they do best.
The window for this change is now, in 2026. MCP is standard, supported by the three main AI providers. Security gaps are being closed progressively. Clients are starting to understand they want something like “talk to ChatGPT and done”. Anyone who doesn’t move in this direction will be cut out. Not tomorrow. Now.
But “now” doesn’t mean “at any cost”. It doesn’t mean sacrificing data security for implementation speed. It doesn’t mean promising clients functionality that isn’t yet mature. It doesn’t mean ignoring regulation because it’s inconvenient. It means finding the way to move fast in the right direction, with eyes open about where you’re going.
The Builder’s Responsibility
There’s something that particularly stirs me when I think about all this. It isn’t the fear of getting things wrong technically. That’s there, but it’s manageable. It’s something deeper. It’s the awareness that the decisions we make today as software builders are defining the relationship people will have with technology tomorrow. Every API we expose, every piece of data we make accessible, every action we automate sets a precedent. Establishes what’s normal, what’s acceptable, what’s expected.
I think about our clients, people running companies, with employees, who in turn serve other clients. When I open their systems to AI, I’m changing how they work. Redefining which skills will be needed, which roles will make sense, how their day will be structured. It isn’t a responsibility to take lightly, and we have to expect a lot more resistance because what we offer isn’t software but a change—sometimes substantial—of internal roles and processes, and even of hierarchies.
But it’s also an extraordinary opportunity. The chance to free human time and energy for activities that really require intelligence, creativity, judgement. To reduce repetitive work that consumes people without adding value. To make small companies competitive with large ones, because access to automation will no longer be a question of budgeting for dedicated teams.
Maybe this is the fundamental trade-off. On one side the risk of building systems that escape control, create dependencies, concentrate power in the wrong hands. On the other the possibility of building something that genuinely helps people work better, live better, spend their time on what matters.
And I have the conviction that staying still isn’t an option, and the determination to move in the direction that seems right, one step at a time, with eyes open.
So this is what I’m doing.
If you recognise this trajectory and want to talk about where it could lead, let’s talk.
Key takeaways
The control interfaces gave was always an illusion: a way to manage complexity by reducing options instead of facing it.
MCP has serious gaps—authentication, sandboxing, audit—and Gartner estimates 40% of agentic projects will be cancelled by 2027 without solid governance.
Value doesn’t live in the work you do, it lives in the problem you solve: measure yourself in problems eliminated, not in hours billed.
Questions & answers
What is the move from Software 2.0 to Software 3.0?
Software 1.0 was hand-written code. Software 2.0 (Karpathy’s term) was neural models trained on data: the implicit program lives in weights, not in lines. Software 3.0 is the next move: you don’t train a dedicated model, you instruct a general-purpose foundation model via prompts and orchestration. Logic shifts from code to weights to context—with radical consequences for the software lifecycle.
Why does this shift "transform us", as the title says?
Because it changes what “developing” means. In Software 1.0 the skill was translating requirements into algorithms. In Software 2.0 it was collecting and labelling data. In Software 3.0 it’s writing contextual instructions (prompts, tool definitions, retrieval) for models that already exist. It isn’t just a new tool, it’s a different craft that requires a different form of thinking—closer to editing/prompting than to coding.
What does it mean for companies that have invested in Software 2.0?
It means many custom ML projects built in the last five years now compete with foundation-model solutions that do the same with a tenth of the effort. This doesn’t retroactively invalidate the investment, but it does invalidate many future roadmaps. Many ML engineering teams will have to reassess where their IP is defensible: on proprietary data, on custom models, or on orchestration?
What does a developer need to learn today to be relevant in two years?
Not so much a new language as a new abstraction level: contexts, prompts, evaluation, tool use, retrieval-augmented reasoning. The integration code between these pieces is often simple; the challenge is in the design of the pipelines and rigorous evaluation. Those who stop at Software 1.0/2.0 stay specialists in shrinking niches. Those who add Software 3.0 move where demand grows.
The author
