Agenten in einer bestehenden Codebasis einsetzen

Wie führt ihr KI-Agenten in einer bestehenden Codebasis ein?

Ihr führt KI-Agenten in einer bestehenden Codebasis ein, indem ihr ihnen Architektur, Standards und Tickets als Kontextdateien im Repository gebt und sie an echten Sprint-Tickets prüft. Ohne diesen Kontext sehen Agenten nur Dateien. Das gilt besonders für ein Legacy-Projekt, dessen gewachsene Regeln nirgends aufgeschrieben sind.

Die Einführung folgt vier Schritten:

• Kontext schreiben: Architektur, Standards und Grenzen als Dateien im Repository.
• Agenten einrichten: direkt in eurer Codebasis.
• An echten Tickets schärfen: Aufgaben aus dem laufenden Sprint.
• Kontrolle festlegen: Jede Ausgabe geht durch Quality Gates und euer Review.

Warum KI-Agenten in bestehenden Codebasen oft enttäuschen

KI-Agenten enttäuschen in einer bestehenden Codebasis meist, weil ihnen der Projektkontext fehlt, nicht weil das Modell zu schwach ist. Ein Agent sieht beim ersten Start nur Dateien. Warum eure Module so geschnitten sind, welche Regeln im Team gelten und wie ein Ticket bei euch aussieht, weiß er nicht.

Das Ergebnis ist Code, der kompiliert, aber nicht zu eurem Projekt passt. Typisch sind eine Hilfsfunktion, die es längst gibt, ein neues Muster neben dem etablierten oder Tests in einem fremden Stil. Im Review fällt das auf, und die Arbeit landet wieder bei euren Entwicklern.

Ein häufiger Satz lautet: „Wir haben KI probiert, funktioniert bei uns nicht.“ Meist kannte der Agent das Projekt nicht. Es fehlten Kontextdateien und die Anbindung an Ticketsystem und Pipeline. Genau das lässt sich einrichten.

Was ein Agent über eure Codebasis wissen muss

Ein Agent braucht dasselbe Wissen, das ein neuer Kollege in seinen ersten Wochen sammelt, nur schriftlich und bei jeder Aufgabe abrufbar. In einer gewachsenen Codebasis steckt viel davon in Köpfen und alten Review-Kommentaren. Genau dieses Wissen schreiben wir gemeinsam mit eurem Team in Kontextdateien, die im Repository neben dem Code liegen.

• Architektur: Schichten, Modulgrenzen und welche Teile voneinander abhängen dürfen.
• Standards: Namenskonventionen, Fehlerbehandlung, Teststil und wiederkehrende Review-Anmerkungen.
• Befehle: wie gebaut, getestet und geprüft wird, damit der Agent seine eigene Arbeit kontrollieren kann.
• Grenzen: welche Dateien tabu sind und welcher Code nach dem Zonenmodell überhaupt an ein Modell darf.
• Ablauf: wie ein Ticket geplant, umgesetzt und durch die Quality Gates geführt wird.

In der Praxis entsteht dafür ein eigener Ordner im Repository, etwa mit einer Anleitung für den Planner und den Regeln für die Quality Gates. Damit kennen die Agenten eure Architektur, statt sie bei jeder Aufgabe neu zu erraten. Weil die Dateien mit Git versioniert sind, laufen Änderungen daran durch dasselbe Review wie euer Code.

Gerade in einem Legacy-Projekt zahlt sich das aus. Dort steht oft ein alter Weg noch in vielen Dateien, während das Team längst einen neuen vorzieht. Ohne Kontextdatei übernimmt ein Agent, was er im Code vorfindet. Mit ihr weiß er, welchem Weg er folgen soll.

Wir setzen dafür KI-Agenten wie Codex und Claude ein. So liegen eure Regeln bei jeder Aufgabe vor, egal welcher Entwickler den Agenten steuert.

So richten wir Agenten in einer bestehenden Codebasis ein

Wir richten die Agenten in der ersten Programmwoche direkt in eurer Codebasis ein, in fester Reihenfolge. Vorher lesen wir in einer Bestandsaufnahme Codebasis, Sprint-Tickets und Pipeline. Dafür genügt Lesezugriff, verändert wird dabei nichts.

Zu Beginn stufen wir außerdem jeden Entwickler ein, von L0 (arbeitet ohne KI) bis L4 (Automatisierungen laufen dauerhaft mit). So hat jeder seinen eigenen Startpunkt.

So gehen wir mit den Daten um: Einzelergebnisse sind die Einstufung je Entwickler, die Abschlussprüfung und der belegte Titel Product Engineer. Jeder Entwickler erfährt seine Ergebnisse zuerst. Berichtet wird als Teamdurchschnitt, nie für Personalentscheidungen. Die Einbindung eures Betriebsrats liegt bei euch.

Danach läuft die erste Woche im Team-Programm so ab:

• Montag: Programm-Kickoff mit Zielen, Kriterien und einem tagesgenauen Plan.
• Dienstag: Arbeitsplätze einrichten, direkt in eurer Codebasis und mit euren Standards.
• Mittwoch: Zonenmodell festlegen, also welcher Code an ein Modell darf.
• Donnerstag: erste Tickets mit Planner und Umsetzer an echten Aufgaben.
• Freitag: erstes Ticket komplett durch die Pipeline, Ampel-Report an die Geschäftsführung.

Für diese erste Woche gilt eine klare Abbruchregel. Passt es in eurer Codebasis nicht, sagen wir es in dieser Woche und nicht erst am Ende.

Warum der Agent an echten Sprint-Tickets lernt

Der Kontext wird an echten Sprint-Tickets geschärft, weil erst dort sichtbar wird, was in den Kontextdateien noch fehlt. Ein Übungsprojekt hat keine Altlasten, Sonderfälle oder über Jahre gewachsenen Konventionen. Eure Codebasis hat sie alle, und genau dort muss der Agent verlässlich arbeiten.

Deshalb arbeiten wir in Live-Sessions an Aufgaben aus dem laufenden Sprint, etwa einem CSV-Export für Rechnungen. Euer Entwickler und wir sitzen am selben Ticket. Der Planner zerlegt es, der Umsetzer schreibt den Code, und jede Abweichung von euren Standards wird zu einer Ergänzung in den Kontextdateien.

Dabei lernt euer Team, Aufgaben so zu schneiden, dass Agenten sie verlässlich abarbeiten. Eine häufige Frage lautet: „Wie schneide ich das Ticket, damit der Agent es sauber abarbeitet?“ Die Antwort zeigen wir direkt am Ticket, etwa in drei Teilen: Datenmodell, Export, Tests.

Der Aufwand ist planbar: im Team-Programm 6–8 Stunden Freistellung pro Entwickler und Woche. Trainiert wird an Tickets, die ohnehin anstehen. Die Arbeit hättet ihr also sowieso gemacht.

Wie die Kontrolle über den Code bei eurem Team bleibt

Die Kontrolle bleibt bei eurem Team, weil jede Ausgabe im Review landet. Jede Aufgabe läuft durch die Pipeline aus Planner, Umsetzer, zwei Quality Gates und eurem Review.

Das Review macht der Product Engineer, also euer Entwickler, der die Agenten orchestriert und jede Ausgabe prüft. Gute Kontextdateien helfen dabei, weil der Agent eure Regeln schon beim Schreiben befolgt. Ersetzen können sie das Review nicht.

Das Zonenmodell legt fest, welcher Code an ein Modell darf, alles andere geht nicht an ein Modell. Gearbeitet wird über eure eigenen Firmenzugänge.

Wir wählen diese Zugänge so aus und richten sie so ein, dass der Anbieter laut seinen Vertragsbedingungen euren Code nicht für Training verwendet und Anfragen nicht aufbewahrt (Zero-Retention). Die Bedingungen des Anbieters liegen euch vor, weil die Lizenzen bei euch laufen.

Auch nach der Einführung bleibt die Kontrolle bei euch, denn den Kontext pflegen zwei interne Owner aus eurem Team. Eine Codebasis verändert sich mit jedem Sprint, und Kontextdateien ohne Pflege veralten wie jede Dokumentation. Deshalb übergeben wir die Zuständigkeit schriftlich:

• Owner 1 verantwortet Pipelines und Templates, abgestimmt auf eure Codebasis.
• Owner 2 verantwortet die Automatisierungen, die dauerhaft mitlaufen.
• Beide arbeiten als Product Engineer und bekommen fertige Unterlagen fürs Team.

Euer Team-Lead kann danach ebenfalls Tickets so schneiden, dass Agenten sie verlässlich abarbeiten. Eine einfache Regel hilft beim Pflegen: Taucht dieselbe Anmerkung im Review mehrmals auf, gehört sie in die Kontextdateien.

Im Team- und Multiplikatoren-Programm bleiben die Werkzeuge bei euch, nichts wird abgeschaltet. Templates, Dashboard und Evaluationstool laufen weiter, und das Evaluationstool misst, wie eure Pipelines arbeiten. Die Arbeitsweise bleibt, wenn wir gehen.

Wie ihr prüft, ob das in eurer Codebasis funktioniert

Ob Agenten in eurer Codebasis tragen, zeigt die kostenlose Analysewoche, bevor ihr irgendetwas entscheidet. Die Woche ist ideal für Teams mit 3–15 Entwicklern, eigener Codebasis und Git im Einsatz. Lesezugriff genügt, nichts wird verändert.

NDA und AVV sind vorab unterschrieben. Beide regeln das Verhältnis zu uns, der Vertrag mit dem KI-Anbieter läuft über eure eigenen Firmenzugänge.

• Kickoff: 60 Minuten mit Geschäftsführung und Tech Lead.
• Bestandsaufnahme: Codebasis, Tickets und Pipeline.
• Ergebnisdokument mit Einstufung je Entwickler und Potenzialrechnung in Stellen und Euro, das euch in jedem Fall gehört.

Die Entscheidung liegt dann bei euch, ohne Pitch und ohne Preis-Gespräch. Zur Vorbereitung reicht es, Team und Tech-Stack zu notieren: Zahl der Entwickler, Sprachen, Frameworks und eure Arbeit mit Git. Danach wisst ihr schwarz auf weiß, was in eurer Codebasis möglich ist und was in eurem Team steckt.