Agentic Coding in der Praxis: Warum euer Legacy-Code nicht das Problem ist

Wo stehen Softwareteams wirklich?

Alle sprechen gerade von Agentic Coding. Ein Agent bekommt ein Ticket, plant, greift auf die Dateien zu, schreibt Code, führt Tests aus, iteriert selbstständig. In den viralen Demos sieht das aus wie das Ende der klassischen Entwicklung.

Wir haben 92 Tech Leads und Engineering Leads gefragt, wie sie AI heute wirklich einsetzen. Immer wieder taucht dabei dieselbe Lücke auf: Die Wahrnehmung vieler Leute ist, dass es unzählige Demos gibt, in denen alles reibungslos läuft, dass es in der Realität auf einer gewachsenen, komplexen Codebasis aber nicht gut funktioniert.

Genau dieser Lücke wollten wir auf den Grund gehen. Was kann ein Team konkret tun, wenn es nicht bei null anfängt, sondern in einer gestandenen Codebasis steht? Johannes Hense arbeitet als Senior Engineer bei DevBoost tagtäglich agentisch, direkt im Code eines Kundenprojekts. Wir schauen gemeinsam darauf, was wirklich funktioniert.

Das sagen die Zahlen aus unseren Interviews:

• ~22 % der befragten Tech Leads wollen Agentic Coding einführen oder testen es gerade aktiv.
• ~5 % nutzen es produktiv und strukturiert. Der Rest steckt in Proof of Concept oder im Wartemodus.

Ende 2025 bis Mitte 2026 haben wir diese Interviews geführt, und eins zeigt sich ganz deutlich: Die Lücke zwischen Demo und Realität auf bestehenden Codebasen ist im gesamten Datensatz das Frustrationsthema Nummer eins.

Was Agentic Coding wirklich bedeutet

Zuerst brauchen wir eine kurze Abgrenzung, weil der Begriff gerade alles und nichts meint.

Agentic Coding ist kein Autocomplete und kein Chat. Beim assistierten Coding schlägt das Modell die nächste Zeile vor oder beantwortet eine Frage, der Mensch bleibt am Steuer jeder einzelnen Aktion. Ein Agent bekommt dagegen ein Ziel und arbeitet es eigenständig ab: Er plant die Schritte, liest sich in die relevanten Dateien ein, schreibt und ändert Code über mehrere Files hinweg, lässt Tests laufen und korrigiert sich anhand der Ergebnisse selbst. Der Mensch definiert die Aufgabe und bewertet das Resultat, statt jeden Handgriff selbst zu machen. Das ist ein echter Wechsel in der Arbeitsweise.

Wo Teams am Anfang Schwierigkeiten haben

Überraschend wenige Teams haben Agentic Coding bisher produktiv etabliert. In den Interviews zeigt sich eine Handvoll konkreter Schwierigkeiten, auf die Teams beim Einstieg immer wieder stoßen:

1. Kontext-Window zu klein für echte Codebasen. Der Agent sieht immer nur einen Ausschnitt. Bei einem System mit hunderttausenden oder Millionen Zeilen kennt er die entscheidenden Zusammenhänge schlicht nicht.
2. Kein Trust Level. Niemand im Team kann verlässlich sagen, wann man dem Agenten trauen darf und wann nicht. Ohne diese Einschätzung wird jede Ausgabe zur Handarbeit im Review.
3. Monorepos und viele Abhängigkeiten überfordern Agents. Je verflochtener das System, desto größer die Wahrscheinlichkeit, dass eine Änderung an einer Stelle an drei anderen etwas kaputt macht, das der Agent nicht überblickt.
4. Budget- und Token-Limits stoppen Agents, bevor sie fertig sind. Wer bei den Modellen spart, zahlt an anderer Stelle doppelt: durch schlechteren Output, mehr Nacharbeit und Kennzahlen, die die eigene Entscheidung schöner aussehen lassen, als sie ist.

Das sind erstmal nur Beobachtungen aus realen Teams. Das Interessante daran: Eine mögliche Lösung für diese vier Herausforderungen hat in der Praxis weniger mit dem Tool zu tun als mit dem, was drumherum liegt. Schauen wir auf einen verbreiteten Denkfehler.

Was es braucht, damit Agentic Coding in der Praxis funktioniert

Greenfield vs. Legacy-Code

Eine häufige Aussage lautet: Auf der grünen Wiese funktioniert Agentic Coding, aber unser altes, komplexes Produkt ist zu verwoben. Johannes' Erfahrung als Software Engineer in einem unserer Kundenprojekte zeigt: In der Praxis stimmt das so nicht. Der Erfolg hängt nicht am Alter oder an der Größe des Projekts, sondern an seiner Architektur und Dokumentation.

Dort, wo agentisches Arbeiten im Kontext des Kundenprojekts am besten lief, war es ein Projekt, in das schon lange vor dem ersten Agenten viel Sorgfalt geflossen war: saubere Architektur, jeder eingecheckte Code als gutes Beispiel aufgebaut, Tests, gutes Linting, viele automatische Checks. Da, wo schon etwas Gutes steht, arbeitet der Agent besser, nicht schlechter als auf dem Greenfield.

Alles, was du an guter Dokumentation für Menschen hinlegst, greift für einen Agenten mindestens genauso gut, oft sogar besser. – Johannes Hense

Aus diesem einen Prinzip erklären sich beide Enttäuschungen, die Teams erleben. Die eine im gewachsenen System: Wenn ein Team sein Bestandssystem selbst nicht mehr gut warten kann, wird es ein Agent auch nicht können. Dann fehlen Doku, Tests und explizite Regeln, was richtig und was falsch ist. In großen, alten Systemen ist die Chance hoch, dass es viele schlechte Beispiele gibt, und schlechte Beispiele sind ansteckend: Ein Mensch liest eine Abkürzung, denkt „so geht das also auch" und macht sie nach. Ein Agent macht genau dasselbe.

Die andere Enttäuschung auf der grünen Wiese: Greenfield funktioniert nicht besser, im Gegenteil. Johannes und sein Team haben den umgekehrten Fall ausprobiert, einen temporären Service bewusst komplett agentisch aufgesetzt, ohne dass vorher jemand Regeln und gute Beispiele festgelegt hat. Das Ergebnis war deutlich schlechter als in der gepflegten großen Codebasis und auch schlechter als in chaotisch gewachsenen Codebasen.

Die Erkenntnis ist also nicht „alt gegen neu", sondern: Ein Agent ist nur so gut wie die Beispiele, Tests und Regeln, die er vorfindet. Ob die aus einem zehn Jahre alten System stammen oder aus einem eine Woche alten, ist ihm egal.

Was heißt das für alle, deren System gerade nicht in diesem guten Zustand ist? Nicht das Handtuch werfen! Eine natürlich gewachsene, ein bisschen chaotische Codebasis ist kein Ausschlusskriterium für agentisches Coding. Ihr fangt dort an, wo ihr ohnehin gerade arbeitet, und zieht Stück für Stück Dokumentation und Tests nach. Ein bisschen Nacharbeit ist besser als keine, und die Codebasis wird mit jeder Runde ein Stück besser, für Menschen wie für Agenten. Wie ihr diesen Einstieg konkret angeht, ohne euch zu verzetteln, dazu später mehr.

AGENTS.md richtig aufsetzen

Eine AGENTS.md ist eine einfache Textdatei im Repository, in der steht, was der Agent über das Projekt wissen soll: Konventionen, Architektur, Do's und Don'ts. Der Agent liest sie automatisch mit, bevor er arbeitet, ähnlich wie ein neuer Kollege, dem man beim Einstieg die wichtigsten Regeln in die Hand drückt. Liegen weiter unten im Verzeichnisbaum weitere solche Dateien, gelten deren Regeln zusätzlich für genau den Bereich, in dem sie liegen. Diese Datei ist die zentrale Leitplanke für agentisches Coding.

In Johannes' Kundenprojekt arbeiten sie mit einem großen Monorepo mit mehreren Teams und Modulen. Dort gibt es pro Repository mindestens eine Top-Level-AGENTS.md-Datei und, wo ein Modul Besonderheiten hat, zusätzliche Dateien weiter unten. Sie funktionieren hierarchisch: Das Tooling erkennt selbst, welche Dateien von der aktuellen Stelle aus nach oben gelten, ohne dass man sie explizit verlinken muss.

Wichtig ist, diese Dateien schlank zu halten. Jede Zeile darin kostet Kontext, und Kontext ist knapp. Statt alles hineinzuschreiben, funktioniert die Top-Level-Datei eher als Link-Hub: Sie verweist auf die ausführlichen Dokumente, etwa die ADRs, ohne deren Inhalt komplett aufzunehmen. Der Agent liest sie nicht per Default, weiß aber, dass es zu einem Thema eine Doku gibt, und liest sie nach, wenn sie relevant wird.

Genau das entschärft zwei der in den Interviews häufig genannten Herausforderungen, das enge Kontextfenster und die Unübersichtlichkeit großer Monorepos. Der Agent muss nicht das ganze System auf einmal begreifen. Die AGENTS.md gibt ihm gezielt den Kontext, der an dieser Stelle zählt, und hält den Rest als Verweis bereit. So bleibt selbst ein weit verzweigtes System handhabbar, ohne das Kontextfenster zu sprengen.

Der größte Fehler passiert vielen Teams ganz am Anfang.

Die erste, initiale AGENTS.md würde ich nicht vom Agenten schreiben lassen. Was er hineinschreibt, ist genau das, was er sich sowieso aus dem Code zusammensucht. Wertvoll ist das, was nicht im Code steht: eure Best Practices und das, worauf ihr als Entwickler achtet. – Johannes Hense

Wer die Datei vom Agenten generieren lässt, bekommt eine hübsche Zusammenfassung dessen, was der Agent ohnehin sieht. Der eigentliche Wert liegt im impliziten Wissen: die Konventionen, die niemand aufgeschrieben hat, die Dinge, die ein erfahrener Mensch im Kopf hat und beim Review automatisch prüft.

Compound Engineering: Nach jeder Session Erkenntnisse sichern

Eine AGENTS.md ist nichts, was man einmal anlegt und dann vergisst. Der größte Hebel liegt darin, sie nach jeder Session zu schärfen. Der Fachbegriff dafür lautet Compound Engineering. Gemeint ist einfach: am Ende einer Coding-Session Erkenntnisse, die das Arbeiten in der nächsten Session beschleunigen können, in der AGENTS.md oder dort, wo es gerade sinnvoll ist, zu sichern.

So wird das System mit jedem Zyklus ein Stück besser, statt bei jeder Aufgabe wieder bei null zu starten. Jede Korrektur wandert einmal in die Doku und muss danach nicht mehr jedes Mal von Hand nachgezogen werden.

Nebenbei entstehen so auch persönliche Arbeitsstile. Viele im Team haben eigene, lokale Skills oder AGENTS.md-Dateien, die nicht sofort fürs ganze Repo gepusht werden. Es gibt dafür keinen starren Prozess, sondern eine Austauschkultur: Geteilt wird, was sich bewährt und was für alle taugt, wandert irgendwann ins Team oder die zentrale AGENTS.md, der Rest bleibt persönlich.

Planen, laufen lassen, kontrollieren

Ein häufiges Missverständnis ist, dass Engineers dem Agenten ständig über die Schulter schauen müssen. In der Praxis liegt die Kontrolle woanders. Der wichtigste Teil der Arbeit steckt vorne, im Plan.

Der Schlüssel dafür ist ein eigener Modus, den die meisten Agenten mitbringen, etwa Claude Code, OpenCode oder Cline: der Plan-Modus. In diesem Modus darf der Agent ausschließlich lesen, nichts ändern. Und die Rolle dreht sich um: Statt dass ihr euch selbst durch Code und Tickets arbeitet, formuliert ihr euer Ziel, und der Agent erkundet alles Nötige eigenständig, von der Codebasis über Slack bis zu Jira. Bei großen Codebasen schickt er dafür sogar Sub-Agenten los, damit sein eigentlicher Kontext nicht mit Details überschwemmt wird.

Das läuft wie ein freies Gespräch: Der Agent schlägt auf Basis der Unterhaltung und der Fakten, die er selbst zusammengetragen hat, einen Plan vor. Wo die Anforderungen noch unklar sind oder echte Entscheidungen anstehen, fragt er nach. Diese Phase ist der wichtigste Schritt, und hier lohnt es sich, den Output des Agenten wirklich zu lesen und erst aufzuhören, wenn der Plan solide steht. Ist er das, ist der Wechsel in die Umsetzung nur noch ein Knopfdruck: Der Agent arbeitet den Plan dann eigenständig ab, ohne bei jedem Schritt nachzufragen.

Dann kontrolliert ihr das Ergebnis. Sind die Codebasis und euer Netz um die agentischen Prozesse herum gut und die Änderung klein genug, geht das Ergebnis direkt in einen Pull Request. Alternativ könnt ihr manuell testen oder vor dem Commit noch einmal selbst über den Code schauen. Passt etwas nicht, geht es zurück in eine kurze Iteration. Wie viel Kontrolle nötig ist, hängt an zwei Dingen: der Qualität der Codebasis und eures AI-Harness.

Eine Hürde, die viele im Interview genannt haben, war das fehlende verlässliche Gefühl dafür, wann der Agent Vertrauen verdient und wann nicht. Die ehrliche Antwort ist, dass Vertrauen nicht aus dem Bauch kommt, sondern aus dem Aufbau. Wer sauber plant und ein gutes Sicherheitsnetz aus Tests und automatischem Review hat, kann den Agenten auch mal im „YOLO-Modus" laufen lassen. Teams mit einem klaren Sicherheitsnetz haben ein spürbar höheres Trust Level als Teams, denen es fehlt.

Das Harness: das Sicherheitsnetz, das Vertrauen schafft

Genau dieses Netz hat einen Namen, der im agentischen Arbeiten immer wieder fällt: das Harness. Gemeint ist das automatische Gerüst rund um euren Code, das die Arbeit des Agenten prüft, ohne dass ein Mensch jede Zeile lesen muss: Tests, Linting, Typprüfungen, CI-Pipelines und automatisiertes Code-Review. Je dichter dieses Netz, desto mehr Leine könnt ihr dem Agenten lassen, weil Fehler von der Maschinerie abgefangen werden und nicht erst auffallen, wenn es Ärger bedeutet.

Das Harness ist damit die konkrete Antwort auf die Trust-Frage. Es ist kein einzelnes Tool, sondern die Summe der Signale, an denen sich automatisch ablesen lässt, ob eine Änderung in Ordnung ist. Und es ist dieselbe Investition, die auch euren menschlichen Entwicklern zugutekommt, weshalb sie sich doppelt lohnt.

Wichtige Code-Review Prinzipien für agentisches Coding

Agentisches Coding verändert auch das Code-Review. Jeder AI-generierte Code durchläuft mehrere Reviews:

Für das automatisierte Review gibt es im Kundenprojekt zwei Ebenen: einen etablierten Reviewer (GitHub Copilot) und einen selbstgebauten Swarm aus mehreren Review-Agenten mit unterschiedlichen Schwerpunkten, z. B. einer für Security, einer für Wartungskomplexität und so weiter.

Der Schlüssel gegen das bekannte Problem, dass AI immer irgendetwas zu sagen hat, liegt darin, dass jeder Review-Kommentar ein Confidence- und ein Criticality-Level bekommt. Was niedrige Confidence hat, wird gar nicht erst als Kommentar an den Code geheftet. So bleibt das Rauschen niedrig, und die Kommentare, die durchkommen, sind meistens welche, die die Engineers wirklich bearbeiten wollen und sollten. Wer alle Kommentare abarbeitet und den Reviewer erneut losschickt, bekommt natürlich immer wieder neue Funde. Spätestens ab der zweiten oder dritten Runde ist es dann völlig in Ordnung, den Rest bewusst auszublenden.

Das zweite Review erfolgt durch einen Kollegen im Pull-Request, aber nicht mehr zwingend. Wer agentisch gearbeitet hat, entscheidet selbst, ob eine Änderung überschaubar genug für einen direkten Merge ist oder ob sich ein menschlicher Blick lohnt. Das ist genau das Ventil, das den höheren Durchsatz an neuem Code beherrschbar macht, denn im Kundenprojekt war menschliches Review zeitweise ein Bottleneck. Wenn ein Team ein klares System für agentisches Arbeiten aufgesetzt hat, ist der eigentliche Code im Review ohnehin fast nebensächlich. Viel wichtiger sind Testabdeckung und Dokumentation.

Johannes empfiehlt, im Review gerade das genau zu prüfen: Welche Tests gibt es, sind sie nachvollziehbar, und beweisen sie, was der Code tun soll?

Genauso wichtig ist die Dokumentation, die zu großen Teilen natürlich ebenfalls oft von Agenten geschrieben wurde. Wer einen Pull-Request bekommt, schaut auch auf Änderungen an ADRs und anderer Doku. Die AI-Modelle schreiben hier oft zu viel und treffen den Kern nicht, und das frisst wieder Kontext. Zu ausufernde Doku wird nicht gemerged, sondern zurückgeschickt mit der Bitte, sie auf das Wesentliche einzugrenzen.

Den Agenten Kontext geben: Integrationen über MCP

Ein Agent ist nur so gut wie der Kontext, den er erreicht. Über MCP (Model Context Protocol) könnt ihr euren Agenten Zugriff auf die Systeme geben, in denen das Wissen tatsächlich liegt. Im erwähnten Kundenprojekt hängen die Agenten an einer ganzen Reihe von Anwendungen, von Slack über Jira bis zu weiteren internen Tools. Der Effekt ist spürbar: Der Agent sieht dann nicht nur den Code, sondern auch das Ticket, die Diskussion und das Warum dahinter.

Wie Softwareteams pragmatisch mit Agentic Coding starten können

Lieber iterativ starten als lange planen

Der wichtigste Rat für die, die noch nicht mit agentischem Coding angefangen haben oder unzufrieden mit dem bisherigen Prozess sind, ist unspektakulär: nicht lange darüber diskutieren, sondern Schritte gehen. Agentisches Arbeiten einzuführen funktioniert am besten dynamisch und niederschwellig. Einer macht den ersten Schritt, legt eine AGENTS.md an und sagt: „Probiert mal, ob sich das Coden damit besser anfühlt." Jeder soll ein Gefühl dafür bekommen, und das bekommt ihr nur, indem ihr es ausprobiert, nicht, indem ihr ein Meeting darüber ansetzt.

Eine Voraussetzung gehört dabei aber ehrlich dazu: Das Team braucht Rückhalt „von oben". In Johannes' Kundenprojekt trägt das Management den Weg mit und sieht den Wert der AI-Tools. Konkret heißt das dreierlei: Zugang zu leistungsstarken Modellen, die Erlaubnis, hilfreichen Kontext anzubinden, und ein Budget, das nicht bei jedem Token zuckt. Diese drei Hürden muss euer Unternehmen niedrig halten, damit die Leute überhaupt ins Ausprobieren kommen.

Der sanfte erste Schritt: analysieren statt schreiben lassen

Wer Respekt davor hat, die AI am Produktivcode arbeiten zu lassen, fängt am besten dort an, wo fast nichts schiefgehen kann: beim Verstehen. Agenten sind erstaunlich gut darin, große Mengen Code zu durchsuchen und Zusammenhänge zu erkennen, gerade in verworrenen Bestandsprojekten.

Fragt zum Beispiel: Welche Komponenten betrifft Vorhaben X? Welche Dateien müssten geändert werden? Wo bestehen Abhängigkeiten zu anderen Services oder Repositories?

Der Agent liefert zunächst nur eine Analyse und einen Plan. Er verändert noch nichts. Das ist ein sicherer Einstieg und hilft oft gleichzeitig dabei, das eigene System wieder besser zu verstehen.

Legacy-Bestandscode für Agenten aufbereiten

Für Teams, die in der Vergangenheit nicht so sauber gearbeitet oder eine durchwachsene Codebasis überlassen bekommen haben, ist die gute Nachricht: Ihr müsst nicht erst alles wegwerfen oder monatelang Dokumentation und Tests schreiben, bevor es losgeht. Auf einer großen, schlecht dokumentierten Codebasis fangt ihr mit kleinen Änderungen an und schaut genau hin, ob das Ergebnis passt. Der Agent sollte hier noch nicht allein laufen. Der eigentliche Wert steckt für euch in den Fehlern, die der Agent macht: Wenn der Agent etwas produziert, das nicht passt, habt ihr genau eine Lücke gefunden, die eigentlich besser dokumentiert gehört. Stoppt hier und zieht die Dokumentation nach. So schließt ihr Schritt für Schritt die Doku-Lücken, die vorher niemand gesehen hat, und die Codebasis wird nebenbei sowohl für Menschen als auch für Agenten besser.

Ordnet ehrlich ein, wo ihr steht

Agentic Coding ist kein Schalter, den man umlegt, sondern ein Weg mit Stufen. Es hilft, sich ehrlich einzuordnen:

• Experimentieren einzelne Leute noch oder gibt es schon gemeinsame Workflows und erste Leitplanken?
• Schärft sich der Prozess über Compound Engineering schon selbst?
• Was ist die kleinste Sache, die wir als Nächstes besser dokumentieren oder automatisieren können?

Was sich durch Agentic Coding für Softwareteams verändert

In Zahlen: Welchen Effekt hat Agentic Coding wirklich?

Eine Frage, die sich jedes Team stellen sollte: Woran messt ihr, welchen Effekt das Arbeiten mit Coding Agents hat? Ob sich das Investment in teure Tokens lohnt? Token-Verbrauch zu messen, sagt noch nichts über euren Impact aus. Aussagekräftiger sind die Metriken, die es schon vor der Einführung von AI gab, die klassischen Flow-Kennzahlen: Wie lange hängt ein Ticket in Ready, ohne dass es jemand anfängt? Wie lange liegt ein Pull Request im Review, ohne dass jemand draufschaut? Wie oft releasen wir? Kennzahlen, die schon vorher existierten, ermöglichen es euch, die tatsächliche Veränderung abzulesen. Ein Dashboard, das Tokens oder Zeilen zählt, misst Output, nicht Outcome, und sagt damit wenig darüber, ob am Ende bessere Software schneller beim Kunden landet.

Für die Engineers, die jetzt weniger coden, mehr planen und mehr Code-Reviews machen

Zum Schluss ein Punkt, der bei all der Begeisterung über agentisches Arbeiten manchmal zu kurz betrachtet wird: Ein Teil der Entwickler erlebt die Arbeit durch Agenten nicht nur als leichter, sondern auch anstrengender. Früher konnten Entwickler sich nach all den Abstimmungen und Planungs-Runden ins stille Kämmerchen zurückziehen und in Ruhe runterprogrammieren. Diese Phase war für viele Erholung und das, was ihnen besonders Spaß gemacht hat – und diese Phase wird durch AI jetzt immer kürzer. Das Erlebnis, schneller Wert zu schaffen, kompensiert das für viele. Trotzdem erleben viele Engineers die neue Art des Codings als fordernder.

Eine Sache findet Johannes aber besonders gut: Wer vorher von einer Umsetzung in die nächste gehetzt ist, hat jetzt eher Zeit, Dinge wirklich gut zu machen, für die vorher der Druck zu groß war: das Setup optimieren, die Dokumentation schärfen, dafür sorgen, dass das ganze Team morgen schneller und besser arbeitet. Für Leute, die gern in Ruhe an einer Sache tüfteln, entsteht genau hier ein neuer, spannender Aufgabenbereich – der sich langfristig auszahlt.

Eine ehrliche Einschätzung

Agentic Coding lohnt sich, aber nicht als Knopfdruck. Es lohnt sich für Teams, die bereit sind, in drei Dinge zu investieren: eine ehrliche, schlanke Dokumentation dessen, was im Code nicht steht, gute Tests und Beispiele als Leitplanken, und die Bereitschaft, aus jeder Korrektur zu lernen. Wer diese Grundlage hat oder aufbaut, bekommt einen echten Multiplikator. Wer sie überspringt, produziert schneller Murks, ob auf altem oder neuem Code.

Die beste Nachricht für die vielen, die noch zögern: Der Einstieg ist kleiner, als er aussieht. Ihr müsst nicht die ganze Codebasis umbauen. Es reicht, eine erste ehrliche AGENTS.md anzulegen und dann Stück für Stück die Prinzipien anzuwenden, die gute Softwareentwicklung schon immer ausgemacht haben.