Wer kontrolliert die Agenten?
Kann man dem Output überhaupt vertrauen?
„Ich schreibe kaum noch Code. Und trotzdem baue ich mehr Software als je zuvor.“
Als ich das kürzlich auf LinkedIn schrieb, kam:
„Naja, und wer kontrolliert die Agenten? Wer räumt die technischen Schulden, die sie produzieren, wieder auf?”
Eine Frage, eine berechtigte Frage, mit der ich mich ebenfalls schon beschäftigt hatte.
Eine Frage, die ich nicht mit einem Zweizeiler beantworten kann.
Die Frage hinter der Frage
Wer so fragt, will wissen:
Kannst du dem Output überhaupt vertrauen?
Oder baust du dir gerade ein Kartenhaus, das beim ersten echten Problem zusammenfällt?
Meine Antwort ist unbefriedigend für alle, die ein klares Ja oder Nein wollen: Es kommt darauf an. Und genau dieses „es kommt darauf an” ist der eigentliche Skill, den ich in den letzten Monaten entwickelt habe.
Nicht alles ist gleich kritisch
Der erste Schritt war eine simple Erkenntnis: Nicht jeder Bereich meiner Software verdient dieselbe Aufmerksamkeit.
Ich unterscheide grob nach zwei Kriterien:
Wie schnell sehe ich, wenn etwas nicht funktioniert?
Wie groß ist der potenzielle Schaden?
Kritische Bereiche sind für mich zum Beispiel:
Authentifizierung und Login-Flows
Autorisierungslogik – wer darf was sehen und tun
Datenbankdesign, insbesondere das Datenmodell
Row Level Security für Datenbanken
Alles, was mit Zahlungen oder sensiblen Nutzerdaten zu tun hat
Alles, von dem viel abhängt
Diese Bereiche haben zwei Eigenschaften gemeinsam:
Fehler sind nicht sofort sichtbar, und
wenn sie auftreten, ist der Schaden potenziell groß.
Eine kaputte Authentifizierung merkst du nicht, wenn du die Anwendung durchklickst. Du merkst sie, wenn jemand anderes sie ausnutzt.
Unkritische Bereiche sind für mich:
Frontend-Darstellung und UI-Komponenten
Styling und Layout
Nicht-sicherheitsrelevante Formularvalidierungen
Hilfsfunktionen und Utilities
Das heisst nicht, dass sie unwichtig sind. Aber wenn hier etwas nicht funktioniert, sehe ich es schnell. Ein Button, der nicht reagiert, eine Liste, die nicht rendert – das fällt beim Testen auf. Und selbst wenn es durchrutscht: Der Schaden ist begrenzt. Kein Nutzer verliert Geld oder Daten, weil ein Schatten an der falschen Stelle sitzt.
Wie ich Agenten einsetze
Für meine Projekte habe ich spezialisierte Subagents aufgebaut, die auf definierte Aufgaben zugeschnitten sind. Manche habe ich selbst konfiguriert, bei anderen greife ich auf vorgefertigte Lösungen zurück. Entscheidend ist nicht das einzelne Tool, sondern wie sie zusammenarbeiten.
Mein Workflow folgt einem Muster, das menschliche Review-Prozesse nachbildet:
Stufe 1: Entwurf. Ein Agent erstellt einen ersten Vorschlag – sei es Code, eine Architekturentscheidung oder ein Datenbankschema.
Stufe 2: Ausarbeitung. Ein anderer Agent nimmt den Entwurf und arbeitet die Details aus. Er kennt den Kontext, aber er hat eine andere Perspektive.
Stufe 3: Prüfung. Ein dritter Agent überprüft das Ergebnis. Er fragt: Was könnte man aus Sicherheitsperspektive verbessern? Wo sind potenzielle Schwachstellen?
Das klingt aufwendiger, als es ist. In der Praxis läuft vieles davon automatisiert. Ich stoße den Prozess an und bekomme am Ende einen Report, den ich durchgehe.
Der entscheidende Unterschied: Wo ich selbst hinschaue
Bei unkritischen Bereichen reicht mir, was die spezialisierten Agenten identifizieren.
Bei kritischen Bereichen ist das Agenten-Review nur die erste Runde. Die zweite Runde mache ich selbst.
Das bedeutet konkret: Ich lese den Code. Ich hinterfrage die Architekturentscheidungen. Ich überlege, welche Edge Cases nicht abgedeckt sind. Ich gleiche ab, ob das, was da steht, zu meinem mentalen Modell des Systems passt.
Das ist der Human-in-the-Loop, von dem alle reden. Nur dass er eben nicht bei jeder Zeile Code greift, sondern gezielt dort, wo es darauf ankommt.
Vorgaben von Anfang an
Ein Bereich, in dem sich der agentenbasierte Ansatz besonders bewährt. Statt Anforderungen nachträglich zu prüfen, bette ich sie von Anfang an in den Entwicklungsprozess ein.
Das funktioniert über Guidelines – Markdown-Dateien, die beschreiben, welche Regeln gelten. Diese Guidelines fließen in die Spezifikations- und Planungsphase ein. Die Agenten kennen sie und berücksichtigen sie.
Anschließend lasse ich spezialisierte Agenten Reviews durchführen und Reports erstellen. Diese Reports gehe ich durch, hinterfrage kritisch, führe meine eigene Analyse durch und gleiche ab. Wenn Probleme auftauchen, lasse ich sie durch die Agenten beheben und stoße dann ein erneutes Review an.
Es ist ein iterativer Prozess. Aber einer, der Compliance by Design ermöglicht, statt sie als nachträglichen Kontrollschritt zu behandeln.
Die Bilanz: Ähnliche Probleme, andere Dynamik
Produzieren Agenten mehr technische Schulden als Menschen? Nach meiner Erfahrung: Nein. Es sind dieselben Probleme – nur schneller sichtbar.
Wenn eine Codebasis wächst, entsteht duplizierter Code. Nicht, weil die Agenten schlecht arbeiten, sondern weil ihnen der Gesamtüberblick fehlt. Ein erfahrener Entwickler, der seit Monaten an einem Projekt arbeitet, weiß implizit, dass es schon eine Utility-Funktion für diesen Fall gibt. Ein Agent sieht nur den aktuellen Kontext.
Das ist kein Argument gegen Agenten. Es ist ein Argument für iterative Zyklen.
Mein Vorgehen: Erst die Funktionalität, dann das Aufräumen. Ich lasse entwickeln, schaue, dass es funktioniert, und starte dann eine neue Runde, in der ich gezielt auf Code-Qualität achte. Dafür nutze ich einen Subagent, der sich auf Refactorings spezialisiert hat – er analysiert, identifiziert Duplikate, schlägt Zusammenführungen vor.
Dieses Vorgehen ist nicht neu. Es ist das, was erfahrene Entwickler schon immer gemacht haben: Erst zum Laufen bringen, dann aufräumen. Wer versucht, von Anfang an hundertprozentig sauberen Code zu schreiben, verzettelt sich und blockiert sich selbst.
Der Unterschied: Mit Agenten passiert beides schneller. Die technischen Schulden entstehen schneller – aber sie werden auch schneller sichtbar und schneller abgebaut.
Was Agenten gut können – und was nicht
Nach Monaten intensiver Arbeit mit diesem Setup habe ich ein klareres Bild davon, wo die Stärken und Grenzen liegen.
Agenten schreiben exzellenten Code im Kleinen. Eine einzelne Funktion, ein Modul, eine Komponente – das bekommen sie auf dem Niveau eines erfahrenen Entwicklers hin. Saubere Struktur, gute Benennung, Best Practices.
Was ihnen fehlt, ist der Systemüberblick. Sie sehen nicht, wie die Teile zusammenhängen. Sie wissen nicht, dass die Entscheidung in Modul A Auswirkungen auf Modul B hat, wenn das nicht explizit im Kontext steht.
Das liegt in der Natur der Sache: Eine KI kann nur aus dem verstehen, was ihr als Kontext gegeben wird. Ein erfahrener Entwickler hat das Gesamtsystem im Kopf – auch die Teile, die er nie explizit aufgeschrieben hat.
Der Skill-Shift
Diese Erkenntnis hat Konsequenzen für die Art, wie ich arbeite.
Früher konnte vieles implizit bleiben. Ich wusste, wie das System funktioniert, und musste es niemandem erklären. Jetzt muss ich es externalisieren – durch Spezifikationen, Guidelines, Architektur-Dokumentation. Was früher im Kopf bleiben konnte, muss jetzt explizit werden.
Das ist mehr Arbeit. Aber es ist bessere Arbeit. Denn was ich für die Agenten aufschreibe, hilft auch anderen Teammitgliedern. Also den Menschen1. Es zwingt mich, meine Entscheidungen zu artikulieren, statt sie vorauszusetzen.
Der Shift, den ich beobachte, ist real:
Weniger „wie schreibe ich diesen Code”, mehr „wie lenke ich die Agenten”. Das bedeutet nicht, dass Programmierkenntnisse unwichtig werden. Es bedeutet, dass sie nicht mehr ausreichen.
Was jetzt zählt:
Systemdesign auf höherer Ebene: Architektur, Schnittstellen, Datenmodelle
Sicherheitsdenken: Wo sind die Angriffsflächen, was muss besonders geschützt werden
Agenten-Orchestrierung: Wie koordiniere ich verschiedene spezialisierte Agenten, wie definiere ich Richtlinien, wie behalte ich die Kontrolle
Kritisches Prüfen: Wann vertraue ich dem Output, wann schaue ich selbst hin
Die Antwort auf die ursprüngliche Frage
Wer kontrolliert die Agenten? Ich. Aber nicht bei jeder Zeile Code.
Ich kontrolliere durch Struktur: spezialisierte Agenten, die sich gegenseitig prüfen. Ich kontrolliere durch Fokus: menschliche Reviews dort, wo der Schaden am größten wäre. Ich kontrolliere durch Iteration: Entwickeln, prüfen, aufräumen, wiederholen.
Und ich kontrolliere durch Akzeptanz: Die Einsicht, dass kein Prozess perfekt ist – weder mit Agenten noch ohne. Dass technische Schulden entstehen und abgebaut werden müssen. Dass Fehler passieren und gefunden werden müssen.
Der Unterschied ist nicht, dass Agenten fehlerfreien Code produzieren. Der Unterschied ist, dass ich mehr produziere und schneller iteriere. Und dass ich meine Zeit dort einsetze, wo sie den größten Unterschied macht: bei den Entscheidungen, die ein System sicher oder unsicher, wartbar oder unwartbar machen.
Das ist keine Zukunftsvision. Das ist mein Alltag seit Monaten. Und bisher funktioniert es.
Ich finde es schwierig, wenn manche Leute KI-Agenten als Teammitglieder bezeichnen, also vermenschlichen. Eine KI ist und bleibt eine intelligente Maschine und ist kein Menschenersatz.