Own the deterministic core

Imagine an speleology team entering a cave nobody has mapped before. You can expect that the expedition moves slowly as they explore the passages, put landmarks and, overall, learn and have fun. Most of their effort requires backtracking so not everything is moving forward. Actually, they are discovering what forward looks like. Now, think on a second expedition. We are pretty sure they don't have to do all that again, right? That's because once the first team gained confidence, the exploration turned into infrastructure, enabling the next expedition start at yesterday's mark.

That's how internal, custom platforms in software developer work.

Turn AI exploration into infrastructure

AI's ability to generate software does not make custom platforms (e.g., design systems, infra landing zones, custom APIs and libraries) less important. I argue that it makes them more important.

Yes, coding agents can now generate integrations, scripts, infrastructure definitions, and even entire apps. From there, it is tempting to conclude that the stack we are working with can collapse into the application: instead of depending on reusable assets from a platform, generate whatever the application needs, whenever it needs it, inside the application.

But we know that generating software with AI is not free nor deterministic. Every time we ask a model to reconstruct the same feature, we typically pay again in tokens and, more often that not, verification. More importantly, we ask a probabilistic system to rediscover decisions the organization may have already made.

After months of using coding agents daily, I am coming to the conclusion that a better pattern is to use inference to explore a problem, then turn the stable result into software that can be reused without inference. That result may be a library, an API, a template, a policy, a script, or a complete platform capability.

In other words, AI expands what we can discover and platforms preserve what we have learned as foundation so we can move up the value chain faster.

The mirage of the flattened stack

There is a reasonable argument behind the idea of flattening the platform into the application. If an agent can generate an authentication integration, new design system UI components, or a Terraform deployment script in a few minutes, why carry the weight of a shared abstraction?

For some experiments, that may be exactly the right choice. For example, per the Avoid Hasty Abstractions principle (AHA), generating a disposable script can be cheaper than designing a reusable capability. Mitchell Hashimoto has expressed the same instinct from the perspective of dependencies. When evaluating whether to introduce or update a library, he would ask engineers at Hashicorp to “show me the commit we need”, forcing the question of whether the specific functionality was valuable enough to justify importing the abstraction, or simple enough to own directly in the product. Nowadays, an agent can also bridge an awkward SDK, adapt a generic library to a local need, or produce a temporary solution while the problem is still poorly understood.

The trouble starts when temporary generation becomes the default operating model.

Imagine that ten teams need to implement the same UI dashboard component. We could give every agent a prose description of the UX and composition rules and let each one generate an implementation. The results may all look plausible (and beautiful) dashboards, but they will contain slightly different interpretations and assumptions. We have flattened the shared platform, yes, but only by distributing its complexity across ten applications, putting consistency unnecessarily at risk.

In any case, the platform did not disappear in this example. Instead, it just became implicit, fragmented, and expensive to verify. It's just a weak system.

And this is especially dangerous because these coding agents compensate for weak systems surprisingly well. They can read documentation, infer conventions, inspect code, and optimize for the local maximum. The output can hide the absence of a real architectural constraint and you can't see it until one agent interpretation drifts far enough to become a security or performance problem. And then, it will be too late.

Infer once, execute many times

Kelsey Hightower’s deliberately provocative idea of Zero Token Architecture captures the idea of not abusing GPU cycles nicely. Behind the joke about rediscovering shell scripts in the age of agents we can find a useful principle: when a problem has become stable enough, infer once, export the result as software, and execute it repeatedly without further inference.

This is simply old software economics applied to AI.

We have always used expensive reasoning (humans) to create cheap repetition (CPUs). Someone thinks carefully about an algorithm and turns it into a library. A team studies a deployment failure and encodes the lesson in a pipeline check. An architect resolves a recurring integration problem and exposes the answer through an API. The reasoning process may be expensive (measured in time and effort), but every subsequent execution is predictable and relatively cheap computing.

In my experience, to borrow a metaphor from physics, AI bends the spacetime of software creation: it compresses the time from idea to working software while expanding the space of possible solutions. But once a solution proves useful, we should crystallize it into a deterministic core that can be reused without inference. Even if eventually inference becomes dramatically cheaper, deterministic software gives us properties that repeated inference does not provide such as stability, testability, predictability, and reusability.

Yes, an agent Skill may tick all those boxes apparently. However, I argue that once the same reasoning is being repeated reliably, the skill may want to become a script. If the script becomes widely useful, it may want to become a library or service. If multiple capabilities need to work together under common policies, we are building a platform again.

AI appears to preserve this evolutionary pattern, even as it changes the cost, speed, and ownership at which capabilities become platform services.

Platforms help define the laws of physics

Software development is often described as building, but in my personal view, it resembles designing a car or a building more than assembling one.

When engineers design a physical building, the design space is already constrained by implicit environmental laws such as gravity, material strength, weather, and geometry. The architect can create many different buildings, but cannot negotiate with gravity through a more detailed prompt.

Software begins from a stranger place. A CPU offers an enormous space of potential behavior, but very few meaningful boundaries. The machine does not inherently know which customer may access which record, which UI states are valid, or which 3rd-party dependency is approved. Without additional structure and rules, almost every permutation is technically available. To design software is therefore to write the laws of a small universe.

Platforms are where many of those laws live. APIs define valid interactions. Types and schemas define valid data exchanges. Permissions define who may act. State machines define legal transitions. Components and design tokens constrain the user interface. Tests, linters, policies, and delivery pipelines reject behavior the organization already knows is wrong.

This is why “constraining the design space” is more precise than “designing the design space.” Instead of specifying every artifact an agent may generate, the goal is to establish the boundaries within which many useful artifacts can be generated safely.

As I argued in Agent-ready Software vs. Software-ready Agents, context alone is a weak constraint if the system has no executable way to reject a violation. Markdown can tell an agent to use the approved component library. A typed component API, design tokens, accessibility tests, and CI checks make that intent part of the environment, and makes it enforceable.

A useful mental model to think about this is looking a the prompt as the vehicle describing the local task while the platform carries the durable memory of the system.

Talking about memory, my favourite analogy is to think that there is a little bit of Leonard Shelby in an organization that relies too heavily on inference. An agent can reason its way to a good solution today, but unless that solution becomes part of the environment, the next agent may have to reason its way there again. APIs, schemas, libraries, tests, and policies are the tattoos, polaroids, and notes that helped Leonard survive in Memento. Without these artifacts, Leonard would have to reconstruct his reality every time he wakes up, inferring what probably happened from whatever evidence is available (context). The tattoos are conclusions he has decided are too important to keep inferring.

Automation follows certainty

There is a broader principle underneath this.

When we automate something, we actually constrain it with automation. And we can only apply strong constraints when we understand the problem with a sufficiently high degree of certainty. Unfortunately for us in software, product development does not have those properties, since we rarely know the problem, market, operating model, security boundaries, and user needs with enough certainty at the beginning. Asking an agent to generate the whole thing does not remove that uncertainty. It just allows assumptions to become code faster.

The high-level yet practical operating model I am coming up with has at least three layers:

1. Explore the uncertain edge. Humans and agents work together to understand the problem, challenge assumptions, compare alternatives, and discover which constraints are the right ones.
2. Crystallize what becomes stable. Repeated decisions move into scripts, contracts, tests, libraries, workflows, and policies.
3. Reuse the result as a platform. Applications and agents build on those capabilities without reconstructing the same reasoning every time.

Then the process starts again at a higher level.

This is the Wardley Mapping pattern playing out in software architecture: as one capability becomes understood and industrialized (or in this case "crystalized"), it stops being the main source of differentiation. Then, its commoditization enables higher-order systems, and those systems create new sources of value and new skills to develop.

And platforms are what allow exploration to move up.

Note: The same pattern explains why humans remain important even as models become more capable. After Automation uses Zeno’s paradox to describe the relationship between human work and advancing models. My interpretation of that paradox is that, as models automate a task, some organizations move the evaluation frame beyond the original benchmark. For example, once code generation becomes reliable enough, a team may care less about whether a model can produce a function and more about whether product development teams chose the right problem to solve, set the scope, and created value. This cycle is fractal. Models solve tasks, humans assemble those tasks into systems, encounter a larger problem, and ask the models to help solve that. When the larger problem becomes stable, we encode its solution into another layer of software. That new layer creates the substrate for problems we could not economically approach before. There is no obvious final layer because the supply of possible problems to solve is potentially infinite

What architects and product leaders should do

For architects and product leaders, I suggest a calmer response to the current hype of abusing inference.

First, do not treat every successful generation as evidence that a platform capability is obsolete. Ask whether the agent solved a genuinely unique problem or reconstructed a shared decision locally. If the same reasoning appears across teams, repositories, or agent sessions, it is a platform candidate.

Second, and at risk of abusing metaphors about physics, separate the probabilistic orbits from the deterministic core. What does that mean effectively? Use agents where the problem is ambiguous, the solution needs exploration, or judgment is still developing within the team. Then, move stable rules toward APIs, schemas, libraries, policies, and verification systems as soon as they become clear enough.

Third, measure more things than just implementation speed. A team generating code quickly may also be generating tech debt at a high token cost rate. A good platform reduces how much context must be restated, how many interpretations must be reviewed, and how often the same decision must be made.

Finally, keep system boundaries movable. Like in the pre-AI era, software platforms should not freeze every decision forever. Instead, they should encode the parts we understand well enough to be enforced consistently while preserving escape hatches for exceptions. The objective is to obtain a high level of autonomy that still feels constrained with enough structure to protect the system.

Internal platforms as the new Intellectual Property

All in all, this is why platforms remain important in the age of intelligence abundance (don't mistake with zero-cost intelligence!). Platforms package decisions so every application and every agent does not need to rediscover them. Like speleologists mapping the terrain, consider turning probabilistic exploration into deterministic leverage. You can do this by building internal platforms that carry the essential architectural constraints that make generated software become a solid part of a system rather than a plausible fragment.

And humans remain important for the complementary reason. Someone has to recognize when a problem has become stable, decide which lessons deserve to become "laws of your little universe", and raise the level of abstraction toward the next problem. Today, agents can help with that process, but organizations still need humans accountable for those decisions.

Over the next few years, software teams may rely more heavily on inference as they ship with AI. But that possibility should come with a deliberate counterweight, with architects and product leaders turning stable results into artifacts that no longer require inference. For example, more exploration should lead to more crystallized knowledge (e.g., NPM libraries) and more generation should create stronger demand for tools to preserve intent for prosperity (e.g., Linear).

AI helps us explore the almost-infinite possibilities of software, but organizations must own the durable, deterministic knowledge that agents should not rediscover. In an age of cheap and abundant code, maybe this is the new intelectual property.