We’ve all been amazed at how many LLMs and decisional models we’ve managed to integrate, in all sorts of places, in our codebases.

What was once a complicated deterministic process combining many heuristics that had to be managed carefully is now just an agent with a high-level prompt written in English that the whole team can easily maintain.

And even saying that, it’s not clear we’re still editing these prompts manually, or even reading them anymore.

In my case, after integrating my first agent loop in the codebase, I quickly reached for a configuration language in order to orchestrate these agents. Small configuration languages are better, and so I set out for a minimal syntax in yml files.

The configuration language basically looked like a GitHub workflow, simple enough that you’d think it would be really useful and that should be the obvious boundary between stochastic agents and deterministic code.

Deterministically automate what you can deterministically automate.

Underneath that, things were more flexible, constantly changing, and so subagents seemed like the right orchestration approach. One root agent following some high-level script, and getting better and better at orchestrating an army of subagents as models improved.

A friend then asked me, wait why use a configuration language to orchestrate your root agents? Why not just use prompts as well?

This is when the idea of a border between deterministic code and stochastic agents constantly shifting appeared in my head.

The idea of deterministic code is that it is fast, cheap, and predictable. But the predictability has a cost: it is not flexible, and bugs in the code can leave your application in unrecoverable states that will get your application stuck until you fix the code and ship an update.

Agents are slow, expensive, and often non-local. Open-weights are changing the game, but they are still slow and expensive. That hasn’t changed much. At least if you want output tokens of quality.

But we can all predict a future where this ceases to be the case. A future where every MacBook Pro ships with a special AI chip, an NPU, and SteveJobs 5.5 running on it, so that producing code on the fly is no longer slow, expensive, or non-local.

In such a world, perhaps the deterministic code orchestrating our agents will vanish. How much will it vanish? It’s hard to tell. Maybe we won’t use apps anymore, or UIs, maybe everything will be requested from agents on the spot.

Maybe agents will be the only UI humans will interact with going forward, maybe natural language will be the only API.

But beneath these agents, I want to argue, deterministic code is alive, and thriving.

Perhaps, deterministic code is not shifting, it’s getting teleported underneath agents’ feet.

We’re less and less preoccupied by how to run some infrastructure, and getting busier with what tools and custom CLIs and MCPs we’re giving our agents access to.

Tomorrow’s money will be in what your agents can interact with, the building blocks they can use to do useful things, and the code they can generate on the fly for the future requests they will have to handle.

If you’re building for tomorrow’s world, my advice would be to focus on that: one building block that would be useful for many people’s agents.

I sometimes wonder what the future of collaborative work looks like in this agentic world. We’ve set up and philosophized about all of these engineering processes to death. From dependency injection to scrum masters, from best practices to the minimum number of reviewers required for your PR to land, none of this matters anymore, all of this went to trash.

Most of our important tests are now shifting to SCENARIOS.md files, describing high-level flows in English, that agents can test using their pstack-inspired verification commands.

I still talk to people who work at companies where people manually write code, and manually review code, and everything sounds so slow, and so archaic.