The Flight Recorder: a git primer for AI Pilots
Supplement for the Build rung · usable as a 40-minute lab station or a self-serve read
Who this is for: anyone who reached Rung 5 (Build) — or finished Lab 0 and asked their copilot to build something. The moment that happens, git enters your life whether you invited it or not: your copilot uses it constantly. This primer exists so you understand what it's doing on your behalf. You will not memorize commands here. You will learn six ideas.
The honest framing: you don't need to operate git — your copilot types the commands. You need to supervise it, the way you supervise everything else on the ladder. A pilot doesn't build the flight recorder; a pilot knows what it records and how to play it back.
What git is (one paragraph, no jargon)
Git gives a project folder a memory. Every time you (or your copilot) say "save this state," git photographs the entire folder and files the photo in an album it keeps forever. Any photo can be revisited, compared with any other, or restored outright. That's it. Every other git idea is a convenience built on top of the album.
The six ideas, in pilot terms
| Git word | Say instead | What it actually is |
|---|---|---|
| Repository ("repo") | a folder with a memory | Your project folder, plus the photo album |
| Commit | a save point | One photograph of the whole folder, with a caption and a timestamp |
| Diff | what changed | A side-by-side of any two save points — the readable answer to "what did my copilot just do?" |
| Branch | a parallel draft | A copy-on-write draft of the project where experiments happen without touching the good version |
| Merge | accepting a draft | Folding a finished draft back into the good version |
| Push | backing up to the cloud copy | Sending your album to a second location (GitHub) so a dead laptop costs you nothing |
That's the whole vocabulary. When your copilot says "I committed the changes on a feature branch," it means: I made save points of my work in a parallel draft; the good version is untouched until you accept it.
Why pilots care (three real situations)
- "It was working an hour ago." Without save points, that sentence is a tragedy. With them, it's an instruction: play back the recorder, find the save point where it worked, restore it. Total cost: one request to your copilot.
- "What did you just change?" Never accept "trust me" from a machine that is confidently wrong sometimes (Rung 4's card applies to building, too). Ask for the diff — "show me what changed since my last save point" — and read the captions even when you can't read the code. Captions are the checking regime.
- "I want to try something risky." A parallel draft costs nothing. The rule that keeps every Build project safe: experiments happen on drafts; the good version only moves by accepting a finished draft. Ask your copilot to work that way and it will.
The three supervision habits
These are the git equivalents of "it drafts, I send":
- Save early, save often, caption honestly. Before any risky change, say: "make a save point first." After anything works, say: "save this as [what it does]." A save point you didn't make is the only one you can't return to.
- Read the caption before you accept. When your copilot finishes work and offers to merge or push, have it list the save points it made and what each one did. One minute of reading; it's the same human gate as every other rung.
- The cloud copy is your fire safe. Once a project matters, ask your copilot to set up the free cloud backup (GitHub) and push at the end of every working session. "Private by physics" people: the album can also live on a second drive in your house instead — tradeoffs as usual, your call.
Hands-on exercise (~40 min, works in any lab or at home)
Do this on the project from your first solo task (or any folder with a few files):
- Ask your copilot: "Give this folder a memory — set up git and make the first save point." Confirm it reports a save point exists.
- Change something small yourself (edit a sentence in any file). Ask: "What changed since the last save point?" Read the answer — that's a diff, and you just supervised one.
- Ask: "Save this as 'edited the intro'."
- Now break something on purpose — delete a paragraph, mangle a file. Ask: "Restore the last save point." Watch the damage vanish. This step is the whole point of the primer. Sit with how cheap that recovery was.
- Ask: "Start a parallel draft called 'experiment' and make the background red" (or any silly change). Confirm the good version is untouched, then either accept the draft or throw it away. Both should feel undramatic.
- Optional, if you're ready for the cloud copy: "Set up a free private backup on GitHub and push." You'll create an account; your copilot handles the rest.
Checkpoint: you can answer, in your own words, "what's a save point, and how do I get back to one?" If yes, you're supervising. Log it — this one belongs in the logbook.
When things go wrong (the calm table)
| Symptom | What it usually means | What to say |
|---|---|---|
| "Merge conflict" | Two drafts changed the same lines; git wants a human to pick | "Walk me through each conflict and tell me which side does what" |
| Scary red error text | Usually less serious than it looks; git errs loudly and early | Paste it to your copilot and ask "is anything lost?" — the honest answer is usually no |
| "Detached HEAD" | You're viewing an old photo instead of the live draft | "Get me back to the latest save point on the main draft" |
| Copilot force-pushed or deleted something | The one genuinely sharp edge | This is why the never-touch list from Rung 3 applies here: tell your copilot it must always ask before any command with "force" in it |
The one rule to keep
If you retain a single sentence from this primer: never do risky work without a save point, and never accept work you haven't seen the diff of. Everything else is vocabulary.
Questions, or want this as a guided lab station: handsinjars.com
Open source under CC BY-SA 4.0. · AI Pilot School