Elephant-Goldfish Model

Framework operativo per lo sviluppo software assistito da Coding Agent ideato dal team di Dave Rensin in Google (nato nell'estate 2025 attorno a un tool interno adottato da oltre 100.000 Googler e rilasciato come plugin open source il 21 ottobre 2026 su egm.dev). ¹ Nasce dalla constatazione che usare l'AI per andare veloci senza mantenere un alto rapporto segnale/rumore significa "produrre i propri errori in serie" (mass-producing our mistakes), facendo collassare il progetto sotto il peso di slop illeggibile e non manutenibile non appena il tasso di codice cattivo supera quello di codice produttivo. ¹

La metafora: Elefante, Pesce Rosso e Umano

Il modello prende atto che l'era del "coder" puramente umano sta finendo e struttura il ciclo di vita del software attorno a tre attori: ¹ ²

L'Elefante (The Elephant): "un elefante non dimentica mai". È la sessione AI ad alto contesto, pesantemente istruita, insieme al Design Document che aiuta a redigere: conserva la conoscenza istituzionale, l'architettura, le micro-decisioni, le discussioni sostenute col modello e l'intera storia della feature. ¹ ²
Il Pesce Rosso (The Goldfish): una sessione AI nuova di zecca e completamente isolata a memoria zero (zero-context), che conosce esclusivamente ciò che le viene messo davanti (la bozza del documento e i file sorgente che referenzia), priva dei bias conversazionali accumulati con l'Elefante. ¹ ²
L'Umano (The Human): l'AI agisce da partner di esplorazione e revisore automatizzato, ma gli ingegneri umani restano proprietari delle decisioni architetturali, dei trade-off e degli esiti finali (vedi Design come Nuovo Codice). ²

La regola operativa per ogni nuova feature è: "Nutri l'elefante; mettilo alla prova col pesce rosso" (Feed the Elephant; test it against the Goldfish). ¹

I tre Aha Moment e `sizeof(docs) << sizeof(code)`

Il framework emerge da tre rivelazioni sul campo: ¹

Ripartire in 30 secondi dopo un crash: quando una sessione complessa va in crash dopo un'ora di lavoro, ri-fare bootstrap di una sessione vuota dandole in pasto centinaia di righe di codice è frustrante e divora token; mantenendo invece un documento scritto con chiarezza che spiega l'intento e lo stato d'avanzamento, ripartire diventa un'operazione da 30 secondi ("Leggi questo doc. Leggi il codice che referenzia. Dimmi dove siamo e continuiamo"). ¹
Guardrail stretti contro la corsa giù dal dirupo: anche dopo aver recuperato il contesto, se si chiede semplicemente al modello di "finire l'implementazione", l'AI — ansiosa di compiacere (eager to please) — corre felicemente giù da un dirupo, allucinando API e prendendo scelte architetturali insensate se non viene vincolata da guardrail strettissimi. ¹
sizeof(docs) << sizeof(code): per far comprendere il sistema all'AI all'inizio di una nuova feature non serve nutrirla col codice sorgente, ma bastano i design doc. È molto più economico, rapido e affidabile dare contesto tramite documenti di design in inglese semplice che costringere il modello a leggere e interpretare decine o centinaia di migliaia di righe di codice grezzo. ¹

Le 4 fasi e i 9 step del workflow

Fase 1: Crescere l'Elefante (Growing the Elephant — niente codice)

L'obiettivo è co-progettare feature e criteri di valutazione prima che venga scritta una sola riga di codice, applicando al software i principi di AI come Strumento, non Giocattolo: ¹

Step 1 — Context Loading: si apre una sessione nuova puntandola ai design doc o al source tree e si chiede all'AI una descrizione ad alto livello di ciò che ha imparato; se fraintende il sistema al minuto uno scriverà codice terribile al minuto dieci, quindi va corretta immediatamente (step omesso solo nei progetti creati da zero). ¹
Step 2 — La regola "No Code": poiché sia gli ingegneri sia l'AI amano scrivere subito codice, si impone il vincolo esplicito ("Non voglio che tu crei codice... faremo una discussione di design. Voglio che mi faccia domande chiarificatrici e metta in discussione le mie assunzioni") e si discute per 20–30 minuti, correggendo le allucinazioni con i riferimenti ai file reali. ¹
Step 3 — La sfida dell'adulatore (The Sycophant Challenge): se il modello smette di fare domande scomode ("Great idea, Dave!"), lo si riporta in modalità critica ricordandogli che il suo miglior uso è sfidare il nostro pensiero; il pro-tip più efficace per spezzare un loop di allucinazione è chiedergli semplicemente "Perché pensi questo?" ("Why do you think that?"). ¹
Step 4 — Prima proposta tecnica chiesta all'AI: è cruciale chiedere all'AI di formulare la prima bozza di proposta tecnica (in prosa chiara e block diagram, con al massimo brevi blocchi di pseudocodice) anziché proporre la propria soluzione chiedendo una reazione, altrimenti si perdono angoli ciechi e non si verifica se il modello ha davvero capito il codebase. Si dibatte sulla bozza correggendo i file fraintesi (es. auth.py o AUTH.md) anche per ore o per 2–3 giorni (come nelle sessioni di Rensin con Gemini). ¹

Fase 2: Istruire l'Elefante (Teaching the Elephant — le 4 sezioni del Design Doc)

Nella stessa sessione si costruisce il documento markdown che diventerà fonte assoluta di verità e nuovo codice sorgente, facendolo scrivere iterativamente sezione per sezione (mai one-shot, per non scontrarsi coi limiti di token in output dei modelli): ¹

The Problem: descrizione in inglese semplice del problema di business in 3–5 frasi, comprensibile a un lettore occasionale. ¹
The Technical Plan: prosa esplicativa priva di gergo sui grandi componenti e su come si incastrano, accompagnata da un block diagram. ¹
Alternatives: le idee valutate e scartate durante la Fase 1; documentare le decisioni rifiutate costruisce guardrail essenziali contro future allucinazioni e discussioni. ¹
Detailed Implementation: la sezione più lunga e critica del documento, con un piano passo-passo dettagliatissimo in cui si esige che l'AI enumeri ogni singolo file che verrà creato o modificato e la motivazione del perché, così da tenere il modello sui binari durante l'implementazione. ¹

Fase 3: Il Protocollo Pesce Rosso (The Goldfish Protocol)

Per sapere se il design doc è davvero solido o se sta solo campando di rendita sul contesto accumulato nella sessione Elefante, lo si testa contro sessioni Pesce Rosso vuote: ¹

Step 5 — Test di comprensione (The Comprehension Test): si apre una sessione vuota, le si passa il markdown e si chiede di spiegare cosa il documento cerchi di ottenere e come funzioni il sistema attuale basandosi esclusivamente sul doc e sui file che referenzia; se il Pesce Rosso non riesce a spiegarlo, mancano dettagli di contesto da aggiungere prima di ripetere il test. ¹
Step 6 — Critic Review: nuova sessione Pesce Rosso nel ruolo di revisore tecnico esperto incaricato di scovare omissioni, assunzioni fallaci ed edge case; empiricamente circa il 30% dei suggerimenti è di grande valore, e si aggiorna il file ripetendo il ciclo finché restano solo nit pick. ¹
Step 7 — Implementation Readiness: nuovo Pesce Rosso nel ruolo di software engineer esperto del codebase a cui si chiede se il documento contenga davvero tutte le informazioni necessarie per implementare con successo la feature al primo passaggio; risolte le ultime domande nel doc, lo si sottopone alla revisione e approvazione di un umano reale. ¹

Fase 4: Implementazione

Step 8 — Coding con guardrail: solo a questo punto si consegna il Design Doc finalizzato all'AI dicendole "Leggi questo design doc e i file che referenzia. Implementa la feature come descritto. Segui il piano esattamente"; se la sessione va in crash o deraglia, basta aprire una nuova sessione e ridarle il doc per tornare operativi all'istante. ¹
Step 9 — La "Mean" Code Review: terminato il codice, lo si sottopone all'AI con il prompt reale di Rensin ("Ho la forte sensazione che questo codice sia di bassa qualità. Fallo a pezzi e dimmi tutti i modi in cui fa schifo"), ordinando inoltre di segnalare ogni punto in cui si superano 10 righe senza un commento e iterando finché le critiche diventano banali o spariscono. ¹

Bootstrap su un monolite in una settimana ("Peanuts and Hay") e Onboarding

Per addestrare un Elefante su un monolite esistente di milioni di righe senza farlo soffocare sull'intera giungla del codice, bastano circa una settimana e bocconi compressi di contesto ("peanuts and hay", arachidi e fieno) costituiti da una gerarchia di README.md generata per summarization ricorsiva dalle foglie alla radice: ¹

Partire dalle foglie (Peanuts): ogni sviluppatore punta l'AI alle directory foglia assegnate per generare un README.md con (a) scopo della directory e (b) elenco di ogni file e sua funzione. Poiché nelle foglie l'AI ha solo il codice su cui basarsi, sbaglia circa il 50%, e l'ingegnere impiega 5–10 minuti per correggere il file. ¹
Risalire l'albero (Roll up the Hay): salendo di un livello alla volta fino alla radice, l'AI legge i README.md delle sottodirectory sottostanti più il codice della directory corrente per generare il README.md del livello superiore. ¹
Ciclo di vita dei README: nutrendo una sessione nuova alla radice coi soli README.md, l'Elefante comprende quasi istantaneamente sottosistemi e design pattern consumando pochissima finestra di contesto; i README.md servono solo finché i design doc non arrivano a referenziare il 100% dei file di codice, dopodiché possono anche essere cancellati. ¹

Bonus — Onboarding istantaneo: versando l'intera gerarchia di README.md e design doc in un notebook NotebookLM (con istruzioni di sistema sull'area del nuovo membro), il primo compito di un nuovo ingegnere è usare il notebook per scrivere un design doc per la sua prima feature; quando il doc supera il test del Pesce Rosso, è pronto a contribuire senza settimane di shadowing. ¹ Con lo stesso metodo, product manager e program manager con un minimo di basi di codice scrivono da soli i design doc delle feature che propongono, consegnando in pochi giorni bozze già corrette al 70%–80% alla prima revisione. ¹

Il plugin open source EGM (`egm.dev`)

Il repository github.com/google/elephant-goldfish-model (egm.dev, licenza Apache 2.0, "not an officially supported Google product") codifica il metodo per gli harness Antigravity, Claude Code, Codex, Claude Cowork e ChatGPT (vedi Harness Engineering): ²

Le 7 skill: /egm-brainstorm (ideazione zero-doc con uno swarm multi-lente di Pesci Rossi che demolisce i concetti iniziali), /egm-draft (compilatore iterativo sezione per sezione della specifica markdown in docs/designs/<feature>.md), /egm-review (orchestratore della pipeline di verifica multi-stadio: Zoom Out → Comprehension → Critic → Readiness), /egm-review-loop (dispatch concorrente dei subagent di review, diretto e gerarchico), /egm-resolve (triage interattivo e applicazione automatica di patch dai rilievi), /egm-drift-report (scanner AST sequenziale che rileva divergenze tra specifiche versionate e codice vivo) ed /egm-bootstrap (generatore ricorsivo bottom-up di documentazione del codebase con upsert a sentinel-block). ²
Le personas Pesce Rosso (agents/): i subagent stateless valutano il design da prospettive conflittuali tramite le personas Design Critic, Naive Reader, Tech Lead, Codebase Auditor, Structural Validator, Style Editor e Zoom Out Architect. ²

Vedi anche: Dave Rensin, Design come Nuovo Codice, AI come Strumento, non Giocattolo, Siamo Tutti Manager Adesso, Spec-Driven Development e Dark Factory Agentica, Harness Engineering, AI Skills e Grill-Me