Die Boy-Scout-Regel im Code: Mit KI wird sie wichtiger, nicht überflüssig

Heute früh hatte ich einen dieser Momente, in denen eine 15 Jahre alte Regel plötzlich sehr aktuell wird.

In einem größeren Kundenprojekt, einer über Jahre gewachsenen Web-Anwendung, brachte ein Framework-Update rund 350 neue Warnungen mit. Nicht weil der Code schlechter geworden wäre, sondern weil eine strengere Prüf-Regelfamilie dazukam, die vorher nie lief. Alle auf einmal zu beheben wäre ein Wochen-Projekt mit hohem Risiko gewesen. Sie einfach zu ignorieren wäre der Anfang vom schleichenden Verfall.

Die Antwort war eine Regel, die ich seit Jahren kenne und die heute in die Anweisungsdatei meines KI-Assistenten gewandert ist: die Boy-Scout-Regel.

Woher die Regel kommt

Der Ursprung liegt bei den Pfadfindern. Robert Baden-Powell, ihr Gründer, schrieb sinngemäß: "Versuche, die Welt ein bisschen besser zu hinterlassen, als du sie vorgefunden hast." Daraus wurde in Pfadfinderkreisen das griffigere "Hinterlasse den Lagerplatz sauberer, als du ihn vorgefunden hast."

In die Softwareentwicklung kam die Regel über Robert C. Martin, in der Szene bekannt als "Uncle Bob". Er widmete ihr ein eigenes Kapitel im Standardwerk "97 Things Every Programmer Should Know" (O'Reilly, 2010) und griff sie in seinem Buch "Clean Code" auf. Seine Übersetzung für Entwickler: "Check ein Modul immer sauberer wieder ein, als du es ausgecheckt hast."

Sein Versprechen dahinter: Wenn das jeder täte, würde der ständige Verfall von Software-Systemen aufhören. Sie würden mit jeder Änderung ein Stück besser statt schlechter.

Was sie in der Entwicklung bedeutet

Software zerfällt, wenn niemand hinschaut. Jede schnelle Lösung, jeder Workaround, jede nicht aufgeräumte Kleinigkeit ist ein Krümel technischer Schuld. Über Jahre summiert sich das zu einer Codebasis, die keiner mehr anfassen will.

Die Boy-Scout-Regel setzt genau dort an, aber ohne den großen Kahlschlag. Der Kern ist:

Wenn du eine Stelle im Code ohnehin öffnest, räum die Kleinigkeiten dort gleich mit weg. Einen schlechten Variablennamen. Eine überflüssige Funktion. Eine Warnung, die schon lange dort steht.

Wichtig ist die Abgrenzung: Das ist kein großes Refactoring und kein Scope Creep. Du reißt nicht das halbe System ein, weil dir gerade danach ist. Du machst genau die Stelle sauber, an der du sowieso bist. Klein, lokal, im Vorbeigehen. Das Risiko bleibt winzig, der Effekt summiert sich.

Bei den 350 Warnungen von heute früh hieß das konkret: kein Big-Bang. Stattdessen die Regel "Wer eine Komponente ohnehin anfasst, räumt die dort gemeldeten Warnungen gleich mit weg." Der Bestand wird nicht auf einen Schlag saniert, sondern schmilzt mit jeder normalen Arbeit ab.

Warum die Regel bei Agentic Coding zur Notwendigkeit wird

Bis hierhin ist das ein bekanntes Thema. Interessant wird es, wenn nicht mehr ein Mensch den Code schreibt, sondern ein KI-Agent.

Ein Mensch produziert Code langsam. Er spürt Widerstand, wenn eine Datei chaotisch wird. Ein KI-Agent produziert Code schnell und billig. Er spürt keinen Widerstand. Wenn du ihm nur die gestellte Aufgabe gibst, löst er genau diese Aufgabe und lässt den Rest liegen, wie er ihn vorgefunden hat. Technische Schulden wachsen dadurch nicht langsamer, sondern schneller.

Was bei einem Menschen eine Tugend ist, wird beim Agenten zur Leitplanke. Ein Agent ohne Boy-Scout-Prinzip hinterlässt mit jeder Iteration ein bisschen mehr Wildwuchs. Ein Agent, der die Regel als feste Anweisung mitbekommt, verbessert den Bestand bei jeder Berührung mit.

Und hier passt die Arbeitsteilung erstaunlich gut: Der Mensch zieht die Grenze, kein Kahlschlag, kein Umbau ohne Auftrag. Der Agent erledigt das inkrementelle Aufräumen im Vorbeigehen, zuverlässig und ohne dass es extra Zeit kostet. Genau das, wozu Menschen im Alltag oft zu bequem sind.

Haltung wird Konfiguration

Für mich ist die eigentliche Erkenntnis eine andere. Die Boy-Scout-Regel war immer eine Frage der Haltung, kein Prozess. Man kann sie nicht erzwingen, man muss sie wollen.

Bei einem KI-Agenten wird aus Haltung plötzlich Konfiguration. Er hat keine Haltung. Er hat einen Systemprompt. Was ich ihm dort mitgebe, ist seine Haltung. Sorgfalt ist bei KI kein Charakterzug mehr, sondern eine Zeile in einer Anweisungsdatei.

Und das Schöne: So eine Anweisung ist nicht projektgebunden. Sie passt in jede Datei, mit der du deinen KI-Assistenten steuerst (bei mir eine CLAUDE.md). Zum Kopieren:

Boy-Scout-Regel: Wenn du eine Datei fuer eine Aufgabe ohnehin
oeffnest, raeum die kleinen Maengel dort gleich mit weg
(schlechte Namen, toter Code, offene Warnungen).
Kein grosser Umbau, keine Refactorings ausserhalb der Aufgabe:
nur die Stelle, an der du sowieso gerade bist.

Ein paar Zeilen. Und trotzdem der Unterschied zwischen einem Assistenten, der eine Codebasis langsam verkommen lässt, und einem, der sie mit jeder Aufgabe ein Stück besser macht.

Das ist übrigens der direkte Gegenentwurf zu dem, was oft "Vibe Coding" genannt wird: schnell irgendwas hinwerfen, Hauptsache es läuft. Boy-Scout ist das Gegenteil, Sorgfalt statt Wegwerf-Code. Warum ich meine Arbeit mit KI nicht "Vibe Coding" nenne, habe ich hier beschrieben: Warum ich Software-Entwicklung mit KI nicht "Vibe Coding" nenne.

Wann passt das, wann nicht

Passt: In gewachsenen Codebasen mit Altlasten. Bei kontinuierlicher Weiterentwicklung. Immer, wenn ein KI-Agent regelmäßig am selben Code arbeitet.

Passt nicht: Wenn "sauberer machen" zur Ausrede für ungefragte große Umbauten wird. Wenn der Aufräum-Schritt das eigentliche Ziel verwässert oder das Risiko explodieren lässt. Und nicht als Ersatz für ein bewusst geplantes Refactoring, wenn eine Stelle wirklich grundlegend faul ist. Die Regel ist der stetige kleine Hebel, nicht der große Wurf.

Der Punkt

Software verfällt, wenn niemand die Krümel wegräumt. Mit KI-Agenten, die viel und schnell Code produzieren, verfällt sie schneller. Die gute Nachricht: Dieselben Agenten sind auch die besten Boy Scouts, die man sich wünschen kann, solange man es ihnen sagt. Sorgfalt lässt sich nicht mehr nur hoffen. Sie lässt sich aufschreiben.