What does the future of software look like?

How AI is changing both how software is built and what software does?

If we look things from first-principles, given the pressures that are actually acting on software right now: let's consider what the software end game must look like. If the reasoning is sound, the shape it points at should be less like a bet and more like the only door left open.

Two questions sit underneath most of the noise about AI and software. The first is about how software gets built: the work of turning an intention into a running system, which for fifty years meant a person typing.

The second is about what software does once it is running: for those same fifty years, it stored data and gave it back, and left every judgment in between to a human operator.

Both are moving at once, and they are usually discussed as if they were separate stories. We think they are one wave seen from two ends. One of us works the first half and one of us the second, so we wrote this together, and we tried to keep it analytical rather than promotional. The conclusion happens to describe what we each build, but the point of the essay is the reasoning, not the conclusion.

Start from automation

The cleanest place to start is not with models but with automation, because automation is the pressure doing the work.

For most of computing's history, two activities stayed stubbornly manual because there was no affordable way to do otherwise.

1. Building software was manual: a scarce, expensive person translated a need into code, line by line.
2. And operating software was manual too: another person, many of them, sat in front of the finished application and supplied every decision it could not make for itself, which was nearly all of them. The software held the data. The human held the judgment.

What is happening now is that both of those manual activities are being automated, and they are being automated by the same underlying capability: a machine that can take in an ambiguous situation and produce a reasonable response to it:

1. Point that capability at the building of software and you get agentic development.
2. Point it at the running of software and you get an application that acts.

It is one advance landing in two places, which is why the two halves arrive together and rhyme so exactly. Keep that in mind, because it is the reason the ending converges.

Take each half in turn, honestly, including what is still missing.

The build half: from hand-coding to orchestration

I will take this half in the first person, because I have spent a lot of the last year in it, and the view from inside is more useful than the view from the announcements.

A great deal of the frontier R&D right now is agent orchestration, and once you are actually doing it the shape of the work is not what the demos suggest. The model writes the code, and it writes it well. What it does not do is the part that turns out to be most of the job. My role, in practice, has become supplying context and guidance, wiring up the accesses an agent needs and no more than those, grounding the agent in the reality of the system it is changing, and running the cross-agent conversation so that several of them arrive at one coherent result instead of four conflicting ones. That is where the hours go, and it is precisely the part the current tools, including the ones I reach for daily, support least well. It is the thing that most needs better support right now.

I can say how much this matters from my own week, because I lean on it daily. A good part of Aito now runs through a small set of agents: one for daily work, one taking a CRO's view, one a CPO's, each surfacing what to do next. What makes them useful is not the models. It is that they share one backlog, filing tickets and pulling their next task from the same queue, and one store of business context and plans they all read and write, so they pull in one direction instead of four. The leverage is large, and the lesson is plain: the value is in the orchestration, and I built that scaffolding by hand, brittle and personal. Doing it properly, for building software rather than for one founder's operation, is ModernPath's half.

Put analytically, the build half has four problems, and none of them is "can the model write code."

• Grounding. Generation that is not tied to the real architecture will invent: an API that does not exist, an assumption the system does not hold. Fluent and wrong is worse than slow, because someone has to find the wrong part later.
• Context and access. An agent needs the right facts in front of it and the right permissions to act, and not one permission more. Getting that boundary right is a real, unglamorous, unsolved problem.
• Coordination. More than one agent, working toward one outcome, without stepping on each other. The cross-agent conversation is its own discipline, and today it is mostly improvised.
• Governance. If you are going to trust generated code in a system that runs a business, you have to be able to trace what was built back to what was asked, and audit it.

This is exactly the problem ModernPath was built to answer, and the answer is an Agentic Engineering OS rather than a cleverer prompt. It extracts what your software actually is, the architecture, the data, the decisions already encoded in the code you run, into a knowledge core that the generation has to answer to. Requirements are written against that core and held in a ledger: the record of what was decided, who decided it, and what has to stay true for it to hold. Code is produced with traceability, so every piece ties back to the requirement and the architecture it came from.

Traceability on its own is not governance. A record that cannot tell you whether it is still true is just a document, and documents drift. So every requirement carries the evidence that proved it, and that evidence has a state: current, stale, or invalid. Change an input and everything that depended on it is demoted, visibly, without anyone having to remember to look. The approvals that matter sit at gates an agent cannot pass by itself. People supervise where being wrong is expensive, instead of reviewing every step. And it does not stop at the moment of writing: runtime findings feed back into the knowledge core, so the system keeps learning from how the software actually behaves, and drift is caught instead of accumulating.

None of this replaces the coding tools. Claude Code, Cursor, Codex and Copilot are where the inner loop happens, and most teams have already chosen. The OS sits above whichever one you run and drives it with your context, your rules, and your acceptance criteria. Standardising an entire delivery process on a single model vendor is a bet a company does not need to make.

You do not have to take this on faith. Point ModernPath at a slice of your own estate and see what it reads back: the architecture and the encoded decisions it recovers before a line is generated. Talk to us about a baseline.

Notice the shape, because we are going to meet it again: ground the generation in the real system, gate it before it ships, feed back what happened. That is what it takes to trust software a machine wrote.

The application half: from store-and-retrieve to predict-and-act

Now the other half, framed the way we frame it at Aito, because the consistency is the point.

For fifty years an application has rested on one quiet assumption: the data lives in the software and the decisions live in the user. The system stores and presents; the person reads, judges, and types the answer back. The shift now underway is an inversion of that. The application begins to predict and to act, and the person moves from operating it to supervising it. Less you doing things with the software, more the software doing things for you.

Applications are turning more autonomous and more holistically intelligent. But three things are conspicuously missing, worth naming as problems before anyone sells you a solution.

• Interactive intelligence with the user. Full autonomy is the easy story to tell and the wrong one to ship first. Real work needs software that acts with a person: confident where it should be, deferential where it should not, drafting and asking rather than either doing nothing or doing something irreversible. That middle ground is where most of the value and nearly all of the safety live, and it is underbuilt.
• Infrastructure that supports LLMs and agents rather than fighting them. An agent composes its requests at runtime, against data it was not written against, and needs fresh answers at interactive speed. Most of our data infrastructure was designed for none of that.
• Coherence underneath. The capabilities an acting application needs, facts, text, semantics, relationships, prediction, sit in separate systems today, and building one real behavior means wiring four or five of them together and keeping them agreeing. The seams are where an agent's freshness, latency, and trust go to die.

An application that acts needs two abilities held together: reasoning, from generation, to read a messy request and handle the case nobody wrote a rule for; and intuition, from prediction over the business's own data, the calibrated sense of what usually happens here, with a number attached. Reasoning handles the exception. Intuition handles the rule. The calibrated number tells the software which case it is in, and that number is what makes interactive intelligence possible: act where confidence is high, assist where it is middling by drafting and asking a person, abstain where it is low.

This is not a whiteboard idea. In the live sales agent, the language model reads the situation and does the talking, while the predictive database answers the questions generation cannot: the win odds and why, the effort estimate, the references to cite, the best way in, each returned as a calibrated tool call. The agent runs the moves that clear the gate and hands the rest to a person.

Step back from the single decision to the whole application, and a structure appears, the same one whatever surface the action happens to show up on. There are the outside interfaces where the software meets the world: the people who used to drive the screen by hand, the agents now acting on their behalf, the other systems it integrates with. There is the application itself and its inner interfaces. There are its databases, the operational record, everything the business already knows. And there is one more layer that most applications are missing, the one that turns the record into action.

Call it the epistemic layer, because its job is to supply what the software knows and what it does not: the known, by retrieval over the record, and the unknown, by calibrated prediction on top of the same data. It grounds every operation in the real record and guides it with a sense of how sure it is. It is, in effect, a company AI, the part that holds the judgment the application used to leave to a person and feeds it to every surface above. We would rather not oversell the phrase, so the concrete version is the honest one: you can open the live agents running on exactly this layer, and click through the open reference applications, an ERP, an accounting system, a store, each acting on calibrated probability over its own data. The diagram is only a picture of what those already do.

Read straight rather than through an agent, that same layer is just a dashboard. Every KPI, the known, is paired with the lever that moves it, a calibrated prediction of what will change it; root causes come from relating the data to itself; and there is no language model anywhere in the view. Judgment, sitting in the database.

The same layer shows up on the customer's side of the glass, not only in operations. One open reference store runs sixteen different views, smart search, personalised recommendations, basket analysis, demand forecasting, markdown decisions, win-back, on a single predictive database with no trained models. Each view is another query against the same data, with a probability and an explanation attached.

The coherence problem has the same answer the build half did: stop assembling the capabilities at the seams and put them in one place. That is what a predictive database is. Facts, text, vectors, and relationships live in one store, and it answers questions about the unknown the way an ordinary database answers questions about the known, calibrated and explainable, fresh, at interactive speed. The stack an acting application would otherwise stitch together collapses into a query. This is not a promise about a roadmap: Aito's v2 predictive database is in public beta now, and the operators in these examples, calibrated and explained, are its live API. The full version of the argument, with the architecture it forces and real queries you can read, is in What would it take for software to act for you?

The one shift underneath both

Read the two halves next to each other and the symmetry is hard to miss, and we did not arrange it.

Both halves begin by refusing ungrounded generation: on the build side, code not held to the real architecture; on the application side, action not held to the real data. Both then ground the generation in the system's own reality, a knowledge core on one side, a calibrated model over the business's data on the other. Both gate it before it is allowed to matter, an audit that has to pass, a confidence threshold that has to clear. And both close a loop, feeding what happened back into what the system knows.

Ground the generation. Gate it. Close the loop. Learn from the real thing. That single pattern is showing up in how software is built and in what software does at the same time, because it is one underlying shift arriving in two places. The thing that used to be exclusively human, judgment, is becoming native at both layers. The builder gains judgment. The product gains judgment. That is the whole wave, and it is why treating agentic coding as the story while still shipping store-and-retrieve apps is building half of it. If the way you build is intelligent, the thing you build should be too. It is the same discipline; there is no principled reason to stop it at the halfway point.

Why the shape converges

Here we want to be careful, because it would be easy to slide from analysis into a sales pitch.

Start from the needs, not from any product. If software is going to be built by agents you can trust, that building has to be grounded, gated, and self-correcting; there is no version of trustworthy machine-written code that skips those. If software is going to act on your behalf, it has to reason and predict together, know how sure it is, act within that confidence, and learn from the result; there is no version of safe autonomy that skips those either. And both, to work at interactive speed against real data, need a coherent substrate rather than a pile of systems held together with glue.

Now ask how many genuinely different shapes satisfy those constraints. Our honest answer is: not many. The constraints are tight, and they are not matters of taste. Grounding is not optional once you have watched ungrounded generation fail. Calibration is not optional once you have to decide whether to act. Coherence is not optional once latency and freshness are on the line. When the constraints are this binding, the space of valid solutions is small, and the solutions in it tend to resemble each other whatever names they carry.

So we will not claim the future is ModernPath and Aito. It may not be. Companies are fragile and timing is unforgiving, and plenty of correct ideas are built by someone other than the people who first described them. What we will claim is the shape. The future of software will be built by grounded, audited, self-correcting orchestration, and it will do its work through applications that predict and act on calibrated judgment over a coherent substrate. That is what we are each building, not because we chose it as a strategy, but because we followed the constraints and this is where they led. If we are wrong about ourselves we will not be very wrong about the shape.

The part you cannot read off the past

There is a limit to how far this kind of reasoning carries, and it is worth being plain about it. We can argue the shape of the solution, because the constraints are tight. We cannot argue the possibilities it opens, because those are genuinely new. A change moving this fast does not only automate the old work; it makes things feasible that were not on anyone's list, and it quietly changes what is even worth doing. That part is a real unknown, and it is a large one.

It is also the part today's tools are worst at, for a structural reason. A language model is a superb compression of what has already been written. Ask it where a genuine discontinuity leads and it will answer fluently from the past, which is exactly the wrong place to look. The future of software is close to being out of its training distribution by definition. It has to be reasoned about and explored, with people, not retrieved.

So here is the honest offer. We have spent real time thinking about how to move well through this on both halves: how software should be built, and how the software itself has to change to stay competitive while the ground shifts. We do not have all the answers, and we are wary of anyone who claims to. What we have is a way of reasoning about it that has held up so far, and two working systems that came out of it.

If that is useful to you, we are opening a small Future of Software working session: a practical sparring on how to adapt your own R&D and product to stay competitive in the age of AI, across both halves, how you build and what you build, aimed at where the real constraints and the real openings are for you. It is not a pitch. It is a working session between people trying to read the same hard thing, and we expect to learn as much from your perspective as you take from ours. Bring the parts you have not figured out. Reach Antti or Pasi, plain email still works.

---

This is a joint essay by Pasi Vuorio, founder of ModernPath, a platform that turns software product delivery from a collection of tools and meetings into a governed Agentic Engineering OS, and Antti Rauhala, founder of Aito, a predictive database that lets applications predict and act on calibrated, explainable inference over their own data. The application half is argued in full in What would it take for software to act for you?. Reach us at pasi@modernpath.ai and antti@aito.ai.

This piece was written with Aito.ai.