Pipelines statt Chat-Fenster

Warum das Chat-Fenster im Browser für Entwicklerteams nicht reicht

Das Chat-Fenster im Browser hilft einem einzelnen Entwickler bei einer einzelnen Frage, aber ohne Anbindung an eure Codebasis verbindet es die Arbeit eines Teams nicht. Jeder fragt für sich, kopiert die Antwort in seinen Editor und passt sie von Hand an. In unserem Stufenmodell L0 bis L4 ist das Stufe L1: KI im Chat-Fenster, jeder für sich.

Das Problem zeigt sich, sobald ein ganzes Team so arbeitet. Ohne Anbindung an eure Codebasis kennt das Modell im Chat weder eure Standards noch eure Architektur noch eure Tests. Copy-Paste aus dem Chat liefert deshalb oft Code, der sauber aussieht, aber nicht zu eurem Projekt passt. Es fehlen Kontextdateien und die Anbindung an Ticketsystem und Pipeline.

Dazu kommt, dass eine Chat-Sitzung nicht skaliert. Ein Entwickler führt ein Gespräch zur Zeit, und jede Antwort wartet darauf, dass er sie liest, kopiert und einfügt. Der Durchsatz bleibt an seine Aufmerksamkeit gebunden. Auf dieser Stufe fehlen einem Team vier Dinge:

• Ein gemeinsamer Ablauf: Jeder richtet sich seine Werkzeuge selbst ein.
• Projektkontext: Das Modell sieht nur, was jemand hineinkopiert.
• Eine feste Prüfung: Was geprüft wird, hängt vom Einzelnen ab.
• Kontrolle über Zugänge: Anfragen können über private Accounts laufen.

Was eine Agenten-Pipeline ist

Eine Agenten-Pipeline ist ein fester Ablauf, in dem mehrere Agenten ein Sprint-Ticket nacheinander bearbeiten, bis es bereit zum Review ist. Jeder Agent hat genau eine Aufgabe, und jede Station übergibt ihr Ergebnis an die nächste. Die Pipeline ist direkt in eurer Codebasis eingerichtet, mit euren Standards und eurer Architektur.

In unserem Setup hat eine Pipeline fünf Stationen:

• Planner: zerlegt das Ticket.
• Umsetzer: schreibt den Code.
• Quality Gate 1: prüft Tests und Standards.
• Quality Gate 2: prüft Sicherheit.
• Review: durch euer Team.

Der Unterschied zum Chat-Fenster liegt nicht im Modell. Als Agenten setzen wir Codex und Claude ein. Das Risiko liegt nicht im Modell, sondern im fehlenden Ablauf. Die Pipeline ist dieser Ablauf: Darin steht fest, wer was tut, was geprüft wird und wann ein Mensch entscheidet.

Die Pipeline liegt dabei nicht in einem Browser-Tab, sondern in eurem Repository. Neben eurem Code gibt es einen Ordner für die Agenten mit Dateien für den Planner, für die Quality Gates und für eure Standards. So arbeitet jeder Entwickler mit demselben Ablauf, und Änderungen daran laufen wie jede andere Änderung über Git.

Wie ein Sprint-Ticket durch die Pipeline läuft

Ein Sprint-Ticket läuft durch die Pipeline, indem der Entwickler es schneidet, an den Planner übergibt und am Ende das geprüfte Ergebnis abnimmt. Ein Beispiel, wie wir es in Live-Sessions zeigen, ist das Ticket „CSV-Export für Rechnungen“ aus einem laufenden Sprint. Der Ablauf sieht so aus:

• Schneiden: Der Entwickler teilt das Ticket in drei Teile: Datenmodell, Export, Tests.
• Planen: Der Planner erstellt daraus einen Plan.
• Umsetzen: Der Umsetzer ändert die betroffenen Dateien, im Beispiel drei.
• Prüfen: Die Quality Gates lassen die Tests laufen und prüfen Standards und Sicherheit.
• Übergeben: Das Ergebnis ist bereit zum Review.

Der erste Schritt entscheidet über den Rest. Ein Ticket, das sauber geschnitten ist, arbeiten Agenten verlässlich ab. Deshalb üben wir das Schneiden von Tickets für Agenten in den Live-Sessions an echten Aufgaben, bis der Ablauf sitzt.

Ein guter Plan trägt weit: Agenten können ein Feature über Stunden autonom umsetzen. Die Arbeit des Entwicklers liegt dann vor allem am Anfang, beim Plan, und am Ende, beim Review.

Der letzte Schritt bleibt beim Menschen. Der Entwickler prüft jede Ausgabe, bevor sie in euren Code geht. Was ein Quality Gate im Einzelnen prüft, beschreibt unser Artikel über Quality Gates für KI-Code.

Wie drei Pipelines parallel laufen

Drei Pipelines laufen parallel, indem der Entwickler Tickets startet, Zwischenstände prüft und Ergebnisse abnimmt. Er schreibt nicht mehr jede Zeile selbst. In der einen Pipeline setzt der Agent gerade um, in der zweiten prüft ein Quality Gate, die dritte ist bereit zum Review. Drei Tickets in drei Zuständen, ein Entwickler.

In einem Chat-Fenster ohne Anbindung an eure Codebasis geht das nicht, weil jedes Gespräch die volle Aufmerksamkeit braucht. In einer Pipeline arbeiten die Agenten zwischen den Prüfpunkten selbstständig weiter. Der Entwickler wechselt dorthin, wo gerade eine Entscheidung ansteht.

Im Stufenmodell ist das L3: Steuert Agenten, mehrere Pipelines laufen parallel. Im Team-Programm ist das der Zielwert nach 4 Wochen: 3–5 Pipelines parallel pro Entwickler und Tag, und jede Ausgabe wird geprüft. Damit das stabil läuft, müssen ein paar Dinge erfüllt sein:

• Tickets sind so geschnitten, dass Agenten sie verlässlich abarbeiten.
• Jede Pipeline hat ihre Quality Gates, damit nicht jeder Zwischenstand von Hand geprüft werden muss.
• Die Agenten kennen eure Codebasis, eure Standards und eure Architektur.
• Zugänge laufen über Firmenzugänge, und ihr legt fest, welcher Code an ein Modell geht.

Parallel arbeiten lernt man schrittweise. Im Programm starten wir in Woche 3 mit zwei Pipelines gleichzeitig, dann mit drei. Das Kriterium für Woche 3 ist einfach: Mehrere Pipelines laufen stabil nebeneinander.

Was sich am Arbeitstag eines Teams ändert

Am Arbeitstag ändert sich vor allem, dass Arbeit nicht mehr nacheinander, sondern nebeneinander passiert. Ohne Pipelines kommen Bugfixes nach dem Feature, und nachts passiert nichts. Mit Pipelines sieht derselbe Ablauf so aus:

• Features: werden schneller fertig, weil Agenten umsetzen, während der Entwickler das nächste Ticket plant.
• Bugfixes: laufen parallel zum Feature, nicht danach.
• Nachts: Agenten arbeiten Tickets ab, zum Beispiel eine Ticket-Triage über Nacht.

Am Morgen liegen dann Ergebnisse bereit, die der Entwickler prüft. Die Entscheidung, was in euren Code geht, bleibt bei ihm.

Der zweite Unterschied betrifft das Wissen im Team. Was jemand im Chat-Fenster gelernt hat, bleibt Einzelwissen. Eine Pipeline dagegen ist einheitlich für alle eingerichtet, sie hat Templates, und ein Evaluationstool misst, wie eure Pipelines arbeiten.

Nach dem Programm tragen zwei interne Owner die Arbeitsweise weiter. Der eine ist für Pipelines und Templates zuständig, der andere für Automatisierungen. Auch euer Team-Lead kann danach Tickets so schneiden, dass Agenten sie verlässlich abarbeiten.

Für uns ist das kein Konzept vom Whiteboard. Wir haben unsere eigene Entwicklung vor zwei Jahren auf Agenten umgestellt. Seitdem laufen Planen, Umsetzen und Prüfen bei uns täglich parallel, mit Quality Gates.

Wie euer Team vom Chat-Fenster zur Pipeline kommt

Euer Team kommt vom Chat-Fenster zur Pipeline, indem die Pipelines in eurer Codebasis eingerichtet und eure Entwickler an echten Sprint-Tickets trainiert werden, nicht an Übungsprojekten. Im Team-Programm dauert das 4 Wochen, bei 6–8 Stunden pro Entwickler und Woche. Die Geschäftsführung braucht rund 2 Stunden in 4 Wochen.

Im Team-Programm läuft das erste Ticket am Ende von Woche 1 durch die Pipeline, mehrere Pipelines parallel ab Woche 3. In Woche 1 legen wir auch das Zonenmodell fest, also welcher Code an ein Modell darf. Die Geschäftsführung bekommt jede Woche einen Ampel-Report.

Der Startpunkt ist bei jedem Team anders. Ein Team arbeitet vielleicht noch ohne KI, ein anderes nutzt das Chat-Fenster nebenher, ein drittes gibt schon einzelne Aufgaben an Agenten ab. Bevor eine Pipeline entsteht, muss deshalb klar sein, wo jeder Entwickler steht.

Genau das klärt die kostenlose Analysewoche. Wir sichten Codebasis, Tickets und Pipeline mit Lesezugriff, verändert wird dabei nichts. Wir stufen jeden Entwickler von L0 bis L4 ein und rechnen das Potenzial in Stellen und Euro. Das Ergebnisdokument gehört euch.

Die Analysewoche passt zu eurem Team, wenn drei Dinge zutreffen:

• Ihr habt ein eigenes Entwicklerteam, ideal sind 3–15 Entwickler.
• Ihr arbeitet an einer eigenen Codebasis.
• Git ist im Einsatz.