Toolchain ist der leichte Teil der Umstellung

Agentic Engineering heißt, dass KI-Agenten unter menschlicher Führung eigenständig substanzielle Teile des Codes schreiben, testen und überarbeiten – nicht Autovervollständigung im Editor, und nicht unkontrolliertes „Vibe Coding“ ohne Review. Der Unterschied zu einfacher KI-Unterstützung liegt im Umfang der Delegation: Ein Agent bekommt eine Aufgabe, keine einzelne Zeile.

Genau dieser größere Umfang macht die Einführung anspruchsvoller als der Kauf einer Lizenz. Ein Team, das Agenten Aufgaben statt Zeilen gibt, muss Spezifikation, Review und Qualitätssicherung neu kalibrieren – sonst verschiebt sich das Problem nur vom Schreiben zum unbemerkten Ausliefern von Fehlern.

Der Begriff ist bewusst enger gefasst als „KI in der Softwareentwicklung“ allgemein. Ein Team, das gelegentlich Vorschläge eines Assistenten übernimmt, betreibt noch kein Agentic Engineering. Der Übergang beginnt dort, wo ein Agent eigenständig einen mehrschrittigen Plan verfolgt – Dateien anlegen, Tests schreiben, Code ändern, Ergebnis prüfen – und ein Mensch das Ergebnis, nicht jeden Einzelschritt, beurteilt.

Ein Greenfield-Projekt kann Agentic Engineering von Anfang an mitdenken: Architektur, Testabdeckung und Dokumentation entstehen parallel zum Code. Ein bestehendes Engineering-Team trifft auf gewachsene Systeme, ungleich verteiltes Wissen und eine Codebasis, die nicht für die Zusammenarbeit mit einem Agenten dokumentiert wurde. Beides braucht ein Vorgehen, aber ein unterschiedliches.

In einem bestehenden Team ist der erste Schritt selten die Toolchain, sondern die Frage, welcher Teil der Codebasis überhaupt ausreichend verstanden und getestet ist, um einen Agenten sicher daran arbeiten zu lassen. Module mit dünner Testabdeckung oder unklarer Verantwortung sind der falsche Startpunkt – dort maskiert ein Agent bestehende Probleme, statt sie sichtbar zu machen.

Die Wahl zwischen Claude Code, Codex, Cursor oder einem anderen Werkzeug ist weniger entscheidend, als die meisten Teams annehmen. Wichtiger sind drei Eigenschaften: ein einheitliches Werkzeug über das gesamte Team, damit Reviewer wissen, was sie vor sich haben; Integration in die bestehende CI/CD-Strecke, statt eines parallelen Prozesses; und die Möglichkeit, Rechte zu scopen – welche Systeme, Repositories und Aktionen ein Agent tatsächlich erreichen darf.

Ein oft übersehener Punkt: Jede Aktion eines Agenten – Commit, Pull Request, Kommentar – sollte im Repository eindeutig einem Agentenlauf zugeordnet sein, nicht unter dem Namen des Entwicklers verschwinden, der ihn gestartet hat. Ohne diese Zuordnung wird jede spätere Analyse von Qualität oder Vorfällen zur Rekonstruktionsarbeit.

Ein Wechsel der Toolchain mitten in einem laufenden Projekt kostet mehr, als er meist einbringt, weil Prompts, Konventionen und die eingeübte Review-Praxis nicht automatisch übertragen. Die pragmatische Reihenfolge ist deshalb: ein Werkzeug testen, mit einem klaren Kriterienkatalog bewerten, dann für die Dauer eines Projekts oder Quartals festlegen – statt bei jedem neuen Modell-Release die Toolchain zu wechseln.

Die Disziplin, die den größten Unterschied macht, ist simpel und wird trotzdem regelmäßig übersprungen: eine geschriebene Anforderung vor der Delegation an einen Agenten, nicht ein Chat-Prompt aus dem Bauch heraus. Ein Ticket mit klaren Akzeptanzkriterien produziert reproduzierbar bessere Ergebnisse als eine informelle Anweisung – unabhängig vom Modell.

Der Review-Prozess muss sich auf KI-generierte Diffs einstellen. Ein Reviewer prüft, ob der Code funktioniert und ob die Lösung zur Zielarchitektur passt, und ob der Agent eine Abkürzung genommen hat, die auf den ersten Blick nicht auffällt – etwa Logik dupliziert statt wiederverwendet oder eine Fehlerbehandlung stillschweigend weggelassen. Automatisierte Gates – Tests, Linting, Sicherheitsprüfung – laufen dabei vor jedem Merge, unabhängig davon, wer den Code geschrieben hat. Ein Agent, der Tests selbst schreibt, verdient hier eine zusätzliche Prüfung: ob die Tests das Verhalten wirklich verifizieren oder nur den vom Agenten selbst geschriebenen Code widerspiegeln.

Teams, die Agenten ohne Review auf Geschwindigkeitskennzahlen optimieren lassen, bauen unsichtbare Komplexität und doppelte Logik auf. „Der Agent hat es schnell gebaut“ ist nicht dasselbe wie „der Agent hat es richtig gebaut“. Das häufigste Anti-Pattern ist, ausschließlich Ausstoß zu messen – Codezeilen, Anzahl gemergter Pull Requests –, ohne zwischen explorativem Prototyp-Code und Produktionscode zu unterscheiden.

Ein zweites Anti-Pattern ist ebenso verbreitet: Agenten laufen ohne einen Menschen, der Architekturentscheidungen prüft, weil das Team davon ausgeht, dass Geschwindigkeitsgewinne kostenlos sind. Sie sind es nicht. Sie verschieben nur, wo die Kosten anfallen – meistens später, als Nacharbeit an Stellen, die niemand mehr genau kennt.

Aussagekräftig sind die Zykluszeit von Anforderung bis Produktion, die Fehler- und Rollback-Rate nach Release, der Durchsatz der Reviewer – verschiebt sich der Engpass vom Schreiben zum Prüfen? – und der Anteil an Code, der ohne Änderung durch den Review kommt. Letzterer ist ein direkter Indikator für die Qualität der Spezifikation, nicht nur für die Fähigkeit des Agenten.

Diese Kennzahlen sind nur aussagekräftig, wenn eine Baseline vor der Einführung existiert. Ein Team, das erst nach der Umstellung zu messen beginnt, kann nie belegen, was sich tatsächlich verändert hat – für die eigene Steuerung nicht, und für ein Investment Committee erst recht nicht.

Je mehr Code Agenten schreiben, desto knapper wird Review-Kapazität – nicht Schreibkapazität. Das verändert, wohin ein Team investieren muss: gezielte Schulung in Review-Fähigkeiten, bessere Werkzeuge zur Diff-Analyse, und in manchen Fällen ein zweiter Agent, der einen ersten Entwurf vorprüft, bevor ein Mensch entscheidet. Der Mensch bleibt in jedem Fall der Punkt, an dem Verantwortung landet – die Frage ist nur, wie effizient er diese Verantwortung wahrnehmen kann.

Ein Senior Engineer, der früher überwiegend selbst Code geschrieben hat, verbringt in einem reifen agentischen Team einen wachsenden Anteil seiner Zeit mit Review und Architekturentscheidung. Das ist keine Abwertung der Rolle, sondern eine Verschiebung – die Teams unterschätzen, wenn sie Kapazitätsplanung noch nach der alten Verteilung von Schreiben und Prüfen machen.

Die größte Widerstandsquelle ist selten die Technologie, sondern die unausgesprochene Sorge, dass die eigene Rolle überflüssig wird. Diese Sorge verschwindet dadurch, dass das Team sieht, wie sich die eigene Arbeit verschiebt: weniger repetitives Schreiben, mehr Entscheidung über Architektur, Priorisierung und Qualität. Wer diese Verschiebung offen benennt, statt sie zu verschweigen, bekommt eher Mitwirkung als Widerstand.

Genauso wichtig ist, früh sichtbar zu machen, wessen Verantwortung sich durch die Umstellung nicht ändert: Wer für ein Produkt endverantwortlich ist, bleibt es. Die Unsicherheit entsteht meist dort, wo diese Frage offenbleibt, nicht dort, wo sie klar beantwortet ist.

Der belastbare Weg ist gestuft: ein Pilot mit einem Team und einem klar abgegrenzten Workflow, Qualitätsschwellen, die vor der Skalierung feststehen, eine gemessene Baseline vor und nach der Umstellung, und eine strukturierte Befähigung der übrigen Organisation, sobald der Pilot belastbare Ergebnisse zeigt. Ohne diese Reihenfolge wird aus einer vielversprechenden Toolchain schnell ein weiteres Werkzeug, das im Alltag verpufft.

Die Befähigung der übrigen Organisation ist dabei kein einmaliger Workshop. Ein Team lernt die neuen Leitplanken am schnellsten an echten Aufgaben, mit erfahrenen Kolleginnen und Kollegen aus dem Pilotteam als Multiplikatoren – nicht an synthetischen Übungsbeispielen, die mit der eigenen Codebasis wenig zu tun haben.