How I build it with AI agents

Who does what

How a change gets to the drum

1. Write the target down

   Requirements say what the robot has to do and where each number came from. Decisions record what was chosen and why. Agents cite these files instead of restating them, so each target lives in one place.

2. An agent writes the change

   The stroke state machine is plain C++ with no hardware dependency, so it compiles on a laptop and gets checked against the bench's measured parameters before it goes anywhere near the robot.

3. The simulation plays it first

   A preflight compiles the robot's actual planner and stroke code against a model fitted to bench measurements, then plays the piece. It reports which notes land late and what the grip spring can't do. Nothing moves until the piece is sent to the robot.

4. The bench runs from chat

   A session drives the rig one step at a time. Before any powered move, the agent tells me the angle, the direction, and where the move starts and ends, checked against the slack in the wiring. Nothing moves until I say “go”. If a reading is out of range, it's flagged for me to look at.

5. Everything gets filed

   Each bench day gets a dated ledger entry with its printouts, data and recordings, and it ends with the state the rig was left in. A simulation result doesn't count until it has a data file, and every number on the project dashboard is read from one.

6. An agent reconciles overnight

   A scheduled job reads the day's session transcripts, marks work done where the record shows it, commits what it wrote, and turns anything it can't settle into a question for me. The agent only judges. A separate script makes every write and refuses the ones it isn't allowed to make, like changing a requirement.

7. Questions wait for me

   If the answer is already in the repository, the agent applies it and shows me so I can reverse it. If it needs my decision, it waits until I answer it on the dashboard.

8. The next session picks up where the last one stopped

   A handoff records the outcome, the evidence, the rig's physical state and the next step to run. It's printed into the first message of the next session along with the overnight report, so nobody has to reconstruct the bench from memory.

Rules that came from mistakes

Most of these rules exist because something went wrong first.

• An agent wrote that a design question was settled when nobody had decided it.

  Now there's a table of which file answers which question, and corrections get logged the day they're found.

• One measured result showed up with four different values in four files.

  Now experiments write a data file beside their report, and every number shown is read from that file.

• I scrapped a rewrite of the project's tooling after 34 hours and 38 commits. It had run about ten agents in parallel before the design was settled, and it invented vocabulary I never used.

  Now parallel work waits for a settled design, nobody creates a new kind of record unless I ask, and a reviewer's “no” stops the plan.

• A wrist calibration spin ran past the slack in the wiring and bound the encoder and finger wires. Two procedures described back to back had blurred together.

  Now every powered move is described start to finish before I say go.

• A wrist moved with its finger motor off, dragged the limp stick across the head and left it trapped off the drum.

  Now the firmware refuses to home a wrist unless that hand's stick is latched or held.

• The nightly agent asked me the same question in three reports, after I'd already answered it in a session.

  Now each question is a file with a permanent number. An answer stops the asking, and if I let a proposed answer sit through two asks, it applies itself on the record, where I can reverse it.

One night, 4–5 October 2026

Three agents worked at once that night, each in its own session, on overlapping parts of the firmware and simulation. This is the timeline from the commit history and the bench ledger.

1. Evening

   The first agent, on its own branch, raises the grip stiffness limit from 4 to 16 N·m/rad.

2. 01:15

   The second agent finishes pulled doubles, for doubles slower than the spring can bounce, and checks them in simulation. It's editing the same files as the first agent's branch.

3. 01:45

   The first agent's build has held up at the bench: the spring is stable from 4 to 16, and a double-stroke exercise plays clean at 260 to 280 BPM. Before merging, it messages the second agent that it won't touch the main branch until the pulled doubles are committed. The second agent doesn't commit without my OK, so it asks me.

4. 01:46

   A third agent re-runs the simulated test battery and asks me which build the next bench tests should use.

5. 01:49

   The pulled doubles are committed. The second agent tells the first, which merges thirteen seconds later, adjusts one simulation test for the new stiffness limit, and reports back.

6. 02:20

   The merged firmware goes onto the robot. The first takes are the double-stroke exercise at 260 BPM, 49 of 49 notes, and a roll from 120 to 260 BPM, 49 of 49. The roll's first double is the first pulled double on hardware, written 125.0 ms apart and played 123.6 ms apart.

7. 02:31

   I answer the night's three open questions from the dashboard.

8. 03:34

   The nightly reconciler files the night. It moves three items forward and flags five pieces of work the record didn't have yet.

9. 13:41

   The third agent re-runs its simulations on the build I picked.

This site

The progress posts here are drafted by the same nightly agent from the project record. They go up only after I approve them, edit them or send them back.