The Problem
If you want to get code out of a model, you use Claude Code. Tell it what you want, and it authors some code or makes a fix.
We want services. We don't have a tool that can get services out of models. We need to build that.
Grow, Don't Build
We found out a while ago that we should empower people to get the best out of them. We took the risk to give up control, to not treat them like robots, and let them be creative. Align on mission, align on goals. Compartmentalize, so nobody has to solve the whole enchilada.
When we build big software components and services, we build it in a pretty traditional way. Whether we're talking agile or STARTUP_MODE=on, we are still talking waterfall: you discuss, you write, you deploy, you learn, and you loop it back. The obvious way to think about LLMs here is to think about them helping us with the writing part. They are tools for our machines.
What happens if we apply the people empowerment lesson to models? If we treat them (and I know how wild this sounds) a little more like people, and a little less like a wrench, what do we get?
We might start thinking of them as "people" who can "build" services. Building that sense is quite weird: we're not really in there.
It might be easier to think about growing services, instead of building them.
Building
- Specify every component
- Wire every connection
- Plan before executing
- You are the only source of intention
Growing
- Set conditions and constraints
- Provide goals and resources
- Respond to what emerges
- The system has its own growth logic
Goals, Not Tasks
Older models are kind of back and forth question-and-answer bots. Newer ones break down the work you give them into tasks. You see them use external storage as memory, and recitation (going back to the todos) seems to help them stay on track.
People who use these systems a lot sense something slightly different: the models seem to understand the goal better. Eventually the models will be goal-oriented, and much better at breaking their work down. ("Eventually" meaning, like, months.)
In that world, the people empowerment metaphor is profound. You can't call timeout and put the players into place every couple of seconds. You are a real coach. You have to help the players be better at reading the game, and knowing what to do. They come to you when they need advice.
The loop looks something like this:
What This Means
Let's play it out.
Anyone can vibe code anything now. That means proliferation. Many more services will exist than exist today.
Many more services means AI must operate them. There won't be enough people.
AI operating services means services have to be manageable by AI. They need to be built in a way that does not require people.
This is the real meaning of "AI-native" service. Not "built with AI help." Built for AI to run.
For more on what AI-native infrastructure actually looks like, see The AI-Native Infrastructure Primer.
This Builds on IaC
There's a simpler version of "AI and infrastructure" that's already here: AI can speak the languages we use to control infrastructure. Terraform, Kubernetes manifests, CloudFormation, Pulumi. Models are pretty good at writing these. They're getting better.
Infrastructure-as-code gives us version control, reproducibility, governance, and more. And you want all that goes with it — the ledger, everything — even more when AI is controlling things.
What we're describing here is how the services are built and operated. This is "behind" the IaC wall, which is the programming substrate to speak your intent into the service. It's unrelated, in a sense, to what is behind that wall.
Ways This Could Be Wrong
Maybe AI models don't get a lot more capable soon. This all depends on models being a bit more capable than they are today... but not a lot. I think they will get more capable, quickly. (Here's why.)
Maybe we don't need more infrastructure. Perhaps infrastructure is becoming commoditized — crystallizing around model training needs rather than proliferating. Just more storage, more compute, more networking. The same shapes, bigger numbers. In that world, we don't need AI to grow new services. We need AI to scale existing ones.
Maybe you can't teach models taste, or judgment. Maybe it never really succeeds at hill climbing, and makes bad decisions along the way.
Maybe "AI-native" is a local maximum. We optimize for AI operability and lose something in the trade — legibility to humans, debuggability, the ability to reason about the system when the AI is wrong. We might build infrastructure that only AI can understand, and regret it.