Ein guter Entwickler ist ein fauler Entwickler. Auch mit KI.

Einer meiner Lieblingssätze als Entwickler war immer: Ein guter Entwickler ist ein fauler Entwickler.

Gemeint war nie, wenig zu arbeiten. Gemeint war, dieselbe Arbeit nicht zweimal zu machen. Wer ein Problem dreimal von Hand löst, schreibt sich beim vierten Mal ein Skript. Wer einen Fehler einmal gemacht hat, sorgt dafür, dass er nicht wiederkommt.

In den letzten Wochen habe ich mich gefragt, ob der Satz noch stimmt, jetzt, wo die KI den Code schreibt. Je länger ich darüber nachdenke, desto sicherer bin ich: Er stimmt noch, und er ist sogar wichtiger geworden.

Alle nutzen KI. Der Unterschied liegt danach

KI nutzen inzwischen alle, der faule Entwickler genauso wie der fleißige. Das unterscheidet niemanden mehr.

Der Unterschied liegt in dem, was nach einem Fehler passiert. Der fleißige Entwickler korrigiert ihn, und beim nächsten Projekt korrigiert er ihn wieder. Die KI macht es ja auch gern wieder falsch, sie hat kein Gedächtnis für meine Projekte von letztem Jahr. Der faule Entwickler will jeden Fehler nur einmal machen und überlegt sich danach, wie er dafür sorgt, dass das nicht wieder vorkommt.

Bei mir heißt die Antwort darauf: Code Guard.

Was der Code Guard ist

Der Code Guard ist ein Skript, das nach jeder Code-Änderung läuft, egal ob ich sie selbst gemacht habe oder ein Modell. Erst wenn es durchläuft, gilt eine Aufgabe bei mir als erledigt.

~/.claude/skills/code-quality/bin/code-guard

Es erkennt selbst, welche Prüfungen ein Projekt hat, und fährt sie in fester Reihenfolge: PHPStan, phpcs, Tests, composer audit und so weiter. Das Ergebnis landet maschinenlesbar in docs/.guard/results.json, der Exit-Code sagt, ob es weitergeht:

• 0: alles grün, weiter.
• 1: Befunde, beheben und neu fahren.
• 3 (UNSAFE SIDE EFFECT): sofort anhalten und mich fragen.

Die Standardwerkzeuge sind aber nur die halbe Sache. Der interessante Teil sind die Prüfungen, die ich selbst dazugeschrieben habe. Inzwischen sind das 18 eigene Prüfskripte, jedes davon ist aus einem Fehler entstanden, den ich irgendwann einmal gemacht oder gefunden habe. Ein paar Namen, damit du ein Gefühl dafür bekommst: check-secrets, check-migrations, check-auth-policy, check-legal, check-third-party.

Ich habe dem Code Guard also quasi beigebracht, auf die Fehler und Probleme zu achten, die ich in den letzten Jahren hatte.

Ein Beispiel: Google Fonts

Ein Fall, der jeden deutschen Webentwickler irgendwann einholt: Schriften, die direkt von Google geladen werden. Das ist in einer Zeile passiert, gerade wenn eine KI eine Vorlage baut und fonts.googleapis.com einbindet, weil das in ihren Trainingsdaten tausendfach so steht. Datenschutzrechtlich ist es ein Problem, weil beim ersten Seitenaufruf die IP-Adresse des Besuchers an Google geht.

Früher hätte ich das im Review gesehen, wenn ich es gesehen hätte. Heute steht es als Regel im Code Guard. check-third-party ruft die lokal laufende Seite auf, geht die Startseite und alle URLs aus der sitemap.xml durch und meldet jede Anfrage an einen fremden Host, die beim ersten Aufruf rausgeht. Google Fonts, Google Maps, Analytics, eingebettete Videos ohne Zwei-Klick-Lösung. Schriften müssen lokal auf der Platte liegen.

Das musste ich genau einmal festlegen. Seitdem schaut die Prüfung jedes Mal drüber und sagt: Da wird etwas von extern geladen, das ist nicht gut. Und weil die Prüfung nach jeder Änderung läuft, die ein Modell macht, bekommt das Modell den Befund zurück und behebt ihn, bevor ich überhaupt draufschaue.

Warum das mit KI wichtiger wird

Ohne KI habe ich einen Fehler selbst gemacht und mich meistens beim zweiten Mal erinnert. Mit KI kommt derselbe Fehler aus einer Quelle, die sich nicht erinnert, und er kommt in viel höherer Geschwindigkeit. Wo ich früher pro Tag eine Handvoll Dateien angefasst habe, ändert ein Agent in derselben Zeit ein Vielfaches.

Das heißt: Was ich nicht automatisch prüfe, rutscht irgendwann durch. Nicht, weil die Modelle schlecht sind, sondern weil niemand bei dieser Menge jede Zeile mit derselben Aufmerksamkeit liest. Die Faulheit, jeden Fehler nur einmal zu lösen und dann in eine Prüfung zu gießen, ist deshalb keine Bequemlichkeit mehr. Sie ist das, was die Qualität hält.

Ein Punkt noch, der mich selbst überrascht hat: Ein schwaches Modell behauptet gern „alles grün“, ohne dass es stimmt. Deshalb fahre ich den Code Guard nach einer delegierten Aufgabe immer selbst noch einmal. Ein Lauf kostet wenig, und der Exit-Code lügt nicht.

Inspiration, keine Vorlage

Mein Code Guard ist auf meine Projekte zugeschnitten: Symfony, Docker, Traefik, deutsche Rechtslage. Er ist ausdrücklich nicht der mächtigste, den es gibt. Wenn du einen richtig umfangreichen sehen willst, schau bei Prompt Geflüster vorbei. Meiner soll dir eher als Anregung dienen, wie du deine eigenen Fehler in Prüfungen verwandelst.

In den nächsten Beiträgen zeige ich weitere Werkzeuge und Skills, mit denen ich arbeite. Das Ziel dabei ist immer dasselbe: Die gewonnene Zeit soll in Dinge fließen, die sich lohnen. Bessere Codequalität, bessere Tests, bessere Kommunikation mit Kunden.

Was ich daraus mitnehme

• Der Satz bleibt. Ein guter Entwickler ist ein fauler Entwickler, denn wir machen die Sachen nur einmal.
• Jeder Fehler, der mich einmal Zeit gekostet hat, wird eine Prüfung: ein Skript mit Exit-Code. Eine Notiz im Prompt vergisst das Modell spätestens im nächsten Projekt.
• Prüfungen müssen automatisch laufen. Nach jeder Änderung, egal von wem, sonst werden sie bei der Geschwindigkeit von Agenten übersprungen.
• Ein Code Guard findet allerdings nur, was ich ihm beigebracht habe. Neue Fehler muss immer noch jemand zum ersten Mal sehen, und das bin meistens ich.