KI-Agenten in der Softwareentwicklung: Mit Governance übernehmen

Ein KI-Assistent wartet auf Ihre Frage. Einem KI-Agenten wird ein Ziel vorgegeben und er handelt so lange, bis er es erreicht oder bei dem Versuch nicht weiterkommt.

Dieser Unterschied ist heute die wichtigste Grenze in der KI-Entwicklung. Codierungsagenten schlagen keine Snippets vor: Sie nehmen eine Aufgabe an, öffnen das Repository, ändern Dateien, führen die Tests aus, lesen, was fehlgeschlagen ist, beheben das Problem und öffnen einen Pull-Request zur Überprüfung.

Die Frage für diejenigen, die führen, ist nicht, ob diese Fähigkeit vorhanden ist. Es existiert und es funktioniert. Die Frage ist, wie man es übernehmen kann, ohne Produktivität gegen Chaos einzutauschen.

Was ist ein Codierungsagent in der Praxis?

Ein Agent arbeitet in einer Schleife. Er erhält ein Ziel, plant Schritte, führt eine Aktion aus, beobachtet das Ergebnis und entscheidet über den nächsten Schritt. Wiederholen Sie dies, bis Sie fertig sind oder aufgeben.

Was den Agenten vom Assistenten unterscheidet, ist die Autonomie über die Handlungen. Er schreibt nicht nur den Code: Er führt den Befehl aus, liest die Terminalausgabe, stellt fest, dass der Test fehlerhaft ist, und versucht es erneut. Sie stecken nicht mitten in jeder Iteration fest.

Dadurch können Sie ganze Aufgaben delegieren. „Migrieren Sie diesen Dienst auf die neue Bibliotheksversion und stellen Sie sicher, dass die Tests erfolgreich sind“ ist kein Skript mehr, das Sie manuell ausführen, sondern eine Anforderung, die der Agent erfüllt, wobei Sie das Endergebnis überprüfen.

Es ist mächtig. Und gerade weil es mächtig ist, braucht es Regeln.

Wo Agenten auftreten

Agenten glänzen bei klar definierten, überprüfbaren und langwierigen Aufgaben. Je klarer die Definition von „ready“ ist, desto besser ist das Ergebnis.

Es lohnt sich, Tests für vorhandenen Code zu schreiben, weil das Kriterium objektiv ist: Der Test besteht oder nicht, deckt ab oder nicht. Sie führen zu mechanischen Umgestaltungen, die sich über Dutzende von Dateien hinweg wiederholen – die Art von Änderung, die den Menschen ermüdet und ihn dazu verleitet, ihm die Aufmerksamkeit zu verweigern. Sie führen zu Abhängigkeitsmigrationen, Syntaxaktualisierungen und Korrekturen von Fehlern, die im Build auftreten.

Sie profitieren auch von der Erkundung unbekannter Stützpunkte. Wenn Sie einen Agenten bitten, zu erklären, wie eine Funktion funktioniert oder wo eine Geschäftsregel implementiert ist, können Sie stundenlange Lesezeit sparen. In der Wartungsphase, die bei langlebigen Systemen immer die teuerste ist, sehe ich die größte Rendite bei geringstem Risiko.

Der gemeinsame Nenner ist einfach: Aufgabe mit nachweisbaren Erfolgskriterien. Wo es einen Test gibt, der sagt: „Es hat funktioniert“, hat der Agent eine Anleitung.

Ein weiteres Merkmal der Aufgaben, die Agenten ausführen, ist die schnelle Rückmeldung. Wenn der Agent einen Befehl ausführt und das Ergebnis innerhalb von Sekunden sieht, iteriert er und korrigiert ihn selbstständig. Wenn das Erfolgssignal langsam oder vage ist oder nur in der Produktion erscheint, wird die Schleife unterbrochen und der Agent läuft weiter. Deshalb lohnt es sich, den Boden zu bereiten: Eine Basis mit guten Tests und schnellem Build holt viel mehr Wert aus einem Agenten als eine Basis ohne Sicherheitsnetz, bei der jeder Fehler erst spät auftritt.

Wo Agenten versagen

Sie scheitern, wenn die Erfolgskriterien nicht eindeutig sind oder nicht vorhanden sind. Architektonische Entscheidungen, Produktauswahl, Kompromisse, die vom Geschäftskontext abhängen: Nichts davon hat einen Test, der sagt, ob es richtig ist, und der Agent wird etwas Plausibles hervorbringen, das für Ihren Fall völlig falsch sein könnte.

Sie scheitern an Aufgaben, bei denen es darum geht, das Warum und nicht nur das Wie zu verstehen. Ein Agent gestaltet eine Funktion so um, dass sie sauberer aussieht, und löscht dabei ein Edge-Handle, das aus einem Grund vorhanden war, der nirgendwo beschrieben ist.

Sie scheitern stillschweigend, und das ist das gefährlichste Risiko. Der Code funktioniert wieder, die Tests sind erfolgreich, die Pull-Anfrage sieht fehlerfrei aus und die Logik ist leicht fehlerhaft. KI macht Fehler mit Zuversicht, und Selbstvertrauen verunreinigt diejenigen, die es eilig haben.

Und sie scheitern im großen Maßstab, wenn man zu sehr vertraut. Ein Agent, der täglich zehn Pull-Anfragen öffnet, generiert zehn Bewertungen von zweifelhafter Qualität für einen Menschen, der nur einer bleibt. Ohne Governance verlagert sich der Engpass auf den erschöpften Prüfer.

Die Daten, die Vorsicht rechtfertigen

Die Zahl, die diese Haltung unterstützt, ist es wert, wiederholt zu werden. In der Stack Overflow-Umfrage 2025 mit über 49.000 Befragten überwiegt das Misstrauen gegenüber der Genauigkeit von KI-Tools das Vertrauen, und nur ein sehr kleiner Bruchteil, 3 %, vertraut ihnen voll und ganz.

Diese Skepsis der Entwickler selbst ist kein Widerstand gegen Veränderungen. Es ist die Erfahrung derer, die mit dem Werkzeug leben und gesehen haben, wo es strauchelt. Eine Führungskraft, die Agenten einsetzt, muss den Prozess auf der Grundlage dieser Realität gestalten und nicht dagegen.

Wenig zu vertrauen und viel zu kontrollieren ist kein Mangel an Ehrgeiz. Dies ist die einzige verantwortungsvolle Möglichkeit, das Beste aus dem Angebot der Makler herauszuholen.

Wie man sich mit Governance anpasst

Governance ist hier keine Bürokratie, sondern das Regelwerk, das Ihnen den sicheren Einsatz von Agenten ermöglicht. Zunächst wird definiert, was delegiert werden kann und was nicht.

Delegieren Sie das Überprüfbare und das Reversible. Aufgaben mit klaren Tests, isolierten Änderungen, Arbeiten, die ein Pull Request enthalten und rückgängig machen kann. Delegieren Sie nicht die unumkehrbaren und kritischen Dinge ohne die Verantwortung eines Menschen: Migration von der Datenbank zur Produktion, Änderungen der Sicherheitskonfiguration, Änderungen, die sich auf Kundendaten auswirken.

Halten Sie den Agenten innerhalb der technischen Grenzen. Isolierte Umgebungen, eingeschränkte Berechtigungen, kein direkter Zugriff auf die Produktion, keine Möglichkeit zur alleinigen Bereitstellung. Der Agent schlägt vor, der Mensch entscheidet, was auf Sendung geht. Für Einzelheiten zur Organisation habe ich über KI-Agenten in Unternehmensumgebungen und über Governance bei der Einführung dieser Tools in Unternehmen geschrieben.

Behandeln Sie jede Pull-Anfrage eines Agenten wie eine Pull-Anfrage von jemandem, der neu im Team ist: ausnahmslos obligatorische Überprüfung, mit besonderem Augenmerk auf die Logik und nicht nur auf die Syntax. Und messen Sie die Ergebnisse. Steigt die Fehlerquote oder wird die Wartung der Basis schwieriger, hilft der Agent nicht weiter, auch wenn er produktiv erscheint.

Der Mensch als verantwortlicher Gutachter

Verantwortung ist nicht delegierbar. Wenn der Code in Produktion geht, antwortet die Person, die ihn genehmigt hat, und nicht das Tool, das ihn generiert hat.

Dadurch wird der Ingenieur neu positioniert. Der Wert liegt nicht mehr darin, jede Zeile zu schreiben, sondern darin, die Aufgabe gut zu definieren, das Ergebnis gut zu beurteilen und eine Entscheidung zu treffen. Es handelt sich um eine höhere Position, nicht weniger, und sie erfordert mehr Diskretion, nicht weniger.

Der verantwortliche Prüfer ist derjenige, der den Code so gut versteht, dass er mit ihm nicht einverstanden ist. Wer bemerkt den gelöschten Rand, die falsche Annahme, die gefährliche Abkürzung. Ein Team, das an Agenten delegiert, aber über starke Prüfer verfügt, gewinnt an Geschwindigkeit, ohne die Kontrolle zu verlieren. Ein Team, das die Überprüfung delegiert und lockert, lagert lediglich seine Fehler aus.

Wenn Sie Agenten einsetzen, fangen Sie klein und überprüfbar an: Wählen Sie eine Aufgabe mit klaren Tests aus, lassen Sie sie vom Agenten ausführen und überprüfen Sie sie, als wäre es die Arbeit eines neuen Mitarbeiters. Sie bauen Governance auf, bevor es zu einer Eskalation kommt, und nicht erst nach dem ersten Vorfall.

Quelle: Stack Overflow Survey 2025.