KI-Agenten in der Softwareentwicklung: wo sie helfen und wo Kontrolle nötig ist

In den meisten Entwicklungsteams hat KI an einer Stelle begonnen: als Coding-Assistent im Editor. Das ändert sich gerade. Assistenten wie Claude Code oder Cursor können inzwischen auch in den Werkzeugen rund um den Code handeln, also Jira-Tickets anlegen, Pull Requests kommentieren, Confluence-Seiten aktualisieren oder eine Zusammenfassung in Slack posten. Technisch möglich macht das vor allem das Model Context Protocol (MCP), ein offener Standard, über den ein KI-Client Funktionen in anderen Systemen aufrufen kann.

Damit verschiebt sich die Frage, die ein Team beantworten muss. Es geht nicht mehr nur darum, welchen Assistenten man einsetzt, sondern darum, was dieser Assistent in jedem einzelnen System tun darf und wie man später nachvollzieht, was er getan hat. Dieser Artikel geht die Phasen des Softwareentwicklungsprozesses durch, beschreibt, wo Agenten in jeder Phase sinnvoll sind, und nennt die Kontrolle, auf die es dort am meisten ankommt. Zu jeder Phase gibt es in dieser Serie einen eigenen, ausführlicheren Artikel.

Warum sich der Blick auf den gesamten Prozess lohnt

Ein Agent, der in einem lokalen Branch Code schreibt, kann nur begrenzten Schaden anrichten. Ein Agent, der zusätzlich Tickets schließt, Pull Requests merged, Dokumentation ändert und E-Mails verschickt, hat einen deutlich größeren Wirkungsbereich. Das Risiko entsteht dabei selten durch ein einzelnes Werkzeug, sondern durch die Summe der Zugriffe. Diese Zugriffe laufen meist über persönliche API-Tokens, die sämtliche Rechte der Person haben, die sie erstellt hat.

In der Praxis führt das oft zu einem von zwei Ergebnissen. Entweder das Unternehmen sperrt Agenten außerhalb des Editors, und der Produktivitätsgewinn geht verloren. Oder einzelne Entwicklerinnen und Entwickler binden Agenten auf eigene Faust an, und niemand kann mehr sagen, welcher Agent welches System erreicht. Beides ist keine gute Ausgangslage. Sinnvoller ist es, pro Phase zu entscheiden, welche Operationen ein Agent tatsächlich braucht, genau diese freizugeben und jeden Aufruf zu protokollieren.

Planung: Backlog, Sprints und Work Items

Planungsarbeit ist wiederkehrend und textlastig und eignet sich deshalb gut für Agenten. Typische Aufgaben sind Tickets aus einem Meeting-Protokoll erstellen, das Backlog pflegen, Issues in den nächsten Sprint verschieben oder zusammenfassen, was sich im letzten Sprint geändert hat. Die betroffenen Systeme sind Jira, Azure DevOps Boards und Trello.

Die wichtigste Kontrolle ist hier der Zugriffsbereich. Ein Agent, der die Sprints eines Teams plant, sollte nur das Jira-Projekt dieses Teams sehen und Issues zwischen Backlog und Sprint verschieben können, ohne Projekte löschen zu dürfen. In Vordix wird der Jira-Zugriff über den Projektschlüssel eingegrenzt, zusätzlich gibt es Allowlists für Issue-Typen, Boards und Sprints. Vor jeder Sprint- oder Board-Operation prüft Vordix, ob das Board oder der Sprint tatsächlich zu einem freigegebenen Projekt gehört. Die Suche akzeptiert nur strukturierte Filter und kein freies JQL, sodass ein Agent seine Abfrage nicht selbst ausweiten kann. Details dazu stehen im Artikel KI-Agent in der Jira-Sprintplanung.

Dokumentation: Confluence und Wikis

Dokumentation hinkt dem Code meistens hinterher. Agenten können helfen, indem sie Release Notes entwerfen, ein Runbook nach einem Incident aktualisieren oder eine Architekturseite mit dem Repository abgleichen. Die betroffenen Systeme sind Confluence, das Azure DevOps Wiki und in manchen Teams Notion.

Entscheidend ist hier, in welche Bereiche ein Agent schreiben darf und ob er löschen kann. Den gesamten Confluence-Bestand zu lesen, ist oft vertretbar; Seiten im HR-Bereich umzuschreiben, ist es nicht. Vordix grenzt Confluence nach Space und Seite ein. Im Azure DevOps Wiki wird eine Änderung abgelehnt, wenn sie auf einer veralteten Seitenversion beruht, sodass ein Agent die Änderung einer Kollegin nicht unbemerkt überschreiben kann. Mehr dazu in KI-Dokumentation in Confluence und im Azure DevOps Wiki.

Code und Review: GitHub und Azure DevOps Repos

Hier setzen die meisten Teams bereits KI ein, und hier steht am meisten auf dem Spiel. Für das Review eines Pull Requests braucht ein Agent Lesezugriff auf Dateien und Diffs sowie das Recht zu kommentieren. Mergen, auf einen geschützten Branch pushen oder einen Deployment-Workflow auslösen sind dagegen eigene Operationen mit einem ganz anderen Risiko.

Die passende Kontrolle ist das Prinzip der minimalen Rechte pro Operation. In Vordix ist jede Operation eine eigene Berechtigung: Ein Agent darf zum Beispiel Pull Requests lesen und Review-Kommentare schreiben, während das Mergen abgeschaltet bleibt. Der Zugriff wird pro Repository eingegrenzt, Branches lassen sich per Allowlist einschränken. Für Operationen, die nur nach einer menschlichen Entscheidung laufen sollen, kann ein Admin eine Freigaberegel hinterlegen, etwa für das Mergen eines Pull Requests. Der Aufruf wird dann angehalten, bis jemand ihn freigibt. Das wird pro Operation konfiguriert und ist nicht standardmäßig aktiv. Mehr dazu in Berechtigungen für KI Code Review auf GitHub und Azure DevOps.

Daten: Databricks und das Data Warehouse

Agenten werden nützlicher, wenn sie Fragen mit echten Zahlen beantworten können, zum Beispiel zur Fehlerrate eines Service nach einem Release. Dafür brauchen sie Zugriff auf die Datenplattform, und dort liegen häufig personenbezogene Daten.

Die Kontrollen betreffen hier Tabellen und Spalten sowie den Umgang mit sensiblen Werten im Ergebnis. Die Databricks-Anbindung in Vordix ist rein lesend und akzeptiert strukturierte Abfragen statt freiem SQL; Spalten werden pro Tabelle freigegeben. Datenrichtlinien können Werte wie E-Mail-Adressen oder IBANs maskieren, pseudonymisieren oder entfernen, bevor das Ergebnis beim Modell ankommt. Siehe KI-Agenten und Datenzugriff in Databricks.

Kommunikation: Slack, Teams und E-Mail

Am Ende vieler Abläufe steht eine Nachricht: eine Release-Zusammenfassung in einem Slack-Channel, ein Status in Microsoft Teams, eine E-Mail an einen Kunden. Kommunikationswerkzeuge sind heikel, weil eine Nachricht das Team verlässt, bei E-Mail oft sogar das Unternehmen.

Die Kontrollen sind hier der Channel-Bereich für Chat und Empfängerregeln für E-Mail. Vordix grenzt Slack nach Channel und Teams nach Team und Channel ein. Für Gmail und Outlook können Admins die Empfänger auf eine Allowlist oder auf interne Domains beschränken, die Zahl der Empfänger begrenzen und BCC verbieten. Dieselben Regeln filtern auch, was der Agent lesen darf; E-Mails außerhalb der Richtlinie erreichen das Modell also gar nicht erst.

Über alle Phasen hinweg: ein gemeinsames Audit-Log

Jede Phase hat ihr eigenes Risiko, eine Anforderung haben aber alle gemeinsam: Wenn etwas schiefgeht, muss das Team rekonstruieren können, was passiert ist. Protokolliert jedes Werkzeug die Agentenaktivität auf seine eigene Art oder gar nicht, wird daraus eine mühsame Suche über mehrere Systeme.

Ein zentrales Gateway kann jeden Aufruf an einer Stelle festhalten, auch die abgelehnten Aufrufe samt Begründung. In Vordix ist das Audit-Log append-only (Einträge werden nur angehängt) und über eine Hash-Kette gesichert, nachträgliche Änderungen fallen also auf. Es lässt sich exportieren oder an ein SIEM-System (Security Information and Event Management) streamen. Ein Protokoll, das außerhalb des KI-Anbieters geführt wird, hat außerdem eine andere Beweiskraft als die Aufzeichnungen des Anbieters selbst. Darum geht es im Artikel Audit-Log für KI-Agenten und der EU AI Act.

Ein Kontrollpunkt statt vieler

Die beschriebenen Phasen folgen einem gemeinsamen Muster: Agenten brauchen Zugriff auf viele Systeme, und jedes System braucht eine andere Art von Grenze. Man kann diese Grenzen in jedem Werkzeug einzeln konfigurieren, das Ergebnis lässt sich aber kaum prüfen, weil die Antwort auf die Frage „Was darf dieser Agent?“ über ein Dutzend Admin-Oberflächen verteilt ist.

Ein MCP Gateway setzt einen einzigen Kontrollpunkt zwischen die KI-Clients und die Werkzeuge. Der Agent verbindet sich mit dem Gateway, statt für jedes System eigene Tokens zu halten, und das Gateway entscheidet bei jedem Aufruf. Wie das funktioniert und wann ein Team so etwas wirklich braucht, erklärt der Artikel Was ist ein MCP Gateway?.

Trade-offs und Einschränkungen

Ein Gateway ist eine zusätzliche Komponente und hat seinen Preis. Es muss betrieben, aktualisiert und überwacht werden. Vordix läuft selbst gehostet auf der Infrastruktur des Kunden; die Daten bleiben damit im Haus, der Betrieb liegt aber beim Team. Außerdem brauchen Berechtigungen eine verantwortliche Person: Ein Gateway macht Zugriffe überprüfbar, entscheidet aber nicht, welche Zugriffe richtig sind. Schließlich deckt ein Gateway nur die Operationen ab, die es unterstützt. Der Umfang unterscheidet sich je nach Werkzeug; die Notion-Anbindung ist zum Beispiel derzeit auf Seiten in Datenbanken beschränkt. Vor einer Einführung sollte ein Team daher die benötigten Operationen mit der Dokumentation abgleichen.

Fazit

KI-Agenten wandern aus dem Editor in Planung, Dokumentation, Review, Daten und Kommunikation. Der Nutzen ist real, die Summe der Zugriffe aber auch. Ein tragfähiger Weg ist, pro Phase zu entscheiden, welche Operationen nötig sind, nur diese freizugeben und jeden Aufruf an einer Stelle zu protokollieren. Die weiteren Artikel dieser Serie betrachten jede Phase im Detail.

Wenn Sie sehen möchten, wie das für Ihre eigene Toolchain aussieht, können Sie eine Demo anfragen oder die Vordix-Dokumentation lesen.