Lesson 24. Coinbase: A Plan Gate Turns One Giant PR Into Many Small Ones

A Coinbase engineer asked an agent to build a backend domain in one go, and it did. The result was a single pull request of 19 files and more than 14,000 added lines, and by the company's own account the code was correct and it merged. A frontend page went the same way: one request, one pull request touching 85 files (Coinbase, self-reported, observed 2026-10-28). Nobody reads fourteen thousand lines. Approving a diff that size is a handshake with the agent, and the review that was meant to catch mistakes turns into a formality that still eats a day of someone's attention. The cost had moved. Writing the code took minutes, while judging it had no ceiling, and the whole weight landed on the one engineer who had asked for the work. Coinbase did not answer with a stricter reviewer or a longer prompt. It changed what must exist before the agent writes a line. Decide now: your agent can produce a hundred-file change in an afternoon, and you have one reviewer who can read a few hundred lines in a sitting. What do you require before line one, and what is the largest pull request you will accept?

This lesson gives you factory/adopt/coinbase.md - a plan sign-off and PR size rule. It serves the Prove stage: you read a published case, keep the one mechanism the evidence supports, and write it into your charter as a rule a script can check.

What is actually going on

Coinbase has published two separate pieces, and they work at different layers. The first is a Figma-to-code agent for frontend pages and backend domains. The second is Mux, an internal tool that runs many agents side by side. Read them as one line with two halves: how a big job is cut, and how many agents run at once without trampling each other.

The cutting half starts with an engineer copying a prompt template, filling in the product, the route and the endpoints, and attaching one screenshot per design tab. In phase one the agent reads those screenshots, a rules document with an ordered checklist, and a reference implementation, then writes a component-by-component plan and stops. An engineer signs the plan before any code exists. Phase two builds a scaffold: folders, permissions, routing and stubs, run through every validation gate and opened as a draft pull request. Phase three starts one independent worker per component. Each worker implements its piece, runs the local gates (lint, type check, format, query compilation, tests with coverage thresholds), and opens its own small draft pull request aimed at the scaffold branch (Coinbase, self-reported, observed 2026-10-28). Humans then review the small pull requests and fix what the agent got wrong: domain edge cases, spacing, tests beyond the happy path, quirks of upstream services.

The diagram has two diamonds of human attention, and everything between them is automated. The plan is the first stop and the cheapest place to reject work, because a page of text costs minutes to refuse. The small pull requests are the second stop, and they are small on purpose.

The Mux half answers a different question: what happens when one engineer runs several agents. Each agent gets its own git worktree, branch and terminal, so nothing is stashed and nothing collides. Plugins send work to Coinbase's internal cloud agent fleet, deploy through its Codeflow system and run team review flows as reusable commands. The engineer reviews each agent's output as it finishes and merges it (Coinbase, self-reported, observed 2026-10-28).

The rule and its condition

Use a plan sign-off and a PR size cap when an agent can write more changed lines than your reviewer can read in one sitting. Otherwise skip both and let a single small pull request through, because ceremony on a ten-line change costs more than it saves.

The condition is a comparison you can run today: look at the largest diff your agent produced last month, then look at what one reviewer reads carefully in a sitting. If the first number is larger, you have the Coinbase problem. This is the same comparison Lesson 02 teaches for slicing a release, seen here through a company that published it.

What it does well: it puts the human decision where it is cheapest, and it keeps every later unit small enough to read. What it costs: a reviewer must learn to read a plan, someone must keep the rules document and reference implementation current, and the pattern fits repeatable work such as tables and product pages better than novel, judgment-heavy features, as the post itself says.

Worked case

Illustrative composite. Fernhill Payments, a seven-person team, must add a settlements dashboard: a backend domain over four upstream services and a frontend page with five tabs. The agent can build all of it in an afternoon. They have one senior reviewer, Priya, who reads about 300 changed lines carefully in a sitting, and two engineers who could review a smaller slice.

Decide now, before reading on: which of Coinbase's published mechanics do you copy first, and which one do you refuse?

Start with the mechanics, each tied to the lesson that teaches it.

First, the plan stops and a human signs it. This is the release-as-unit rule from Lesson 02, and it is the whole point of the page. Second, the scaffold fixes shared decisions once, so parallel workers cannot disagree about routes or permissions. Third, one worker per component, each with a small pull request against the scaffold branch; when branches do collide, Agent Fleets, lesson 13, on reconciling many branches, is the repair. Fourth, local gates run before any pull request opens, which is Lesson 08's rule of wrapping agent steps in deterministic nodes: lint and type checks do not need an agent's opinion. Fifth, the rules document, prompt templates and reference implementation are ground truth, and Coinbase says output quality tracks the quality of the reference. Those files govern every run, so they belong among the protected paths of Lesson 06 and deserve review like production code. Sixth, Mux's worktree-per-agent shows parallelism needs isolation before it needs more agents.

Now the one to refuse. In Mux the engineer who started the agent reviews and merges its output, and the post describes no second reviewer. That may suit Coinbase's setup, but it is the opposite of Lesson 04, where the author never holds the merge key. This course's judgment: copy the plan gate and the size cap, and keep a different person as approver on anything that touches money. Fernhill's settlements work is exactly that.

Hold the page in one line: "A diff nobody can read has been approved, not reviewed."

Here is the file Fernhill fills in. It is the deliverable, in full, with its validator.

Validator, which exits non-zero if any cell is empty, any placeholder remains, any sign-off blank is open, or the operator and the approver are the same person:

awk -F'|' '/^\|/ && !/^\|[- |]+\|$/ { k=$2; v=$3; gsub(/^[ \t]+|[ \t]+$/,"",k); gsub(/^[ \t]+|[ \t]+$/,"",v); if (v=="" || v ~ /<fill>/) { print "EMPTY: " k; bad=1 } if (k=="Agent operator") op=v; if (k=="PR approver") ap=v } /_{3,}/ { print "OPEN BLANK: " $0; bad=1 } END { if (op!="" && op==ap) { print "SAME PERSON: operator and approver"; bad=1 } exit bad }' factory/adopt/coinbase.md

Illustrative composite. Fernhill fills the table: the dashboard repo, Priya as plan owner, an integration branch named for the release, a cap of 300 changed lines and 12 files, and a CI step running git diff --shortstat against the integration branch. Priya signs a one-page plan on Monday. The scaffold lands Tuesday, with stubs for each of four upstream services and five tabs. Nine workers run Wednesday, each PR under the cap, each reviewable in minutes by Priya or one of the two engineers. The operator is Marco, and the approver for the settlement-posting PRs is Priya, so the validator passes.

The rejected path costs a week-long review of one giant diff that ends in trust. The accepted path costs Priya one page of attention on Monday and a rule she cannot waive on Wednesday.

Faded case

Skip to the open case if this is familiar. Coinbase is one of several published teams that cut work into reviewable pieces, but each puts the human in a different place. The table compares four, using only what each team published.

Sources, self-reported by each company: Meta, Airbnb talk, Intercom, observed 2026-10-28.

The rows that differ are the ones that matter. Coinbase and Intercom both treat size as a gate, but Coinbase cuts the work before code exists while Intercom's reviewer rejects a finished PR afterward. Airbnb's speakers saw the failure Coinbase designed against: trust loosened faster than review habits did.

Decide now: your team wants a size gate but has no plan stage yet. Which of the two, cut-before or reject-after, do you add first, and what does that choice cost you?

Open case

These are this course's judgment, not Coinbase's advice.

Solo developer. Copy the size cap and a plan file you sign yourself; skip scaffold PRs. Week one: set a cap from what you read before lunch and add the CI check.

Small team. Copy the whole plan, scaffold and worker pattern; skip a second approval layer until volume demands it. Week one: pick one repeatable feature type and write its rules document.

Enterprise. Copy worktree isolation and a named plan owner; skip company-wide rollout before one team has outcome numbers. Week one: log operator and approver per PR.

Regulated shop. Copy the plan sign-off as audit evidence; skip operator-as-approver entirely. Week one: store signed plans next to each release.

Scenario: your agent opens one pull request of several thousand lines for a new admin screen, and your only senior reviewer is away for two weeks. Write the three lines you would add to your adopt file today.

Where this breaks

Most of what you would want to know is not public. Coinbase has published no defect, revert, incident or cost figures for either piece, no mandatory-reviewer rules, and no size limit. The post's headline comparison of time and size is a chart image whose values this lesson does not print. The agent or model behind the workflow is not named. Read the whole case as a mechanism, not a measured result.

The numbers that exist are self-reported. The per-engineer comparison from Mux, roughly 39.6 merged PRs against 11.4 for others, comes with the authors' own warning that Mux users were probably already high-output (Coinbase, self-reported, observed 2026-10-28). Do not read it as a multiplier you will get.

A vendor's story about Coinbase sits at the other end of the evidence scale. Cursor's customer page says agents created 75% of Coinbase's pull requests and merged PRs per engineer rose 55% (Cursor, vendor-hosted, observed 2026-10-28). It says "created", not merged, gives no definition, and no first-party Coinbase source for these figures was found. Treat them as hypotheses.

The pattern also has a limit it states itself: it suits CRUD-style tables and product pages, not novel work. Humans still fixed edge cases, spacing and test depth after the agents finished. And a signed plan does not guarantee a correct plan; it moves the risk to whoever signs.

Key Takeaways

• Compare your agent's largest diff with what your reviewer reads in a sitting; act on the gap.
• Stop the agent after the plan and require a named human signature before code.
• Fix shared decisions in a scaffold PR so parallel workers build on one base.
• Cap pull request size with a CI check, and set the cap from your approver.
• Treat vendor numbers as hypotheses until a first-party source confirms them.
• A diff nobody can read has been approved, not reviewed.

What You Have Now

factory/adopt/coinbase.md - a plan sign-off and PR size rule. It is a filled header table, a signed-plan line, a cap checked in CI and an approver who is never the operator, validated by a short command that fails on any empty cell. Keep it beside the release slice from Lesson 02 and the review gate from Lesson 04. This is the Prove stage for one published case: you took the mechanism the evidence supports, left the claims it does not, and wrote the rule where a script can enforce it.

Further Reading

• Coinbase, "Automating Figma to code at Coinbase" - the first-party source for the plan, scaffold and worker pattern and the pull request sizes.
• Coinbase, "Coding had a concurrency problem: how Mux helped solve it" - worktree-per-agent, with the authors' own selection-bias caveat.
• Coinbase, "Tools for developer productivity at Coinbase" - Coinbase's own wider tooling post, the first-party place to check vendor claims against.
• Cursor, "Coinbase" customer story - vendor-hosted case study; read it to see numbers with no first-party source.
• Meta Engineering, "How Meta built Forum, AI-native engineering" - a different human gate on a small greenfield app.
• Intercom, "AI is approving our pull requests" - a size cap enforced by the reviewer itself.

Exercises

1. Measure your gap. Find the largest merged agent-authored diff in your repo and write what one reviewer can read carefully in a sitting. State whether you need a size cap.
2. Fill the file. Complete every cell of factory/adopt/coinbase.md for one repo, then run the validator and fix what it prints. Test it on a scratch copy with one cell left empty.
3. Audit a run. Take a past agent task and write the plan you would have signed, the scaffold it needs, and the pull requests it should have become. Name who approves each.

Check your understanding