Das größte Problem mit KI-generiertem Code ist nicht die Qualität, sondern der Scope.
Du promptest einen Bugfix und bekommst den Bugfix – plus ein Refactoring der Nachbardatei, eine geänderte Import-Struktur und einen neuen Utility-Helper, den niemand verlangt hat. Der eigentliche Fix sind drei Zeilen. Der Diff hat 180.
Das passiert nicht, weil das Modell schlecht ist. Es passiert, weil der Prompt keinen Scope deklariert. Ohne explizite Grenzen optimiert ein LLM auf das, was es für eine Verbesserung hält — und das schließt alles ein, was es im Kontext sieht.
Das Pattern: Scope deklarieren, Ausschlüsse definieren
In meiner täglichen Arbeit mit Claude Code hat sich ein Muster bewährt, das dieses Problem löst. Es ist einfach eine Prompt-Struktur, die du in jede Aufgabe einbauen kannst.
Vergiss nicht: Am Ende ist alles, was ein Coding-Agent bekommt, Text. Ein frischer Kontext und klare Anweisungen helfen enorm.
Das Muster besteht aus vier Teilen:
-
Files in scope. Benenne explizit, welche Dateien der Agent anfassen darf. Nicht „das Modul“, sondern die konkreten Pfade.
-
Out of scope. Benenne explizit, was nicht angefasst werden darf. Das klingt redundant — ist es nicht. Ohne Ausschlüsse interpretiert das Modell deinen Scope großzügig.
-
Erwarteter Output. Beschreib, was am Ende rauskommen soll: ein Plan, Code-Änderungen, Tests, eine Risiko-Notiz. Wenn du das nicht definierst, entscheidet das Modell.
-
Reviewer-Erwartung. Der entscheidende Teil. Formulier eine Ablehnungsregel: „Sofort ablehnen, wenn X.“ Das zwingt das Modell, den eigenen Output gegen ein Kriterium zu prüfen.
Ein konkretes Beispiel
Angenommen, dein Team arbeitet an einem Django-Backend (das ist ein fiktives Beispiel für mich, weil ich nicht mit Django arbeite). Ein Endpoint berechnet Lagerbestände falsch. Teileingänge werden nicht korrekt abgezogen. Der Prompt könnte so aussehen:
Files in scope: warehouse/views.py, warehouse/tests/test_views.py
Out of scope: Models, Migrations, Serializer, Utility-Funktionen.
Fix: Fehlerhafte Bestandsberechnung im Endpoint.
Teileingänge werden nicht korrekt abgezogen.
Output: Plan (max 5 Punkte), View-Änderungen, Test-Updates, Risiko-Hinweis.
Reviewer-Erwartung: Sofort ablehnen, wenn Model-Layer berührt oder Migration vorgeschlagen wird.
Was passiert: Das Modell kann den Fix implementieren, aber es kann nicht in die Models ausweichen. Es kann nicht „mal eben“ den Serializer verbessern. Der Diff bleibt auf den View und die Tests beschränkt. Und wenn das Modell trotzdem eine Migration vorschlägt, hast du eine klare Ablehnungsregel, die auch im Code Review funktioniert.
Warum das funktioniert
LLMs arbeiten mit dem Kontext, den du ihnen gibst. Wenn du keinen Scope setzt, ist der gesamte sichtbare Code der implizite Scope. Alles, was das Modell sieht, wird zum Kandidaten für Änderungen. Die aktuellen Modelle unterscheiden in einem ‚explore‘ Schritt oft schon, welchen Kontext sie sich zum Lesen holen, und was angefasst werden soll, aber eben eher zufällig.
Die Reviewer-Erwartung ist dabei der wichtigste Teil. Sie gibt dem Modell eine Selbstprüfungsregel und deinem Team ein Kriterium für das Code Review. Reviewer sehen das Kriterium ebenfalls und können fast schon mechanisch ablehnen, wenn nötig. Beides löst dasselbe Problem: unkontrollierte Änderungen erkennen, bevor sie in den Main-Branch gelangen.
Die Reviewer-Erwartung funktioniert im Prompt als ‚framing‘: die Ablehnungsregel wird mitgeführt. Wer mal eine LLM beim ‚thinking‘ beobachtet hat, weiß, wie manche Vorschläge direkt wieder abgelehnt werden, weil im Kontext irgendeine Limitierung drin steckt, egal wie diffus.
Die Erwartung selbst lässt sich im Prozess auch codieren, indem du einen Reviewer-Subagenten vorbereitest. Der kann den implementierenden Agenten in Schach halten.
Was das Pattern nicht löst
Scoping hilft bei Aufgaben, deren Grenzen du kennst. Bei explorativen Aufgaben wie „Finde heraus, warum der Memory-Verbrauch steigt“ funktioniert ein enger Scope nicht, weil du die betroffenen Dateien noch nicht kennst. In solchen Fällen teile ich die Arbeit in zwei Schritte: erst eine Analyse ohne Code-Änderungen, dann einen zweiten Prompt mit dem Scope aus der Analyse. Je nachdem, welche Werkzeuge du nutzt, welchen Agent Harness, Kannst du die explorative Aufgabe zuerst ausführen und das Ergebnis in einer Markdown-Datei schreiben lassen, mit einem Überblick über all die Teile, die involviert sind. Und dann gleich nochmal einen Agenten losjagen, um kritisch dasselbe zu machen und die Arbeit zu überprüfen – und daraufhin erst einen Agenten , der den Fix implementiert. Alle mit einem frischen Kontext, um die Ehrlichkeit hochzuhalten (und die Kosten niedrig).
Ein guter Prompt ersetzt kein Code Review, aber er macht das Review leichter, weil der Diff vorhersagbar wird.
Die Entscheidung, ob die Änderung korrekt ist, liegt weiterhin beim Team.
Zum Mitnehmen
Wenn dein Team KI-Coding-Tools einsetzt und die Diffs regelmäßig zu groß oder unvorhersehbar ausfallen, probier dieses Muster bei der nächsten Aufgabe aus:
- Dateien explizit benennen (in scope und out of scope)
- Erwarteten Output beschreiben
- Eine Ablehnungsregel formulieren
Der Aufwand pro Prompt sind 30 Sekunden. Der Effekt auf die Review-Zeit ist erheblich. Und wenn du faul praktisch veranlagt bist, baust du dir Prompt-Template-Werkzeuge, die es leicht machen, das Richtige zu tun.