This series started in July with a simple premise: a commercial security product for a mobile operator, built by a distributed team and one person running fleets of coding agents, with every claim checked against the git history. Five posts later the product is live, the incidents have their rules, and the fleet has moved on to a new job. This is the closing card — one lesson per post, in the order they were learned, with the link to the evidence.
Mock what you cannot run on a laptop — and let git correct your memory of what happened.
Seven operator-side systems mocked in ten days, one extraction that bent the cost curve, and one mock that took fourteen minutes. What I remembered about that fortnight and what the commits said were not the same story; the commits were right. Seven mocks in ten days.
When the real system is open thirty minutes a day, a mock turns testing from a gamble into a ritual.
A partner's shared test environment, physical SIM cards, a team across three time zones — and a daily window too short for anything but confirmation. The mock did not replace the window. It made the window the last step instead of the first. The thirty-minute test window.
Every session is a new hire. A decision that is not written where agents start reading was never made.
Day-one memory, year-five confidence. The same technology proposed for the fortieth time after it had been tried, removed and replaced — until the decision record moved to the one place every session reads first. My agents couldn't agree on a tech stack.
The oldest commit in the repo is a sales strategy, not code. Decide the business before the first mock.
1,662 lines of sales strategy and deep-link specification, six days before the first mock — and the subsystem they specified was built, moved and deleted in twenty-six days. The strategy outlived the code. That turned out to be the pattern, not the exception. The first commit was a sales strategy.
A security product has to break in a direction. Write it down, then check every layer the sentence must reach.
We chose fail-open for the customer in April. In June a phone that changed networks twenty-six times in four minutes found the one layer the sentence had not reached — and our first fix fired twenty times and restarted nothing. Fail open, fail closed.
Read together, they are one lesson wearing five coats. Every incident in this series was, underneath, a decision that existed in somebody's head and not in the place the next session — human or agent — would look. The mock nobody wrote down. The window everybody knew about. The technology already rejected. The strategy that predated the code. The direction of failure, chosen in April and unknown to the layer that broke in June. The fix in each case was the same shape: write the decision where the work starts, and make the record, not memory, the thing you trust.
The fleet that built this product now builds something else: the control plane that made the fleet governable in the first place — Saphan Studio. The notes continue, but their source changes. They will come straight from that fleet's own record: what it proposed, what a human approved, what was refused, and what it cost. The new series is called From the record, and the first note is about why code turned out to be the least durable thing in the repository.
The five posts above stay where they are. They are dated, they have their hours and their commits, and nothing in them will be edited to look better later. That was the rule of the series, and it is the rule of the next one.