Agentic Engineering: Wie wir mit KI-Agenten entwickeln und die Kontrolle behalten

Bei uns schreiben KI-Agenten den Code, die Tests und die Dokumentation. Menschen entscheiden, was gebaut wird, ob es passt und wann es live geht. Das klingt nach weniger Kontrolle. Tatsächlich prüfen wir heute mehr als früher, weil die Agenten auch die Fleißarbeit übernehmen, die in klassischen Projekten oft liegen bleibt: Tests schreiben, Belege sammeln, Dokumentation nachziehen. Was hinter dem Begriff steckt, beschreibt unser Artikel Was ist Agentic Development?. Hier geht es darum, wie wir konkret arbeiten und woran Sie sehen, dass es funktioniert.

Kurz gesagt

• KI-Agenten schreiben bei uns Code, Tests und Dokumentation. Was gebaut wird, ob es passt und wann es live geht, entscheiden Menschen.
• Jedes Ticket bekommt vor dem Bau einen schriftlichen Bauauftrag mit Szenarien und Tests. Gebaut wird es von einem frischen Agenten, geprüft von einem Agenten eines anderen Anbieters.
• Jede Änderung durchläuft zwei automatische Prüfstufen, bevor sie auf die Testumgebung kommt.
• Sie nehmen auf der Testumgebung ab, je Ticket mit einer kurzen Testanweisung in Alltagssprache. Was nicht passt, geht mit einem Satz zurück.
• Für Entwicklung, Tests und Abnahme arbeiten die Agenten mit Code und Beispieldaten, nicht mit den Daten Ihrer Kunden.
• Im Kumpel OS sehen Sie jederzeit, was gebaut wird, was auf der Testumgebung liegt und was auf Ihre Abnahme wartet.

Wer macht was

Agentic Engineering heißt nicht, dass eine KI unbeaufsichtigt Code produziert. Es heißt, die Arbeit so aufzuteilen, dass jede Rolle das tut, was sie gut kann, und dass niemand seine eigene Arbeit abnimmt:

• Mensch: legt fest, was gebaut wird, entscheidet Architektur- und Produktfragen, nimmt ab und gibt die Produktion frei.
• Planer: Ein KI-Agent zerlegt den Auftrag in Tickets, bündelt sie zu Releases und schreibt für jedes Ticket einen Plan und einen Bauauftrag.
• Entwickler: Für jedes Ticket startet ein frischer Agent in einer eigenen Arbeitskopie des Codes. Er kennt nur seinen Auftrag, nicht die Vorgeschichte, und arbeitet an genau einem Ticket.
• Prüfer: Ein Agent eines anderen Anbieters liest die Änderung gegen den Auftrag. Baut ein Modell von Anthropic, prüft eines von OpenAI, und umgekehrt. Ist der Prüfer vom selben Anbieter wie der Entwickler, verweigert unser Werkzeug den Lauf.

Der frische Agent je Ticket ist Absicht. Er bringt keine Annahmen aus früheren Aufgaben mit, und alles, was er weiß, steht im Auftrag. Damit ist nachvollziehbar, warum etwas so gebaut wurde.

Kommt ein Agent nicht weiter, fragt er, statt zu raten. Die Frage landet im Kumpel OS, mit Antwortmöglichkeiten, ihren Folgen und einem eigenen Vorschlag. Die Arbeit an anderen Tickets geht weiter, bis die Antwort da ist.

Vom Ticket zum Bauauftrag

Ein Ticket beschreibt, was sich ändern soll, und enthält eine Testanweisung für die Abnahme. Bevor gebaut wird, wird daraus ein Bauauftrag:

• Szenarien: Für jedes Kriterium ein Ablauf nach dem Muster „Gegeben ..., wenn ..., dann ...“.
• Tests: Zu jedem Szenario gehört ein automatischer Test. Der Auftrag hält fest, warum dieser Test vor der Änderung fehlschlägt. Ein Test, der schon vorher besteht, prüft nichts.
• Gefährdete Stellen: Bestehende Tests, die von der Änderung betroffen sein können, sind benannt und laufen mit.
• Dateien: Der Auftrag nennt die Dateien, die die Änderung berühren darf. Alles andere bleibt außen vor.

Offene Fragen klären wir, bevor gebaut wird, gebündelt für das ganze Release und nicht mittendrin. So wartet niemand auf eine Antwort, während ein halb fertiger Stand herumliegt.

Prüfen statt glauben

Ein Agent meldet gern, er sei fertig. Darauf verlassen wir uns nicht:

• Tests laufen unabhängig: Nach dem Bau führt unser Werkzeug die im Auftrag genannten Tests selbst aus. Schlägt einer fehl, bekommt ein neuer Agent die Fehlermeldung und bessert nach.
• Zweiter Anbieter: Erst wenn alle Tests bestehen, prüft der Agent des anderen Anbieters die Änderung gegen Auftrag und Szenarien. Ohne sein „bestanden“ geht nichts weiter.
• Beleg statt Haken: Ein Ticket gilt erst als erledigt, wenn am Ticket steht, welcher Test welches Szenario belegt und mit welchem Ergebnis.
• Nicht gelaufen heißt nicht bestanden: Eine Prüfung, die nicht gelaufen ist oder nicht laufen konnte, zählt nie als bestanden.

Zwei Prüfstufen vor der Testumgebung

Jede Änderung kommt als Änderungsvorschlag (Pull Request) in den Code. Dort startet automatisch die erste Stufe unserer Prüfstrecke (CI-Pipeline): Der Code wird gebaut und auf Fehler geprüft, eine Sicherheitsprüfung läuft, und die schnellen Tests laufen durch. Diese Stufe ist bewusst kurz gehalten, damit jede Nachbesserung schnell wieder geprüft ist.

Die zweite Stufe läuft einmal je Release, bevor es auf die Testumgebung geht. Dazu gehören Tests gegen eine echte Datenbank und Tests im Browser, die sich durch die Anwendung klicken wie ein Mensch. Schlägt einer davon fehl, hält die Auslieferung an. Auf die Testumgebung kommt nur, was beide Stufen bestanden hat.

Die aufwendigen Tests laufen damit nicht bei jeder kleinen Nachbesserung, sondern genau auf dem Stand, der ausgeliefert wird.

Releases und Testumgebung

Mehrere Tickets bilden ein Release, das gemeinsam ausgeliefert wird. Im Kumpel OS sehen Sie jederzeit, wo ein Release steht: geplant, in Arbeit, bereit, auf der Testumgebung, abgenommen, ausgeliefert.

Ist ein Release fertig und hat es beide Prüfstufen bestanden, kommt es automatisch auf die Testumgebung (Staging). Das ist eine eigene Installation Ihrer Anwendung, getrennt von der Produktion. Danach prüfen wir, ob die neue Fassung dort wirklich läuft, und verlassen uns nicht nur auf eine grüne Pipeline. Steht das Release bereit, bekommen Sie eine Nachricht im Projektchat.

Abnahme in Alltagssprache

Abgenommen wird je Ticket, auf der Testumgebung. Zu jedem Ticket gibt es eine kurze Testanweisung, die ohne Fachwissen verständlich ist: was Sie öffnen, was Sie tun und was Sie dann sehen sollten. Dateinamen und Fachbegriffe haben darin nichts zu suchen.

Passt etwas nicht, weisen Sie das Ticket zurück und schreiben in einem Satz, was fehlt. Der Satz geht mit dem Ticket zurück in die Entwicklung. Bevor nachgebessert wird, schreibt der Agent ans Ticket, wie er Ihren Hinweis verstanden hat.

Zu Releases mit sichtbaren Änderungen nehmen wir ein kurzes Video auf der Testumgebung auf, mit Beispieldaten. Es zeigt, was sich geändert hat, und liegt direkt am Release. Die Aufnahme ist für uns zugleich ein letzter Funktionstest: Wer eine Funktion vorführt, merkt schnell, wo sie noch hakt.

Produktion: ein bewusster Schritt

Von der Testumgebung in die Produktion geht es nicht automatisch. Den Schritt löst ein Mensch aus, nachdem abgenommen wurde. Vorher halten wir fest, welcher Stand gerade läuft. Geht etwas schief, kehren wir zu genau diesem Stand zurück. Nach dem Ausrollen prüfen wir, ob die neue Fassung wirklich läuft, und behalten Fehler und Alarme im Blick. Wie wir das im Betrieb tun, steht in Betrieb und Monitoring.

Updates und Sicherheits-Patches

Jede Anwendung baut auf fremden Bausteinen auf, und die bekommen laufend Updates. Dependabot schlägt sie jede Woche als Änderungsvorschläge vor, kleine Updates gebündelt, große Versionssprünge getrennt. Für sie gelten dieselben Prüfstufen wie für jede andere Änderung. Große Versionssprünge lesen wir, bevor wir sie übernehmen. Automatisch eingespielt werden sie nie.

Für Sicherheits-Patches gibt es einen festen, schnelleren Weg, wenn Sie ihn für Ihr Projekt freigeben:

• Eng begrenzt: nur kleine Versionssprünge, nie Änderungen an Datenbank, Anmeldung oder Bezahlung.
• Gleich geprüft: Prüfer eines anderen Anbieters, beide Prüfstufen, Tests im Browser auf der Testumgebung.
• Abgesichert: Nach dem Ausrollen in die Produktion wird automatisch geprüft, ob die Anwendung läuft. Ist sie auffällig, wird automatisch auf den vorherigen Stand zurückgerollt.
• Zu Bürozeiten: nur montags bis donnerstags tagsüber, wenn jemand da ist.

Alles, was nicht in diese Klasse passt, geht den normalen Weg mit Ihrer Abnahme.

Datenschutz: Was die KI zu sehen bekommt

Für Entwicklung, Tests und Abnahme brauchen die Agenten keine Daten Ihrer Kunden. Sie arbeiten mit Code, Tests und Beispieldaten, und so richten wir die Arbeit auch ein:

• Eigene Testdaten: Automatische Tests laufen gegen eine eigene Testdatenbank mit Beispieldaten, nicht gegen Ihre Produktion.
• Keine Zugänge zur Produktion: Testläufe bekommen keine Zugangsdaten für Ihre Produktion.
• Bilder und Videos nur mit Beispieldaten: Abnahme-Videos und Bilder entstehen auf der Testumgebung, nie auf der Produktion.
• Hosting in Deutschland: Betreiben wir Ihre Anwendung, liegt sie mit ihren Daten auf unserer eigenen Plattform in einem Rechenzentrum in Nürnberg.

Die Sprachmodelle, mit denen die Agenten arbeiten, stammen von Anthropic und OpenAI, beide aus den USA. Was die Agenten bei der Arbeit lesen, also Code, Tickets, Nachrichten im Projekt und Testergebnisse, wird dort verarbeitet. Welche Modelle und Anbieter in Ihrem Projekt arbeiten, legen wir offen. Bei besonderen Anforderungen sprechen wir vor Projektbeginn darüber.

Leitplanken für die Agenten

Agenten arbeiten auf einem Entwicklerrechner mit weitreichenden Rechten. Deshalb gelten feste Sperren, die bestimmte Schritte gar nicht erst zulassen:

• Zugangsdaten: Vor jedem Commit wird die Änderung auf Passwörter und Schlüssel durchsucht. Dateien mit Zugangsdaten dürfen Agenten nicht ausgeben.
• Gefährliche Befehle: Ausgewählte riskante Befehle sind gesperrt, etwa das Überschreiben der Versionsgeschichte oder das Löschen geschützter Zweige im Code.
• Wirkung nach außen: Alles, was nach außen wirkt, etwa eine Nachricht verschicken, braucht eine Rückfrage. Nachrichten an Kunden schreiben Agenten nur als Entwurf.

Diese Sperren sind eine zusätzliche Sicherung, keine vollständige Absperrung. Deshalb verlassen wir uns nicht auf sie allein: Prüfer, Pipeline, geschützte Zweige im Code-Repository und Ihre Abnahme sind eigene Grenzen, die unabhängig davon greifen.

Kumpel OS: alles an einem Ort

Kumpel OS ist unsere eigene Projektplattform. Dort laufen Tickets, Releases, Abnahme und Projektchat zusammen, für unser Team, für die Agenten und für Sie:

• Tickets: Jedes Ticket hat einen Typ, etwa neue Funktion, Fehler oder Verbesserung, und einen fachlichen Bereich. Jeder Änderungsvorschlag hängt automatisch am passenden Ticket.
• Releases: Phase, Auslieferungsschritte und Abnahme-Video auf einen Blick. Hält eine Auslieferung an, sehen Sie es dort.
• Abnahme: Ihre Testliste, gruppiert nach Release, mit Testanweisung und Video.
• Rückfragen: Fragen der Agenten mit Antwortmöglichkeiten und Vorschlag, an einer Stelle gesammelt.
• Chat: die Nachricht, dass ein Release zum Testen bereitsteht, und der direkte Draht zu uns.

Sie sehen die Tickets, Releases und die Abnahme Ihres Projekts. Rein technische Aufgaben, die Sie nicht abnehmen müssen, blenden wir für Sie aus. Die Bilder in diesem Artikel zeigen die nächste Fassung der Oberfläche mit Beispieldaten einer erfundenen Bäckerei.

Fragen, die Sie Ihrem Dienstleister stellen können

Wenn Ihr Dienstleister mit KI entwickelt, helfen diese Fragen:

• Wer prüft den Code, den eine KI geschrieben hat, und woran sehen wir, dass er geprüft wurde?
• Welche Tests laufen, bevor eine Änderung auf die Testumgebung kommt, und was passiert, wenn einer fehlschlägt?
• Wie nehmen wir eine Änderung ab, ohne selbst Entwickler zu sein?
• Welche Daten bekommen die KI-Modelle zu sehen, und bei welchem Anbieter laufen sie?
• Wie kommen Sicherheits-Updates in unsere Anwendung, und wie geht es zurück, wenn eine Auslieferung schiefgeht?

Fazit

KI-Agenten machen Software nicht von selbst besser. Besser wird sie durch den Ablauf drumherum: klare Bauaufträge, Tests, die vorher fehlschlagen, ein Prüfer, der nicht der Autor ist, eine Testumgebung und eine Abnahme, die Sie ohne Fachwissen machen können. Die Agenten sorgen dafür, dass dieser Ablauf auch im Alltag durchgehalten wird, weil sie die Fleißarbeit übernehmen.

Wie wir Ihre Anwendung nach dem Go-live überwachen, lesen Sie unter Betrieb und Monitoring. Auf welchen Bausteinen unsere Anwendungen aufbauen, zeigt unsere Referenzarchitektur für den Mittelstand. Sie möchten sehen, wie das in Ihrem Projekt aussehen würde? Sprechen Sie uns an.

Werkzeuge

• Claude Code: KI-Agent von Anthropic
• Codex: KI-Agent von OpenAI
• GitHub Actions: automatische Prüfstufen
• Playwright: Tests im Browser
• Dependabot: Vorschläge für Updates
• Gitleaks: Suche nach Zugangsdaten im Code
• Trivy: Prüfung auf bekannte Schwachstellen
• Argo CD: Auslieferung auf unsere Plattform
• Kumpel OS: Tickets, Releases, Abnahme und Projektchat, selbst entwickelt