Wie man Regeln und Skills baut, damit Agenten sich erinnern

Agentische Softwareentwicklung bezeichnet einen Ansatz, bei dem KI-Agenten Code schreiben, testen und reviewen, während Menschen am System arbeiten statt im System. Qualität entsteht durch deterministisch ausgelöste Feedback-Schleifen: Git-Hooks, Pipeline-Tests, Accessibility-Checks und Architektur-Reviews laufen automatisch während der Agent arbeitet und korrigieren ihn sofort.

Das Wichtigste in Kürze

• Wer am System arbeitet statt im System, gibt Agenten Regeln, Hooks und Skills mit auf den Weg, statt jeden generierten Code manuell zu reviewen.
• Agent-Hooks feuern deterministisch bei bestimmten Events, zum Beispiel nach jeder Frontend-Änderung ein Accessibility-Check, sodass der Agent sofortiges Feedback bekommt, bevor er weitermacht.
• Nicht-Determinismus in KI-Agenten ist kein reines Risiko: Ein Modell erkennt flaky Tests als Symptom, wo ein deterministischer Test nur “rot” meldet.
• Zwei Modelle gegeneinander zu nutzen, etwa Claude als Implementierer und Codex als detailgetreuen Reviewer, ergibt qualitativ mehr als jedes Modell allein.

Am System arbeiten statt im System: Wie sich die Rolle des Entwicklers verschiebt

Wer Software mit KI-Agenten baut, arbeitet nicht mehr am einzelnen Code-Stück, sondern am System, das den Code erzeugt. Benedikt Stemmildt beschreibt diese Verschiebung als Kern seiner Arbeitsweise. Statt selbst zu implementieren und danach zu reviewen, beobachtet er, wo der Agent immer wieder in die falsche Richtung läuft, und greift auf der Ebene der Regeln ein.

Das Bild dahinter ist ein neuer Junior-Kollege im Pair Programming. Man merkt, dass er keine Hotkeys nutzt oder ein wichtiges Architekturpattern ignoriert, und gibt ihm den Hinweis. Ein Mensch merkt sich das. Ein Agent nicht: Er hat kein Gedächtnis, das die Korrektur automatisch behält.

Deshalb muss die Korrektur ins System wandern, nicht nur ins Gespräch. Wer bemerkt, dass der Agent ein dokumentiertes Architekturpattern übergeht, hinterlegt es als Regel im Regelset. Aus einer einmaligen Bemerkung wird eine dauerhafte Leitplanke. Dieses Anlernen ist projekt- und aufgabenspezifisch und lässt sich zwischen Projekten kaum wiederverwenden, ähnlich wie man jeden neuen Mitarbeiter neu einarbeiten muss.

Und dann baut man eher am System, als irgendwie im System zu sein. Ich mache auch gar keine Reviews. Man ist nicht mehr der, der Reviews macht, sondern man arbeitet am System. Benedikt Stemmildt

Supervised oder unsupervised: die erste Weiche für Qualität

Bevor man über Testen und Qualität redet, muss geklärt sein, ob der Code supervised oder unsupervised entsteht. Diese Unterscheidung geht in vielen KI-Debatten unter, prägt aber jede weitere Entscheidung über Feedback und Absicherung.

Supervised heißt: Der Entwickler schaut mit, verfolgt die laufenden Terminals und greift ein, wenn etwas in die falsche Richtung kippt. Unsupervised heißt: Der Code entsteht ohne menschlichen Blick, vergleichbar mit einer Deployment-Pipeline, in der niemand daneben sitzt.

Im supervised-Modus kann man dem Agenten folgen und aus dem Beobachteten ableiten, was er systematisch falsch macht. Genau dort setzen die Regeln an. Je weiter man Richtung unsupervised geht, desto stärker müssen die Feedbackschleifen deterministisch abgesichert sein, weil kein Mensch mehr eingreift.

Wie die klassischen Qualitätsmechanismen erhalten bleiben

Der Bau mit Agenten unterscheidet sich weniger von klassischer Entwicklung als oft angenommen. Die Mechanismen, die Fehler auf verschiedenen Ebenen verhindern, bleiben dieselben: Git-Hooks, Linter, Terraform-Plans beim Push, Tests in der Pipeline, Smoke-Tests auf einer Development-Umgebung vor dem Produktions-Deployment.

Diese Baseline sollte man ohnehin haben, unabhängig von KI. Benedikt beobachtet, dass sie in vielen Projekten fehlt. Wer sie noch nicht hat, kann Agenten nutzen, um sie aufzubauen, muss dann aber genau hinsehen, dass Hooks und Pipeline sauber sind. Hier gilt kein YOLO-Modus.

Der Unterschied liegt im Tempo. Wenn eine Pipeline schlecht läuft oder Fehler fünfmal durchrutschen, merkt man das nicht nach fünf Wochen, sondern nach dreißig Minuten. Die Verbesserung der Pipeline funktioniert wie bei jedem Team, nur auf Steroiden.

Tests entstehen am lebenden Objekt, nicht aus dem Spec

Die Tests schreibt der Agent, nicht der Entwickler. Woher die Testbasis kommt, hängt vom Vorgehen ab. Viele setzen auf spec-driven Development, bei dem Akzeptanzkriterien vorab definiert werden und die Tests darauf aufbauen.

Benedikt bevorzugt einen anderen Weg. Er erhebt Requirements am lebenden Objekt, also an der genutzten Software mit echten Endkunden. Deren Feedback wird zur neuen Requirement: Ein Bug muss gefixt werden, ein gewünschtes Verhalten kommt dazu.

Aus diesem Feedback lassen sich auch die Tests verbessern. Observability-Daten, Klickverhalten und echte Interviews zeigen Pfade, die in den End-to-End-Tests noch fehlen. Ein Klickpfad, den Kunden immer wieder gehen, gehört abgebildet, weil er offenbar wichtig ist.

Die Testpyramide gilt auch für Agenten

Ein guter Agent arbeitet nach der Testpyramide, weil er die Arbeitsweise und das Erfahrungswissen des Entwicklers spiegelt. Prinzipien und Patterns aus Jahren der Softwareentwicklung übertragen sich auf den Agenten, sofern man sie ihm mitgibt.

Sich selbst überlassen tendieren Agenten dazu, jedes Feature manuell zu testen: Sie öffnen einen Browser, machen einen Screenshot, analysieren ihn visuell und klicken sich durch. Das ist langsam und teuer. Wer jedes Feature so testet, verschenkt genau den Vorteil der Pyramide.

Die einzelnen Ebenen erfüllen unterschiedliche Zwecke:

Unit-Tests schreibt Benedikt bewusst zuerst, damit die Architektur des echten Codes testbar wird. Ändert der Agent später am Produktionscode, weist ihn ein rot werdender Test darauf hin, dass er womöglich eine Stelle anfasst, die er gar nicht anfassen wollte.

Contract-Tests fangen einen typischen Agenten-Fehler ab. Ein Agent doktert schnell an seiner Schnittstelle herum und baut dabei Breaking Changes ein. Ein separater Test von außen, ausgeführt durch einen anderen Agenten, gibt den Hinweis, dass der Consumer kaputtgeht, bevor der Schaden entsteht.

Warum nicht-funktionale Anforderungen unterschiedlich behandelt werden müssen

Performance, Security und Accessibility verlangen unterschiedliche Modi. Nicht jedes Qualitätskriterium lässt sich gleich behandeln, und die Trennung zwischen supervised und unsupervised entscheidet mit.

Performance funktioniert unsupervised sehr gut, weil sich harte Ziele vorgeben lassen. Man definiert Performance-Budgets pro Endpunkt und lässt den Agenten den Code so optimieren, dass er sie einhält. Ein Performance-Test in der Pipeline prüft, dass die Budgets nicht reißen. Grenzen bleiben: Mengengerüste in der Datenbank sind testbar, eine DDoS-Attacke prüft keine normale Pipeline.

Security lässt sich schlechter automatisieren und gehört in den supervised-Modus. Ein regelmäßiges Security-Audit, täglich oder wöchentlich, deckt gemeinsam mit dem Agenten Angriffsvektoren und Threats auf. Licensing, Package-Dependency-Updates und Accessibility dagegen laufen als normale Pipeline-Bestandteile, letztere etwa über ein Tool wie Axe.

Feedback auf der richtigen Ebene ist die Kernfrage

Qualität mit Agenten entsteht dort, wo an vielen Stellen das richtige Feedback verfügbar ist. Ein Mensch bekommt beim Schreiben permanent inneres Feedback: Das ist nicht accessible, das ist nicht performant. Der Agent hat diesen inneren Dialog nicht.

Deshalb wandern diese Prüfungen nicht nur in die Pipeline, sondern über Hooks direkt in die Arbeit des Agenten. Ändert der Agent eine Frontend-Komponente, feuert ein Hook den Accessibility-Test schon während der Arbeit. Der Agent bekommt sofort den Hinweis, dass er Accessibility vergessen hat, und arbeitet nach, bevor überhaupt gepusht wird.

Zwei Arten von Hooks greifen ineinander. Der Git-Hook feuert beim Commit. Der Hook im Agenten-Harness feuert bei anderen Events, etwa wenn ein Tool ausgeführt oder eine Datei gelesen wird. Ein Hook auf das Event “Implementierung fertig” kann den Agenten anweisen, den Code dreimal zu vereinfachen, bevor er weitermachen darf.

Deterministisch oder nicht: beide Wege haben Wert

Die Wahl zwischen deterministischem und nicht-deterministischem Feedback ist eine Skala, kein Entweder-oder. Hooks sind deterministisch, weil ein Event Code auslöst. Regeln und Skills sind weicher und nicht-deterministisch.

Ein Beispiel macht den Unterschied greifbar. Ob die Architektur einem Domain-Driven-Design-Prinzip folgt, kann ein ArchUnit-Test deterministisch prüfen oder ein Skill nicht-deterministisch bewerten. Der Test übersieht möglicherweise etwas außerhalb seines Szenarios. Das Modell bewertet möglicherweise falsch. Oft ist beides zusammen die beste Lösung.

Der Nicht-Determinismus wird dabei unterschätzt. Er hat Wert bei der Recoverability. Ein roter Test ist deterministisch einfach rot. Ein Modell fragt zurück: Ist der Test rot, weil etwas kaputt ist, weil der Test schlecht ist, oder weil er flaky ist? Aus dieser Bewertung kann die Erkenntnis folgen, dass man die flaky Tests grundsätzlich fixen sollte. Man nutzt beide Modi dort, wo sie helfen.

Architektur bleibt sauber durch Tracking und regelmäßiges Review

Gute Architektur entsteht mit Agenten wie ohne sie: durch dokumentierte Entscheidungen und regelmäßiges Review. Agenten können Architekturentscheidungen mitdokumentieren und eine arc42-Dokumentation aktuell halten. Für Menschen wirkt das mitunter überflüssig, für Agenten dient es als eigenes Referenzwissen über Schnittstellen und Strukturen.

Der zweite Baustein ist ein geplantes Review. Über Schedules lässt sich festlegen, dass der Agent einmal täglich eine Aktion ausführt, so wie ein Team einmal die Woche auf seine Architektur schaut. Ein Architektur-Review-Skill bewertet dann, ob die Entwicklung den Prinzipien folgt.

Ein konkreter Fall zeigt das Muster. In einem großen Frontend wuchs eine globale CSS-Datei Richtung Monolith. Bei rund viertausend Zeilen bemerkte der Agent im Review, dass das nicht mehr trägt, schlug Modularisierung vor, lagerte Komponenten aus und machte jede Komponente selbstversorgend. Die nächste Iteration deckt vermutlich die nächste zu harte Kopplung auf.

Diese Schedules entstehen nicht von selbst. Der Entwickler richtet sie in der supervised-Phase ein, während er den Agenten an die Hand nimmt. Eine wiederkehrende Anweisung lautet, in die letzten Unterhaltungen zu schauen, die eigenen Korrekturen zu sammeln und daraus Regeln, Skills und Schedules abzuleiten, damit der Agent sich künftig daran hält.

Retrospektiven auf Steroiden

Kontinuierliche Verbesserung wird mit Agenten zur täglichen Routine. Statt einmal im Monat eine Retrospektive zu halten, läuft sie mehrmals täglich und in Sekunden. Benedikt baut als eine der ersten Maßnahmen einen Skill ein, der selbst eine Retro durchführt.

Dieser Skill schaut auf alte Sessions, sucht nach Dingen, die häufig schiefgelaufen sind und nachkorrigiert werden mussten, und aktualisiert die eigenen Regeln. Ob das dauerhaft trägt, ist offen. Denkbar ist, dass man Wissen, das im Modell ohnehin steckt, nur noch einmal in Regeln dupliziert. Der Wert liegt trotzdem im Experimentieren am System.

Diese Rolle ist für viele Entwickler ungewohnt. Über Jahre steckten sie tief im System und bauten für andere, ohne Zeit, am System zu arbeiten. Es fehlen sogar die Kriterien dafür, was “am System arbeiten” heißt und wie man Qualitätsziele wie Sicherheit messbar macht. Wie sicher genau? Diese Frage bleibt oft unbeantwortet, weil man selten die Distanz zum System hatte.

Warum zwei Modelle gegeneinander die Qualität heben

Ein Review durch ein zweites Modell fängt Schwächen des ersten ab. Benedikt lässt Code, den Claude entwickelt hat, durch Codex reviewen und nutzt die unterschiedlichen Charaktere der Modelle gezielt.

Claude verhält sich wie ein Full-Stack-Entwickler, der pragmatisch einen Weg zur Implementierung findet, Hauptsache der Business Value steht. Codex schaut stärker in die Details und hält sich strikter an die Regeln. Diese Strenge hilft beim Review, kann aber blockieren, wenn eine Implementierung Flexibilität braucht, weil Codex Regeln zu wörtlich nimmt.

Das Zusammenspiel funktioniert wie zwischen zwei Kollegen. Codex liefert die Fehlerliste, Claude arbeitet einen Teil davon nach und begründet, warum manches nicht umsetzbar ist. Viele nutzen Agenten konsequent wie Mitarbeiter, inklusive Probezeit: Funktioniert die Konfiguration nicht, wird der Agent verworfen und neu aufgesetzt.

Model-Hopping ist ab einem gewissen Niveau überflüssig

Man muss nicht jedem neuen Modell hinterherlaufen. Benedikt hält es nicht für nötig, mit jedem Release das Modell zu wechseln. Ab dem Niveau von Opus 4.5 sind die verfügbaren Modelle mehr als gut genug für die anstehende Arbeit, nachprüfbar in den Benchmarks.

Was danach zu entscheiden bleibt, sind andere Fragen: Kostenoptimierung, ob eine Subscription genutzt werden darf, und Souveränität. Open-Weights-Modelle oder lokale Modelle über vLLM sind bei DSGVO-Fragen relevant, verlangen aber Tiefe. Ein reines Terminal mit Chat und Inference-Endpoint bietet keine Features und funktioniert erst nach viel Konfiguration so, wie man es will.

Für den Einstieg in Firmen bleiben Codex und Claude Code praktikabel, weil die User Experience einer fertigen Desktop-App den Umstieg erleichtert. Souveräne Setups sind mächtig, aber selten der einfachste erste Schritt.

Wann noch von Hand geschrieben wird

Manuellen Code schreibt Benedikt nur noch an den äußersten Am-System-Fällen. Architekturregeln und ähnliche Vorgaben formuliert er selbst, weil es sonst mehr Aufwand wäre, generierte Fassungen zu reviewen und auf das Gewünschte einzudampfen.

Manchmal betrifft das auch Hooks, in die er genau hineinschaut und die er manuell korrigiert. Das ist weit weg von der eigentlichen Software, die am Ende genutzt wird. Am Produktcode selbst schreibt er nicht mehr von Hand.

Eine offene Frage bleibt, ob das Formulieren von Regeln in Englisch überhaupt noch als Programmieren zählt. Die Arbeit verschiebt sich von der Zeile zum System, von der Implementierung zur Steuerung der Feedbackschleifen.

Häufig gestellte Fragen

Braucht agentisch entwickelter Code eine andere Qualitätssicherung als handgeschriebener?

Die Mechanismen bleiben dieselben: Git-Hooks, Linter, Terraform-Plans beim Push, Tests in der Pipeline, Smoke-Tests auf einer Development-Umgebung vor dem Produktions-Deployment. Diese Baseline sollte ohnehin stehen, fehlt aber in vielen Projekten. Der Unterschied liegt im Tempo. Läuft eine Pipeline schlecht oder rutschen Fehler mehrfach durch, zeigt sich das nach dreißig Minuten statt nach fünf Wochen.

Warum reicht es nicht, einen KI-Agenten im Gespräch zu korrigieren?

Ein Agent hat kein Gedächtnis, das die Korrektur automatisch behält. Ein menschlicher Junior merkt sich den Hinweis, der Agent nicht. Deshalb gehört die Korrektur ins Regelset: Wer bemerkt, dass ein dokumentiertes Architekturpattern übergangen wird, hinterlegt es als Regel. Dieses Anlernen ist projekt- und aufgabenspezifisch und lässt sich zwischen Projekten kaum wiederverwenden.

Woher kommen Testfälle, wenn man nicht spec-driven arbeitet?

Anforderungen lassen sich am lebenden Objekt erheben, also an der genutzten Software mit echten Endkunden. Deren Feedback wird zur neuen Requirement: ein Bug, der gefixt werden muss, ein gewünschtes Verhalten, das dazukommt. Observability-Daten, Klickverhalten und Interviews zeigen Pfade, die in den End-to-End-Tests fehlen. Ein Klickpfad, den Kunden immer wieder gehen, gehört abgebildet.

Wie testen Agenten, wenn man ihnen keine Vorgaben zur Teststrategie macht?

Sich selbst überlassen testen Agenten gern manuell: Browser öffnen, Screenshot machen, visuell analysieren, durchklicken. Das ist langsam und teuer und verschenkt den Vorteil der Testpyramide. Gibt man ihm Prinzipien und Patterns mit, spiegelt der Agent die Arbeitsweise des Entwicklers. Unit-Tests zuerst erzwingen eine testbare Architektur und warnen, wenn er ungewollt Produktionscode anfasst.

Lassen sich nicht-funktionale Anforderungen wie Security automatisiert absichern?

Nur teilweise. Security ist schlechter automatisierbar und gehört in den supervised-Modus, etwa als tägliches oder wöchentliches Audit, das gemeinsam mit dem Agenten Angriffsvektoren und Threats aufdeckt. Performance funktioniert unsupervised gut, weil sich Budgets pro Endpunkt vorgeben und in der Pipeline prüfen lassen. Licensing, Dependency-Updates und Accessibility laufen als normale Pipeline-Bestandteile.

Wie verhindert man, dass die Architektur bei agentischer Entwicklung erodiert?

Durch dokumentierte Entscheidungen und regelmäßiges Review, genau wie ohne Agenten. Eine arc42-Dokumentation, die der Agent aktuell hält, dient ihm selbst als Referenzwissen über Schnittstellen und Strukturen. Dazu kommt ein geplantes Review per Schedule, bewertet durch einen Architektur-Review-Skill. In einem großen Frontend fiel so bei rund viertausend Zeilen globaler CSS auf, dass modularisiert werden musste.

Muss man bei jedem neuen Modell-Release das Modell wechseln?

Nein. Ab dem Niveau von Opus 4.5 sind die verfügbaren Modelle für die anstehende Arbeit mehr als gut genug, nachprüfbar in den Benchmarks. Zu entscheiden bleiben andere Fragen: Kostenoptimierung, ob eine Subscription genutzt werden darf, und Souveränität. Open-Weights- oder lokale Modelle über vLLM sind bei DSGVO-Fragen relevant, verlangen aber viel Konfiguration.