Scope Creep bei Coding Agents beginnt fast immer mit einem Pull Request, der gut aussieht. Der Titel heißt „Lieferdatum im CSV Export“. Die Beschreibung ist sauber, die Pipeline ist grün, die Akzeptanzkriterien sind abgehakt. Dann öffnet ihr die Liste der geänderten Dateien und zählt 23. Für eine Spalte.
Das Feature stimmt. Daneben stehen eine neue Bibliothek für Datumsformate, ein Interface mit genau einer Implementierung, eine Migration und ein umformatierter Service, der mit dem Export nichts zu tun hat. Jede einzelne Änderung lässt sich begründen. Bestellt hat sie niemand. Und weil alles läuft, winkt das Review sie durch.
Wer mit Agents arbeitet, kennt diesen Moment. Hier steht, warum Tests ihn nicht bemerken, woran ihr ungefragte Änderungen erkennt und wie ihr sie mit Spec, Pipeline und Permissions stoppt.
Scope, Specs und Gates am eigenen Code üben: Eure Developer lernen, Coding Agents mit klaren Aufträgen, Regeldateien, Permissions und Quality Gates zu führen. Zum NCA KI Workshop für Developer
Was ist Scope Creep bei Coding Agents
Scope Creep bei Coding Agents heißt, dass der Agent mehr ändert, als der Auftrag verlangt. Im Englischen liest man auch Out of Scope Edits oder Unrequested Changes. Gemeint ist immer dasselbe. Der Diff ist größer als die Aufgabe.
Das OWASP Cheat Sheet zu Secure Coding with AI widmet dem Thema einen eigenen Abschnitt. Dort geht es um Lockfiles, CI Konfiguration, fremde Tests, Formatierung und Dependency Updates, die im Pull Request landen, obwohl sie niemand bestellt hat. Reviewer schauen auf die bestellte Änderung und übersehen den Rest. OWASP nennt das den häufigsten Fehler im Review von agentischem Code.
Der Begriff kommt aus dem Projektmanagement. Dort wächst der Umfang über Wochen, weil immer neue Wünsche dazukommen. Beim Agent passiert es in Minuten, und niemand hat einen Wunsch geäußert.
Warum grüne Tests Scope Creep nicht erkennen
Tests beantworten eine Frage: Tut der Code, was er soll? Die Spec beantwortet dieselbe Frage aus Sicht der Anforderung. Keine von beiden fragt, was sonst noch im Repository gelandet ist. Eine zusätzliche Bibliothek bricht keinen Test. Ein neues Interface erfüllt jedes Akzeptanzkriterium. Die Pipeline misst das Verhalten. Den Umfang misst sie erst, wenn ihr es ihr beibringt.
Dazu kommt die Neigung der Modelle. Andrej Karpathy programmiert nach eigener Aussage inzwischen überwiegend mit Agents und beschreibt auch, wo sie ihn ärgern. The Decoder fasst seinen Beitrag zusammen: Die Modelle blähen Abstraktionen auf, räumen toten Code nicht weg und bauen tausend Zeilen, wo hundert reichen würden.
OWASP beschreibt die Folge für das Review in einem Satz:
Agents routinely touch files beyond the scope of the requested change.
OWASP Cheat Sheet, Secure Coding with AI
Und dann ist da die Beschreibung des Pull Requests. Sie stammt oft vom selben Agent und erzählt die bestellte Geschichte. Wer das Review mit der Beschreibung beginnt, liest den Diff danach durch diese Brille. OWASP spricht von Review Anchoring.
Woran ihr ungefragte Änderungen im Diff erkennt
Die gute Nachricht für alle, die Reviews machen: Scope Creep hinterlässt Spuren an festen Stellen. Die meisten lassen sich an Dateipfaden ablesen, bevor ihr eine Zeile Code gelesen habt.
| Was der Agent ungefragt ändert | Woran ihr es erkennt | Was es stoppt |
|---|---|---|
| Neue Dependency | Manifest oder Lockfile im Diff | Sperre für Manifest und Lockfile, Updates nur als eigener Pull Request |
| Datenmodell | Neue Migration, geänderte Entity | Pfadregel mit Freigabe durch einen Menschen |
| Neue Abstraktion | Interface, Factory oder Basisklasse mit genau einer Nutzung | Review gegen die Spec, Obergrenze für die Größe des Diffs |
| Refactoring nebenan | Dateien außerhalb des Auftrags, Umbenennungen, neue Formatierung | Scope Gate mit Pfadliste |
| Tests | Gelöschte Tests, schwächere Assertions, neue Mocks | Pflichtreview für geänderte Testdateien |
| Pipeline und Regeln | Änderungen an Workflows, Regeldateien oder der Konfiguration des Agents | Feste Reviewer für diese Dateien und Freigabe durch einen Menschen |
Dependencies sind die teuerste Spur. Forschende der Purdue University haben in einer Studie zu Dependency Entscheidungen von Coding Agents 117.062 Änderungen an Abhängigkeiten aus Pull Requests von Agents und Menschen in sieben Ökosystemen ausgewertet. Agents wählten in 2,46 Prozent der Fälle eine Version, für die zum Zeitpunkt des Pull Requests schon eine Schwachstelle bekannt war. Bei Menschen waren es 1,64 Prozent. Unter dem Strich kamen durch die Agents 98 Schwachstellen mehr dazu, als verschwanden. Bei den Menschen verschwanden 1.316 mehr, als dazukamen. Die Autoren halten fest, dass solche Folgen unsichtbar bleiben, solange nur bestandene Tests zählen.
Für Updates empfehlen wir Renovate, das wir auch selbst einsetzen. Es öffnet für jedes Update einen eigenen Pull Request. Das hat einen angenehmen Nebeneffekt. Ein geändertes Lockfile in einem Feature Branch fällt schneller auf, weil es dort selten etwas zu suchen hat. Wie ihr die Lieferkette zusätzlich härtet, steht in npm Package Security und SBOM.
Wann eine ungefragte Änderung trotzdem richtig ist
Manchmal hat der Agent recht. Er sieht, dass das Datumsformat an fünf Stellen unterschiedlich gebaut wird, und zieht es zusammen. Das kann eine gute Idee sein. Trotzdem ist gerade über eine Architekturfrage entschieden worden, ohne dass ein Mensch sie gesehen hat. In drei Monaten weiß niemand mehr, warum es dieses Interface gibt, und keiner fühlt sich zuständig.
Für Zusatzideen gilt deshalb eine einfache Regel. Der Agent schlägt vor und ändert nichts. Alles, was ihm außerhalb des Auftrags auffällt, landet als Liste unter „Vorschläge“ in der Beschreibung des Pull Requests. Ein Mensch macht daraus eines von drei Dingen:
- Eigener Auftrag. Die Idee ist gut und bekommt eine eigene Spec und einen eigenen Pull Request.
- Bewusste Freigabe. Die Änderung bleibt im aktuellen Pull Request, und die Entscheidung steht mit Begründung im Repository.
- Ablehnung. Die Änderung fliegt raus, bevor sie jemand pflegen muss.
So bleibt der Blick des Agents erhalten, und die Entscheidung liegt wieder bei jemandem, der sie verantwortet. Welche Entscheidungen grundsätzlich beim Menschen bleiben, haben wir in Rote Linie für KI im Coding und in Was wir KI Agenten nicht erlauben aufgeschrieben.
So schreibt ihr den Scope in die Spec
Die meisten Specs beschreiben, was gebaut werden soll. Was ausdrücklich draußen bleibt, steht selten drin. Diese Lücke füllt der Agent nach eigenem Geschmack. Vier kurze Angaben schließen sie:
- Auftrag. Ein Satz, der sagt, was sich ändern soll.
- Im Scope. Die Ordner oder Module, in denen der Agent arbeiten darf.
- Nicht im Auftrag. Keine neuen Dependencies, kein geändertes Datenmodell, kein Refactoring außerhalb des Auftrags, keine Änderungen an Pipeline und Regeldateien.
- Vorschläge. Was dem Agent sonst auffällt, schreibt er in die Beschreibung des Pull Requests und ändert es nicht.
Bei OpenSpec bekommt jede Änderung einen eigenen Ordner. Dort passt der Scope gut hin, direkt neben Proposal und Tasks. Wie das mit Tests zusammenspielt, zeigt unser Beitrag zu TDD und OpenSpec. Die Stufen und Frameworks ordnen wir unter Spec Driven Development für KI Coding ein.
Was für jeden Auftrag gilt, gehört zusätzlich in die Regeldatei. Dort steht dann dauerhaft, dass der Agent nur Dateien aus dem Auftrag ändert und Ideen als Vorschlag notiert. Eine Regel in der AGENTS.md ist allerdings eine Bitte. In langen Sessions geht sie verloren. Deshalb braucht sie ein Gate, das sie durchsetzt. Das Prinzip dahinter steht bei den Quality Gates für KI Code.
So funktioniert ein Scope Gate in der Pipeline
Ein Scope Gate vergleicht die geänderten Dateien eines Pull Requests mit den Pfaden aus dem Auftrag. Mehr Technik braucht es nicht. Der Auftrag bringt eine kurze Liste erlaubter Pfade mit. Die Pipeline holt sich die Liste der geänderten Dateien aus Git und legt beide nebeneinander. Liegt eine Datei außerhalb, wird der Check rot und nennt sie beim Namen.
Ein zweiter Check schützt die heiklen Pfade. Manifest, Lockfile, Migrationen, Pipeline und Regeldateien gehen nur durch, wenn ein Mensch sie ausdrücklich freigibt, zum Beispiel mit einem Label am Pull Request. Drei Dinge sind dabei wichtig:
- Zwei Schlösser. Eine neue Dependency muss im Auftrag stehen und zusätzlich die Freigabe bekommen. Der Auftrag erlaubt sie, ein Mensch bestätigt sie.
- Kein Auftrag, kein Merge. Ein Pull Request ohne Pfadliste wird rot. Für einen kleinen Fix reicht eine einzige Zeile.
- Das Gate gehört nicht dem Agent. Die Pfadliste schreibt, wer den Auftrag gibt. Den Check selbst sichert ihr über feste Reviewer und einen Pflicht Check am Branch. Ein Gate, das der Agent selbst umschreiben darf, hält nichts auf.
Das Prinzip hängt an keinem Anbieter. Es läuft in GitHub Actions genauso wie in GitLab CI, weil es nur zwei Dateilisten vergleicht. Wer mag, ergänzt ein Diff Budget, also eine Obergrenze für geänderte Zeilen pro Auftrag. Mehr zum Aufbau solcher Pipelines steht bei den Vibe Coding CI/CD Pipelines und im Beitrag zur OpenCode GitHub Action.
So halten Permissions den Agent schon vor dem Commit im Scope
Die Pipeline greift nach dem Schreiben. Permissions greifen davor. In OpenCode legt ihr fest, wo der Agent ohne Rückfrage schreiben darf, wo er fragen muss und was gesperrt ist. Für den Scope heißt das: frei im Ordner des Auftrags, Rückfrage überall sonst, Sperre für Manifest, Lockfile und Migrationen.
Eine Grenze solltet ihr kennen. Regeln für das Schreiben gelten für die Datei Werkzeuge des Agents. Ein Befehl im Terminal kann trotzdem Dateien ändern. Darum gehört eine kurze Liste erlaubter Befehle dazu, und die Pipeline behält das letzte Wort. Die Details stehen in OpenCode Permissions richtig einstellen, das große Bild im Beitrag zum Agent Harness.
Was ein gutes Review bei Agent Pull Requests zuerst prüft
Gates nehmen dem Review die mechanische Arbeit ab. Die Reihenfolge beim Lesen bleibt trotzdem entscheidend:
- Erst die Dateiliste, dann die Beschreibung. So seht ihr den Umfang, bevor euch jemand die Geschichte dazu erzählt.
- Abgleich mit dem Auftrag. Jede Datei ist entweder im Scope oder braucht eine Erklärung.
- Heikle Pfade einzeln. Manifest, Lockfile, Migrationen, Pipeline und Regeldateien lest ihr Zeile für Zeile.
- Tests. Wurde ein Test gelöscht, eine Assertion abgeschwächt oder ein Mock an die Stelle der echten Abhängigkeit gesetzt?
- Vorschläge. Was der Agent notiert hat, wird entschieden und verschwindet nicht im Archiv.
Den Abgleich mit der Spec kann ein Review Agent in einer frischen Session vorbereiten. Wie das im Alltag aussieht, steht in KI Code Review mit Agents. Was passiert, wenn dieser Schritt fehlt, zeigt die Studie aus unserem Beitrag AI Slop in Pull Requests. Die Verantwortung für den Merge bleibt bei dem Menschen, der ihn auslöst.
Warum Scope eine Aufgabe für das ganze Team ist
Scope klingt nach einem Thema der Entwicklung. Er entsteht aber früher. Wer den Auftrag schreibt, legt fest, was gebaut wird, und das sind oft Product Owner, Fachabteilung oder Geschäftsführung. Je schneller Agents liefern, desto mehr hängt an diesem Auftrag. Ein unscharfes Ticket kostete früher ein paar Rückfragen. Ein Agent fragt selten zurück und baut einfach.
Deshalb gehören Regeln, Specs und Gates zusammen. Die NCA Agentic AI Coding Guardrails bringen diese Kette in bestehende Projekte, mit Plan vor Code, kleinen Diffs, Wissen im Repository und Gates in der Pipeline. Wie Scope, Nachweise und Freigabe in einem Loop zusammenspielen, zeigt der Governed Agent Loop. Was sich ansammelt, wenn niemand hinschaut, steht unter technische Schulden durch Vibe Coding. Und warum schnelle Features auch ein Geschäftsrisiko sind, haben wir in Das Feature Risiko durch KI Agenten eingeordnet.
Häufige Fragen zu Scope Creep bei Coding Agents
Was ist Scope Creep bei Coding Agents?
Scope Creep bei Coding Agents bedeutet, dass der Agent mehr ändert, als der Auftrag verlangt. Typisch sind neue Dependencies, Migrationen, zusätzliche Abstraktionen, Refactoring in fremden Dateien und geänderte Tests. Das bestellte Feature funktioniert dabei meist. Der Diff ist aber größer als die Aufgabe, und über die Zusatzänderungen hat kein Mensch entschieden.
Warum bauen Coding Agents mehr als beauftragt?
Ein Agent behandelt alles, was er im Kontext sieht, als Arbeitsfläche. Fehlt im Auftrag eine Grenze, füllt er die Lücke mit dem, was er für sauber hält. Dazu neigen Modelle zu mehr Abstraktion und mehr Code, als die Aufgabe braucht. Mit einem Abschnitt „Nicht im Auftrag“ in der Spec und engen Permissions wird das deutlich seltener.
Wie erkenne ich ungefragte Änderungen im Pull Request?
Lest zuerst die Liste der geänderten Dateien und erst danach die Beschreibung. Achtet auf Manifest und Lockfile, auf neue Migrationen, auf Dateien außerhalb des beauftragten Ordners, auf gelöschte Tests und auf Änderungen an Pipeline und Regeldateien. Fast alles davon erkennt ihr am Dateipfad. Ein Scope Gate in der Pipeline übernimmt diesen Abgleich automatisch.
Was ist ein Scope Gate?
Ein Scope Gate ist ein Check in der Pipeline, der die geänderten Dateien eines Pull Requests mit den erlaubten Pfaden aus dem Auftrag vergleicht. Liegt eine Datei außerhalb, wird der Check rot und blockiert den Merge. Heikle Pfade wie Lockfiles oder Migrationen bekommen zusätzlich eine Freigabe durch einen Menschen, zum Beispiel über ein Label.
Darf ein Coding Agent neue Dependencies hinzufügen?
Ja, wenn der Auftrag es erlaubt und ein Mensch die Entscheidung bestätigt. Eine neue Abhängigkeit bringt Wartung, Lizenzfragen und mögliche Schwachstellen mit. Darum sollte sie nie als Nebeneffekt eines Features ins Projekt kommen. Sperrt Manifest und Lockfile im Agent Setup und gebt sie nur gezielt frei, am besten als eigenen Pull Request.
Ist jede ungefragte Änderung schlecht?
Nein. Agents sehen oft echte Schwächen im Code. Schwierig wird es, wenn die Änderung ohne Entscheidung im Merge landet. Lasst den Agent seine Ideen als Vorschläge notieren. Dann entscheidet ein Mensch, ob daraus ein eigener Auftrag wird, ob die Änderung bewusst im Pull Request bleibt oder ob sie verworfen wird.
Bremst ein Scope Gate die Arbeit mit Agents aus?
Am Anfang kostet es ein paar Minuten pro Auftrag, weil der Scope aufgeschrieben werden muss. Danach spart es Zeit. Kleine Pull Requests mit klarem Umfang sind schnell gelesen. Große Diffs mit Überraschungen liegen dagegen lange im Review oder gehen ungelesen durch. Der Agent bekommt die Meldung des Gates zurück und kann den Diff selbst kürzen.
Fazit
Grüne Tests sagen, dass das Bestellte läuft. Was zusätzlich ins Repository kam, steht nur im Diff. Schreibt den Scope in die Spec, prüft ihn in der Pipeline, sperrt die heiklen Pfade und lasst den Agent Vorschläge machen. Dann bleibt jede Architekturentscheidung bei jemandem, der sie verantwortet.
Scope, Specs und Gates für euer Agent Setup
Wir bauen mit euch die Kette aus Auftrag, Regeldatei, Permissions und Quality Gates in euer bestehendes Projekt ein. Im kostenlosen Kennenlernen schätzen wir den Aufwand, abgerechnet wird transparent auf die Minute.
