Use AI to build your deterministic tools, not to decide what to do with your prod data.
When people talk about AI, there’s usually no distinction between where it’s deployed and how many people are going to be using it. That distinction turns out to be most of the game.
Using Claude Code, vibe coding, building an agent or some tooling for yourself: I think of that as Dev Mode.
In dev mode you just keep prompting until you get what you want. Mistakes are cheap. Take a look at the millions of purple gradient websites that exist these days.
Infra Mode is a different game.
In infra mode your user gets one shot. If the answer is wrong, they don’t reprompt four times and switch models until it comes out right. They just think your product is bad. And if the harness does let them retry, congratulations, you paid twice for the same answer.
That’s before you get to the part where the model doesn’t just say something wrong, it does something wrong. Queries the table it shouldn’t have. Sends the email. Touches the record.
Once you start thinking about trust boundaries, action scoping, and what an eval suite for this even looks like, you land somewhere uncomfortable: you don’t want the model deciding much of anything on your production data.
So don’t give it that job.
The move
Same model, completely different job.
Think about how an airplane works. Certification happens on the ground. It’s slow, it’s expensive, humans review everything, and failure is cheap because nobody’s in the air. Then in flight, the autopilot is extremely capable, but every maneuver it can execute is one that got certified on the ground. It cannot invent a new one at 30,000 feet. It has never once been given the option to open a door.
That’s the whole pattern.
In dev mode, the model builds. It writes the tools, and you review and test them while review is cheap. You end up with deterministic artifacts where you know exactly what happens when they run in production.
In infra mode, the model picks. Its job is choosing which of the already-built tools applies, and summarizing what came back. It isn’t writing new tools. It isn’t reaching data it shouldn’t. It’s composing from a set of things whose behavior you already established.
The model is still doing real work. It’s just doing it inside a boundary that was drawn while the stakes were low.
As a more practical example: I’ve built a few pipelines at work and on personal projects with “AI features” on top. Chat interfaces, scheduled jobs, UI buttons, all triggering the same pipeline.
Nothing about AI made those surfaces possible. It’s old-fashioned engineering. Build the tools API-first so security and deterministic behavior are baked in, encode your domain knowledge as skills the model can choose from, and the surface becomes a detail. A tool doesn’t care whether a person, a cron job, or an LLM called it.
The new models were genuinely great in dev mode. They just weren’t the unlock.
Why this holds up
Every few weeks there’s a new framework, a new prompt trick, a new orchestration library somebody wants to sell you. Most of it is gone in six months.
Anthropic and OpenAI have enormous incentive to commoditize the tooling layer, and they’re doing it fast. What they can’t commoditize is your business and your domain knowledge. So wherever the tooling lands, the durable work is in the same place it always was: knowing what your systems do, writing that down, and building bounded tools that encode it.
The model is the generic part. The tools are yours. The boundary, not the model, is the durable part.
The projects on this site are this essay implemented end to end — code gated into deterministic tools while the stakes are low, and a model that only picks from them once anything real is on the line.
Use AI to build your deterministic tools. Don’t use it to decide what to do with your prod data.