
Tailor runs experiments on our customers' web pages. It works out what's worth testing, writes the variants, and ramps up whatever wins.
Which means our code is already running inside pages we don't own. We can't restart them, and when we break something we break it in front of our customer's customers. There's a Chrome extension too, in the browser they use all day.
Agents write most of what we ship now. Five things changed so the work stopped waiting on us.
A green test suite tells you almost nothing
You can read our code and tell whether it's correct. You can't tell whether it works. Those are different questions when the page belongs to somebody else and changed last Tuesday.
We have plenty of tests. They run against pages we wrote, and our failures happen on pages we didn't. Most software is cooking in your own kitchen. Ours is catering in somebody else's, and you don't find out what's in the cupboards until you get there.
So checking anything means running the whole product: backend, dashboard, the code we serve into customer pages, a build of the extension, its own database and URL. We call that a harness.
An agent without a harness hands you a guess
We each had one harness, which was plenty back when you could only work on one thing at a time.
Then agents made the writing fast and the queue moved somewhere I hadn't expected. I wasn't the one waiting. I was reviewing the last change, and the agents were stopped, finished and idle, because the harness was busy showing me something else.
Give an agent a harness of its own and it opens the page, sees the headline hasn't moved, fixes it and looks again, over and over before I see anything. Without one it hands me its best guess and I become the place everything queues up.
Harnesses should be borrowed, never owned
Building more of them helped, right up until the laptop ran out. A harness is heavy, and a machine only holds so many awake at once.
So we stopped keeping them awake. An untouched harness parks itself: the process exits, the memory comes back, and its address still works, so the next request wakes it. Most are asleep at any moment, which is what let one laptop carry far more agents than it could ever run at once, each with a full harness of its own.
Then we stopped letting a harness belong to one piece of work. One used to sit reserved for something you'd abandoned while the agent you actually cared about waited for somewhere to run. Now they're a pool: ask, and you get whichever is free. Nothing gets taken from an agent that's still working.
Renting more capacity wouldn't fix it
The obvious answer is to put harnesses in the cloud and stop caring what they weigh. We can't.
The agent does its looking through Claude in Chrome, so the browser has to be signed in to our Claude account, and to everything else it needs to reach. That's a machine somebody set up by hand, not one you start on demand.
The laptops are already paid for, so the economics suit us for now. But the wall we hit next is a browser session, not a bill.
Running many agents at once is a management problem
With the pool in place nobody waited for a harness again, and we started agents as fast as we had work for them. That created a problem I hadn't considered. They don't report in, and by the time you notice one has gone the wrong way it's been going that way for an hour.
So we started managing them the way you'd manage people.
Everything gets a ticket before the first edit, including investigations that produce no code. We had that part wrong at first: an investigation leaves no pull request, so without a ticket it leaves nothing at all.
And every night a job reads the day out of GitHub, Linear, our call recordings and the sales pipeline, and writes the standup nobody wants to write. The rows are people rather than agents, so work you directed appears under your name the same as work you typed.
What that adds up to
We'd had harnesses for a while. The three that changed our pace all landed inside a single month: letting them sleep, handing them out from a pool, and running agents the way you'd run a team.
Below are my own merged pull requests over that month, mostly written by agents and reviewed by me.
- 22 July to 1 August: 78 pull requests
- 1 to 11 August: 87 pull requests
- 11 to 23 August: 141 pull requests
Each change made the next piece of work cheaper to start, so the pace kept accelerating. The last ten days ran at nearly double the first.
What we got back
What I didn't expect was what it freed up. When how to build something stops being the hard part, the time goes to what to build, and that conversation happens with customers. We work with our design partners close to real time now: someone describes a problem on a call, and the improvement is in front of them in days. Because we build for everyone at once, the fix for them ships to every customer we have.
Quality went up as well. An agent that can check its own work catches the obvious mistakes before a person ever sees them, so what reaches review is a second or third draft rather than a first.
None of that came from writing code faster. It came from a pool of harnesses, a ticket for every piece of work, and a standup nobody has to write. Plumbing and paperwork, and between them they let a handful of us build at close to the speed we can think.
Figures are from our own GitHub history, 22 July to 22 August 2026.


