Why Google Splits the Designer from the Reviewer

Originally published at Trida AI. Ask the session that designed a feature to review the design document, and it will call the document clear. It remembers the argument behind every sentence: the trade-off that took twenty minutes to settle, the edge case somebody raised and answered, almost none of it written down. The session reads a gap and fills it from memory, so the review certifies a document a fresh reader would trip over immediately. You know this failure from your own writing. Self-proofreading is unreliable, because you read what you meant to say. A long design session has the same blind spot, backed by perfect recall of everything except what reached the page. Google's response is to build the split into the workflow. The Elephant-Goldfish Model (EGM) plugin, open-sourced in October 2026, separates two kinds of AI session and keeps them apart. One designs. Others, who never saw the designing, review. Two kinds of session, one document The Elephant is the context-rich session. It holds the architecture, the requirements and the decisions, and writes no code. Its job is conversation: interviewing you, debating options, challenging assumptions. The Goldfish are the opposite. Each is a fresh, stateless session that gets the design document and its referenced sources, and nothing else. No transcript, no memory of the debate. That makes the document the only channel from designer to reviewers. Anything the Elephant knows that never got written down does not survive the trip. The workflow runs in three phases. In egm-brainstorm, you and the Elephant shape the idea under a no-code rule. In egm-draft, the two of you produce a Markdown design document: the problem, the technical plan, the alternatives considered, and an implementation plan naming the specific files to change. Then egm-review hands it to the Goldfish, in three checks. First, a comprehension check: a Goldfish reads the document and has to explain the architecture and intent back. If it can't restate the plan accurately, the document is ambiguous and goes back. Second, an antagonistic review: several Goldfish act as skeptical reviewers, hunting edge cases, hidden dependencies, and logical gaps, and their findings go back to the Elephant. Third, an implementation readiness check: a final Goldfish makes a go/no-go call on whether file paths, data structures, and function signatures are present and unambiguous. The plugin is Apache 2.0 and lives in the EGM repository, built to bring EGM into Antigravity first, with installs available for Claude Code and Codex. One README rule shows how seriously the split is taken: Goldfish reviews require fresh subagent contexts, and if the host can't create them, EGM stops the review. Independence that cannot be established is not faked. Google says thousands of Googlers use this plugin every day to ship production Google code. The model comes from Dave Rensin's essay "Elephants, Goldfish, and the New Golden Age of Software Engineering." Rensin is a Distinguished Engineer at Google. Its thesis fits in one line: "Design is the new code." The EGM split: the Elephant designs, the document carries the design, zero-context Goldfish review it, and a person approves before any code is written. Independence you can't prompt for The obvious shortcut is one session, instructed to review its own design objectively: list your assumptions, argue the other side. The instruction cannot remove the problem, and the reason is mechanical. The memory that creates the blind spot is still in the room. A prompt can change what a session says; it cannot change what the session knows. EGM changes what the reviewer knows, by handing the review to sessions that never had it. Independence is not an attitude. It is a property of the topology: separate sessions, separate context, enforced the way you would enforce it between people. The comprehension check is the sharpest because of what it tests. A reviewer who has to teach the design back produces a restatement you can compare with your intent. Where the restatement drifts, the document is at fault: it read fine line by line and did not add up as a whole. In George Witt's analysis, EGM is "a good test of whether a design doc stands on its own and a weaker test of whether the design is right." The machinery distrusts itself a little. The same analysis notes a skeptic who hunts for scope the design doesn't need, and then a second skeptic who re-reads the document to cut the defensive bulk the critics' findings added. Reviews that only ever add are how design documents grow fat. What it catches, and what walks past it What the Goldfish catch is document failure: ambiguity, unstated assumptions, missing implementation detail. Witt's analysis describes a Zero-Decision Rule: whoever implements the design should not have to make a single design choice. If a decision is still open, the document is not finished. An illustrative design excerpt in the EGM format: webhook delivery, with Goldfish findings pinned to the lines they question. What walks past is a design that is wrong about the world. A Goldfish can check the document against itself and against the code it cites. It cannot check the decision against reality: the traffic figure in a dashboard nobody attached, the constraint a stakeholder mentioned in a hallway. That judgment stays with the person who approves the design. Fresh eyes find what is missing from the page; they say nothing about whether what is on the page should happen. Two more limits. The default reviewer set has no security pass: security flaws are not on the reviewers' list by name, so a team that wants a threat review has to set one up. The personas are customizable, so a security-minded Goldfish is possible, but nobody gets one by default. And, as Witt notes, the reviewers usually run on the same model as the designer, with a clean context. That buys independence of memory, not independence of judgment; a blind spot built into the model itself walks straight through the context wall. The cost is real: several fresh reviewer runs per design, plus your time triaging what the reviewers return. Google's own guidance is to skip EGM for a small, clear bug fix. It is aimed at work where design decisions exist to be gotten wrong. The pattern is bigger than code review Step back, and the shape is familiar to anyone running agents in production. Whoever produces an output should not be its only evaluator. Teams say this about evals, then wire a single session to grade its own homework because it is convenient. EGM is what the principle looks like when it is enforced by architecture instead of requested in a system prompt: separate context, separate session, and a hard stop when separation can't be provided. It is the same lesson as isolating untrusted content from instructions, from the other direction. What a session has seen determines what it can check. A session steeped in the design conversation is compromised as a reviewer the way a session that ingested a hostile document is compromised as an actor: not through bad intent, but through context it can't unsee. Google putting context isolation into a plugin its engineers use on production code moves it from principle into tooling, and we think it's the right direction. Where it stops Be clear about what EGM is not. It is a workflow plugin — Markdown rules, reviewer personas, structured checks — and the release adds no new model; what it encodes is discipline as tooling. The adoption claim is Google's. Thousands of Googlers use the plugin every day, on Google's account, with no published figures for defects caught or rework avoided, and no published empirical evaluation behind the central claim. The mechanism is plausible; the claim remains untested, and the evidence is still anecdote. There is a failure mode in the other direction: run every change through a three-phase design ritual and the document becomes the product, polished past the point where an afternoon and a test would settle it. EGM does not replace tests or human judgment. The repository says so itself. Work with us If your team is letting agents write code, one quality lever you control directly is the review topology: who checks the work, and what they are allowed to remember. If you want help building that discipline around your own agent workflows, start with Trida AI's intake and tell Trida AI what you are building.