I Built an AI Layer, Then Deleted It

The most useful thing I shipped this year was a deletion. In late May I removed the package every other part of my studio called when it needed a model to do something — the standardized AI layer — along with the analytics wired to watch it and most of the orchestration I'd built to make several AI services behave. The studio runs more of itself now than it did when all of that existed.

Building around the model

It began on a different premise. Last September I was building products with an earlier coding model, and the way you worked with a model then was to surround it: a package to standardize the calls, a router to decide which task went where, retry logic, an evaluation harness, somewhere to store and inspect what came back. None of this was unreasonable. The model was a component — capable in bursts, unreliable across them — and you built the way you build around any unreliable component, by wrapping it in enough structure that its failures became your structure's problem instead of your user's.

Every wrapper was a bet

What I did not see at the time was that each of those abstractions was a bet that the model would stay as weak as it was the day I wrote it. The router assumed I would always need to route around something that couldn't hold a long task. The eval harness assumed the failure modes were stable enough to be worth instrumenting. The orchestration assumed that getting useful work out of the thing required someone — me, in code — to choreograph it. These were sensible bets in September. They were losing bets by spring, and they lost in the way you want a bet to lose: the model got good enough that the structure I had built to compensate for its weaknesses became, simply, structure in the way.

Taking it out

So it came out. The AI package, inlined down to nothing and deleted, because there was no longer a class of "AI task" distinct enough from "task" to deserve one. The analytics that watched the model — gone, because I was no longer debugging a flaky component, I was reading the work it did. The orchestration layer, the custom internal tooling, the half-built managers for managing agents: removed across a few weeks of commits that read, in the log, more like subtraction than construction. What replaced all of it is close to embarrassing in its plainness — one capable agent, operating the studio directly, with nothing standing between it and the work. The rule I keep now, single agent and no custom orchestration, did not come from taste. I earned it by building the opposite first and then deleting it.

Infrastructure that fights back

The general shape is the part worth keeping. In a domain improving this fast, infrastructure is not an asset that compounds; it is a depreciating bet against the thing it sits on. Every layer you add to compensate for a model's present limits becomes a liability the moment those limits move, and they move on a schedule you do not set. This runs against the instinct that has built most of the AI tooling now in the world, which is to add — a framework here, an orchestration layer there, an agent to supervise the agents. The harder and rarer discipline, the one I keep relearning a package at a time, is to build as little as the capability allows, and to delete the moment it allows less.

I don't think this generalizes cleanly. Infrastructure that sits on something stable earns its abstractions and should keep them; a database did not get less worth wrapping this year. What I am describing is specific to building on a capability that is still, visibly, in motion. And here I am guessing: for a while yet, the most valuable thing a small operation can do with AI may be not to build cleverly around it, but to keep removing what it no longer needs — and to notice quickly when that day has come. The studio is, in honest summary, a record of me noticing late. These notes are an attempt to notice a little sooner.