The constraint

This one was an experiment with a game attached. I wanted to know how far a build could be parallelised across coding agents and still arrive as something finished — not a prototype with the interesting 80% done. A puzzle game is an unusually honest test: physics either behaves or it visibly does not, levels either solve or they do not, and a store review is a hard deadline that does not negotiate.

What I built

A bridge builder for iPhone, iPad and Mac. A deterministic structural solver written from scratch with no third-party dependencies, a live X-ray of tension and compression on every beam, 57 levels across eight worlds, and a level editor. Specified, directed and shipped in the margins of other work.

Decisions worth defending

• Deterministic, not a physics engine. A general engine gives you plausible motion and unrepeatable results; a solver gives the same answer every time. In a puzzle game a bridge that holds on one run and fails on the next is not a difficulty curve, it is a bug report.
• No third-party dependencies in the solver. The maths is the product. Owning it outright meant the X-ray view could show real tension and compression rather than an approximation of them.
• Parallel work needs a specification, not instructions. Agents working concurrently do not share your intent; they share what you wrote down. The bottleneck was never generation speed — it was how precisely the thing being built had been described.

What it proved

That the hard part of parallelising a build is not the agents. It is holding a coherent product in your head while several people who are not you work on different parts of it — which is the same problem as running a team, arriving sooner. It shipped, which was the whole point of the exercise.