The Word Warp Drive

The core aims at what you wrote. Whatever you didn't write, it fills in with the most plausible guess, and plausible is not the same as what you meant. "Improve the login page" has a thousand plausible completions; the one you get is whichever the training text made typical, and "simplify" is a very typical instinct. So say what done means first: a short list of criteria a reading can confirm, written before the first edit.

Put the list in a file, not in the chat. Chat gets compacted and sessions end (Deck 3, Section 6); a plan file is re-read every pass and survives both. And keep it short. A forty-page brief is not more precise, it's more diluted: every criterion competes for the same attention budget (Deck 1, Section 4). Toggle criteria on the desk below and watch which parts of the mission report were aimed at and which were guessed.

"All 14 tests pass" is the most plausible last line of a fix. The core will write it whether or not tests ran, because that's the shape a fix report takes (Deck 1, Section 6, the holodeck). It isn't lying; it has no way to know. A report is text. A reading is something a tool brought back from the world: the runner's output, a screenshot, a diff, a URL that returned 200.

So separate the two on purpose. Ask for the reading behind every claim, and better, install protocols that produce readings without being asked: a hook that runs the tests after each edit and pastes the result into the context (Deck 3, Section 5). Then a claim that skipped its reading has nowhere to hide. Below is a five-line mission report. Every line is plausible. Check the sensors.

Every step the crew takes is a bet (Deck 1). Bets that land on other bets compound: a wrong assumption at turn 3 shapes turns 4 through 40, and by then the work is a long way from the course you plotted. Nothing inside the loop notices, because each step was plausible given the last one. The distance only shows up when something outside the loop measures it.

So measure often. Check the readings after each small hop, and checkpoint each verified hop (a commit) so a bad step is reverted, not repaired. Autonomy is a dial, not a virtue: it's the number of steps between checks, and the right setting depends on how much a wrong step costs. Run the plot below at different check intervals. The noise is identical every run; only the correction changes.

By turn forty the bridge has absorbed your assumptions. Turn 12 said the store API returns dollars, and every pass since has re-read that line and agreed with it (Deck 1, Section 4). Ask the same context to review its own diff and you'll get the review you'd give yourself: approval, with reasons you already believe. That's not a second opinion. It's the first one, twice.

A first officer is a reviewer with an empty context (Deck 3, Section 4): the diff, the orders, the relevant doc, and nothing else. It can't inherit the bridge's blind spots because it never saw the bridge. A model from a different vendor shares even fewer of them. The same rule decides what to delegate at all: independent work, fully briefed, with a reading that can confirm it. Your own job shifts with this. You're less the author now and more the one who reads the first officer's report.

Sort every action the crew might take by two things: can it be undone, and who else does it touch. Reversible and contained runs on its own: tests, drafts, branches, deploys to a preview nobody else can see. Irreversible or outward-facing waits for a human: the deploy every user sees, a message to a real person, deleting data, spending money. And a few things you never delegate, no matter how well the crew is doing.

The trick is to move the line as far out as the readings allow, then hold it. A preview environment moves it a long way: the crew can build, test, and deploy a live copy end to end, and you review something real before the one step that can't be taken back. Automate to the boundary. At the boundary, it's your voice. Sort the eight actions below and compare against the defaults.

The words of working well with an agent, each with its address on this deck:

Four rules fall straight out of these five sections, and they're the rules people shipping with these tools keep re-learning the expensive way:

• Write done before engage. A short list of checkable criteria, in a file, before the first edit. Anything you leave out gets the plausible guess, and the plausible guess is usually "simplify."
• Readings over reports. A report is text the core wrote; a reading is what a tool brought back. Wire the readings into the loop so they arrive without being asked, and ask anyway.
• Short hops, checkpoints. Errors compound across unchecked steps. Check often, commit each verified hop, and revert instead of repair. Autonomy is a dial; set it by what a wrong step costs.
• Automate to the boundary and hold it. Reversible and contained runs itself. Irreversible or outward-facing waits for your voice. Previews move the line outward; nothing removes it.

That's the chair. The core is still the guessing game from Deck 1 and the crew is still the loop from Deck 3. What changed is that the captain now writes down the destination, reads the instruments instead of the log entry, corrects in small hops, listens to a first officer who wasn't in the room, and keeps one hand on the line nobody else may cross. Used that way, the crew ships.