SailMOB, built by one person and a crew of AI agents.

In SailMOB you trim, tack, and cover your rival, and the AI bots sail by the same rules you do. The difficulty came from keeping the physics, the racing rules, the payments, and the iPhone app working at once while one person moved between them.

The sections below cover the build order, the sailing research behind the physics, the testers, and the safeguards that let one person and a set of AI agents keep a team's pace.

Physics first, then the boat, then the fleet

The build went in a set order: wind and water first, then one boat that sails true in that wind, then a fleet of bots beside it, then the rules for when boats meet, then the tactics that use those rules. Each layer rests only on the one below, so each could be finished, tested, and trusted before the next went on top. Tacking never had to be fixed while the wind was still wrong, and bot tactics were never tuned against rules that might themselves be wrong.

The simulation came first for a second reason. AI agents build against it, so it had to be right before any of them started on the layers above.

Sailing sets the standard

Much of the simulation work was research into how wind behaves and how hulls accelerate. Boat speed comes from polar curves, the charts of expected speed at every wind angle that racing sailors navigate by. The chart that tells a bot its fastest angle is the same one the game's physics follows, so the bots and the world agree about what a boat can do. Wind shadow from a rival's sail, the lee-bow effect, puffs, and shifts are all in the game, because a sailor would miss them at once.

The expert is also the builder

The person building SailMOB spent twenty years teaching sailing, so requirements never went through a game of telephone, and there was no week-long wait to learn what "mark-room" means in an odd situation. That also set the bar for the game's rules, which are written straight into its tests. Does the boat that must give way keep clear, and does the game call the encounter the way a sailor would?

A test fleet, ages 8 to 15

It's hard for an expert to see what beginners trip on. The other testers are family, nieces and nephews aged 8 to 15, all learning to sail on the water. They're who a sailing-school product has to serve. When a kid who just learned what starboard tack means gets confused by a penalty call, the problem is in how the game teaches. Between the sailor and the juniors, every change gets judged twice, for whether it's true and whether it teaches.

Races that replay exactly

A screenshot can't show whether a race felt fair, so the tests check something more concrete. Every bit of chance in the game replays exactly, from the same starting point to the same race, every time. On top of that, a race simulator sails whole fleets unattended and records the results. After a physics change it runs again, and a comparison with the last run shows what the change altered, so nothing shifts by accident.

The numbers point at causes. The simulator counts rule breaches by distance from the nearest mark. Fouls in a crowded mark rounding are part of racing, while fouls in open water mean a bot has got worse at staying out of trouble, and that count, broken down by leg and by tack, shows which situation to fix.

The Rules Lab

The game follows the numbered Racing Rules of Sailing, including right of way, mark-room, penalties, and exoneration. Getting them right started with writing out the classic racing situations, each with two or three boats set up in precise positions, such as a port boat crossing a starboard boat or an overlap formed at the zone.

That one set of situations does two jobs. An automated check replays every one and grades the game against a sailor's judgment. The in-game Rules Lab lets a player watch and sail those same situations, so the tests double as lessons. Each official rules case should come out the way the judges ruled it.

Divide the work like a crew

A sailing crew has fixed roles, and SailMOB's crew is three AI coding agents, each looking after one part of the game. They're directed and reviewed the way you'd run a small team. Each one stays in its own lane, so a physics change can't touch payments by accident and a screen tweak can't quietly change a racing rule.

Rules the computer enforces

SailMOB's written rules, its Constitution, run as a command. Before any work starts, one check confirms the things that matter: the right accounts are active, the local copy is up to date, and nothing the game depends on has changed underneath it. If anything fails, that gets fixed first. The same idea shows up as hard limits. Files that grow too large stop the build, and nothing can be saved straight onto the main copy of the code. The computer keeps the standard, so it doesn't depend on anyone remembering it at 11pm.

Ship, track, move

Solo work loses momentum when half-finished work piles up, or when the fear of breaking things slows everything down. A change counts as done when it works in the game. Anything put off goes on a tracked list. Work that can't ship today gets saved where it can be picked up, so nothing lives only on one laptop. When work in progress hits its cap, the next job is finishing something.

One place to look when it breaks

When something breaks for players, a scavenger hunt across five dashboards is the slow way to find out why. Every SailMOB error lands in one place first, and the rest (what the player was doing, a snapshot of the game at that moment) links back to that record. Finding the cause starts there and works outward.

Try it on your own system

Pick the part of your product or operation that everything else depends on, and ask whether anyone has proven it works. If the answer is a shrug, test that layer before building anything on top of it. Internal tools covers the build when you get there.

The other case study is the Boston Dynamics support center rebuild, where the hard parts were organizing content, connecting systems, and compliance.