José Ochoa

Process · How I work with AI

I own the what and the done. Agents own the how, and show proof.

This is the method behind the bakery build, written down after launch as a playbook. Below are its rules, the loop every change runs, excerpts from the real records, what the retro changed, and how this site was built the same way.

Ten principles fit on one page

  1. I own the what and the “done”. Claude owns the how, and shows proof.
  2. Proof, not summaries: the command and its output, and a screenshot for any screen change.
  3. The builder never grades its own work.
  4. Small steps, committed often, easy to undo.
  5. Staging first, always. I do the production push.
  6. Care in proportion to risk. Words and looks get a quick check; logic, money, data and permissions get the full gate.
  7. Lean beats thorough-looking. Every doc, test and agent costs something.
  8. One job per session, started from a short brief.
  9. Know the way back before going forward.
  10. I understand the load-bearing parts: money, data and access.

Every change runs the same loop

A change starts as a brief of one page or less and ends with my word on staging. The risk decides the middle: wording and layout get my staging check, while logic, money, data and permissions get a scored review.

  1. I own the what

    1. Briefone page or less
    2. PlanI say yes or no

  2. Agents own the how, and show proof

    1. Build in a lanesmall steps, committed often
    2. Fresh review9/10 to pass, at most 3 roundsBelow 9, the change goes back to the build with a new reviewer. The small lane skips this step and goes straight to staging.
    3. Stagingstaging first, always

  3. I own the done

    1. My phonemy check, on staging
    2. “passed”my word on staging
    3. ProductionI do the push

The evidence is in the records, not in adjectives

Three excerpts from the bakery repo, trimmed for length and otherwise as written, then two charts from its history.

A ticket prompt’s stop rules. Builders are told what is not a reason to stop:

docs/agents/session-prompts/holiday-ticket-12-mixed-cart.md243 lines · ticket #49
# #49 (draft ticket 12) — Mixed cart: holiday is the third kind, and the department is decided at checkout## 0. The goal, in José's words## 1. Blocked by, and what you may assume has landed on `holiday`## 2. What you build (the ticket body on #49 is the contract; this is the order — seams first, screen last)## 3. The `--only` list (the check files found by grep in the `holiday` tree 2026-10-25 …)## 4. Check 47's `47.12.*` sections (engine seam — library / stored data in → verdict out)## 5. The browser pass on Local (own orders, every tick by own order id)## 6. The review lane — PILLARThe scored review of `docs/agents/review-loop.md` by a **fresh subagent** each round […] **9/10 passes; below 9 → fix every MUST FIX → a NEW reviewer; at most 3 rounds; never hand back below 9.**## 7. The Local lock, the stop rules, the 40% rule, the hand-back**Never push `staging`, `holiday` or `main`; never merge; never edit `STATUS.md`** […] Never `git stash`; never switch branches in José's checkout.A question only José can answer is not a stop: build the default named here or in the draft, record it as 'José's call (as built first)', go on. A bug outside this ticket: one 'found, not fixed' line under Owed, no fix.**The 40% rule:** past ~40% context before the ticket is done → stop at a clean pushed commit, write `docs/agents/handoffs/ticket-49-<date>-<time>.md` […] and tell the orchestrator `handoff #49 <hash>`.

Highlighted: the stop rules. Headings carry their line numbers; the rules sit in lines 210–217 and 221–243. Quoted in research/bakery-case-study.md, Part 4 §2.

A hand-off’s first lines. It claims no authority and states where everything is:

docs/agents/handoffs/ticket-24-2026-10-24-rebase.md94 lines · ticket #24
# #24 — the rebase onto `admin-polish` d51a677 (2026-10-24): hand-backNothing here is a decision; José's calls are in STATUS §4 / §6.1. Where things are`ticket-24-change` = `ticket-24-self-service` = **this commit's parent `daf95f5`** […] 23 commits on `admin-polish`**Not on staging.** The orchestrator fast-forwards `admin-polish` and `staging`; this lane never touched either.Harness at `f1aea63` […] `tests/cli/run.sh` **3893 passed / 2 failed** (check 18 A349; check 30's recorded intermittent variation-rename line, STATUS §4), `tests/cli/run.sh --no-theme` **3894 / 1**Local lane windows (all GO'd by the orchestrator, 'run ended' after each): 1 the five targeted runs; 2 the re-runs […] 5 the reviewer's three runs. Between windows nothing ran on the DB.2. The conflicts, file by file (what each resolution kept)3. Browser pass on Local (window 4) — all PASS4. The review (round 1 — `docs/agents/review-loop.md`, the hand-resolved-conflicts round)5. Owed after this

Highlighted: no authority claimed, and where things are. Quoted in research/bakery-case-study.md, Part 4 §2.

A register row. One of my decisions, recorded in my own words, typos included:

docs/assumptions-register.mdrow A960 · 1 of 1,594
A960 · **Nothing prints on its own; a Print click goes on the site's print list and a runner next to the Epson prints it** (José, 2026-10-20: 'i dont want tickets to automatically print when an order gets confirmed. just when me admin or a user (not yet created, bakery) clicks print'; the laptop reaches the printer only inside the co-op network, the site never does).

Quoted in research/bakery-case-study.md, Part 4 §4.

Figure 1 · Review rounds to a pass

Most changes passed review in one or two rounds

Mentions of “9/10 in N rounds” in the bakery records. A ticket can be mentioned more than once, so read the shape, not a count of tickets.

159 of 188 mentions are one or two rounds. In the retro’s words, every failed round found a real bug.
Source: grep across STATUS.md, docs/agents and docs/parity, computed 2026-11-07 Data

Figure 2 · Co-author trailers by model

1,482 of 1,503 commits carry a Claude co-author trailer

Co-Authored-By trailers by model on the bakery plugin, all branches.

Every commit is under my login; the trailer records which model wrote it.
Source: git log --all trailers, computed 2026-11-07 Data

The retro made the method cheaper

The bakery retro found that the process worked and cost too much: 1.09 million words of docs, nearly half the commits docs-only, and ticket prompts of 3,000 to 7,000 words. The playbook now sets budgets: a CLAUDE.md of 150 lines at most, a one-page brief and status, three parallel lanes, three review rounds.

Keep

  • A fresh reviewer, 9/10, capped roundsEvery failed round found a real bug.
  • Staging, then my phoneMy staging check caught a pricing bug that review had passed.
  • Record-and-ask; one decision at a time

Change

  • Ticket prompts of 3,000–7,000 wordsSize tickets to fit one session; keep briefs to one page.
  • Tests that pin markup and wordingTest behaviour; check looks by eye.
  • One test database shared by parallel sessionsEach lane gets its own data.

Drop

  • Essay commits
  • History in code comments
  • “Known reds”One “base red” was a real bug.

Each incident became a rule. Overlapping test runs corrupted 16 settings, so runs take a lock; an agent resolved 13 review threads, so agents now answer threads but never resolve them. And because “Understood” was once taken as yes, a session now confirms its scope in one line before acting.

This site was built in one night by one orchestrator and 15 worker terminals

The same method, smaller. On 7 November an orchestrator session opened four research lanes, read what they found, and wrote a 235-line spec that gives every file to exactly one lane. Then it opened five build lanes, each a terminal with one prompt (shell, charts, data, the Epoch study, and the words you’re reading), and after them the page lanes.

My playbook caps parallel lanes at three. This build ran four, then five at once, because no two lanes share a file, so no two workers can collide.

Figure 3 · This site’s build, by lane

One night from the first research lane to a deployable site

Start and end time of every lane, Pacific time, 7–8 November 2026.

Lanes run in parallel only where the spec gives them separate files; the page lanes waited for the shell and the charts.
Source: lanes/logs, via data/build-log.json Data

Models: the orchestrator ran on Claude Fable 5.1, and every worker from the build phase on ran on Claude Opus 5.5. Each lane’s prompt is published as written:

Every prompt and the spec, on one page

One exception to principle 5: this site went live the night it was built, because I asked for a hands-off run. What my phone finds becomes the first fix round, and it is logged on this page.