KI-Coding-Agenten brauchen XP

7 Min. Lesezeit

Agentisches Coding braucht ein Rückgrat

Wer nicht jeden Tag in der Software-Entwicklung arbeitet, kann das Grundproblem trotzdem leicht verstehen: Die Maschine schreibt schnell, aber schnell ist nicht dasselbe wie stimmig. Viel Software scheitert aus demselben Grund wie eine chaotische Küche. Messer in einer Schublade, Gabeln in der nächsten, Gewürze überall außer dort, wo gekocht wird, und drei angebrochene Reissäcke, weil niemand wusste, dass schon Reis da ist. Die Arbeit läuft weiter. Der Abfall wächst.

Software bekommt genau dieses Chaos, wenn Menschen oder Maschinen dieselbe Regel in fünf Dateien kopieren, für jede Laune eine neue Klasse erfinden oder Code refaktorieren, nur weil es intellektuell gerade juckt. Das Ergebnis kann immer noch laufen. Es wird nur teuer, es zu ändern.

XP funktioniert noch, weil die Physik noch funktioniert

Extreme Programming wurde für eine Welt gebaut, in der sich Software ständig ändert und Entwickler mehrmals am Tag falsch liegen. Diese Welt ist nicht verschwunden, nur weil ein großes Sprachmodell ganze Dateien vervollständigen kann.

Die XP-Gewohnheiten, die im Jahr 2000 wichtig waren, sind mit Agenten im Jahr 2026 noch wichtiger:

• Zuerst einen fehlschlagenden Test schreiben.
• Die kleinste Änderung machen, die Rot in Grün verwandelt.
• Nur refaktorieren, solange die Tests grün bleiben.
• Ständig integrieren, statt Überraschungen für später aufzuheben.

Nichts davon ist glamourös. Gute Praxis ist es selten. Gute Praxis sieht meist so aus, dass man sich weigert, sich selbst zu belügen.

Agentisches Coding erhöht den Einsatz, weil das Modell viel plausiblen Unsinn produzieren kann, bevor ein Mensch den Kaffee ausgetrunken hat. Genau deshalb Tests schlagen Anweisungen. Die Gewohnheit zählt, weil die Feedback-Schleife zählt. Nimmt man sie weg, bleibt Geschwindigkeit und Hoffnung. So werden teure Fehler massenhaft produziert.

DRY heißt eine Regel, ein Zuhause

DRY wird oft zu einem Slogan verkürzt, der nur weniger Tipperei meint. Das verfehlt den Punkt. Es geht nicht darum, weniger Tasten zu drücken. Es geht darum sicherzustellen, dass eine Geschäftsregel nicht heimlich in mehrere konkurrierende Versionen zerfällt.

Wenn die Rabattlogik in einem Controller, einem Hintergrundjob, einem Checkout-Service und einem Reporting-Skript lebt, ist das keine Wiederverwendung. Das sind vier zukünftige Meinungsverschiedenheiten, die nur auf ein Release-Wochenende warten.

Genau diesen Schmutz produzieren Agenten, wenn die Disziplin fehlt. Das Modell sieht ähnlichen Code an zwei Stellen und klebt bereitwillig eine dritte Version dazu, weil das die aktuelle Aufgabe löst. Das ist nicht bösartig. Das ist opportunistisch. Schnelle Ausgabe ohne Design-Druck driftet immer zur Duplikation.

Darum gilt die alte Regel noch immer:

• Ein bestehendes Domain-Objekt oder Hilfsmodul wiederverwenden, bevor etwas Neues entsteht.
• Wenn eine Geschäftsregel zweimal auftaucht, sie extrahieren, bevor die Aufgabe als fertig gilt.
• Keine Validierungs-, Preis-, Autorisierungs- oder Mapping-Logik über Module hinweg kopieren.

Das ist der menschliche Job in der Arbeit mit einem Agenten. Nicht Handwerksromantik predigen und zugleich vermeidbare Duplikation akzeptieren. Die alte Gewohnheit gewinnt weiterhin: die Regel an einem Ort halten und diesen Ort bei jeder Änderung verteidigen.

Für Leser außerhalb des Entwickleralltags ist DRY nur dies: Wenn sich eine Firmenregel ändert, will man sie an einer Stelle anpassen und nicht an sieben Stellen vergessen.

OOP dreht sich um Verantwortung, nicht um Vererbungs-Kostüme

Auch objektorientierte Programmierung wird ständig missbraucht von Leuten, die Vokabular mit Design verwechseln. Eine Klassenhierarchie ist keine Architektur. Oft ist sie nur der längere Weg zum Bedauern.

Gute OOP bedeutet gerade im agentischen Coding ein paar schlichte Dinge:

• Jedes Objekt oder Modul sollte genau einen klaren Grund haben, sich zu ändern.
• Verhalten sollte nah an den Daten leben, von denen es abhängt.
• Öffentliche Schnittstellen sollten klein bleiben.
• Komposition sollte gegen Vererbung gewinnen, außer Vererbung ist offensichtlich einfacher.

Das ist wichtig, weil Agenten Abstraktionen lieben. Gibt man ihnen einen vagen Prompt, liefern sie mit Freude BaseManagerFactoryAdapter, als wäre Satire ein Entwurfsmuster.

Die Gewohnheit, die das im Zaum hält, ist älter als der aktuelle Werkzeughype: kleine Objekte mit klarer Verantwortung bevorzugen, eine bestehende Abstraktion nur erweitern, wenn der umliegende Code dieses Muster bereits benutzt, und keine neue Schicht einziehen, solange die aktuelle noch nicht versagt.

Der Praxistest ist brutal einfach: Wenn ein menschlicher Entwickler nicht erklären kann, wo eine Regel lebt und warum, wird der Agent sie auch nicht kohärent halten.

TDD gibt dem Agenten ein Metronom

Viele Teams sagen, sie wollten, dass das Modell TDD betreibt, meinen aber in Wahrheit: “Schreib bitte auch ein paar Tests dazu, damit das Ganze respektabel aussieht.” Das ist kein TDD. Das ist Bürokratie mit Assertions.

Wenn ein Agent sich wie ein disziplinierter Entwickler verhalten soll, muss die Entwicklungsschleife intakt bleiben, statt Tests zu dekorativem Papierkram verkommen zu lassen.

Die Schleife ist alt und weiterhin ungeschlagen:

1. Die bestehenden Tests und den bestehenden Code lesen, bevor etwas geändert wird.
2. Einen fehlschlagenden Test hinzufügen oder anpassen, der das nächste Verhalten beschreibt.
3. Die kleinste Änderung umsetzen, die diesen Test grün macht.
4. Die relevanten Tests ausführen.
5. Erst nach Grün refaktorieren.

Das gibt dem Modell einen Rhythmus. Es verengt den Suchraum. Es macht aus der Aufgabe nicht mehr “schreib etwas Eindrucksvolles”, sondern “erfülle diesen konkreten Vertrag, ohne den Rest zu beschädigen”. Modelle brauchen diese Disziplin noch mehr als Menschen, weil sie sehr gut darin sind, korrekt zu klingen und strukturell falsch zu liegen.

Wer die breitere Abrechnung mit Freestyle-Prompting lesen will, findet sie hier: Vibe Coding ist keine Software-Entwicklung. Es ist Improvisation mit besserem Autocomplete.

Was gute Agent-Anweisungen tatsächlich sagen

Die meisten schlechten Anweisungsdateien teilen denselben Fehler: Sie versuchen, jede Programmierentscheidung in Prosa vorwegzunehmen. Das ist nicht zu gewinnen. Die Datei bläht sich auf, Widersprüche tauchen auf, und der Agent pflückt sich das Token-Muster heraus, das gerade am leichtesten passt.

Der bessere Ansatz ist kleiner und härter. Eine gute Anweisungsdatei sollte vor allem dies abdecken:

• Arbeitsablauf: Test zuerst, kleinste Änderung, grün vor Refactoring.
• Design-Leitplanken: DRY halten, kleine Objekte bevorzugen, bestehende Abstraktionen wiederverwenden.
• Sicherheitsregeln: Tests nicht abschwächen, keine Abhängigkeiten leichtfertig erfinden, bei unklaren Anforderungen fragen.
• Abschlussregeln: Tests grün, Linter grün, fokussierter Diff.

Mehr braucht es nicht, um Verhalten zu formen, ohne so zu tun, als könne Markdown Urteilskraft ersetzen.

Anders gesagt: Anweisungsdateien sind für Gewohnheiten da. Tests sind für Beweise da. Linter sind für Konsistenz da. Jedes Werkzeug sollte seinen eigenen Job machen.

Eine bessere Prompt-Gewohnheit für Teams und Solo-Entwickler

Rund um agentisches Coding hält sich eine verführerische Fantasie: einmal einen cleveren Master-Prompt schreiben und dann das Handwerk von der Maschine tragen lassen. Diese Fantasie überlebt, weil die ersten Demos meistens funktionieren.

Dann kommt die Realität. Das Modell dupliziert Logik. Es ändert eine Schnittstelle, die niemand anfassen wollte. Es fügt einen Helfer hinzu, der fast zum vorhandenen Helfer passt, aber eben nur fast. Plötzlich schreibt das Team Prompt-Recht statt Software.

Das Gegenmittel ist nicht mehr Drama im Prompt. Das Gegenmittel ist ein Repository, das die Wahrheit sagt:

• Tests erklären, was das System tun muss.
• Anweisungsdateien erklären, wie der Agent sich bei Änderungen verhalten soll.
• Bestehender Code zeigt, welche Muster bereits leben.

Sobald diese drei Dinge zusammenpassen, werden Prompts einfacher. Dann kann man sagen: “Füge Schweizer Mehrwertsteuer für Rechnungen hinzu”, und darauf vertrauen, dass der Agent durch die Vordertür kommt, statt ein Fenster einzuschlagen.

Das gilt auch für Solo-Entwickler. Ein Solo-Repo kann genauso zum Sumpf werden. Meist sogar schneller, weil niemand da ist, der sich beschwert, bevor das Schilf schulterhoch steht.

Beispiel-Dateien

Die Beispiele unten sind bewusst kurz. Sie versuchen nicht, das gesamte Handwerk der Software-Entwicklung in Markdown zu serialisieren. Sie etablieren Disziplin und geben die Durchsetzung dann an Tests und Werkzeuge zurück.

• GitHub-Copilot-Beispielanweisungen
• Claude-Beispielanweisungen
• AGENTS.md-Beispiel für Multi-Agent-Arbeit

Nimm sie. Kürze sie. Passe sie an deinen Stack an. Aber halte den Schwerpunkt dort, wo er hingehört: winzige Feedback-Schleifen, klare Verantwortlichkeiten und weniger duplizierte Dummheit.