How I use AI

Most of the conversation about agents stops at the harness: the tools, skills, memory, permissions, and loop that turn a model into something that can make changes. But the harness is still designed around one agent.

Once people inside a company are each running a dozen agents, the problem changes. Control planes coordinate them. Supervisors make sure they are actually running. Change control proves what happened and whether the organization can safely move forward.

These are the layers that keep humans from becoming routers, babysitters, and approval buttons as ten agents become fifty, one hundred, or one thousand.

Two engineering leaders, in two separate first sessions, asked me the same question in the same words: how do you trust the AI output? I don't. And the two things everyone reaches for first, unit tests and manual code review, are exactly the two things that stop working.

Unit tests don't catch customer regressions. Manual review doesn't scale past a handful of agents. What replaces them is a verification cycle that lives outside the code the agent wrote and as close to the customer as you can afford.

Eight steps, in the order a change moves through them, from the agent review that lets it out of the pull request to the rollback that beats any fix forward.

In January I wrote that languages like Rust would matter more as AI writes more of our code. In September I froze the Rust code and rebuilt my agent platform in Elixir.

Rust the language was fine. The tooling around it was built for one person at one machine with a warm cache. Fifty agents in fresh checkouts, and dozens of pull requests hitting CI at once, is a different world: 47 GB of build artifacts on one laptop, a 15-minute CI median, and a one-minute build target we never got near.

Two backends, same specs, same agents, almost the same number of commits. Then I picked the wrong winner, and reversed it eleven days later.