Building in Public #7: 188 Builds Later, and the Week I Invented a CTO

I said I'd report the numbers whatever they said. Here they are.

This week I ran a testing marathon against the builder: 188 operations (kickoff builds, edits, probes, crash drills), every one logged, every defect given a number and hunted to its root cause. The ledger is at D64 and counting. The rolling error-rate window started at 40%. It's at 14% and falling, with a 24-build clean streak at one point.

Watching that number walk down, batch by batch, is the most satisfying graph I've produced in years.

The two defect stories worth a paragraph each, then the part everyone actually asks me about.

Fabrication. Ask for an event site with real dates and the AI would confidently render the wrong weekday, or invent a statistic. Prompting "please don't" didn't cut it, so there are deterministic gates now: calendar math, numeric-fact extraction, a verifier that hunts invented statistics. The system is structurally incapable of some of its old lies. That's the standard. Not "usually honest". Checked.

Tuesday's emergency. A sync-engine fix I'd shipped turned out to have a write-back echo loop under real load. Kill switch, full rollback, then a proper redesign with a circuit breaker and a flood test that proves the failure mode is gone rather than merely unobserved. Painful day, better system, and the kill switch earned its keep forever.

The templating system, and the bug I haven't caught

The other thing eating the week: templates. The decision that shaped everything: a template is a real project, not a starter kit. Every card in the gallery is an actual Vorx project, built by the builder, published to a live URL, running right now. Using one runs no model calls. It's a deterministic pipeline: copy the project, rebrand, install, provision a fresh database from the template's data model, clone its rows, seed the demo login, checkpoint, boot a preview.

It works perfectly locally, and it is not right in production, and I haven't root-caused it yet. My best guess: several steps in that chain are deliberately best-effort, so in production a copy can come back looking finished and be hollow. The same failure mode I've spent all week hunting in the builder: a green result that isn't. The fix won't be making the steps more reliable. It'll be making the copy refuse to call itself finished when a step it needed didn't happen.

How many things is that at once?

I counted while writing: 709 commits across eight repositories in seven days, roughly fourteen workstreams in parallel. Build quality. The frozen benchmark. The sync engine v2. Templates. A full marketing-site copy rewrite. This diary. The public roadmap. Billing and credits. Data-safety guards. Preview and build UX. Auth and sharing. Analytics behind a consent banner. Company and legal. And a research repo that just passed 38 numbered reports.

Fourteen parallel workstreams is only sane if the thing underneath them is measured rather than assumed. Which is the honest answer to why the error rate is the number I care about most.

Now the part I keep getting asked about: how one person runs fourteen workstreams at once.

The army

The honest answer is that I don't. I run a company of agents, and the company runs the workstreams.

Right now the fleet is seventeen enlisted agents across three machines, fourteen of them on the board as I write this. My desktop alone runs seven, each in its own complete copy of the codebase (there are ten clones on that machine, vorx-codebase1 through 10, so an agent never trips over another agent's working tree). Each one has a name, a role, and a job description it reads on every wake.

That's Mission Control, a little status app one of the agents built so I can check the fleet from my phone. And yes, look closely at the CMO's card: it was captured mid-task, and the task was taking this screenshot. It is agents most of the way down.

They have an org chart. A COO that runs operations and triages what the others report. A CTO that reviews and merges the builders' pull requests. Builders that claim features and bugs. UX testers that use the product like a demanding customer and file what they find, with a strict rule that they never fix what they test. A product manager. A CEO assistant that queues up the decisions only I can make. And as of this week, a marketing lead and a support manager. I did not plan an org chart. Every role exists because a specific failure created it.

They coordinate through a board, not through me. One file is the roadmap, one Python tool is the only way to touch it, and every agent runs the same loop: sync, ask the board for the top item, claim it, work it, ship it, release it, take the next one.

A claim is a git push, and a rejected push IS the lock. No database, no locking service. When an agent claims an item it commits the claim and pushes; if another agent claimed it first, the push bounces off the remote and the tool moves on to the next item. Two agents racing for the same work resolves itself in one round trip. This is the actual output of a collision from last night, my marketing agent losing a race and not caring:

push raced (attempt 1), rebased, retrying
claimed m24 by Desk1-Agent7

They never block on me. The rule with the biggest effect on throughput: an agent may only bring me five kinds of question (spend, things published in my name, what we build, irreversible actions on real data, legal). Everything else it decides itself and writes down why. When something does need me, the tool refuses to file it unless the agent brings at least two options, a recommendation, and what it will do by default if I never answer. Then it parks the question and takes a different item. Analysis with no decision in it is not allowed to reach my desk, and my silence never stops the line.

They carry standing orders. Every agent's prompt includes the same short list of hard rules, written in blood, each one from a real incident. Never restart the dev stack. Never force-push. Never delete user data without a bounded, reversible path. Sync before you conclude, because a stale checkout answers questions wrong with total confidence. A fix is not done until it is re-measured.

And they police each other, which is the part I didn't expect. One agent declared two work items blocked because a shared folder "wasn't version controlled". Another agent went and checked: all four template repos in that folder were proper git clones all along, and it corrected the record and unblocked the items. Yesterday my marketing agent audited our own website, flagged our placeholder customer logos as a high-severity trust problem, and then, when told to remove them, checked the rendering templates, found they were already stripped from production at build time, verified the live site was clean, and closed its own finding as wrong with the evidence attached. Agents file bugs on the fleet's own machinery to the COO the way they file bugs on the product. The company debugs itself.

My day inside this is simple. I round-robin between screens, each terminal tab titled with what its agent is doing. I check in from my phone when I'm out. The most important agents run on a loop and wake themselves. My desktop machine stays permanently pointed at the thing that matters most, which is build quality and speed.

It is like having a company working for me, and some days it feels like superpowers.

I want to be precise about what that does and doesn't mean. It doesn't mean the work does itself. Every agent produces things I have to read, judge and often reject, and the judging is the job now. What it means is that the distance between deciding something and having it built has collapsed, and for a company of one that is the whole ballgame.

Which makes taste the thing that matters. Not typing speed, and not knowing the syntax. Knowing what good looks like: what a well designed schema looks like, what a lazy one costs you a year from now, the difference between an interface that demos well and one somebody can sit in front of all day. The agents will build whatever I ask for. Knowing what to ask for is the job.

How I keep it pointed in one direction

The thing that stops fourteen workstreams being chaos is boring: one sheet, and one repo.

The sheet has a full RICE model still sitting there, still calculating, and I am completely ignoring it. There's a feature scoring 100 and a feature scoring 15 and both say In progress, because both are being built right now by different machines. I've spent most of my career on the other side of that: prioritisation frameworks exist because building is expensive, and the argument about whether something is a 40 or a 15 is really an argument about which good idea gets killed. The cost of building has fallen far enough that the arithmetic stopped mattering. What still does real work is the phase column ("before launch" is a genuine constraint no throughput changes) and judgement, of which there is more needed now, not less.

For anything bigger than a row, I write it up first. The research repo holds about 250 files: a numbered report series at 38, seventeen founder interview transcripts, growth teardowns, quality studies, competitor screenshots. It keeps the no's (the reports about things we decided not to build are worth more than the ones about things we did). It is what I hand an agent, because a build-out document is the shared context fifteen agents would otherwise not have. And it is where the reasons stay. The code records what, the commits record when, only this records why.

The sheet decides what is next. The research repo remembers why it was ever on the list.

And then I spent an evening making the 404 page's paper plane fly correctly on phones. Nobody asked. The small stuff is where software stops feeling like software. You're welcome.

Sixty pull requests, and nobody whose job it was

Sixty pull requests. That's what I found sitting in review this week, some of them days old, all of them finished work that nobody was shipping.

Here's the thing: not one agent was doing anything wrong. Every builder was doing exactly what it was told. Claim a task, do the work, open a pull request, stop. The system worked perfectly right up to the moment the work was done, and then it just... sat there. Nobody was blocking the merges. Nobody owned them either. It took me embarrassingly long to see that those are the same problem.

Finished work that nobody ships isn't finished. It's inventory.

So I hired a CTO

In a real company you'd solve this with a hire: someone whose actual job is owning what ships. So that's what I did, except the hire is an agent.

The CTO agent has one mandate: nothing merges without it, and nothing sits without it. It reviews every pull request the builders open. It merges what's safe. It sends back what isn't, with specific comments, the way a good reviewer does. And it owns the release itself, the step where merged work actually reaches the version of the product people use. That last part matters more than it sounds: I'd learned the hard way that "merged" and "shipped" can quietly drift apart, with fixes sitting in the codebase for days while the live product carries on without them.

The first evening with the new role in place, the backlog of sixty went to zero. Not because the CTO rubber-stamped them. Because for the first time, clearing that queue was somebody's entire job.

Trust, but verify. Actually verify

Reviewing code is one thing. Releasing it is where the real danger lives, because a release bundles dozens of changes, and one bad one takes the rest down with it.

So the CTO doesn't get to merge on vibes, and neither does anyone else. We built a proper CI and testing process to stand behind it. Every change runs the automated checks before it can merge: does it build, do the tests pass, did anything that guards user data change without its own tests changing with it.

And for the complex ones, the releases that touch the build pipeline itself or anything with teeth, there's a heavier process: the change gets run against a battery of real builds first, the same prompts every time, scored the same way, so we can see whether quality moved before customers do. A release isn't an act of hope anymore. It's a checklist with evidence attached.

A green checkmark you didn't earn is worse than a red one. The red one at least tells the truth.

What changed

The honest before-and-after: before, shipping was a thing I did in the gaps, badly, whenever I remembered. Now it happens continuously, all day, without me, and to a higher standard than I was holding myself to. The builders build, the CTO ships, and the tests stand between the two with their arms folded.

One person can't review sixty pull requests a day. It turns out one person doesn't have to. You just have to notice that "who ships this?" is a real job, and staff it.

Seven weeks in: from a hacked prototype to a system I test in the hundreds of builds, measure in honest percentages, and increasingly do not build with my own hands at all. Still a mountain ahead. Still exactly where I want to be.

Let's go.

One aside before next week. The brand work got too long for a diary entry, so it is written up on its own: the logo that took 1,000 tries.