Why I started building Fletch

The first time a coding agent finished a real task for me, I sat there for a second longer than I needed to. I had described a change in plain English, walked away to refill my coffee, and come back to a working diff. Not a suggestion, not a snippet I would spend twenty minutes adapting. A change that compiled and did the thing.

That feeling is why so many of us fell for AI coding agents in the first place. One agent in a terminal, doing careful work while you think about the next problem, feels like the future arrived early. For a few weeks that was enough. Then I got greedy.

Where one agent becomes three

The obvious move, once one agent works, is to run more of them. If a single agent can take a task off my plate, three should clear the backlog. So I opened three terminals and handed each one a job.

It fell apart faster than I expected, and not in the way I expected.

The agents themselves were fine. The problem was me, and the total absence of any process around them. I would tab into a terminal, see a finished diff, skim the first few hunks, decide it looked reasonable, and approve it. Then do the same for the next one. By the third terminal I was not reading diffs at all. I was pattern-matching on “this looks like code an agent would write” and clicking through. I approved changes I had not read. I want to be honest about that, because I think it is the most common failure in this whole space and almost nobody admits to it.

Then came the afternoon one agent decided the cleanest path forward was to reset my working tree. It was operating in the same checkout I had uncommitted work in. An hour of my own edits, gone, because I had given a probabilistic process write access to the one directory I could not afford to lose. That was the day the magic wore off.

The deeper issue was that I had no idea who was doing what. Three terminals, three branches in my head, no record of which agent had touched which file or why. When something broke I could not tell you which change caused it. I had traded one careful collaborator for a small crowd of anonymous ones, and I was the only thing standing between their output and my main branch. That is not a position you want to be the last line of defense in.

The bottleneck moved

Here is what those weeks taught me. For most of my career the scarce thing was writing the code. You knew what you wanted; the work was typing it out correctly. Agents made that part cheap. Almost free.

But the total amount of judgment a change requires did not go down. Someone still has to decide the change is correct, safe, and worth merging. When generation was the slow step, review hid inside it. Now generation is instant and review is naked, and there is a lot more of it, arriving all at once.

So the bottleneck moved. It stopped being code generation and became trust and review. And more agents, pointed at that bottleneck without any discipline, do not relieve it. They flood it. You get slop faster. The speed is real and the speed is the trap, because it outruns the one human whose attention still has to clear every change.

That reframed the whole problem for me. The interesting question was never “how do I run more agents.” It was “how do I stay in control of the ones I run.”

What real engineering always needed

The answer, when I finally saw it, was almost boring. AI coding needs the same things real engineering has always needed. We just skipped them because the demo was so good we forgot they were load-bearing.

It needs a process. Not a rigid one, but a repeatable one: a way to say “features get planned, built, reviewed, and tested, in that order, every time” instead of improvising the shape of the work on every task. When the process is the same each time, you can trust the output the same way each time.

It needs isolation that is real, not polite. An agent should not be able to touch my working tree, or my repo’s history, or another agent’s work, even if it tries, even if it is wrong about what it is doing. Not because I distrust the model, but because “please do not reset my working tree” is not a safety mechanism. A boundary the agent physically cannot cross is.

And it needs a gate that a person actually holds. Not a checkbox I click on autopilot after skimming two hunks, but a review step built so that reading the diff is the path of least resistance and nothing merges until I have cleared it. Control, not autopilot. The human in the loop only means something if the loop is built so the human cannot fall out of it.

That belief is what Fletch is.

What that turned into

Fletch runs your coding agents, the ones you already use and pay for, Claude Code, Codex, Cursor, OpenCode, in parallel and in real isolation. Each agent gets its own private checkout of your repo under a sandbox that denies writes by default, so two agents can never edit the same file and none of them can reach your actual working tree. The thing that clobbered my afternoon is not a risk you have to remember to avoid. It is not possible.

When a task deserves a real process, you can chain agents into a deterministic workflow, plan, build, review, test, with a gate at every step that the engine itself checks rather than trusting an agent’s word for it. And nothing merges until you say so. The review gate is the point, not an afterthought bolted on at the end.

That is the product in one paragraph, and I am going to leave it there, because this post is about why, not how. The rest of this blog is where we get into how: how the sandbox actually works, what makes a workflow deterministic instead of just a prompt chain, what we have learned running fleets of agents on real code. I started building Fletch because I wanted the magic of that first finished diff without the afternoon I lost a few weeks later. It turns out you can have both. You just have to bring the discipline.