This series keeps mentioning that the project is one human and one AI pair, 974 commits in the first month. This chapter is the workflow itself: what each party actually does, the rituals that made the speed safe, and the failures, because a collaboration writeup without failures is an ad.
The division of labor, honestly
The AI wrote most of the code, most of the tests, most of the documentation, and every first draft of most things. The human made every decision that mattered: product taste (a storage-dedup scheme was built, then withdrawn on a risk judgment; an entire UI-framework port was built and dropped on look and feel), every merge and every release, and all of the real-device testing. The clean way to say it: the AI supplies breadth and endurance; the human supplies judgment and reality. Neither is the junior partner, and the failure mode of pretending otherwise runs in both directions.
Ritual one: decisions are written down when they are made
The repo's docs directory is a running decision record: design docs that become dated decision records, and handoff documents written for whoever picks the work up next, including a different AI session on a different machine. When a Windows-side instance needed to validate a release, it got a handoff file stating the checklist, the risks, the house rules, and what done means. This is not bureaucracy; it is how a collaboration with no shared long-term memory stays coherent. If your pair programmer forgets everything between sessions, write the project down and the forgetting stops mattering.
Ritual two: the pair never marks its own homework
Before anything significant merges, independent review passes run over the full diff, prompted adversarially: construct failure sequences, verify against the code, try to refute the fixes. This is not ceremony. On one architectural change, three successive review rounds each found real bugs, including a reference-count leak that would have silently disabled the very feature being shipped, and a cleanup path that could delete a file it should not. The verification pass then found holes in the fixes themselves. External validators hold the other line: the PDF merger answers to Acrobat and qpdf, the eDiscovery writer answers to Relativity's published validator, and the crypto answers to independent OpenSSL. The pattern generalizes: an AI pair is excellent at satisfying the checks you give it, so the checks must come from outside the pair.
Ritual three: green is not done
The thesis of two chapters deserves its plain statement. Every serious field bug this month was found by a person with a real phone or a real Activity Monitor, minutes after a fully green suite: the freeze, the crawl, the lingering processes, an archive landing in the wrong directory. And the test fixture that should have caught the image-pipeline stall did not, because its photos were 2 KB fakes; the fixture encoded our assumptions and then confirmed them. The working rule: automated gates are necessary and never sufficient, and every done claim names the human verification still owed. Our tester with the 84,000-message thread is not a nice-to-have; he is part of the release process.
What this cost and what it bought
The honest ledger. Costs: the human reviews a lot of prose and diffs; discipline about branches, merges, and claims has to be enforced every day; and an AI pair will occasionally do something confidently wrong at speed, which is why the rituals exist. Purchases: a solo developer shipped, in one month, a device-sync engine, an export pipeline hardened against Acrobat, a cryptographic verifier, a licensing service, a Store submission, and this documentation. The tools are real. The judgment they demand is also real. That trade, stated plainly, is the most useful thing this series can tell you.