From Copilot to Orchestration

Two years of handing more and more of my codebase to agents.

These days, I plan work with an orchestrating agent, give it the go-ahead, and walk away. Eight or ten hours later, I can come back to find the work implemented, reviewed, and merged into develop. The agents have been working the whole time, coordinating with one another, resolving issues, and moving things forward without me. The fact that I can set this much work in motion without being there to supervise every step still amazes me.

In 2024, my setup looked like almost everyone else’s. I’d played with Copilot and found it pretty lacking. I had ChatGPT running in a window next to my editor, and I spent much of the day talking to it about the code I was writing. But I was still doing the actual coding myself, with a little copy/paste thrown in.

It happened in five stages, and every one of them followed roughly the same pattern: I’d get something working, think “This is amazing!”, and then promptly discover whatever new limitation I’d just introduced.

Stage one: The Advisor

I’d spend much of the day talking with an agent about what I wanted to accomplish. We’d work through a problem together, figure out an approach, and then I’d write the code myself in VS Code. When I ran into trouble, I’d paste in my questionable implementation or a stack trace, and GPT would dutifully explain what I’d done wrong and hand me back a corrected version. Which I’d then retype by hand, convinced that somehow this kept me “closer to the code.”

The agent was an advisor, and a genuinely useful one. I no longer had to spend time hunting down syntax or looking up implementation patterns. I had a reference sitting right there, ready to answer questions whenever I needed it. I worked this way for quite a while, and I liked it.

But retyping code that already exists is a strange way to spend your day.

Stage two: The Pair

Then I solved the copy/paste problem by putting an agent directly in the repository.

Huge change. No more ferrying context back and forth between my IDE and the model. The agent could read the code, make changes, run tests. We were pair programming.

I was giddy. It felt like I was working alongside a developer who was, frankly, better than me, and my productivity went through the roof. But there was a catch. I’d become a babysitter. The agent would consider a problem, propose a solution, and then ask permission for every single command it wanted to run. I spent an awful lot of time sitting there hitting Enter. This is still how a lot of engineers work with coding agents today.

And somewhere in all of this, I felt… ashamed? As an engineer, shouldn’t I be the one writing the code?

Stage three: The Worker

Eventually, I got tired of hitting Enter and dipped my toe into the --dangerously-skip-permissions waters.

Exhilarating. Like riding a motorcycle without a helmet. Super dangerous, somehow rewarding. I could feel the wind in my hair. Instead of micromanaging every command, I had an autonomous worker. I could hand it something substantial, walk away, and let it work without me for a meaningful stretch.

My review moved up a level, too. Instead of approving individual commands, I was reviewing pull requests and, more often than not, rejecting them with specific, actionable feedback. That felt like the right altitude.

The results were… mixed. Output went way up, and I was pleased to be reviewing completed work rather than supervising every step. But the quality was mediocre. I was writing a lot of feedback, which led to heavy refactoring, churn, and wasted tokens.

Still, it was progress. I was finally spending my time on the right problem: How do you give an agent enough context and instruction to produce something you’d actually accept? Too little, and the possible solutions are practically endless. Too much, and the agent starts taking everything literally, losing the elegance of a well-considered solution.

Everything I describe involving --dangerously-skip-permissions (and anything dependent on it) is on my personal projects. At Simple Thread, we use auto-mode and operate within the company’s security policies. I don’t bypass permissions or security controls on company projects.

Stage four: The Team

I’d picked up two things along the way. First, agents seem to do better work when they’re told up front that their output will be reviewed. Second, an independent review pass produces better code. I read both of these somewhere I can no longer find, so treat them as folklore rather than research. But my own experience has borne them out enough that I’ve built much of my system around them.

So, I stopped running one agent and started running two. One implements, the other reviews. Of course, managing multiple agents meant I needed a better way to keep track of them. I knew tmux was the answer. I tried it. I drowned. I spent more time learning (and forgetting) keyboard shortcuts and fighting configuration than I spent actually getting work done.

Then I found Herdr.

It’s a TUI and, critically, it supports using a mouse. Everything I’d struggled with in tmux (panes, sessions, moving between running agents) suddenly became discoverable. I could see what was happening and click my way around instead of memorizing keyboard shortcuts. The tooling finally got out of my way.

With Herdr handling the mechanics of managing multiple agents, I could focus on how they worked together. I plan work with a main orchestrating agent, which delegates implementation to other agents. When an implementing agent opens a PR, the orchestrator hands it to a separate reviewing agent for an adversarial review. If the review fails, the work goes back for corrections. If it passes, the PR gets merged. The reviewer works against the original Shortcut or Linear ticket, and the process can repeat up to three times before escalating to me.

Stage five: The Shop

Eighteen months ago, the question gnawing at me was: “How do I stop being tied to an individual agent?” Once the setup matured and agents could work for hours at a time, a new question emerged: “How do I stop being tied to the machine doing the work?”

There are lots of ways to answer that. I bought a Mac mini. Enough RAM and CPU to handle most of what I’m throwing at it today, with room to expand if I need to. Maybe that means something with room for more GPUs for more demanding local inference, or more smaller machines to run additional agents.

But adding another machine introduces another problem. Herdr had served me well, but its view was limited to the machine it was running on. I’ve recently moved to Standard Code, which is a TUI that gives me a more holistic view of agents running across multiple machines. Unlike Herdr, Standard Code is built on tmux rather than a custom terminal implementation. So, somewhat ironically, I’ve ended up back where I started, only this time the tooling makes tmux manageable.

And the real improvement is that I no longer need to SSH into individual machines to manage the work. Standard Code connects to them over sockets, giving me a single place to see and manage my agents, wherever they’re running. I can plan the work, set everything in motion, and close my laptop. The agents keep working, whether I’m sitting at my desk or not.

Where that leaves me

Of all the controversial topics surrounding AI, and there are plenty, who actually writes the code is dropping pretty quickly to the bottom of the list. At my day job, I still write a little code. On my own projects, I’ve stopped writing code almost entirely.

Eighteen months ago, that sentence would have horrified me. I still have mixed feelings about not writing code myself, but I’ve come to appreciate what I can accomplish without doing it. These days, I spend my time planning, designing, and thinking deeply about the problems I’m trying to solve. And I have what amounts to an automated software shop at my fingertips, twenty-four hours a day, ready to act on those plans.

I’ll be straight with you, though… it isn’t free.

I don’t have a huge sample to draw from because, frankly, I’m the bottleneck. I can’t generate enough well-specified work to keep the system busy, so it sits idle more than it runs. But when I do feed it properly, the results are interesting. Algorithmic work, deep in the bowels of a project where the problem is well-defined and correctness is relatively easy to verify, it absolutely crushes. What comes back is genuinely excellent.

UI work is another matter. I’ve experimented with a few approaches, but I still don’t have a reliable process for orchestrating it. I’ve had some genuinely good results, but they’ve come about almost by accident. I’ll get a foothold on something I like, work through a few iterations, and eventually the agents seem to find their stride. The results can be quite good, but I haven’t figured out how to make that happen consistently.

Then there’s the upkeep. Underneath all of this is a fairly bespoke CLAUDE.md and a collection of skills I’ve accumulated over the last six to twelve months. They’ve been instrumental in getting the system to where it is today, but I fear they are problematic at times. As the agents improve, instructions that were useful six months ago may actually be getting in the way today. So, I’ve been reviewing, refining, and paring them down for some time now, and there’s still plenty of bloat to remove.

The Next Layer: Audits

The time I get to spend working on this system is mostly weekends, which means my Mac mini runs hot for two or three days a week and then sits mostly idle for the other four or five.

So, I’ve started using some of that idle time to audit my codebases.

An agent can implement a feature, write perfectly good code, pass an independent review, and still introduce something that doesn’t belong. Maybe we solved a similar problem six weeks ago, somewhere else in the codebase, using an entirely different approach. The new implementation works, and the reviewer approves it, but now we have two ways of doing essentially the same thing.

The audits look across the broader codebase for inconsistencies, duplication, and opportunities to clean things up. I run them manually, read through the resulting report, and then hand it to my orchestrator. So far, I’ve been telling it to take the whole thing and work through the findings using the same implement/review cycle I’ve already described.

If something in the report is ambiguous, the orchestrator can skip it and report back when the rest of the work is done. I’d rather have it make progress on the things it understands than get stuck trying to resolve something that needs my input.

I’ve had remarkably good results with this approach. It’s another layer of review, but one that’s looking at the codebase as a whole, rather than evaluating individual changes in isolation.

Onward…

A reminder, dear reader: in 2024, I was asking ChatGPT the odd question and otherwise coding like a caveman. As 2026 draws to a close, I’m in command of a legion of agents who never get tired and, much to my surprise, write really good code really quickly.

What I’ve discovered along the way is that none of these stages was the destination. Every time I thought “This is amazing!” I found the next constraint within a week. Typing, then attention, then review, then hardware, and now upkeep.

It’s worth noting, too, that in the ten days or so that I’ve been working on this article, my setup has already changed. I’ve moved to a different orchestration tool, introduced regular codebase audits, and continued stripping away instructions that were essential just a few months ago. Parts of what I wrote when I started were already out of date and needed revising.

I have no idea what my setup will look like six months from now. At this rate, I’m not entirely sure what it’ll look like next Tuesday. But I do know that every time I think I’ve reached the limit of what these agents can do, I discover that the limit was mostly in how I was using them.