Agentic Development heißt, dass ein Agent mehrschrittig und selbstständig im Repository arbeitet: Er ruft Werkzeuge auf, führt Code aus, prüft das Ergebnis und korrigiert sich, um sein Ziel zu erreichen. Das ist der Punkt, an dem KI in der Entwicklung von einer Schreibhilfe zu einem eigenständig handelnden Akteur wird, und es funktioniert umso verlässlicher, je belastbarer die Testabdeckung, die Architekturdokumentation und die CI-Pipeline sind. Ohne diese Grundlage ist Agentic Development nicht ausgeschlossen, sondern riskanter. Diese Grundlage können Sie herstellen. Sie entscheiden über die Rechte des Agenten und über die Stelle, an der ein Mensch bestätigt.
Die Gesellschaft für Informatik beschreibt Coding-Agenten als Sprachmodelle, die wiederholt Werkzeuge aufrufen, deren Ergebnisse verarbeiten und sich schrittweise auf ein Ziel zubewegen. Der Unterschied zur Codevervollständigung liegt in der Ausführung: Der Agent schreibt nicht nur Code, er lässt ihn laufen, liest die Fehlermeldung und ändert daraufhin die nächste Datei. Damit übernimmt er einen Teil der Arbeit, die bisher zwischen Vorschlag und Ergebnis von Hand lief.
Andrej Karpathy hat den Ausdruck Vibe Coding im Februar 2025 geprägt, für das Übernehmen generierten Codes ohne Lektüre. Anfang 2026 hat er ihn auf Wegwerfprojekte, Demos und Erkundungen zurückgestutzt, weil die Modelle seither deutlich besser geworden sind und professionelle Agenten-Workflows erst dadurch tragfähig wurden. Für die professionelle Form benutzt er den Begriff Agentic Engineering und beschreibt damit dasselbe Verfahren: Entwickler schreiben die meiste Zeit keinen Code mehr selbst, sondern leiten Agenten an und führen die Aufsicht.
Wo ein Agent läuft, entscheidet mit darüber, worauf er zugreifen kann. Die GI unterscheidet drei Bauformen: Claude Code und OpenAI Codex sind ursprünglich terminalbasiert, laufen also auf demselben Rechner wie die Entwicklungsumgebung, Cursor bettet den Agenten in die grafische Entwicklungsumgebung ein, und Google Antigravity orchestriert mehrere parallele Agenten über eine gemeinsame Oberfläche. Für ein Projekt zählt daran vor allem die Reichweite. Ein Agent im Terminal liest die Codebasis, editiert Dateien und führt Befehle aus, sieht also alles, was der Entwickler sieht. Er gehört deshalb in eine isolierte Umgebung, wie sie OpenHands über Container vorsieht. Daneben nennt die GI Cloud-Varianten, in denen der Agent auf einem Server arbeitet und am Ende einen Pull Request öffnet. Er sieht weniger, aber alles, was vorher die Anwesenheit eines Menschen abdeckte, muss dort über Rechte festgelegt sein.
Die GI beschreibt dafür ein gestaffeltes Berechtigungssystem: Lesezugriffe laufen ohne Rückfrage, Dateiänderungen brauchen eine Freigabe, und Shell-Befehle lassen sich pro Projektverzeichnis dauerhaft erlauben. Für ein Projekt lässt sich das in eine Staffel übersetzen:
An einer Stelle weicht diese Staffel bewusst von der GI ab. Nur-Lesen bleibt der Ausgangspunkt, aber die Freigabe sitzt am Merge und nicht an jeder einzelnen Dateiänderung. Der Grund ist der Branch: Was dort entsteht, ist noch nichts, was bestehen bleibt. Wer die Freigabe früher setzen will, verschiebt sie auf Stufe zwei und prüft jede Änderung einzeln.
Welche Stufe für ein Projekt infrage kommt, entscheidet der Zustand des Repositories:
| Stufe | Voraussetzung im Repository | Wofür geeignet |
|---|---|---|
| 1 Lesen | keine | Analysefragen, Abschätzung eines Umbaus |
| 2 Im Branch ändern | Branch-Schutz auf dem Hauptzweig | abgegrenzte Änderungen mit überschaubarem Umfang |
| 3 Tests ausführen | eine isolierte Ausführungsumgebung und eine Testsuite, die Regressionen meldet | Änderungen über viele Dateien |
| 4 Pull Request öffnen | dokumentierte Architektur, eingespieltes Review | laufende Weiterentwicklung |
| 5 Mergen | bewusst nicht vergeben, auch wo Auto-Merge technisch möglich wäre | nicht vorgesehen |
Der eigentliche Hebel entsteht ab Stufe drei. Ein Agent, der die Testsuite starten darf, arbeitet mit dem Ergebnis weiter, statt einen Vorschlag abzuliefern, den jemand prüfen und zurückgeben muss. Wo Tests belastbar sind, übernimmt er den mechanischen Teil einer Änderung über viele Dateien, und die Entscheidung über Schnittstellen und Datenmodell trifft weiterhin ein Entwickler. Wer belastbare Tests hat und trotzdem auf Stufe eins bleibt, verschenkt genau den Teil, den die Tests abdecken.
Stufe vier fügt sich in ein eingespieltes Team ohne neuen Prüfschritt ein, weil ein Pull Request ohnehin durch das Review geht. Stufe fünf ist die Grenze: Bis dahin lässt sich jede Änderung im Repository zurücknehmen, ab dem Merge steht sie in dem Stand, auf dem alle weiterarbeiten. Befehle, die nur der Agent für seinen Lauf braucht, laufen in einer isolierten Umgebung und erreichen diesen Stand gar nicht.
Die Verantwortung für das Ergebnis liegt beim Entwicklungspartner, gegenüber dem Auftraggeber. Ein Agent im Ablauf verschiebt nur, an welcher Stelle jemand hinsieht.
Beim Start liest ein Agent die Regeldateien im Repository, also die Projektanweisungen in einer CLAUDE.md oder AGENTS.md, dazu die Konfiguration der angebundenen Werkzeuge. Daraus baut er sein Verhalten für den ganzen Lauf. Darin liegt die Wirkung des Verfahrens: Was im Repository steht, gilt für jeden Lauf und für jeden im Team, ohne dass es jemand mündlich weitergibt.
Dieselbe Eigenschaft verlangt Sorgfalt. Die GI weist auf zwei Wege hin: Über eine Regeldatei lassen sich Shell-Befehle auslösen und Zugangsdaten abziehen, und über MCP, das Model Context Protocol, sowie über Inhalte aus dem Browser kommt Prompt Injection in den Lauf.
Für den ersten Weg ist die Antwort das Review. Eine Regeldatei durchläuft dasselbe Review wie jede andere Änderung, und welche Werkzeuge sie freigibt, entscheidet das Team bei jeder Änderung neu. Das greift allerdings nur, solange die Änderung durch den eigenen Prüfprozess läuft. Ein fremdes Repository oder ein ungeprüfter Branch wird deshalb nie ungeprüft mit einem Agenten geöffnet, weil die Regeldatei dort schon beim Einlesen wirkt. Der zweite Weg lässt sich damit nicht schließen, weil diese Inhalte erst zur Laufzeit entstehen. Dort entscheidet, welche Werkzeuge ein Lauf überhaupt aufrufen darf und in welcher Umgebung er läuft.
Ein Agent kennt keine Geschichte, jede Sitzung beginnt ohne Erinnerung. Er liest Quelltexte, Konfigurationsdateien, Tickets und Dokumentation und setzt sich daraus ein Bild zusammen. Christopher Flocke und Daniel Engelhardt beschreiben in ihrem Beitrag zum Agent Harness den Rahmen, den er dazu braucht: Tests, Architekturregeln, persistente Dokumentation und deterministische CI-Pipelines. Dieser Rahmen macht, wie sie schreiben, aus probabilistischen Modellen steuerbare Agenten.
Im Greenfield stimmt das, was der Agent liest, mit dem überein, was gilt. Im Bestand trifft er auf Tickets, die einen alten Stand beschreiben, und auf Tests, die das tatsächliche Verhalten nicht mehr abbilden. Was er dort produziert, spiegelt das, was er vorfindet, nicht das, was sein sollte.
Wie wenig verbreitet weitgehend unbeaufsichtigte Agenten in der Praxis sind, zeigt die DORA-Untersuchung „State of AI-assisted Software Development“. Google hat dafür zwischen dem 13. Juni und dem 21. Juli 2025 knapp 5.000 Fachleute aus der Technologiebranche befragt. 61 Prozent von ihnen gaben an, nie mit KI-Werkzeugen zu arbeiten, die ohne direkte Aufsicht Änderungen vornehmen. Beim Vertrauen in generierten Code stehen 24 Prozent mit viel oder sehr viel Vertrauen gegen 30 Prozent mit wenig oder keinem. Die Staffel oben beschreibt den dritten Fall: selbstständig im Branch, bestätigt am Merge.
Woran das Misstrauen hängt, sagt die Erhebung nicht. Unsere Erfahrung aus Projekten legt einen Zusammenhang nahe: Wer keine Testsuite hat, die Regressionen meldet, kann generierten Code auch nicht überprüfen, und ohne diese Prüfung bleibt nur Misstrauen als vernünftige Haltung.
Daraus folgt die Reihenfolge. Testabdeckung und Architekturdokumentation zahlen sich unabhängig von jedem Agenten aus. Neu ist, dass es dafür jetzt ein zweites Argument gibt. Oliver Nocon und Lukas Heimann bringen es im Gespräch mit heise developer über den SAP-Rollout auf einen Satz: KI wirkt als Verstärker, gute Praktiken werden verstärkt, schlechte auch.
Für ein Bestandssystem steht damit die Reihenfolge fest. Erst Testabdeckung und Architekturdokumentation an den Stellen, die verändert werden sollen, dann Stufe drei. Diese Vorarbeit lässt sich abschätzen, und Sie begrenzen sie auf den Bereich, um den es tatsächlich geht.
Wie das im Konzernmaßstab aussieht, beschreiben Nocon und Heimann im selben Gespräch. Linting, statische Codeanalyse sowie Lizenz- und Sicherheitsscans bleiben relevant, heißen dort Sensoren und müssen dem Agenten direkt als Datenquelle zur Verfügung stehen. Was nur im Dashboard steht, liest er nicht. Firmenspezifisches Wissen wie Produktstandards und Integrationskonzepte kommt als zentrale Skills und MCP-Server in den Entwicklungsprozess, und im Pull Request prüft ein Review-Bot mit.
SAP bündelt die Rechte zentral: Zugriff auf die Sprachmodelle nur über einen zentralen Proxy, eine Registry für erlaubte Skills und MCP-Server, Vorgaben für erlaubte Agent Harnesses, dazu Human-in-the-Loop. Die Begründung steht im selben Gespräch: Coding-Agenten haben hohe Berechtigungen und große Flexibilität, und das macht sie zum Einfallstor, von Prompt Injection bis zur Datenexfiltration über MCP-Server.
Wo die offizielle Integration fehlt, baut sich jemand eine, oft mit KI, und damit entsteht Schatten-IT. Ein Verbot verlagert diesen Eigenbau nur. Die zentral angebotene Integration muss so einfach einzurichten sein, dass sich der Eigenbau nicht lohnt.
Der Weg dahin ist im Mittelstand derselbe, nur kleiner. Bei devosphere läuft die Verteilung über einen internen Marketplace, ein Repository, das bei uns liegt und nicht öffentlich zugänglich ist. Dort stehen Commands, Skills und Agenten allen Entwicklern zur Verfügung, und Verbesserungen fließen ausschließlich dorthin zurück, sodass niemand eine Version manuell nachziehen muss. Die Prüfschritte gibt der Marketplace ebenfalls vor, ausgeprägt je nach Sprachstack, für ein Laravel-Projekt also anders als für ein Go-Projekt. MCP-Server verteilen wir nicht als eigene Kategorie. Einzelne Skills binden Systeme wie GitHub oder Jira an, einen zentralen Katalog dafür führen wir nicht.
Vorher hatte jeder sein eigenes Setup, und das hieß: dieselbe Aufgabe, unterschiedliche Ergebnisse, unterschiedlicher Token-Verbrauch, keine Konsistenz. Der Marketplace sorgt dafür, dass alle mit demselben, aktuellen Toolset arbeiten.
Diese vier Punkte fragen Sie ab, bevor Sie beauftragen.
Die Voraussetzungen, die ein Agent braucht, gehören bei devosphere in den Projektprozess: die Spezifikation vor der ersten Zeile Code, die Dokumentation daraus, Security-Tests in der CI/CD-Pipeline und eine Instrumentierung im Code, die im Betrieb sichtbar macht, welcher Aufruf wo hängt. Dieses Zielbild stand schon, als es dafür nur einen Grund gab, nämlich Systeme, die man in fünf Jahren noch anfassen kann. Agenten sind der zweite Grund. Wie weit ein einzelnes Projekt dort steht, hängt vom Bestand ab und davon, welche Schritte auf Auftraggeberseite mitgehen.
Für unsere eigenen Agenten reicht das bis Stufe vier. Ein Agent legt Branches an, schreibt Tests, erzeugt Migrationen und öffnet Pull Requests. Er hat dafür Zugriff auf das vollständige Repository und liest, was die jeweilige Aufgabe erfordert. Der Merge ist die Grenze, den nimmt kein Agent vor. Jeden Pull Request prüft ein Teammitglied, und die Entscheidung, ob gemergt wird, liegt bei einem Entwickler.
Im Review hat sich dadurch eine Ebene verschoben. Früher durchlief jede Änderung zwei menschliche Reviews. Heute läuft sie durch ein vorgeschaltetes KI-Review und danach durch ein menschliches. Ein KI-Review ersetzt kein menschliches, es sortiert vor, und die Person am Ende steht weiterhin für das Ergebnis gerade.
Danebengelegen hat ein Agent bei uns nach einem wiederkehrenden Muster: Große gewachsene Projekte und Monolithen lassen sich nachträglich nur schwer in ein spec-driven Raster bringen. Dort fehlt dem Agenten der Kontext, und dann trifft er Fehlentscheidungen. Daran arbeiten wir weiter.
Wenn Ihr Repository Tests und eine dokumentierte Architektur mitbringt, ist Stufe drei die richtige Wahl, mit eingespieltem Review auch Stufe vier. Wenn nicht, fängt das Projekt bei Tests für den Bereich an, der verändert werden soll.