---
title: "Elephant-Goldfish-Modell: Googles Design-Review"
canonical: https://wavect.io/de/blog/elephant-goldfish-model-design-review/
language: de
description: "Googles Elephant-Goldfish-Modell prüft KI-Softwarepläne vor dem Coding. So nutzt du die fünf Review-Stufen, erkennst Grenzen und bewertest Aufwand und Nutzen."
image: "https://wavect.io/img/blog/headers/header_elephant-goldfish-model-design-review.png"
author: ["Kevin Riedl"]
published: "2026-11-02"
updated: "2026-11-02"
reviewed: "2026-11-02"
---

# Googles Elephant-Goldfish-Modell: Plan prüfen, dann Code

[**Zurück**](/de/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/)

[Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt

12 Min Lesezeit · 2. November 2026 Zuletzt geprüft 2. November 2026

[**Weiter**](/de/blog/github-spec-kit-production-guide/)

TL;DR

Googles Elephant-Goldfish-Modell lässt Softwareentwürfe vor der Implementierung von frischen Agenten prüfen. Der Elephant entwickelt die Spezifikation, Goldfish suchen ohne das vorherige Entwurfsgespräch nach Lücken. Fünf Review-Stufen prüfen auch, ob Kritik unnötige Architektur erzeugt hat. Menschen entscheiden und geben frei. Der Elephant hat kein unbegrenztes Gedächtnis; schriftliche Entscheidungen tragen den Kontext weiter. Reviews ersetzen keine Tests. Unser hypothetischer CSV-Export zeigt offene Entwurfsfragen; eine Kostenrechnung und konkrete Pilotkriterien helfen dir, den zusätzlichen Aufwand zu bewerten.

Ein KI-Agent kann „CSV-Export hinzufügen“ umsetzen, ohne zu fragen, wer welche Datensätze exportieren darf. Die fehlenden Entscheidungen trifft er trotzdem. Du entdeckst sie später im Code.

**Googles Elephant-Goldfish-Modell (EGM) ist ein Open-Source-Plugin, das Softwareentwürfe vor der Implementierung prüfen lässt.** Ein Agent mit Projektkontext entwickelt die Spezifikation. Frische Reviewer-Sitzungen hinterfragen, was das Dokument erklärt. Die verantwortlichen Entwickler wägen die Befunde ab und geben den Entwurf frei. Der Ablauf lohnt sich vor allem, wenn ein Feature noch Entscheidungen enthält, die der Coding-Agent sonst selbst treffen müsste.

Google [veröffentlichte das Open-Source-Plugin am 22. Oktober 2026](https://opensource.googleblog.com/2026/10/introducing-elephant-goldfish-model-plugin.html). Laut Google nutzen Tausende seiner Entwickler es täglich für produktiven Code. Das ist eine Aussage zur Verbreitung. Eine gemessene Senkung der Fehlerquote belegt sie nicht.

**Quellen geprüft: 2. November 2026.** Wir haben Googles Ankündigung und das Repository in Revision `403d8881` ausgewertet. EGM haben wir dabei nicht an einem Kundenprojekt ausgeführt. Das Feature, die Kostenrechnung und der Pilotvorschlag dienen der Veranschaulichung.

## Was ist Googles Elephant-Goldfish-Modell?

Googles Elephant-Goldfish-Modell trennt Entwurf und Review durch unterschiedliche Gesprächskontexte. Laut [Projekt-README](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/README.md) bekommt der Elephant den Projektkontext. Die Goldfish prüfen das Dokument mit frischem Blick. Architekturentscheidungen bleiben beim Menschen. EGM besteht aus Skills und Anweisungen für Agenten; es liefert kein neu trainiertes Sprachmodell.

| Rolle | Verfügbarer Kontext | Aufgabe |
| --- | --- | --- |
| Elephant | Anforderungen, Architektur, Diskussion und festgehaltene Entscheidungen. | Den Vorschlag hinterfragen und den Entwurf schreiben. |
| Goldfish | Dokument, Reviewer-Anweisungen und relevante referenzierte Quellen, ohne das vorherige Entwurfsgespräch. | Fehlende Annahmen, Unklarheiten und Umsetzungsrisiken aufdecken. |
| Verantwortlicher Entwickler | Produktziele, Rahmenbedingungen und Review-Befunde. | Abwägen, Verantwortung übernehmen und die Spezifikation freigeben. |

Die Elefantenmetapher verspricht kein unbegrenztes Gedächtnis. Der [Draft-Skill](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-draft/SKILL.md) rechnet ausdrücklich mit einer neuen Sitzung. Er fordert den Agenten auf, verworfene Alternativen im Briefing nachzulesen. Schriftliche Entscheidungen tragen den Kontext weiter. Unser Leitfaden zum [Repository-Kontext für Coding-Agenten](/de/blog/ai-coding-agents-context-not-intelligence/) erklärt die übergreifende Arbeitsweise hinter dieser Übergabe.

Auch die No-Code-Regel hat einen konkreten Geltungsbereich: Die [EGM-Ausführungsregeln](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/execution_instructions.md) verbieten die produktive Implementierung während des Entwurfs. Gekennzeichnete Codebeispiele in Markdown oder einer temporären Arbeitsdatei sind erlaubt. Ein Schnittstellenbeispiel kann eine Entwurfsfrage klären, ohne bereits die Anwendung zu implementieren.

## Wie greifen Brainstorming, Entwurf und Review ineinander?

EGM überführt die Diskussion über ein Feature in eine Spezifikation, die auch eine andere Sitzung versteht. Der [offizielle Ablaufleitfaden](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/getting_started.md) beschreibt eine Kernfolge. Teams dürfen einzelne Skills auch gezielt einsetzen.

1. **`egm-brainstorm`:** Anforderungen und Alternativen klären, das Konzept mit frischen Reviewern hinterfragen und die vereinbarte Richtung in `concepts_brief.md` festhalten.
2. **`egm-draft`:** `design_draft.md` Abschnitt für Abschnitt entwickeln, einschließlich Problem, Bestandssystem, Änderungen und Implementierungsplan.
3. **`egm-review`:** Den Entwurf in getrennten Stufen prüfen. Anschließend entscheidest du, welche Befunde vor der Freigabe geklärt werden müssen.

Nach der menschlichen Freigabe setzt der Coding-Agent einen klar begrenzten Teil des Plans um. Lege die freigegebene Spezifikation in der Versionsverwaltung ab, üblicherweise unter `docs/designs/`. Wenn du zunächst einen umfassenderen Ablauf für Spezifikationen auswählen willst, behandelt unser [Praxisleitfaden zu GitHub Spec Kit](/de/blog/github-spec-kit-production-guide/) diese Entscheidung.

## Was prüfen die fünf Review-Stufen?

Der aktuelle [EGM-Review-Skill](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-review/SKILL.md) durchläuft fünf Stufen. Die Stufen prüfen Architekturrichtung, Verständlichkeit, Entwurfsqualität, unnötige Komplexität und Umsetzungsreife. Die CSV-Export-Befunde in der Tabelle zeigen mögliche Prüfergebnisse. Wir haben dafür kein Review ausgeführt.

| Stufe | Leitfrage | Beispielbefund |
| --- | --- | --- |
| 1. Initial Zoom Out | Löst der Entwurf das konkrete Problem mit dem vorhandenen System? | Ein neuer Export-Service dupliziert den Abfragepfad des Rechnungsmoduls. |
| 2. Comprehension | Kann ein neuer Leser Vorschlag und bisheriges Verhalten erklären? | Das Dokument spricht von „Account“, unterscheidet aber nicht zwischen Benutzerkonto und Mandant. |
| 3. Critic Review | Wo scheitern Entwurf, Annahmen oder Abhängigkeiten? | Eine Exportanfrage kann einen Mandanten auswählen, ohne die Zugehörigkeit nachzuweisen. |
| 4. Intermediate Zoom Out | Haben die vorgeschlagenen Korrekturen vermeidbare Architektur hinzugefügt? | Für einen begrenzten Export wurden Queue und Object Storage ergänzt, ohne ihren Bedarf zu belegen. |
| 5. Implementation Readiness | Kann die Umsetzung beginnen, ohne offene Entwurfsentscheidungen zu erfinden? | Im Plan fehlen das Verhalten am Zeilenlimit und die Signatur der vorhandenen Autorisierungsmethode. |

Der [Comprehension-Reviewer](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/agents/comprehension.md) muss zwei Dinge in eigenen Worten wiedergeben: den Vorschlag und das Bestandssystem, wie es im Dokument beschrieben wird. Kann er einen Abschnitt nicht erklären, ist das ein Blocker. Weicht seine Erklärung von deiner Absicht ab, suche im Dokument nach der fehlenden Verbindung.

Das Review kann zwischen den Stufen pausieren oder einen zusammengefassten Bericht erzeugen. Ein Readiness-Befund unterstützt die Entscheidung des Entwicklers. Er erteilt keine Release-Freigabe.

## Warum prüft EGM zweimal auf Overengineering?

EGMs zweites Zoom-Out-Review ist relevant, weil auch Kritik neue Komplexität erzeugen kann. Der [Zoom-Out-Standard](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/document_standards/zoom-out-standard.md) fordert Reviewer auf, spekulative Features abzulehnen, voreilige Infrastruktur zu vermeiden und vorhandene Komponenten wiederzuverwenden. Nach der Detailkritik muss der Entwurf erneut am ursprünglichen Problem gemessen werden.

Angenommen, ein Reviewer fragt, was bei einem Export mit Millionen Zeilen passiert. Die Frage ist sinnvoll. Ob du dafür eine Job-Queue brauchst, hängt von der Produktanforderung, der bestehenden Infrastruktur und gemessenen Ausführungsgrenzen ab. Für den aktuellen Bedarf kann ein ausdrückliches Limit reichen. Ein größerer Export kann Hintergrundverarbeitung rechtfertigen.

Wir würden für jede zusätzliche Komponente einen beobachteten Engpass oder eine vereinbarte Anforderung verlangen. Halte auch fest, warum du eine Alternative verworfen hast. Sonst beginnt der nächste Reviewer dieselbe Debatte erneut und vergrößert den Entwurf, ohne ihn zu verbessern.

## Praxisbeispiel: CSV-Export mit Mandantentrennung

Eine brauchbare Export-Spezifikation klärt Zugriffsrechte, Dateiinhalte und das Verhalten bei überschrittenen Grenzen. Das folgende eigene Beispiel ist bewusst verkürzt und beschreibt eine hypothetische NestJS-Anwendung. Dateinamen, Berechtigungen und Limits sind Annahmen. Ersetze sie durch geprüfte Angaben aus deinem Repository, bevor ein Agent etwas implementiert.

Wir nehmen an, dass die Anwendung bereits eine geprüfte Mandantenzugehörigkeit, ein Rechnungs-Repository und einen getesteten CSV-Encoder besitzt. Der Product Owner möchte einen synchronen Export mit höchstens **1.000 Rechnungen**. Dieses Limit ist eine Produktentscheidung für das Beispiel. Es ist weder ein Benchmark noch eine allgemein sichere Performance-Grenze.

| Entscheidung | Beispielspezifikation | Abnahmeprüfung |
| --- | --- | --- |
| Zugriff | `invoices.export` verlangen. Den Mandanten aus der serverseitig geprüften Zugehörigkeit ableiten. Keinen vom Client gewählten Mandantenparameter akzeptieren. | Ein Nutzer aus Mandant A kann keine Zeilen von Mandant B exportieren. Ohne Berechtigung folgt 403. |
| Auswahl | `issued_at` von einem inklusiven UTC-Zeitstempel bis zu einem exklusiven UTC-Zeitstempel filtern. Ungültige Angaben oder umgekehrte Zeiträume mit 400 ablehnen. | Zeilen genau am Anfang sind enthalten. Zeilen genau am Ende bleiben ausgeschlossen. |
| Ausgabe | Nur `invoice_id, issued_at, total_minor, currency` exportieren, sortiert nach `issued_at` und dann `invoice_id`. Den vorhandenen CSV-Encoder nutzen. | Spalten und stabile Zeilenreihenfolge entsprechen den Testdaten. Kundennotizen und zusätzliche Felder fehlen. |
| Limit | Höchstens 1.001 passende Zeilen laden. Bei mehr als 1.000 Zeilen 422 mit `EXPORT_LIMIT_EXCEEDED` zurückgeben, bevor CSV-Header oder Daten gesendet werden. | Genau 1.000 Zeilen funktionieren. 1.001 ergeben eine vollständige Fehlerantwort, keinen abgebrochenen Download. |
| Leeres Ergebnis | 200 mit CSV-Kopfzeile und ohne Datensätze zurückgeben. | Eine leere, berechtigte Auswahl erzeugt einen gültigen, vorhersehbaren Download. |

Der Implementierungsabschnitt ordnet diese Entscheidungen dem vorhandenen Code zu. Eine beispielhafte Dateiliste könnte so beginnen:

```
Ändern: src/invoices/invoices.controller.ts
  GET /api/invoices/export?from=...&to=...
  Vorhandene Guards für Authentifizierung und Berechtigungen nutzen.

Anlegen: src/invoices/invoice-export.service.ts
  buildCsv(principal: TenantPrincipal, range: ExportRange)
    -> Promise<InvoiceExport>
  InvoiceExport: { filename: string; csv: string }
  Autorisierung, Auswahl und Limit vor der Antwortausgabe prüfen.

Ändern: src/invoices/invoices.module.ts
  Export-Service mit vorhandenen Rechnungsabhängigkeiten registrieren.

Anlegen: test/invoices-export.e2e-spec.ts
  Mandantengrenzen, Rechte, Zeiträume, Spalten und Limits prüfen.
```

Dieser Ausschnitt ist absichtlich unvollständig: Ein echter Plan muss Guards und Repository-Methoden benennen, `ExportRange` und die Fehlerzuordnung definieren sowie Encoding, Dateiname, Cache-Header und Fehlerverhalten festlegen. Ein frischer Reviewer sollte diese Lücken melden. Plausible Dateipfade allein machen einen Entwurf noch nicht umsetzbar.

Entferne für den Pilotversuch die Mandantenregel aus einer Kopie und das Verhalten bei 1.001 Zeilen aus einer zweiten. Frage die Reviewer, was in diesen Fällen passiert. Ein nützlicher Befund benennt die fehlende Entscheidung und ihre Folge. Unterstellt der Reviewer stillschweigend eine Regel, hat er die Lücke nicht erkannt.

## Wann ist ein Plan bereit für die Implementierung?

EGMs [Standard für Implementierungsreife](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/document_standards/implementation-readiness-standard.md) verlangt geklärte Entwurfsentscheidungen, eine ausdrückliche Dateiliste, genaue Änderungen und konkrete Tests. Außerdem sollen aufeinander aufbauende Phasen das Projekt jeweils baubar und testbar halten. Das ist ein Qualitätsziel für den Plan. Es verspricht nicht, dass generierter Code beim ersten Versuch korrekt ist.

- **Referenzen prüfen:** Jeder bestehende Pfad, jede Methode und jede Datenstruktur muss zum ausgecheckten Quellstand passen. Unterscheide neue Symbole deutlich von vorhandenen.
- **Verhalten festlegen:** Kläre Autorisierung, Fehlerfälle und Kompatibilität, soweit sie relevant sind. „Fehler angemessen behandeln“ lässt die Entscheidung offen.
- **Anforderungen mit Prüfungen verbinden:** Beschreibe beobachtbare Ergebnisse, einschließlich Grenz- und Fehlerfällen. Ein Testdateiname ohne erwartetes Verhalten reicht nicht.
- **Arbeitsschritte ordnen:** Benenne Abhängigkeiten zwischen Phasen und die Prüfungen, die vor dem nächsten Schritt bestehen müssen.

Nach der Implementierung folgt [unabhängige QA für KI-generierten Code](/de/blog/qa-for-ai-generated-code/). Auch eine gründlich geprüfte Spezifikation kann falsch umgesetzt werden.

## Wie installierst und nutzt du EGM?

Installiere das vollständige EGM-Plugin in einer Coding-Umgebung, die frische Subagenten starten kann. Der [Leitfaden zu Installation und Host-Funktionen](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/harnesses.md) warnt davor, nur das Skills-Verzeichnis zu kopieren: Dann fehlen Reviewer-Personas und Dokumentstandards. Die folgenden Installationsbefehle haben wir am 2. November 2026 anhand der Dokumentation geprüft.

### Claude Code

```
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm
```

### Codex

```
codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm
```

### Antigravity CLI

```
agy plugin install https://github.com/google/elephant-goldfish-model
```

Starte nach der Installation eine neue Sitzung. Claude Code und Antigravity CLI verwenden den Präfix `/egm:`, zum Beispiel:

```
/egm:egm-brainstorm Plane einen Rechnungs-CSV-Export mit Mandantentrennung.
/egm:egm-draft
/egm:egm-review design_draft.md
```

Führe die Schritte nacheinander aus und beantworte dazwischen die Entwurfsfragen. Verwende den Draft-Pfad, den der Agent zurückgibt. In Codex wählst du den jeweiligen EGM-Skill in der Skill-Auswahl.

Prüfe die Funktionen deiner konkreten Umgebung. Der ausgewertete Leitfaden unterscheidet Antigravity CLI, App und VS-Code-Erweiterung von der eigenständigen Antigravity IDE. Letzterer fehlt das benötigte Delegationswerkzeug. Für Cowork und ChatGPT Work sind Installationswege mit dokumentierten Verifikationslücken vorhanden. Ohne frische Subagenten stoppt EGM das Review. Dieselbe Sitzung einen Goldfish spielen zu lassen, schafft die verlangte Trennung nicht.

Getrennte Gesprächskontexte und Werkzeugberechtigungen sind zwei unterschiedliche Anforderungen. Prüfe die Berechtigungskontrollen des Hosts für Reviewer. Eine Anweisung, nur Entwürfe zu bearbeiten, ist keine Dateisystem-Sandbox.

## Was kostet EGM, und spart es Zeit?

EGMs Quellcode steht unter der [Apache-2.0-Lizenz](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/LICENSE). Die Ausführung verbraucht trotzdem das Kontingent deines Coding-Agenten oder verursacht API-Kosten. Dazu kommt die Review-Zeit im Team. Das Repository stellt außerdem klar, dass EGM kein offiziell unterstütztes Google-Produkt ist.

Das [Testhandbuch des Projekts](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/TESTING.md) beschreibt Prüfungen der Plugin-Struktur und ausgewählter nativer Ausführungswege. Eine allgemeine Verkürzung der Lieferzeit oder weniger Fehler nach der Auslieferung belegen diese Tests nicht. Die [offiziellen FAQ](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/faq.md) benennen das Review ausdrücklich als möglichen Engpass und empfehlen, nützliche Befunde und Nacharbeit zu messen.

Eine hypothetische Arbeitskostenrechnung macht die Abwägung greifbar:

- Wir bewerten Entwicklerzeit mit angenommenen **90 € pro Stunde**.
- Zusätzliche **20 Minuten** Review kosten 30 €. Mit angenommenen **6 €** Agentennutzung entstehen insgesamt 36 €.
- Vermeidet der Ablauf später **45 Minuten** Nacharbeit, entspricht das 67,50 €. Der angenommene Nettovorteil beträgt 31,50 €.
- Der Aufwand rechnet sich ab `36 € / 90 € × 60 = 24 Minuten` vermiedener Arbeit.

Diese Werte sind frei gewählte Annahmen. Sie sind weder Wavect-Preise noch EGM-Tarife oder gemessene Einsparungen. Berücksichtige sämtliche zusätzliche Zeit für Entwurf, Review, Klärung und Dokumentation, wenn du deine eigenen Zahlen einsetzt. Miss die verstrichene Lieferzeit separat: Auch ein kurzes Review kann das Release verzögern, wenn die Freigabe zwei Tage wartet.

## Wie würden wir EGM im Team testen?

Wir würden EGM an einem begrenzten Feature mit bekannten Abnahmekriterien erproben und den gesamten Ablauf mit der bisherigen Arbeitsweise vergleichen. Prüfe zunächst die Spezifikationsreviews, bevor du ihren Urteilen vertraust. Der folgende Evaluierungsvorschlag enthält absichtliche Lücken, deren Erkennung du nachvollziehen kannst.

1. **Ausgangsstand festhalten:** Dokumentiere Repository- und Plugin-Revision, Host, Modell, Berechtigungen und die geprüfte Spezifikationsversion.
2. **Kontexttrennung prüfen:** Platziere eine harmlose Testphrase ausschließlich im Gespräch des Autors. Lass einen Reviewer den Entwurf anhand der übergebenen Dokumente erklären. Taucht die Phrase auf, wurde Kontext weitergegeben. Ihr Ausbleiben ist nur ein Smoke-Test, kein Beweis vollständiger Isolation.
3. **Bekannte Lücken einbauen:** Entferne die Mandantenregel oder das Verhalten am Limit aus getrennten Kopien des Exportbeispiels. Wiederhole Reviews in frischen Sitzungen und erfasse erkannte Lücken, übersehene Probleme und Fehlbefunde.
4. **Reviewer prüfen:** Ein Entwickler ordnet jeden Befund ein: fehlende Entscheidung, nützliche Präzisierung oder unnötige Arbeit. Verlange eine Begründung, bevor eine Abhängigkeit oder Komponente hinzukommt.
5. **Umsetzen und messen:** Vergleiche abgenommene Änderungen, gesamten menschlichen Aufwand, Agentennutzung, erneut geöffnete Aufgaben und Fehler aus denselben Abnahmeprüfungen. Wiederholte Durchläufe und vergleichbare Aufgaben helfen, ein günstiges Einzelergebnis nicht mit einer verlässlichen Verbesserung zu verwechseln.

Lege die Bestehenskriterien vor dem Pilotversuch fest. Für dieses Beispiel müssten die eingebauten Zugriffs- und Limitlücken erkannt sein. Bei der Freigabe dürften keine Entwurfsentscheidungen mit großen Auswirkungen offenbleiben. Vereinbare außerdem eine Obergrenze für zusätzlichen Review-Aufwand. Scheitert der Pilotversuch, verkleinere den Ablauf, passe Reviewer-Anweisungen an oder setze EGM für diese Aufgabenklasse nicht weiter ein.

## Wann lohnt sich der vollständige Ablauf?

Wir würden den vollständigen EGM-Ablauf nutzen, wenn wichtige Entwurfsentscheidungen offen sind und eine späte Klärung teuer wäre. Ist das Verhalten bereits klar, reicht ein schlankerer Weg. Das entspricht der Projektvorgabe, Skills gezielt auszuwählen. Ob sich ihr Einsatz lohnt, entscheidest du anhand deiner eigenen Lieferergebnisse.

| Aufgabe | Vorgeschlagener Ablauf | Begründung |
| --- | --- | --- |
| Neues Feature mit Rechten oder Datengrenzen | Vollständigen Entwurfs- und Review-Ablauf erproben. | Fehlende Verhaltensregeln können teure Implementierungsarbeit auslösen. |
| Änderung über bestehende Module hinweg | Spezifikation gegen den aktuellen Code prüfen. | Kompatibilität und Zuständigkeiten müssen ausdrücklich geklärt sein. |
| Bereits detaillierte Spezifikation | Mit den relevanten Review-Stufen beginnen. | Ein brauchbares Dokument neu zu schreiben bringt allein wenig. |
| Kleine Korrektur mit präzisem fehlschlagendem Test | Normalen Ablauf aus Korrektur, Test und Review nutzen. | Das beabsichtigte Verhalten kann bereits feststehen. |
| Noch ungeprüfte Produktidee | Nutzerbedarf prüfen, bevor die Implementierung ausgearbeitet wird. | Ein schlüssiger Entwurf belegt keine Kundennachfrage. |

## Unsere Empfehlung

Wähle ein Feature, dessen offene Entscheidungen du benennen kannst. Nutze EGM, um sie prüfbar festzuhalten, begrenze den Implementierungsumfang und miss, ob das zusätzliche Review seinen Aufwand rechtfertigt. Bewahre verworfene Alternativen auf. So versteht die nächste Sitzung deine Entscheidungen, ohne das Gespräch erneut durchlaufen zu müssen.

Wavects [AI Enablement](/de/services/ai-enablement/) kann dir helfen, diesen Pilotversuch auf dein Repository und deine Abnahmekriterien auszurichten.

Nach der Implementierung kann [EGMs Drift-Report-Skill](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-drift-report/SKILL.md) Entwurfsdokumente mit dem aktuellen Quellcode vergleichen und Abweichungen melden. Nutze die Befunde, um den Entwurf zu pflegen und Abweichungen zusammen mit den Testergebnissen zu bewerten.

## Häufige Fragen zum Elephant-Goldfish-Modell

### Ist EGM ein neues Sprachmodell von Google?

EGM ist ein Open-Source-Plugin mit Skills, Reviewer-Personas und Dokumentstandards für Coding-Agenten. Es bringt keine neuen Modellgewichte mit. Sprachmodell und Werkzeuge stellt deine gewählte Umgebung bereit. Bewerte deshalb die gesamte Konfiguration aus Modell, Berechtigungen und Review-Anweisungen, wenn du entscheidest, ob der Ablauf deinem Team hilft.

### Müssen Elephant und Goldfish unterschiedliche Modelle verwenden?

Die vorgeschriebene Trennung betrifft die Gesprächskontexte. Ein Goldfish darf das Gespräch, aus dem der Entwurf entstanden ist, nicht übernehmen. Ein anderes Modell kannst du zusätzlich erproben. Es ersetzt diese Anforderung aber nicht. Zwei Modelle mit derselben unvollständigen Spezifikation können denselben Fehler übersehen. Behalte konkrete Abnahmeprüfungen und menschliche Reviews bei.

### Kann ich ein bestehendes Entwurfsdokument verwenden?

Ja. Der Review-Skill akzeptiert ein Zieldokument. Du kannst die Stufen auswählen, die zu deinem aktuellen Bedarf passen. Prüfe, ob das Dokument das System erklärt und die verwendeten Quellen verlinkt. Fehlt ein Implementierungsplan, prüfe zuerst den Feature-Entwurf. Fehlende Umsetzungsdetails dürfen nicht als bereits erledigte Arbeit gelten.

### Muss ich jeden Vorschlag eines Reviewers übernehmen?

Nein. Architekturentscheidungen bleiben beim verantwortlichen Entwickler. Prüfe jeden Befund anhand der Anforderungen und des aktuellen Codes. Behebe ihn oder dokumentiere, warum eine andere Entscheidung angemessen ist. Die zweite Zoom-Out-Stufe hilft, wenn Kritik unnötige Komponenten eingebracht hat. Ein längerer Bericht oder eine kompliziertere Architektur belegen für sich keine Verbesserung.

### Garantiert frischer Kontext ein unvoreingenommenes Review?

Frischer Kontext verhindert, dass das vorherige Gespräch als unausgesprochene Wissensquelle dient. Er garantiert weder unabhängiges Schlussfolgern noch vollständige Quellen oder korrekte Ergebnisse. Reviewer können dieselben Modellgrenzen teilen und dieselbe Anforderung missverstehen. Verwende ausdrückliche Kriterien, gleiche Befunde mit dem Repository ab und belasse folgenreiche Entscheidungen in menschlicher Verantwortung.

### Was passiert, wenn die Implementierung den Entwurf verändert?

Halte die geänderte Anforderung oder begründete Abweichung im Entwurfsdokument fest und verknüpfe sie mit der Codeänderung. EGMs Drift-Report kann Widersprüche zwischen Dokumentation und Quellcode aufzeigen. Ein Bericht ohne Befunde beweist keine Korrektheit. Führe die Abnahmetests aus und prüfe das betroffene Verhalten, bevor du die Änderung akzeptierst.

QA und Produktionsreife

## Weiterlesen

Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware.

[Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/)

- [LangSmith: Trace-Aufbewahrung, Sampling und Evaluationskosten](/de/blog/langsmith-trace-retention-sampling-cost/)
- [4 Softwareagenturen in Österreich für Entwicklung und QA (2026)](/de/blog/software-agencies-austria-development-qa/)
- [Ultramarine 1 Flash für Dokumenten-Agenten: Preise, API-Grenzen und Migrationstest](/de/blog/ultramarine-1-flash-api-document-workflows/)
- [Greptile Base, Plus oder Apex: PR-Reviews sinnvoll budgetieren](/de/blog/greptile-base-plus-apex-review-budget/)
- [Arga Labs oder Archal: Zustandsbasierte Integrationstests](/de/blog/arga-vs-archal-agent-integration-testing/)

[Nächster Artikel**LangSmith: Trace-Aufbewahrung, Sampling und Evaluationskosten**](/de/blog/langsmith-trace-retention-sampling-cost/)

[**Zurück**](/de/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/)

[Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt

12 Min Lesezeit · 2. November 2026 Zuletzt geprüft 2. November 2026

[**Weiter**](/de/blog/github-spec-kit-production-guide/)