For more than a year, coding agents have written 90 to 95 percent of the code I ship, and for a while that number felt like the whole story. But the more interesting part, at least for me, is what it did to my attention.

Every time I gave the agents more room, the work sped up, and every time, the bottleneck moved: first it was me, then it was the layer I built to replace me, and then it was the layer above that. The agents themselves were never what held us back. What held us back was how fast the people directing them (and, more and more, the agents directing other agents) could notice drift and correct it.

So here’s the claim I’ve landed on, and the one we build around at TwelveApart: better models don’t reduce the need for structure. They increase the need for faster alignment.

One terminal, then four

It started with one terminal and one agent. Then two. Then four. Eventually I was running an egg timer, rotating between sessions every few minutes and playing a kind of technical whack-a-mole: answer a question here, unblock a test there, explain a decision again somewhere else.

Each agent was productive on its own, but the problem was me. I could hold one context at a time, and the agents produced contexts faster than I could ever read them, so four agents didn’t give me four times the output. They gave me a queue, and I was the slowest thing in it.

And honestly, it’s hard to avoid even now. There’s something really great for our dopamine in jumping back and forth, but that feeling of busyness is often not actual productivity, and it can be very addictive. Watching the screens scroll by is like having multiple doom scrolls open at once. It’s the timeline for a developer, just as addictive and just as sloppy, and it’s something I’m constantly worried about.

Fig. 2, one operator and four agents. Each agent sends questions, test failures and decisions into one queue. The queue feeds a single operator who can read one context at a time and rotates between sessions on an egg timer. The operator, highlighted, is the bottleneck.

Building the layer that replaced me

So I built an orchestrator, an agent whose only job was to coordinate the other agents by dispatching work, gating output and managing handoffs. That fixed the immediate problem, because I stopped rotating terminals and the orchestrator picked up the coordination load I’d been carrying.

That worked until the models got better. Better models produced more output, more of it flowed up through the orchestrator to me, and my context filled with tactical detail: which test failed, which branch conflicted, which agent misread a spec. The strategic work (deciding what we should build and why) got crowded out. I’d solved coordination and recreated the bottleneck one level up, and there was no time left to improve the system, because keeping up with it took everything I had.

Orchestration is still a problem I’m trying to solve. It’s why I’m working on Mandem, my local-first agent orchestration project, as a way to create a kind of distributed thinking. (It’s separate from the orchestrator in this story.)

Fig. 3, the bottleneck moves up. With four agents, the constraint is the operator's attention. With an orchestrator added, it moves up to the tactical detail flowing from the orchestrator to the operator. With a thesis layer added, it becomes alignment speed: how fast the system notices and corrects drift. A highlighted line steps upward through the three constraints.

A third layer that watches the system

That’s when I added a third layer. It doesn’t do the work, and it doesn’t coordinate the work. It supervises how the work is organized.

The difference is in the question each layer asks. The orchestrator asks, “Did the work get done correctly?” The third layer asks, “Is the way we organize and direct this work getting better over time?” A board full of finished tasks can sit on top of a process that’s getting worse, and only the second question catches that.

I call it the thesis layer, which needs a little explaining. I don’t mean a market bet or an investment thesis. I mean a working theory of how to build the system that runs the system that runs the agents that build the software. (Read that twice; it took me a while to say it in one breath.) The agents build the software. The orchestrator runs the agents. The thesis layer governs how the orchestrator itself is built and improved.

The figure at the top of this essay stacks the three layers:

  • Tactics. Engineer agents write code, run tests and implement features. Their context is narrow and deep: everything about the task in front of them, very little about anything else.
  • Strategy. The orchestrator decides what gets worked on, in what order, by which agent, and whether the output is good enough to pass up. Its context is wider and shallower. It doesn’t need every line of code, but it needs to know how the pieces fit and where the work is headed.
  • Thesis. A slower layer reads the record of the other two and changes the rules: routing, gates, when to escalate, the framing each agent gets. It’s the only layer concerned with the system’s own learning.

At TwelveApart we’re building that third layer in the open as Lab 001, a supervisory pass over the transcripts of our engineering sessions that looks for failures that keep coming back. Right now it runs after each session. The open question is whether it helps during one, while there’s still time to correct drift, and the next experiment measures how long drift goes unnoticed with the thesis layer and without it.

Why the layers have to stay separate

Agents, like people, get worse when they straddle layers.

An engineer agent loaded with strategy writes worse code, because the strategic material crowds out the precision the task needs. An orchestrator pulled down into implementation stops orchestrating, because coordination needs a view from above the work. And if “is the system getting smarter?” goes into the orchestrator’s task queue, it simply never happens. Running the system is louder and more urgent than improving it, so when the two share a context, improvement loses every time.

Keeping the layers apart is what protects strategy from tactical noise, and what keeps improving the system from being put off forever.

We’ve built this before. It’s called an org chart

None of this structure is new. It’s the org chart.

Think about why a middle manager sits between a director and the engineers, a manager who has probably forgotten half the syntax of their favorite language. Their value was never the code. It was alignment: turning intent into direction, compressing signal as it travels up, and catching drift before it compounds. That’s the orchestrator’s job. The layer above them, the one watching whether the organization itself is learning and not only whether this quarter’s work shipped, is the thesis layer.

Fig. 4, the org chart, again. On the left, a company: a director, a middle manager and a row of engineers. On the right, the agent system: the thesis layer, the orchestrator and a row of engineer agents. Each level lines up with its counterpart. The middle manager and the orchestrator, highlighted, do the same job: alignment.

I saw what happens without that layer at WeWork. We had a ton of small pods spread across very different geographies, and WeWork was great at giving small teams the agency to move. But without staff engineers going around and making sure all that generative work got integrated into one cohesive platform, you end up crawling to a halt. At OkCupid we once had to stop integrating new backend code for almost six months just to un-f*ck everything. Agents are the new pods. I wrote about the code side of this in At 40-plus merges a day, integration became our bottleneck: many independent agents need one place where their work comes together and gets verified.

So we’re relearning why organizations have layers at all. A single mind can’t hold every level of detail and still steer. What’s new is that reasoning models are now capable enough to occupy those layers. I can hand them the compression and the supervision, and keep myself for the one place only I can work: the top of the thesis layer, where the intent lives.

Where to stand

So where should you stand? Once output is solved, everything depends on feedback, and I see people (myself included) get the feedback loop wrong in one of two ways.

The first is staying one-to-one with a single agent: you see everything and correct everything, so control is high, but leverage is close to zero. You aren’t scaling; you’re moving faster alone, and your attention is the ceiling.

The second is stepping all the way back to pull-request review. Leverage goes up, because you’re out of every keystroke, but alignment lags badly. By the time drift shows up in a pull request, it has already spread through everything built on the decision that caused it. You’re reviewing consequences instead of steering causes.

What works for me sits between the two. I think of it as the cockpit: high enough that I’m not buried in execution, close enough that I can see direction forming and correct it while it’s still cheap to change.

Fig. 5, where to stand. Leverage runs along the horizontal axis and how early drift is caught runs up the vertical one. Working one-to-one with a single agent catches drift early but has little leverage. Pull-request review has high leverage but catches drift late. The cockpit, highlighted, has high leverage and catches drift early.

Speaking at the right altitude

Day to day, the cockpit is a pane. We run our agents in herdr, and one pane is always open to an agent I call the communicator, which has also taken on the supervisory role. It helps me organize a ton of work, synthesize my thoughts, and not become susceptible to speaking in the language of the orchestrator. It’s the handoff from the last section in practice: a model doing the translation so I can stay where the intent lives.

Not speaking the orchestrator’s language matters more than it sounds, because even as we interact with these tools, the tools start to interact with us. Father John Culkin, writing about Marshall McLuhan in 1967, put it this way: “We shape our tools and thereafter our tools shape us.” As much as you want to speak in a language you share with them (the language of architecture, say), when you’re actually in the moment and coding, whether you call it vibe coding or not, you’re in a flow state. Either you’re speaking from a very human-centric place, which has issues of its own with rough translation, or from a very architectural place, which has issues of its own as well. You start to speak like these machines. People have been talking about Claude-ese and neural-ese, and I think those are really going to become issues.

So what we need to think about is hermeneutics, the study of how meaning is conveyed: between the human and the agent, and then between the agent and its teams. Because they’re all operating at different levels, each has a semantic basis at a slightly different altitude: thesis, strategy, tactics. Depending on the task you’re using them for, the embeddings of these models have a much more difficult time understanding you when you’re speaking at a different level, which is where the translation errors come from, and why I keep a communicator between me and the orchestrator.

And when the way we speak changes, the way we express intent changes with it. And intent is all we have people! 😭😂

Fig. 6, speaking at the right altitude. The operator speaks at the thesis level. The communicator, highlighted, translates down to the orchestrator at the strategy level, which translates down to the engineer agents at the tactical level. Each boundary between levels is where translation errors happen.

Let the system improve itself

There’s a second-order lesson here that I think most people miss.

Remember metaprompting? We learned pretty quickly that models write better prompts for models than we do. They’re faster at it, and they write in a form other models read well. We were the bottleneck in prompting, so we handed prompting to the models.

The same holds one level up. Models are also good at organizing themselves and improving as a group, if you acknowledge that they can and give them a framework to do it in. That’s what the thesis layer really is: scaffolding that gives the agents permission to improve how they work together, set up by a human rather than enforced by one. I’m not designing the optimal system. I’m setting up the conditions for the system to optimize itself.

Why better models need more structure

It’s natural to assume that better models need less structure around them, and I get why. But I think the opposite is true.

AI is a tool of leverage, and simply using it is table stakes now, since everyone has the base level. The outsized returns come from second- and third-order thinking, from building systems that compound instead of moving single tasks faster.

But leverage cuts both ways. The multiplier that speeds up good output speeds up drift. A wrong assumption at the thesis layer doesn’t stay there. It flows down through the orchestrator, into every agent and every line of code, at the full speed of the system. The more capable the agents, the faster a bad assumption at the top spreads through everything below it.

Fig. 7, drift flows down. One wrong assumption at the thesis layer, highlighted, passes to the orchestrator, then to five agents, then into every change they make.

A better model can remove a whole class of supervision work, for sure. I used to have most of my engineering agents on lower models, Haiku if the job was just editing things, or a Sonnet model. But intelligence is getting a lot cheaper, so what matters is the superstructure. As long as there’s a coordinating superstructure, you can afford to upgrade all of the models as intelligence gets cheaper, and you’ll have a much better system overall. But the superstructure actually needs to be maintained.

Yes, sometimes less supervision is needed when you put a smarter model in there, but that’s really a matter of the nature of plans. A perfectly prescribed plan is essentially the same thing as code. When you’re making plans, there’s a tradeoff between time spent planning and actual execution, and at some point you really do have to let the plan rip and see what comes up. Otherwise you’re just coding the system yourself, moving everything back into a serial modality with centralized intelligence. What we’re really trying to do is distribute the intelligence across the system and still be able to trust and verify the work it does.

That’s why I don’t think the teams that pull ahead will be the ones with the most agents. They’ll be the ones whose feedback loops are tight enough to keep all that leverage pointed the right way. The variable that matters is alignment speed.

What this means for the job

Here’s the uncomfortable version: you’re not coding with AI anymore. You’re the CTO of a team that moves faster than you can process.

So the job isn’t execution, and it isn’t even direct supervision of execution. It’s keeping a system aligned when it produces more than you can read: building the layers that compress, coordinate and improve on your behalf, and keeping yourself in the one position nobody else can hold.

That’s how we work at TwelveApart. On RoughPatch, Kai turns ideas into specs, and the layers in this essay turn those specs into software we can both try. The open question for anyone building this way is whether your alignment can keep up with your leverage. We’re measuring ours.