How 1-bit is built

The short version

I don’t type 1-bit’s code. AI coding agents do, several at a time, on a few Macs and a Linux box at home, and another agent orchestrates them: it turns what I want into written briefs, runs the reviews and the tests, and merges what passes, under rules I set. My part is deciding what gets built and what the rules are, settling the questions the process brings back to me, trying the result on real devices, and deciding what ships. If that sounds more like a change manager’s job than a programmer’s, it is, and that is the point of this post: the interesting part of building software with agents isn’t the agents. It’s the gates.

Who does what

A piece of work starts as a brief: a page that says what is wrong or missing, where in the code to look, what the fix must not break, and which tests must fail before the fix and pass after it. Before any coding agent sees it, the brief is reviewed by two other models, OpenAI’s Codex and Claude through the API, sometimes Google’s Gemini too. They read it against the actual code and say what is wrong with it. Most briefs come back with something.

Then a Claude Code agent takes the brief, on one of the machines, in its own copy of the repository, with its own simulator and its own build folder. It writes the code and the tests, runs them, and reports. Code never goes straight to the main branch. Each round gets the same treatment: two models review the change, the review bots on the pull request add theirs, every finding is checked against the code before anyone acts on it, and whatever holds up comes back as another round.

The last gate is the test suite. A change to the app’s code waits for the whole suite, run once everything else is settled, on the tree that will be merged, on two versions of iOS; a change to tests or documentation alone reruns what reads them. The bridge’s tests run on Linux, macOS and Windows. A change to the app’s code also gets a release build, because some mistakes only show there.

What the rules don’t settle comes to me: a design choice, a trade-off, anything that changes what people see or what the privacy policy says. It usually arrives with two reviewers’ recommendations attached. Some kinds of question I’ve handed to those reviewers outright, and then their recommendation stands unless I step in.

What the gates catch

Some examples, all from the last few months.

A plan that would have broken the common case. A brief for how the app recovers playback in the car said: don’t retry while the phone is locked. Both reviewers pointed out that a locked phone is the normal state in a car, and that the app can read its saved credentials while locked, once the phone has been unlocked since it started up. The rule would have stopped the ordinary retry to fix a rare one. The brief changed before any code was written. That is where reviewing plans pays most: a wrong fix is cheapest before it exists.

A merge stopped on its way in. A change to the bridge’s web console had been approved, and its merge was queued behind the last review. That review found one more race in the page’s upload handling. The merge was stopped, and the fix became another round. The rule since: a pending merge is cancelled the moment a review finds a defect.

Two consultations, agreeing, both wrong. Two separate consultations once agreed that an Apple framework the app relies on was deprecated and should be replaced. It wasn’t. Another time a reviewer suggested a SwiftUI placement that doesn’t exist. A model can be confidently wrong twice in the same direction, so a claim about a framework is settled by reading Apple’s own interface files on the machine, not by a vote.

Two green changes, one red main branch. Two pull requests built in parallel each passed every test on its own. Merged together, they broke a check that counts across both. Since then, changes built side by side are tested together, on the combined tree, before either merges.

Green tests, broken data. A database migration once passed every test and still failed against a real library, because the failure only showed with data the tests didn’t have. A green suite can’t clear a symptom it never saw. That is why, before a release that changes what the app stores, the new build has to open a library written by the release before it.

Agents getting in each other’s way. Several agents share each machine. One, chasing a stuck process, stopped another agent’s build by its process number. The rule now: an agent only ever stops a process it started and recorded itself.

Public notes saying too much. A change that was otherwise fine described, in the project’s public notes, weaknesses it had chosen to leave for later. The reviews caught it. A weakness that isn’t fixed yet is named in public only by its backlog number.

What it doesn’t catch

Models reviewing models share blind spots. When two of them agree, that is a reason to look, not proof. The proof is a test that fails without the fix and passes with it, and a test proves nothing until someone has watched it fail. Tests catch what they model, and real devices still find what nothing modelled, which is why some checks only count when they are done on a phone, with a real DAC, by me.

The reviewers are also only as good as the brief they’re given. A brief that leaves out the case that matters gets a confident, wrong answer. Writing the brief is the part of the work that got harder, not easier.

Rules that outlive the session

An agent’s session ends, and what it learned doesn’t travel to the next one, on another machine or another account, unless it is written down. So every rule the project learns is written next to the code it governs: short rules in files that load when an agent opens that part of the code, each pointing to a longer history of why it exists and what was tried first. When an agent’s work contradicts one, a reviewer usually notices. The files have size budgets, because an agent can’t follow rules it can’t read, and a checker fails the change when one grows past its budget.

Why this looks like my day job

By day I run IT service management in a regulated industry. The vocabulary is different, but the shape is the same: changes are planned before they are made, reviewed by someone other than their author, tested against agreed evidence and released deliberately, and when something breaks, the cause is written down so it doesn’t happen twice. Building 1-bit with agents is that discipline applied to a team that never sleeps, starts every session from what was written down, and is occasionally, fluently wrong.

The code is cheap now. The evidence that it does what it should is where the work went.