TL;DR

Software-Entwicklung ist ein komplexer und oftmals teurer Prozess. Daher war die Frage, wie der Ablauf unter Nutzung von AI verbessert werden kann. Das Ergebnis wird detailliert in den nächsten Abschnitten beschrieben, hier zu Beginn aber schon die erreichten Zahlen. Verglichen werden jeweils die Durchschnittswerte aus folgenden drei Szenarien:

  1. Letzte drei Sprints (1 Sprint = 2 Wochen Entwicklungsarbeit) vor der Freigabe von AI-Tools für die Software-Entwicklung (= klassischer Softwareentwicklungsprozess)
  2. Letzte drei Sprints vor Start der Implementierung des neuen, AI-unterstützten Prozesses (= klassischer Softwareentwicklungsprozess mit Unterstützung der Entwickler durch AI-Tools, aber ohne Integration in den Prozess)
  3. Erste drei Sprints nach vollständiger Implementierung des hier beschriebenen Prozesses (= neuer Entwicklungsprozess mit Integration der AI-Tools in den Prozess)

Die Werte in folgender Tabelle beziehen sich jeweils auf den Referenzzustand 1 — also auf den Entwicklungsprozess, wie er in vielen Firmen nach wie vor gelebt wird. Szenario 1 entspricht damit bei jedem KPI 100 %: Werte über 100 % bedeuten eine Steigerung gegenüber dem Referenzzustand, Werte unter 100 % eine Verringerung.

KPI (Szenario 1 = 100 %) Szenario 2 Szenario 3
Umgesetzte Story Points je Sprint 184 % 434 %
Anzahl neuer Bugs je Sprint 104 % 35 %
Durchschnittliche Behebungszeit je Bug 90 % 20 %

Die Ergebnisse sind beeindruckend. Allein das Freigeben und Nutzen von Coding-Agents durch die Entwickler hat die Produktivität stark gesteigert. Sobald man den Prozess darüber hinaus strukturiert aufsetzt, vereinheitlicht und optimiert, erreicht man einen weiteren, noch größeren Sprung.

Der Startpunkt

Das vorhandene Setup: GitHub als Plattform — Repository, Pull Requests, Reviews, CI — und der Atlassian-Stack mit Jira für Tickets und Confluence für Dokumentation. Ein durchaus gängiges Tool-Set, das so oder in ähnlicher Form von vielen Teams verwendet wird.

Daraus folgt die erste Entwurfsentscheidung: der Prozess dockt an diese Landschaft an, statt sie zu ersetzen. Tickets bleiben in Jira, Dokumentation bleibt in Confluence, das Code-Review bleibt ein Pull Request. Keine neuen Tools — was sich ändert, ist, wer in diesen Werkzeugen die Arbeit macht.

Repo-Vorbereitung — einmalig

Der Code sagt, was ist. Specs sagen, was sein soll. Dieser Unterschied ist für einen Menschen eine Feinheit und für einen Agenten die entscheidende Größe: ein Agent, der seine Anforderungen aus der Implementierung ableitet, erklärt jeden Bug zur Anforderung und jeden historischen Workaround zur Architekturentscheidung. Er reproduziert den Ist-Zustand sehr zuverlässig, auch dort, wo der Ist-Zustand falsch ist.

Die einmalige Vorbereitung besteht deshalb darin, die existierende Code-Base mit Hilfe der vorhandenen Dokumentation und menschlichem Review in Specs zu übersetzen — so, dass der gewünschte Zustand jederzeit aus den Spec-Files ermittelt werden kann, und nicht aus dem Gedächtnis derer, die lange genug dabei sind.

Fachliche und technische Specs

Die Übersetzung hat zwei Hälften, und beide sind nötig.

Fachlich — das Domänenwissen: welchen Regeln eine Berechnung folgt, welche Zustände ein Vorgang annehmen kann, welche Fälle es gibt und welche bewusst ausgeschlossen sind. Ein großer Teil davon steht nirgends, weil er in Köpfen, Tickets und Besprechungen liegt. Genau dieser Teil entscheidet später, ob ein Agent eine Anforderung erfüllt oder nur Code schreibt, der kompiliert.

Technisch — Code-Style, Architekturentscheidungen, Schichtgrenzen, Fehlerbehandlung, welche Bibliothek für welchen Zweck die gesetzte ist und welche Muster absichtlich nicht verwendet werden. Für einen Menschen sind das Konventionen, die man mit der Zeit aufnimmt. Für einen Agenten sind es Akzeptanzkriterien: sie sind der Grund, warum sein Ergebnis aussieht wie der Rest des Repositories und nicht wie generischer Beispielcode.

Zweite Quelle neben dem Code ist die existierende Confluence-Dokumentation. Sie wird ausgewertet, nicht übernommen. Gewachsene Dokumentation trägt meistens drei Sorten Inhalt zugleich: geltende fachliche Regeln, überholte Entscheidungen, und Pläne, die nie umgesetzt wurden. Jede Aussage wird deshalb gegen den Code gestellt. Was sich bestätigt, wird Spec. Was sich widerspricht, wird eine Frage an das Produktmanagement oder ein Ticket. Was überholt ist, wird als verworfen vermerkt, damit es nicht beim nächsten Durchgang erneut als Anforderung auftaucht.

Der zweite Teil der Vorbereitung sind .md-Dateien zur Code-Navigation. Ein Agent, der nicht weiß, wo etwas liegt, sucht — und Suchen ist die teuerste Art, es herauszufinden. Eine Navigationsschicht beantwortet je Verzeichnis oder Modul vier Fragen vorab: was liegt hier, was ist der Einstiegspunkt, wovon hängt es ab, wo liegen die Tests. Damit wird aus Suchen ein Nachschlagen.

Das zahlt sich zweimal aus. Einmal an den Kosten, weil jeder Durchlauf weniger Tokens braucht. Und einmal an der Qualität, weil ein Agent mit engem, passendem Kontext genauer arbeitet als einer, der sich durch halbe Verzeichnisbäume gelesen hat und dessen Kontextfenster am Ende mehr Nebensachen enthält als Aufgabe.

Das Ergebnis dieser Phase ist ein Repository, das ein Agent selbstständig und effizient bearbeiten kann, ohne in Kontextprobleme zu laufen. Dieser Schritt erfordert am Anfang einmalig einen gewissen Aufwand und läuft anschließend als Teil der normalen, täglichen Arbeit kontinuierlich weiter.

Ticket-Review — laufend

Der laufende Prozess beginnt mit einer Sortierung durch einen Agenten. Für jedes Ticket sind zwei Fragen zu beantworten: Ist es fertig für die Umsetzung, also Problem oder Feature genau genug beschrieben? Und wenn ja, kann die Umsetzung automatisiert durch einen Agenten erfolgen, braucht sie menschliche Begleitung, oder sollte sie komplett von einem Menschen erledigt werden?

Woher die Tickets kommen, bleibt dabei unverändert: Bugs entstehen wie bisher aus Usermeldungen über den Support oder aus manuellen und automatisierten Tests, Features aus Planning-Sessions zwischen Produktmanagement und Entwicklern. Das ist Absicht. Der Prozess setzt nach der Ticketentstehung an, damit er anfangen kann zu laufen, ohne dass die Organisation vorher umgebaut werden muss.

Bei Bugs:

  • Analyse im Code. Oft kann das Problem direkt gefunden werden: das beschriebene Symptom und die infrage kommenden Stellen reichen aus, um die Ursache zu benennen. Ein Agent liest die beteiligten Dateien im Zusammenhang und hat damit nicht nur einen Verdacht, sondern bereits eine Analyse, die zur Behebung ausreicht.
  • Nachstellen im Browser. Bleibt die Analyse unklar, muss der Fall nachgestellt werden. Ein Agent tut das bei Webanwendungen zum Beispiel direkt im Browser.

Ein Bug, der sich weder im Code zeigt noch im Browser nachstellen lässt, ist nicht umsetzungsreif. Er geht zurück zur menschlichen Bearbeitung, und zwar mit der konkreten Frage, die fehlt.

Bei neuen Features:

  • Fachliche Lücken. Widerspricht das Ticket bestehenden Specs? Bleibt ein Fall offen, den es nicht erwähnt? Alles, was für einen Menschen „selbstverständlich“ mitgedacht ist, ist hier eine Lücke, die vor der Umsetzung geklärt werden muss.
  • Technische Probleme. Ist die Anforderung im aktuellen Tech-Stack überhaupt umsetzbar, oder braucht sie größere Anpassungen — eine neue Bibliothek, eine Schemaänderung, eine Schnittstelle, die es noch nicht gibt?

Gelöst wird das Ticket in diesem Schritt nicht. Die Aufgabe des Reviews ist Sortieren, nicht Entscheiden. Das Ergebnis sind Labels am Ticket:

Label Was es bedeutet, und was als Nächstes passiert
agent-ready Beschreibung vollständig, keine offenen fachlichen oder technischen Fragen. Geht in die Umsetzungsplanung.
agent-assisted Umsetzbar, aber mit Entscheidungen, die eine Freigabe brauchen. Geht ebenfalls in die Planung — mit Checkpoints an genau diesen Stellen.
human-only Der Aufwand liegt im Urteil, nicht im Code. Geht in die normale Entwicklung mit Agenten-Unterstützung.
needs-info Bug nicht nachstellbar, Anforderung widersprüchlich oder unvollständig. Geht zurück an den Support oder das Produktmanagement — mit der konkreten Frage.

Daraus entstehen zwei Listen: eine mit Tickets, die die nachfolgenden Prozesse abarbeiten können, und eine mit Tickets, die Informationen brauchen. Die zweite Liste ist dabei nicht negativ zu sehen. Sie existiert in jedem Projekt, nur normalerweise unsichtbar — verteilt auf Tickets, die in Arbeit gehen und dort liegen bleiben, weil die entscheidenden Fragen erst beim Implementieren auffallen.

Ticket-Umsetzungsplanung

Für die freigegebenen Tickets plant ein Agent die Umsetzung. Bei einem Bug ist dieser Plan kurz: Ursache, betroffene Stelle, der Test, der den Fehler zeigt. Bei einem Feature ist die Planung meistens aufwändiger — Schrittfolge, betroffene Module, die Specs, die erweitert werden müssen.

Features, die nicht in einem Zug umsetzbar sind, werden unterteilt. Vor allem die Teile, die menschliches Feedback brauchen, werden als eigene Sub-Tickets herausgeschnitten: Architekturentscheidungen in erster Linie. Das ist kein Formalismus, sondern der Grund, warum der Rest autonom laufen kann — eine offene Architekturfrage soll nicht vier umsetzbare Sub-Tickets blockieren.

Ergebnis der Planung sind Tickets, die komplett autonom umgesetzt werden können, und Tickets, die menschlichen Support brauchen. Beides jetzt in der Granularität von Sub-Tickets statt ganzer Features — die Grenze zwischen „Agent“ und „Mensch“ verläuft mitten durch ein Feature, nicht zwischen Features.

Coding, Variante A — der Agent allein

Für ein Ticket mit vollständigem Plan läuft die Umsetzung ohne Begleitung. Die Schritte, in dieser Reihenfolge:

  1. Specs erweitern, sofern notwendig. Jedes Ticket, das neues Verhalten bringt, bringt eine Spec-Änderung mit sich, um die Spec-Files aktuell zu halten.
  2. Test-Hüllen aus den Specs aufsetzen. Noch vor der Implementierung entstehen die Tests, die der zu schreibende Code erfüllen muss (Test-Driven Development) — bei Features aus den Specs, bei Bugs als der Test, der heute fehlschlägt und das erneute Auftreten zukünftig verhindert. Je nach Setup und Art der Aufgabe sind das Unit-Tests, automatisierte E2E-Tests oder in Einzelfällen auch manuelle Tests. Die Reihenfolge trägt die ganze Konstruktion: ein Test, der nach dem Code entsteht, prüft unter Umständen den Code. Ein Test, der aus der Spec entsteht, prüft die Anforderung.
  3. Implementierung des Codes — durch einen eigenen Agenten.
  4. Implementierung der Tests — durch einen eigenen Agenten. Die Trennung ist wichtig: ein Agent, der Code und Tests im selben Kontext schreibt, schreibt Tests, die seine eigene Implementierung bestätigen, statt sie zu prüfen.
  5. Review-Agent für die Tests. Seine Frage ist nicht, ob der Test grün ist, sondern ob der implementierte Test tatsächlich abdeckt, was die Specs fordern.
  6. Review-Agent für den Code. Untersucht, ob der neue Code den Specs (sowohl fachlich als auch technisch) entspricht.

Die Review-Agenten geben ihre Beanstandungen jeweils an den implementierenden Agenten zurück. Hier werden mehrere Runden gedreht, bis es keine Beanstandungen mehr gibt.

Die Abbruchbedingung

Eine Schleife ohne Grenze ist die typische Betriebsart, in der so ein Aufbau scheitert: zwei Agenten können sich sehr lange höflich gegenseitig korrigieren. Deshalb hat die Schleife eine konfigurierte Anzahl Runden.

Wird sie erreicht, ohne dass die Beanstandungen aufhören, wird der Vorgang abgebrochen — aber nicht stillschweigend. Der jeweilige Code-Stand wird nach GitHub gepusht, die offenen Punkte werden dokumentiert: welche Beanstandung offen blieb, in welcher Runde, was versucht wurde. Dann geht das Ticket mit genau diesem Stand an einen Menschen.

Ein Branch samt Testlage und einer Liste konkreter Beanstandungen ist ein deutlich besserer Ausgangspunkt als ein leeres Ticket. Der Abbruch ist damit kein Fehlschlag des Prozesses, sondern sein vorgesehener Ausgang für die Fälle, die er nicht alleine trägt.

Coding, Variante B — Mensch mit Agent

Für alle Tickets, die mit human-only oder agent-assisted gelabelt sind, bleibt der übliche Workflow: ein Mensch arbeitet, mit Agenten-Unterstützung. Interessant ist daran nur ein Detail, und das ist das Entscheidende am ganzen Entwurf.

Die Schritte aus Variante A sind für den Menschen als Skills verfügbar — Tests implementieren, Test-Review, Code-Review — und jederzeit auch für seinen eigenen Code auslösbar.

Damit sind die beiden Varianten ein Prozess und nicht zwei Welten. Ein Ticket, dessen autonomer Durchlauf an der Rundengrenze abgebrochen ist, landet nicht in einem anders arbeitenden Team, sondern im selben Ablauf mit denselben Werkzeugen — und ein Mensch, der ein Feature von Hand baut, bekommt das Review, das der Agent auch bekommen hätte.

Coding-Abschluss

Der Abschluss einer Coding-Aufgabe ist in beiden Varianten identisch. Die festgelegte CI-Pipeline (statische Code-Analyse, Tests etc.) muss erfolgreich sein und die Änderungen müssen von einem Menschen per Code-Review bestätigt werden. Inwiefern man diesen manuellen Schritt weglassen möchte, hängt von der individuellen Firmenphilosophie und den laufenden Erfahrungen mit dem vorgestellten Prozess ab.

Was das bringt

Der Gesamtprozess liefert schnellere und qualitativ hochwertigere Arbeit. Letzteres klingt zunächst unintuitiv, folgt aber aus drei Gründen, die sich unabhängig voneinander nachprüfen lassen:

  • Die Testabdeckung steigt, weil die Tests vor der Implementierung aus den Specs entstehen — und damit nicht der Teil sind, der am Ende eines Tickets aus Zeitgründen entfällt.
  • Agenten finden Fehler, die Menschen übersehen. Es ist die unspektakuläre Sorte: der vergessene Leer-Fall, der nicht behandelte Fehlerzweig, die kopierte Stelle mit einem nicht angepassten Feld. Ein Review-Agent liest die dreihundertste Zeile so genau wie die erste.
  • Die Menschen arbeiten an den Fragen, die das große Ganze betreffen — Architektur, fachliche Widersprüche, Priorisierung. Also an den Stellen, an denen eine falsche Entscheidung teuer ist und erst Monate später sichtbar wird.

Die Kostenseite steht oben in der TL;DR. Sie ist das Ergebnis dieser drei Punkte und nicht der Zweck des Entwurfs: ein Prozess, der nur billiger ist, hält sich nicht, weil die erste ernste Regression ihn wieder abschafft.

Wo der Mensch bleibt

Fünf Stellen sind im Prozess als Übergabepunkte an einen Menschen vorgesehen:

  • Architekturentscheidungen. Ein Agent kann sie vorbereiten — Optionen, Folgen, Empfehlung. Treffen sollte sie ein Mensch, weil sie oft langfristige Folgen haben und mit der generellen (Produkt-)Strategie übereinstimmen sollten.
  • Fachliche Widersprüche. Wenn ein Ticket einer Spec widerspricht, ist das keine technische Frage. Sie geht ans Produktmanagement, und die Antwort ändert die Spec, nicht nur den Code.
  • Nicht nachstellbare Bugs. Was sich nicht reproduzieren lässt, lässt sich nicht testgetrieben beheben. Hier bleibt die Arbeit, die kein Agent abkürzt: mit dem Melder sprechen, Daten beschaffen, Logs lesen.
  • Die abgebrochenen Durchläufe. Jede Schleife, die ihr Rundenlimit erreicht, ist per Konstruktion ein Fall für einen Menschen. Dieser Anteil ist die ehrlichste Kennzahl des ganzen Aufbaus: er misst nicht die Agenten, sondern die Qualität der Specs.
  • Code-Merge. Kein Code geht ohne menschliche Freigabe live.