AI Is Becoming Infrastructure, Not Software

My grandfather could tell you exactly when electricity arrived at the farm, because for the first several years it was an event. You did not simply use it; you considered it. There were conversations about whether to run a line to the barn. There was a period during which having power was a thing about you rather than a thing about the world.

That period ended, as it always does. Electricity stopped being a decision and became a floor. Nobody chose it anymore. Its presence was assumed and only its absence was noticed, and the interesting questions moved from whether to have it to what to build on top of it.

We are in the late stage of that transition with AI, and most organizational thinking is still calibrated to the early stage.

Software is chosen. Infrastructure is assumed. You can tell which one you have by what happens when it fails.

The tell

The clearest signal that something has crossed the line is the character of its outages. When software you have chosen goes down, work becomes inconvenient. When infrastructure goes down, work stops, and the failure is discussed in terms of hours lost rather than features unavailable.

By that test, AI has already crossed the line in a lot of organizations that have not noticed. Support teams whose response times assume drafting help. Analysts whose reporting cycle assumes summarization. Developers whose estimates quietly incorporate assistance. None of this appears on an org chart. It appears the first time the service is degraded for a morning and everyone is mysteriously behind.

The practical significance is that dependencies you have not acknowledged cannot be managed. You have no fallback, no degradation plan, no sense of what the floor is if the floor disappears. That is not an argument for using less. It is an argument for being honest about what you are already standing on.

Infrastructure has different economics

When something is software, you evaluate it against alternatives and switch when a better one appears. When something is infrastructure, switching costs are structural, because everything above it has been built assuming its particular shape.

This changes what a good decision looks like. For software, choose the best current option. For infrastructure, choose the option most likely to still be reasonable in five years, with the most stable interface and the least dramatic behavior. Boring is a virtue at the foundation and a vice at the surface, which is why organizations that get this backwards feel both fragile and slow.

It also changes how you should feel about price. Infrastructure gets cheaper, reliably, because it commoditizes. Building your strategy around a current price advantage is building on a number that will be different next year. Building it around a capability and an interface is more durable, because those change slowly even as the underlying cost collapses.

What moves up the stack

Each time a layer becomes infrastructure, the valuable work relocates. When electricity commoditized, the value did not stay with generation; it moved to everything that could suddenly be built — refrigeration, machine tools, the modern factory floor. The people who kept competing on generation had a hard few decades.

The equivalent mistake now is treating access to capable models as a differentiator. It is not, or will not be for long. Everyone will have it, at roughly comparable quality, at a price that keeps falling. Building a company around having it is building a company around having electricity.

What relocates upward is judgment about application. Knowing which problems in a specific domain are worth solving. Having the data, the relationships, the taste, and the accumulated understanding that turn general capability into something particular and hard to copy. That is where the work goes, and it is a more interesting place to be.

Nobody competes on having electricity. They compete on what they built once they stopped thinking about it.

The obligation that comes with the floor

Infrastructure carries a responsibility that software does not, and it is worth naming plainly. When people depend on something without thinking about it, they lose the ability to evaluate it in the moment. They are not choosing anymore. They are assuming.

Which means the decisions we make while building on this layer — about accuracy, about what we surface and what we hide, about whether a system admits uncertainty — are being made on behalf of people who will not be checking. That is a heavier position than shipping an app someone opted into after reading reviews.

I do not think this calls for hand-wringing. It calls for a certain seriousness about the boring parts. Logging. Reversibility. Clear boundaries. Honest communication when behavior changes. The unexciting practices of people who maintain things others rely on without noticing.

Building for the assumed layer

Practically, this suggests a few shifts. Design your systems so the model is a replaceable component behind a stable internal interface, not a set of assumptions scattered through your codebase. Know what your product does in degraded mode, and make sure that mode is a designed experience rather than an error message. Write down what you depend on, including the dependencies that arrived informally through individual habit.

And spend your ambition higher up. The floor is being poured whether or not you help pour it. What matters is what you decide to build once you stop thinking about the floor at all — which, judging by every previous transition of this kind, will happen sooner than anyone expects and will feel entirely unremarkable when it does.

If you are trying to work out which parts of your stack should be boring and which should be ambitious, that is a good conversation and I am usually free for it.