Elephants Never Forget. That's the Problem.

I spent part of this week on a call with Google, being walked through their agentic development stack: AI Studio, Antigravity and the rest. The method holding it together is their Elephant and Goldfish model, and the tooling is built to make both animals cheap to summon. I went in expecting the usual vendor choreography. I came out thinking it’s the most sensible thing a big vendor has said about building software with AI this year, and that it has three holes in it big enough to drive a design review through.

The model, briefly

It comes from Dave Rensin, a Distinguished Engineer at Google, who wrote it up earlier this year. I-Programmer’s summary is the clearest walkthrough if you want the detail.

The elephant is a long-running AI session that holds all of the context. You point it at the codebase and the existing design docs, tell it you don’t want any code, describe the feature, and then argue with it. It asks clarifying questions. You correct it when it hallucinates. When it turns sycophantic, you push it back into critic mode. Together you write a design doc, in prose and block diagrams, until you’ve got what Rensin calls a solid technical approach.

The goldfish are fresh sessions with no memory. Each gets the design doc cold. The first has to explain the project back to you, and if it can’t, the doc is missing something. The next plays expert reviewer and hunts for missed items, faulty assumptions and edge cases. Another plays an experienced engineer and is asked whether the doc has everything needed to build the feature on the first pass. You iterate until the feedback is nitpicks, then a human signs it off. Only then does anyone write code.

The design doc is the point. In Rensin’s words, “written design documents become more important than the code itself”.

I agree with nearly all of it. Design before code. Treat the doc as the source of truth. Test it with something that wasn’t in the room. If every team I’ve walked into over the last two years worked this way, I’d have far less to write about.

The elephant is only as good as the argument

The whole method hangs on one instruction. “Really argue with the AI.” Rensin even gives the prompt: “Your highest and best use is to challenge my thinking.”

That’s good advice, and it rests on an assumption the model never states. To argue usefully with an elephant, you have to know when it’s wrong. Not when it’s factually wrong about the codebase (pointing it at the right file fixes that), but when it’s wrong about the design. That means seeing the option it didn’t propose, the constraint it doesn’t know about, the operational cost it hasn’t priced in.

Picture yourself two years out of university. You describe the feature and the elephant proposes a design: a managed queue, a serverless worker, a vector store, all wired together sensibly. It’s articulate. It asks you good questions. You answer them. It refines the design. Nothing in it is obviously wrong, so what are you meant to argue about?

Now put someone with twenty years in the same chair. They know the platform team has never run the serverless thing in production. They know the compliance team will veto that vector store the moment it shows up in a data flow diagram. They know the queue is fine at today’s volume and a disaster at next year’s, and that the boring Postgres table the elephant never mentioned would have done the job for three years. Same elephant, same prompt, completely different design.

So the design an elephant produces depends on how hard its human pushes back, and that depends on experience. The model gets a senior engineer’s judgement out of a senior engineer and records it well, but it can’t create that judgement in someone who doesn’t have it yet.

The options an elephant reaches for in the first place aren’t neutral either. They’re weighted towards whatever had the best documentation, the most tutorials and the biggest developer-relations budget when the model was trained. The experienced engineer discounts for that without thinking. The junior has no reason to suspect it exists.

The goldfish only sees the page

The goldfish phase is the clever bit, and it’s where the method looks most rigorous. A reader with no context is the ultimate test of whether a document stands on its own.

Look at what the goldfish are asked, though. Can you explain this? What’s missing or inconsistent? Is there enough here to build it first time? Every one of those questions tests the doc against itself: is it complete, coherent and buildable? None of them asks whether it’s the right design.

A perfectly coherent document can describe the wrong system. I’ve reviewed plenty of them, well written, every edge case handled, built on an assumption that was false on day one. A goldfish can’t catch that, because the false assumption lives in the world, in the team’s skills, the budget, last year’s outage, the regulator’s letter.

And a fresh session only forgets the conversation, while its training comes along intact. Ask three goldfish to review a design built from the vendor-weighted menu and they’ll check it against the same menu, so of course the feedback converges to nitpicks. Everyone in the review learnt from the same textbook.

Elephants reconcile

An elephant is extraordinarily capable and very eager to please. Give it divergent requirements and it won’t tell you they’re incompatible. It’ll find a way to satisfy all of them. Security wants everything private and inspected. Product wants it live in six weeks. The platform team wants it on the shared cluster. The data team wants its own lakehouse. Somebody senior read about agent memory and wants that too.

A human architect looks at that list and says we’re doing three of these, and here’s who gets disappointed. The elephant looks at the same list and designs a system that does all five. It’s ingenious. It has an adapter for every conflict and a sidecar for every compromise. The goldfish read it and confirm it’s complete, coherent and buildable. It’s all of those things, and it’s a Gordian knot.

Alexander didn’t untie the knot. He cut it. Most of the value of an architect is the cutting: ruling options out, dropping requirements, deciding which stakeholder loses this round and being the one who goes and tells them. That’s a judgement about people, money and risk, made by someone who’ll still be there when it goes wrong. An elephant can’t make that call, because nothing in its instructions lets it fail someone. And an elephant never forgets: every requirement anyone put into the conversation stays in the design, because dropping one would be failing at the job it was given.

The tooling makes this worse. When an IDE will spin up a fresh goldfish, or five of them in parallel, at the click of a button, review is nearly free, so you iterate until the reviewers stop complaining. A method that does that will reward the knot every time, and a knot that has passed five reviews looks a lot like a design that’s been checked five times.

What the model actually is

None of this makes Elephant and Goldfish bad. It’s a very good way to record judgement and test it for completeness. Used by someone who already has the judgement, it’s better than anything most teams are doing. I’ll be stealing bits of it.

The judgement has to come from somewhere else, and the model arrives in a world that’s busy getting rid of the way people used to acquire it. Rensin’s own conclusion is that an engineer’s value will come from “planning and decision-making skills, rather than their ability to type code”. I couldn’t agree more. So where do those skills come from? Juniors used to build them by writing code, getting it wrong and living with the consequences. Now the elephant writes the design, the goldfish sign it off, and the junior watches a machine avoid the one call they most need to learn to make.

An elephant never forgets. Architecture is mostly deciding what to forget.