Who we build software for in the age of AI

Little by little, we are giving less weight to the fact that we use artificial intelligence to write code. By now it is almost like announcing that we have electricity in the office: it is there, it is taken for granted, and saying it out loud no longer impresses anyone. What is interesting is no longer how we build software, but who we build it for.

And that “who” has just changed, and it makes all the difference in how your software will be used in the future. A second user has appeared, and it is not your customer, at least not your “human” customer.

For decades we designed products for the same thing: a person in front of a screen, with their mouse and their willingness. Phones and tablets arrived and we swapped the mouse for a finger, but the underlying script did not change: on the other side there was always a human looking at a screen. That user is still there. What is new is that they now have company: an artificial intelligence agent that wants to use your product with no screen, no mouse, and without anyone explaining anything to it.

And if your application only knows how to communicate through its visual interface, that second user is left at the door.

AI-first is not slapping a chat onto things

It is worth clarifying, because “AI-first” has become a sticker that many slap on top of the usual thing. They add a chatbot in a corner, call it a revolution, and move on. For us, AI-first is something far less flashy and far more profound: taking artificial intelligence into account from the design of the architecture, not at the end.

It means designing the core first (the business logic and the data) and treating the visual interface as just one of the ways to reach that core, not the only one. And you do not have to take our word for it: just look at where the big players are heading. Salesforce is a textbook example. In 2024 it launched Agentforce, its agent platform, but the really big move came afterwards: it is redesigning the whole house so that those agents operate the CRM on their own. It even published, in late 2025, a benchmark to measure how well they manage to do it through clicks and screens, just like a person. The result? Even the best agents fail more than half the time when they have to wrestle with a visual interface. The conclusion is clear: if you want an agent to work, you cannot sit it in front of your screen. Give it access to the logic underneath.

There is one signal that sums it up better than any other. In late 2024, Anthropic published an open protocol, MCP (Model Context Protocol), so that agents can talk to any tool. In less than six months it was also adopted by OpenAI, Google, and Microsoft. Four companies that compete fiercely agreeing this quickly is not something that happens often.

Three foundations we lay from the start

When we say “from the architecture”, it is not just talk. There are three pieces we try to put in place from the ground up, not patch in later.

The first is a well-documented API. It is the product’s contract: what you can ask for, what you get back, and under which rules. If it is explained well, it does not matter who knocks at the door (a person, another service, or an agent): everyone speaks the same language. An API without documentation is a conversation in the dark.

The second is a command-line interface, a CLI.

The CLI is a fairly old way of talking to an application: you open a terminal (that black screen from hacker movies), type a command, press enter, and that is it. We considered it retired when windows and the mouse came along, but it turns out it suits AI agents like a glove.

It sounds retro, we know, but it is exactly the opposite. Anything a human can do by typing a command, an agent can automate just the same. The trick is for it to speak two languages at once: a human-readable output for people and a structured one, in JSON, for machines. Same command, two readers.

The third, which we are working on right now, is the MCP we mentioned earlier. It is the native door for an agent to use your product as just another tool, without having to guess how it works. Instead of explaining to the AI what your API looks like, you give it a protocol it already understands.

We are not going to pretend we have this figured out: we are in the middle of building it, learning as we raise it. But we are absolutely clear that this is where the road leads.

What this looks like in a real project

All of this sounds very nice in an article. The honest question is whether we only preach it or we are already using it. Right now we are putting it into practice in a large project for a client, a management platform with plenty of road ahead.

Without getting into the guts of it, the order of things says everything: we start with the core and with an API that exposes it clearly, we build a CLI to operate it without touching the interface, we put artificial intelligence inside the product (not as decoration, but for real tasks: digesting information that arrives in all kinds of formats, suggesting decisions based on the history) and we keep the technical documentation alive, like a knowledge base that humans and agents consult alike. The next milestone is precisely opening that native MCP door. It is not finished. But it will be soon, and with it the project will speak the language of the future from day one.

Building today for the user who arrives tomorrow

Building this way costs a bit more at the start, we will not deny it. It is always more comfortable to set up the pretty screen and leave the rest for later. But “later” has the nasty habit of turning into “redoing the whole thing”. And that second user, the agent that wants to operate your product on its own, is going to show up sooner than you think. We prefer to be caught with the table already set.

If you have a product and you keep wondering how to prepare it for the future, or you simply want someone to tell you where to start without any fluff, write to us. It could be the beginning of an interesting conversation (and one of those that no chatbot is going to handle for you).