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

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

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. 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 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.

Wer welchen Kontext erhält und wer entscheidet
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 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 erklärt die übergreifende Arbeitsweise hinter dieser Übergabe.

Auch die No-Code-Regel hat einen konkreten Geltungsbereich: Die EGM-Ausführungsregeln 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 beschreibt eine Kernfolge. Teams dürfen einzelne Skills auch gezielt einsetzen.

egm-brainstorm: Anforderungen und Alternativen klären, das Konzept mit frischen Reviewern hinterfragen und die vereinbarte Richtung in concepts_brief.md festhalten.
egm-draft: design_draft.md Abschnitt für Abschnitt entwickeln, einschließlich Problem, Bestandssystem, Änderungen und Implementierungsplan.
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 diese Entscheidung.

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

Der aktuelle EGM-Review-Skill 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.

Der aktuelle Review-Ablauf mit beispielhaften Befunden
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 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 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.

Entscheidungen, die „CSV-Export hinzufügen“ offenlässt
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 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. 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 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. 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 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 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.

Ausgangsstand festhalten: Dokumentiere Repository- und Plugin-Revision, Host, Modell, Berechtigungen und die geprüfte Spezifikationsversion.
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.
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.
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.
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.

Unsere vorgeschlagenen Einsatzkriterien
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 kann dir helfen, diesen Pilotversuch auf dein Repository und deine Abnahmekriterien auszurichten.

Nach der Implementierung kann EGMs Drift-Report-Skill 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.