Tests schlagen Anweisungen für KI-Agenten

13 Min. Lesezeit

Embedded Delivery Partner

Die besten Regeln für KI-Agenten sind die, die den Build abbrechen

17.04.2026, Von Stephan Schwab

Alle wollen, dass KI-Agenten sich an Regeln halten. Also schreiben sie lange Markdown-Dateien voller Anweisungen, Konventionen und Warnungen. Die Agenten lesen sie, verstehen sie irgendwie, und weichen trotzdem ab. Es gibt einen besseren Ansatz, und den gibt es seit über sechs Jahrzehnten: testgetriebene Entwicklung. Tests sind ausführbare Einschränkungen, die sofort fehlschlagen, wenn ein Agent vom Kurs abkommt. Keine Interpretation nötig. Keine probabilistische Einhaltung. Rot oder grün.

Das Wettrüsten der Markdown-Anweisungen

Jedes KI-Entwicklungswerkzeug hat mittlerweile sein eigenes Anweisungsformat. Cursor hat .cursorrules. GitHub Copilot hat copilot-instructions.md. Windsurf hat eigene Konventionen. Die Idee ist überall dieselbe: Schreib die Regeln deines Projekts als Prosa auf, und der Agent wird sich daran halten.

Entwickler investieren Stunden in diese Dateien. „Immer Factory-Funktionen verwenden, niemals Konstruktoren.” „Komposition vor Vererbung bevorzugen.” „Niemals das Datenbankschema ohne Migration ändern.” „Unser eigenes Fehlerbehandlungsmuster aus src/errors/ nutzen.” Die Dateien wachsen. Sie werden zu internen Stilrichtlinien, Architekturdokumenten und Wunschlisten in einem.

Und die Agenten weichen trotzdem ab.

Nicht immer. Nicht sofort. Aber irgendwann. Die KI produziert Code, der technisch den Wortlaut einer Anweisung erfüllt, aber den Geist von drei anderen verletzt. Sie erfindet eine neue Hilfsfunktion, statt die bestehende zu nutzen. Sie baut ein Modul um, das tadellos funktionierte, weil sie eine „Verbesserungsmöglichkeit” erkannt hat. Sie ändert eine Schnittstellensignatur, weil der neue Ansatz sauberer schien.

Das ist kein Fehler im Modell. Das ist die Bedeutung von Nicht-Determinismus. LLMs verarbeiten Anweisungen probabilistisch. Jedes Token ist eine gewichtete Entscheidung. „Immer Factory-Funktionen verwenden” wird im Modell keine harte Einschränkung. Es wird ein Impuls, ein Signal unter tausenden, die während der Erzeugung um Aufmerksamkeit konkurrieren. Manchmal gewinnt der Impuls. Manchmal verliert er gegen ein Muster, das das Modell häufiger in den Trainingsdaten gesehen hat.

Also reagieren Entwickler mit noch mehr Anweisungen. Spezifischeren. „Beim Erstellen einer neuen Service-Klasse IMMER zuerst src/services/ auf bestehende Muster prüfen.” „NIEMALS bestehende öffentliche Methoden umbenennen.” „Wenn du dir bei der Architektur unsicher bist, FRAG NACH.” Die Datei wächst auf 500 Zeilen. Dann 1.000. Der Agent hat jetzt so viele konkurrierende Direktiven, dass er sie nicht alle gleichzeitig erfüllen kann. Die Anweisungen widersprechen sich an den Rändern, wie sich jede hinreichend detaillierte Prosa selbst widerspricht.

Warum Prosa eine Wahrscheinlichkeitsmaschine nicht einschränken kann

Das grundlegende Problem: Man verwendet das mehrdeutigste Kommunikationsmedium (natürliche Sprache), um ein System einzuschränken, das auf Wahrscheinlichkeitsverteilungen arbeitet. Jeder Satz hat mehrere gültige Interpretationen. „Komposition vor Vererbung bevorzugen” klingt klar, bis der Agent einen Fall antrifft, in dem Vererbung den Code tatsächlich vereinfacht. Was bedeutet „bevorzugen” dann? In 70 % der Fälle? 90 %? Immer, außer wenn der Agent anders entscheidet?

Anweisungen in Markdown sind Hoffnungen. Wünsche, formuliert in menschlicher Sprache, eingespeist in ein System, das nicht so darüber nachdenkt wie ein menschlicher Kollege. Ein menschlicher Kollege liest „Komposition bevorzugen” und baut ein mentales Modell der Architektur, der Geschichte des Teams, der bisherigen Designentscheidungen, des spezifischen Code-Kontexts. Ein LLM liest es und passt Token-Wahrscheinlichkeiten an.

Je mehr Anweisungen man hinzufügt, desto mehr spielt man ein Spiel, das man nicht gewinnen kann. Man versucht, jede mögliche Situation aufzuzählen, in die ein Agent geraten könnte, und das korrekte Verhalten vorab festzulegen. Das ist dieselbe Falle, in die BDUF (Big Design Up Front) vor Jahrzehnten getappt ist. Die Welt ist zu komplex, um sie vollständig im Voraus zu spezifizieren. Jede neue Anweisung erzeugt neue Grenzfälle, in denen sich Anweisungen widersprechen.

Tests bitten nicht um Einhaltung. Sie erzwingen sie.

Jetzt stell dir vor, was passiert, wenn eine umfassende Testsuite existiert.

Der KI-Agent schreibt Code. Die Tests laufen. Sie bestehen oder schlagen fehl. Es gibt keine Interpretation. Keine probabilistische Einhaltung. Kein „Ich habe den Geist der Anweisung befolgt.” Der Build ist rot oder grün.

Wenn der Agent ein neues Muster erfindet, statt das bestehende zu nutzen, fangen die Integrationstests die Inkonsistenz ab. Wenn er eine öffentliche Schnittstelle umstrukturiert, brechen die Vertragstests. Wenn er das Datenbankverhalten ändert, schlagen die Datenintegritätstests fehl. Wenn er Geschäftslogik verändert, schreien die Spezifikationstests.

Tests sind Spezifikationen, die ausgeführt werden. Sie definieren, was das System tut, und verifizieren es kontinuierlich. Ein KI-Agent kann sich an einer fehlschlagenden Assertion nicht vorbeireden.

Deshalb erweist sich testgetriebene Entwicklung als das wirksamste Steuerungsinstrument für KI-Agenten im Jahr 2026. Die Praxis geht auf das Jahr 1957 zurück, als Daniel D. McCracken sie in Digital Computer Programming beschrieb: zuerst die erwartete Ausgabe vorbereiten, dann Code schreiben, bis die tatsächliche Ausgabe übereinstimmt. Kent Beck hat sie 2003 wiederentdeckt und formalisiert. Keiner von beiden dachte an LLMs. Aber TDD produziert genau das Artefakt, das nicht-deterministische Code-Generatoren einschränkt: eine dichte, ausführbare Spezifikation des beabsichtigten Verhaltens.

Der Vorteil ausführbarer Spezifikationen

Was repräsentiert eine gut gepflegte Testsuite eigentlich? Sie ist eine präzise, eindeutige, maschinell überprüfbare Beschreibung dessen, was die Software tun soll. Nicht wie sie aussehen soll. Nicht welchen Mustern sie folgen soll. Was sie tun soll.

Ein Unit-Test, der expect(calculateTax(100, 'DE')).toBe(19) sagt, ist eine Spezifikation. Er besagt: Für einen Betrag von 100 in Deutschland beträgt die Steuer 19. Kein LLM kann das falsch interpretieren. Keine probabilistische Token-Auswahl kann 19 gleich 21 machen. Der Test besteht oder er schlägt fehl.

Multipliziere das mit Hunderten oder Tausenden von Tests. Man erhält eine Spezifikation so dicht und so präzise, dass der KI-Agent in einem Korridor operiert. Er darf kreativ sein, wie er etwas umsetzt. Er kann andere Variablennamen wählen, andere Kontrollflussstrukturen, andere interne Muster. Aber er kann nicht ändern, was der Code tut, ohne sofort Fehler auszulösen.

Die meisten übersehen diesen Punkt: Tests fangen Fehler nicht nur im Nachhinein ab. Moderne KI-Agenten lesen die Tests, bevor sie eine einzige Zeile Umsetzung schreiben. Die Testsuite ist Kontext. Wenn ein Agent das hier sieht:

expect(createUser({role: 'admin'})).toHavePermission('delete')

Dann weiß er nicht nur, was er validieren soll. Er weiß, was er bauen soll. Die Tests werden zur klarsten, eindeutigsten Spezifikation, die der Agent in der Codebasis finden kann. Prosa-Anweisungen konkurrieren mit Trainingsdaten und Kontextfenster-Rauschen. Ein Test mit konkreten Eingaben und erwarteten Ausgaben schneidet durch all das hindurch. Der Agent liest ihn, versteht den Vertrag und generiert Code, der ihn erfüllt. Tests sind gleichzeitig Bauplan und Prüfer.

Das ist die tatsächliche Führung, die man will. Ob der Agent eine Factory-Funktion oder einen Konstruktor verwendet, ist egal, solange das Verhalten korrekt ist. Ob er interne Module umstrukturiert, ist egal, solange alle Verträge eingehalten werden. Tests steuern Ergebnisse, nicht Stil. Und Ergebnisse sind das, was zählt.

Vergleiche das mit einer Markdown-Anweisungsdatei. „Immer Factory-Funktionen verwenden” steuert Stil, nicht Ergebnisse. Es schränkt das Falsche ein. Die KI könnte es perfekt befolgen und dabei Code produzieren, der die Geschäftslogik zerstört, und man erfährt es erst in der Produktion.

Die endlose Jagd der Vibe Coder

In der Praxis sieht es so aus: Jemand ohne Erfahrung in TDD beginnt, einen KI-Agenten zu nutzen. Der Agent produziert Code, der für die ersten Prompts funktioniert. Dann beginnt er abzuweichen. Er ändert Muster. Benennt Dinge um. Erfindet Abstraktionen. Der Entwickler bemerkt die Abweichung und tut das Einzige, was er kennt: mehr Anweisungen schreiben.

„Bestehende Funktionen nicht umbenennen.” Hinzugefügt. Der Agent benennt nicht mehr um, fängt aber an, Funktionen in überflüssige Adapter einzupacken. „Keine Adapter-Schichten ohne Rückfrage hinzufügen.” Hinzugefügt. Der Agent fragt jetzt vor jeder Änderung, was alles so langsam macht, dass es unbrauchbar wird. „Nur bei architektonischen Änderungen nachfragen.” Hinzugefügt. Der Agent interpretiert „architektonisch” anders als der Entwickler. Noch mehr Abweichung.

Das ist das Hamsterrad des Vibe Coders. Jede Anweisung ist ein Pflaster für das Versagen der vorherigen. Die Anweisungsdatei wird ein wachsender Haufen aus Sonderfällen, Widersprüchen und zunehmend verzweifelten Warnungen in Großbuchstaben. Manche Entwickler enden mit Dateien, die wie Verträge lesen, voller „MUSS”, „DARF NICHT”, „UNTER KEINEN UMSTÄNDEN”, als ob juristische Sprache gegenüber einem LLM Wirkung hätte.

Hat sie nicht. Das Modell versteht weder Drohung noch Verpflichtung. Es verarbeitet Text und sagt Token vorher. Die Großbuchstaben erhöhen die Wahrscheinlichkeit der Befolgung leicht, so wie „WICHTIG” in einer E-Mail die Chance leicht erhöht, dass jemand sie liest. Leicht.

Ein Entwickler, der TDD praktiziert, arbeitet derweil anders. In der Praxis schreibt der Agent Test und Umsetzung zusammen. Das ist in Ordnung. Geschwindigkeit zählt. Aber hier liegt der entscheidende Unterschied: Diese Tests existieren vor der nächsten Änderung. Wenn der Agent diesen Code erneut berührt, wirken die Tests der vorherigen Runde als Leitplanken. Sie definieren, was nicht kaputtgehen darf. Der Agent weicht ab? Der Test schlägt fehl. Sofort. Keine Anweisungsdatei nötig. Keine Verhandlung mit einer Wahrscheinlichkeitsmaschine.

Die Rolle des Menschen verschiebt sich. Man schreibt nicht mehr jeden Test selbst. Man prüft die Tests, die der Agent geschrieben hat, stellt sicher, dass sie das richtige Verhalten abbilden, und zieht sie an, wo sie zu locker sind. Dann macht man weiter. Beim nächsten Mal, wenn der Agent dieses Modul ändert, läuft er gegen eine Wand aus Spezifikationen, die er nicht ignorieren kann. Jede Entwicklungsrunde hinterlässt Einschränkungen für die nächste. Die Testsuite wächst zu einem zunehmend dichten Sicherheitsnetz, gemeinsam gebaut von Mensch und Maschine.

Und hier wird der Arbeitsablauf noch mächtiger: Man muss nicht jeden Test und jede Codezeile selbst lesen. Man kann den Agenten fragen. „Prüft irgendein Test, dass abgelaufene Token abgelehnt werden?” „Was passiert, wenn der Zahlungsbetrag null ist?” „Zeig mir, welche Tests den Löschvorgang von Benutzern abdecken.” Man befragt die Codebasis im Gespräch, überprüft seine Annahmen, ohne sich manuell durch Dateien zu arbeiten. Es ist, als hätte man einen Zeugen auf der Anklagebank, der jede Zeile gelesen hat und sofort antworten kann. Die Tests werden zu abfragbarer Dokumentation, und der Agent wird zur Schnittstelle dazu.

Aber die richtigen Fragen zu stellen, dafür braucht man echte Erfahrung. Wer Systeme gebaut, ausgeliefert und um 3 Uhr nachts bei deren Versagen zugesehen hat, wer mit Race Conditions, Datenkorruption und kaskadierenden Timeouts zu tun hatte, weiß, wonach man suchen muss. Man fragt nach Grenzfällen, weil man von Grenzfällen verbrannt wurde. Man fragt nach Bereinigung bei Fehlern, weil man verwaiste Ressourcen debuggen musste. Man fragt nach Nebenläufigkeit, weil man gesehen hat, was passiert, wenn zwei Anfragen dieselbe Zeile treffen. Der Agent kann jede Frage beantworten. Er kann nicht sagen, welche Fragen man vergisst zu stellen. Das ist der Unterschied zwischen einem Entwickler und jemandem, der gerade gelernt hat zu prompten.

Was ist mit Stil? Was ist mit Architektur?

Der naheliegende Einwand: Tests steuern nicht alles. Sie erzwingen keinen Programmierstil. Sie hindern den Agenten nicht daran, Tabs statt Leerzeichen zu verwenden, übermäßig clevere Einzeiler zu schreiben oder unglückliche Variablennamen zu wählen.

Stimmt. Aber dafür gibt es Linter, Formatter und statische Analysewerkzeuge. Ruff, ESLint, Prettier, Checkstyle, was auch immer zum jeweiligen Stack passt. Diese Werkzeuge erzwingen Stil deterministisch. Sie laufen, sie markieren Verstöße, der Build schlägt fehl. Genau wie Tests.

Architektur? Wenn die Architektur wichtig ist, drücke sie in Tests aus. Schreib Tests, die Modulgrenzen verifizieren. Schreib Tests, die Abhängigkeitsrichtungen prüfen. Schreib Tests, die sicherstellen, dass bestimmte Pakete nicht aus bestimmten anderen Paketen importieren. ArchUnit für Java macht genau das. Andere Sprachen haben Äquivalente. Wenn eine Architekturregel nur in einer Markdown-Datei existiert, ist sie ein Vorschlag. Wenn sie in einem Test existiert, ist sie eine Einschränkung.

Das Muster ist immer dasselbe: Dinge, die laufen und fehlschlagen, sind Einschränkungen. Dinge, die in einer Datei stehen und hoffen, gelesen zu werden, sind Vorschläge. KI-Agenten sind schlecht darin, Vorschläge konsequent zu befolgen. Sie sind sehr gut darin, Tests zu bestehen.

Das Paradoxon: Alte Praktiken als moderne Werkzeuge

Es gibt eine Ironie, bei der es sich lohnt zu verweilen. Die meistgehypte Technologie des Jahrzehnts, KI-gestützte Software-Entwicklung, wird am besten von einer Praxis gesteuert, die älter ist als die meisten Programmiersprachen. McCracken beschrieb testgetriebene Programmierung im selben Jahr, in dem Fortran erschien. Kent Beck hat sie vier Jahrzehnte später wiederentdeckt. Die Kernidee hat sich nie geändert: Definiere, wie „korrekt” aussieht, bevor du den Code schreibst. Diese Disziplin liefert kleine Schritte, schnelles Feedback und verifiziertes Verhalten. Genau die Eigenschaften, die man braucht, wenn ein nicht-deterministischer Agent den Code schreibt.

Kleine Schritte bedeuten, dass der Agent nicht weit vom Kurs abkommen kann, bevor er an eine Test-Grenze stößt. Schnelles Feedback bedeutet, dass Abweichungen in Sekunden erkannt werden, nicht in Tagen. Verifiziertes Verhalten bedeutet, dass es einen objektiven, automatisierten Richter gibt, ob die Ausgabe des Agenten akzeptabel ist.

Vibe Coding überspringt all das. Der Vibe Coder promptet, der Agent generiert, der Entwickler begutachtet die Ausgabe mit bloßem Auge und schiebt sie in Produktion, wenn sie „richtig aussieht”. Das funktioniert für Wegwerf-Prototypen. Es scheitert katastrophal an allem, was zuverlässig funktionieren, langfristig gewartet oder von jemand anderem als dem ursprünglichen Prompter geändert werden muss.

Deshalb ersetzt KI auch keine Entwickler. Sie ersetzt die Illusion, dass man durchkommt, ohne wirklich zu verstehen, was man baut. Diejenigen, die Ersetzung fürchteten, waren oft die, die nicht formulieren konnten, was ihr Code tun soll, jenseits von „läuft bei mir”. KI hat dieses Problem nicht geschaffen. Sie hat es sichtbar gemacht. Ein Entwickler, der Tests schreiben, die richtigen Fragen stellen und strukturelle Schwächen erkennen kann, wird mit KI dreimal schneller arbeiten. Ein Entwickler, der sich auf Copy-Paste und Stack Overflow verlassen hat, wird feststellen, dass die KI diesen Teil auch kann, und billiger. Die Bedrohung ist nicht künstliche Intelligenz. Die Bedrohung besteht darin, den Beruf wegen des Gehalts statt wegen des Handwerks gewählt zu haben. Gute Entwickler mit KI werden mittelmäßige Teams ohne KI übertreffen. Das ist keine Vorhersage. Es passiert bereits.

Der Vibe Coder, der feststellt, dass sein Agent ständig abweicht, hat zwei Möglichkeiten. TDD lernen. Oder weiter Anweisungen schreiben, die nie genug sein werden. Die meisten wählen die zweite Option, weil sie sich wie Fortschritt anfühlt. Die Datei wird länger. Der Agent weicht weiter ab. Aber wenigstens tut man etwas.

So fängt man an

Wer KI-Agenten nutzt und keine Testsuite hat, sollte anfangen, eine aufzubauen. Nicht als Nachgedanken. Vor dem ersten Prompt an den Agenten.

Schreib einen fehlschlagenden Test, der beschreibt, was du willst. Lass den Agenten eine Umsetzung vorschlagen. Führ den Test aus. Wenn er besteht, schreib den nächsten Test. Wenn er fehlschlägt, war der Vorschlag des Agenten falsch. Sag es ihm. Lass ihn es erneut versuchen, mit dem fehlschlagenden Test als Spezifikation.

Dieser Arbeitsablauf ist schneller als detaillierte Anweisungen zu schreiben, weil man dem Agenten ein eindeutiges Erfolgskriterium gibt, statt zu hoffen, dass er die Prosa korrekt interpretiert. Und jeder geschriebene Test bleibt bestehen. Er wird Teil der permanenten Spezifikation. Das nächste Mal, wenn der Agent diesen Code berührt, verhindert der Test eine Regression. Die Anweisungsdatei? Die vergisst der Agent, sobald das Kontextfenster sich mit etwas anderem füllt.

Wer bereits TDD praktiziert, hat die Antwort bereits. Weitermachen wie bisher. Die Testsuite ist das beste KI-Steuerungsinstrument, das man für kein Geld kaufen kann. Die Agenten werden besser. Die Modelle werden intelligenter. Aber sie bleiben nicht-deterministische Wahrscheinlichkeitsmaschinen, und sie werden immer harte Einschränkungen brauchen. Die Tests sind diese Einschränkungen.

Ein Ausgangspunkt für die Anweisungsdatei

Nichts davon bedeutet, dass Anweisungsdateien nutzlos sind. Sie sollten nur nicht versuchen, die Arbeit zu tun, die Tests und Werkzeuge besser können. Eine kurze Anweisungsdatei, die festlegt, wie der Agent arbeiten soll, schlägt eine lange, die jede Programmierentscheidung vorschreiben will. Hier ein Ausgangspunkt. Ablegen in der copilot-instructions.md, claude.md oder was auch immer das jeweilige Werkzeug erwartet.

## Arbeitsablauf

Testgetriebene Entwicklung strikt einhalten:
1. Zuerst einen fehlschlagenden Test schreiben
2. Den minimalen Code zur Erfüllung umsetzen
3. Umstrukturieren, solange alle Tests grün bleiben
4. Niemals Produktivcode ohne zugehörigen Test schreiben

Nach jeder Änderung die vollständige Testsuite ausführen.
Eine Aufgabe ist erst abgeschlossen, wenn alle Tests bestehen.

## Code-Prinzipien

- Keine Wiederholungen. Gemeinsame Logik in Funktionen
  oder Module auslagern. Duplikate beseitigen.
- Funktionen kurz halten. Eine Verantwortung pro Funktion.
- Komposition vor Vererbung bevorzugen.
- Kein toter Code. Was nicht getestet und nicht aufgerufen
  wird, löschen.

## Was nicht zu tun ist

- Niemals einen bestehenden Test ändern oder löschen, um
  die eigene Umsetzung zum Laufen zu bringen. Schlägt ein
  Test fehl, ist der Code falsch.
- Niemals Tests überspringen, um sie „später zu beheben."
- Niemals Abhängigkeiten hinzufügen, ohne zu prüfen, ob
  sie im Projekt bereits genutzt werden.

## Stil und Formatierung

Der Linter- und Formatter-Konfiguration des Projekts folgen.
Sie nicht überschreiben.

Das sind ungefähr 30 Zeilen. Sie sagen dem Agenten, wie er arbeiten soll, nicht was er bauen soll. Das „Was” steht in den Tests. Und anders als eine 500-Zeilen-Anweisungsdatei voller widersprüchlicher Architektur-Edikte ist diese kurz genug, dass der Agent sie tatsächlich im Kontext behält.

Reichen 30 Zeilen? Ausprobieren. Regeln nur hinzufügen, wenn der Agent wiederholt etwas tut, das Tests und Linter nicht abfangen können. Meistens wird man keine brauchen.

Der Rest ist Vibes.

Verwandte Artikel

Vibe Coding ist keine Software-Entwicklung

13.04.2026

Vibe Coding wirkt im Demo magisch, scheitert aber an echten Systemen.

Das Konzeptdokument war ein Notbehelf

10.04.2026

Jahrzehntelang schrieben Teams Konzeptdokumente, bevor sie bauten, weil Bauen teuer war.

Software ist der neue Maschinenbau

01.04.2026

Der deutsche Mittelstand wartet auf Entlastung, während andere mit Software, KI und Robotik Geschäft, Marge und Tempo...