Eure Leute legen die Regeln fest, KI-Agenten bauen das Produkt.
In einer Software Factory entscheiden Menschen, was gebaut wird, und legen die Regeln fest. KI-Agenten erledigen die Arbeit von der Planung bis zum Betrieb, Gates prüfen jede Änderung.
Gespräch buchen (öffnet in einem neuen Tab)Wie die Factory läuft und wo Menschen steuern
Menschen steuern
- Absicht Ergebnisse, Grenzen, Risiko
- Regeln und Gates mit benannten Verantwortlichen
- Plattform-Verantwortung pflegt Agenten, Kontext und Gates
Code steuert jeden Lauf
- 01 Planung
- Gate 02 Build
- Gate 03 Review
- Gate 04 Deployment
- Gate 05 Betrieb
Zur Technik gehört ein Betriebsmodell
Sobald Agenten die Arbeit machen, beantwortet ihr drei Fragen neu: Wer entscheidet, wer steuert die Agenten, und wem gehört das Delivery-System nach dem Piloten?
-
Menschen legen fest, was entsteht
Produkt- und Engineering-Verantwortliche wählen Ziele, Grenzen und das Risiko, das sie tragen wollen. Agenten dürfen Pläne vorschlagen, die Verantwortung für alles, was in Produktion geht, bleibt bei Menschen.
-
Jede Regel hat benannte Verantwortliche
Architekturgrenzen, Quality Gates und Eskalationswege brauchen Menschen, die sie ändern dürfen, wenn die Belege etwas anderes zeigen.
-
Die Factory läuft wie eine Plattform
Eine benannte Person oder ein Plattformteam kümmert sich um Agenten, Kontext und Gates wie um jede interne Plattform und stimmt mit den Produktteams ab, was die Factory als Nächstes übernimmt.
-
Aus drei Rollen wird eine Engineering-Rolle
Entwicklung, QA und Analyse wachsen zusammen. QA wechselt vom Prüfen einzelner Ergebnisse dahin, die Qualität der Factory und ihrer Gates zu verantworten.
-
Meetings behalten ihren Zweck
Planning, Refinement und Review bleiben, nur ohne festen Termin. Die Produktleute bestimmen das Tempo, also findet Refinement statt, sobald die Arbeit es braucht.
- Im Backlog stehen Annahmen, die ihr testet
- Das Daily wird zur kurzen Retro: Wie haben die Agenten gearbeitet?
- Produkt und Engineering arbeiten den ganzen Tag im Pairing
Teams liefern schneller, wenn Agenten in einem gemeinsamen System arbeiten
Teams liefern schneller, wenn Agenten in einem gemeinsamen System arbeiten
Agenten im Editor verkürzen einzelne Coding-Sitzungen. Das Delivery-System drumherum kann trotzdem im alten Tempo weiterlaufen. In einer Software Factory legen Menschen fest, was entsteht, verantworten die Regeln und stehen für das Ergebnis ein.
Jede:r nutzt Agenten auf eigene Art
Die Tools sind da, aber alle arbeiten anders damit.
- Kontext steckt in privaten Sitzungen und ist mit ihnen weg.
- Der Agent schreibt Code. Planung, Review, Deployment und Betrieb bleiben, wie sie sind.
- Mehr generierter Code landet bei denselben Reviewer:innen. Der Engpass wandert nur weiter.
- Die Organisation kann nicht zeigen, was sich in der Auslieferung verändert hat.
Das Geld verstärkt die Lücken, die es vorher schon gab.
Eine laufende Software Factory
Menschen, Agenten, Quality Gates und Feedback arbeiten als ein System.
- Absicht, Kontext, Regeln und Gates liegen im Repository und gelten für jeden Lauf.
- Agenten arbeiten in Planung, Umsetzung, Review, Deployment und Betrieb.
- Deterministische Prüfungen entscheiden, was weitergeht. Menschen entscheiden, was entstehen soll.
- Delivery-Daten, nur pro Team gemessen, zeigen, was besser wurde und wo der nächste Engpass liegt.
Das Tempo kommt aus dem System, das alle teilen.
Eine Software Factory steuert Agenten über den ganzen Lebenszyklus
Ein Coding-Agent arbeitet in der Sitzung einer einzelnen Person. Eine Software Factory koordiniert Agenten über Planung, Umsetzung, Review, Deployment und Betrieb.
-
Ein Coding-Agent
Sitzt in eurem Editor. Ihr startet ihn, schaut ihm zu und prüft jeden Diff, denn fast richtig ist immer noch falsch. Ihr tippt schneller, der Engpass bleibt.
-
Eine Factory aus Agenten
Kann klar umrissene Schritte im Lebenszyklus nach Zeitplan oder auf einen Auslöser hin ausführen. Menschen lesen die Belege, passen die Regeln an und verantworten, was live geht.
-
Deterministische Orchestrierung
Code legt die Reihenfolge der Agenten fest, deshalb lässt sich jeder Lauf wiederholen.
-
Korrekturen werden Regeln
Korrekturen, die ihr immer wieder macht, können zu Regeln oder Tests werden. Spätere Läufe starten dann mit besserem Kontext.
Eure Menschen steuern. Die Factory trägt begrenzte Arbeit
Je stärker das Feedback-System wird, desto weniger Aufmerksamkeit müssen Menschen Routine-Diffs widmen und desto mehr bleibt ihnen für Absicht, Architektur, Risiko und Ergebnisse. Wie viel Autonomie sicher ist, hängt von Codebasis, Quality Gates, Deployment-Modell und Betriebsverantwortung ab.
Eine klare Pipeline von der Planung bis in den Betrieb
- Menschliche Absicht: Definiert die Produktabsicht, eröffnet Arbeit, beantwortet Eskalationsfragen und startet eine Remote-Session, wenn fortlaufendes Urteilsvermögen nötig ist.
- Feature-Planer: Sichtet neue Arbeit, prüft die Absicht, klassifiziert das Risiko und leitet ausreichend klare Aufgaben ins Backlog weiter.
- Feedback-Auswertung: Verbindet Feedback und Nutzungssignale und eröffnet daraus Verbesserungen oder priorisierte Fehler mit den zugehörigen Belegen.
- Produktverbesserung: Prüft das laufende Produkt. Verbesserungen mit geringem Risiko kommen ins Backlog, Änderungen mit hohem Risiko warten auf einen Menschen.
- Weiter nach Klärung: Erkennt die menschliche Antwort auf eine eskalierte Aufgabe und führt sie erneut durch die Triage, statt sie blockiert liegen zu lassen.
- Prüfung blockierter Arbeit: Findet beanspruchte Arbeit, die nicht mehr vorankommt, gibt sie für einen neuen Lauf frei oder eskaliert wiederholte Fehler.
- Feature-Umsetzung: Übernimmt ein Feature, setzt es nach den Regeln des Repositories um, führt Tests aus und öffnet einen Pull Request.
- Fehlerbehebung: Übernimmt einen priorisierten Fehler, reproduziert ihn, behebt ihn, prüft das Ergebnis und öffnet einen Pull Request.
- Remote-Sessions: Ein Mensch und ein Agent arbeiten live an Architektur, Debugging, Refactoring oder anderer Arbeit, die fortlaufendes Urteilsvermögen verlangt.
- PR-Review: Prüft die Änderung gegen Absicht, Repository-Regeln und Testbelege und meldet die Ergebnisse vor dem Merge.
- PR-Begleitung: Findet festgefahrene Pull Requests, stößt ihre Prüfung an und schließt doppelte Arbeit, bevor die Warteschlange wächst.
- CI: Führt deterministische Builds, Tests, Sicherheitsprüfungen und weitere Fitness Functions aus und meldet den Status an das Review.
- Deployment-Plattform: Baut und veröffentlicht die gemergte Änderung in einer produktionsnahen oder produktiven Umgebung.
- Deployment-Workflows: Führt die Post-Merge-Workflows aus und informiert die Verifikation, sobald ein Deployment bereitsteht.
- Post-Merge-Prüfung: Prüft die ausgerollte Änderung direkt nach dem Merge und eröffnet einen priorisierten Fehler, wenn sie sich in Produktion falsch verhält.
- UI-Prüfung: Bedient die ausgerollte Oberfläche in einem echten Browser und macht sichtbare Regressionen zu bearbeitbarer Arbeit.
- Incident Response: Untersucht einen Incident, identifiziert die wahrscheinliche Ursache und führt Hotfix oder Folgearbeit zurück in die Planung.
- Performance-Monitoring: Beobachtet die Laufzeit-Performance und eröffnet belegte Arbeit, wenn eine Regression ihren Grenzwert überschreitet.
- Automationsprüfung: Findet wiederholte manuelle Korrekturen, aktualisiert Factory-Regeln und markiert festgefahrene Review-Pfade.
- Tägliche Metriken: Erfasst täglich Durchsatz, Autonomie und CI-Zustand, damit die Factory anhand von Belegen geprüft werden kann.
- Wöchentlicher Rückblick: Verbindet die täglichen Snapshots zu einem wöchentlichen Bericht darüber, was ausgeliefert wurde, fehlschlug und sich im System änderte.
- Update-Entwurf: Macht aus geprüften Delivery-Daten einen freigabefertigen internen oder öffentlichen Bericht, statt eine Erfolgsgeschichte zu erfinden.
Scrollt horizontal durch die Pipeline. Wischt horizontal durch die Pipeline.
Beispiel: ein Ticket durch eine Factory
- 00:00 plan Plan mit 8 Akzeptanzkriterien, nutzt die bestehende API
- 00:51 tests 4 neue Tests zuerst geschrieben: rot, 4 fehlgeschlagen
- 02:09 implement Grün: 4 bestanden; Lint und Typecheck sauber
- 03:30 review, Runde 1 Erstes Review: keine Findings
- 04:00 review, Runde 1 Zweites Review: 3 Findings
- 04:12 converge, Runde 1 3 Fixes, zurück zu implement
- 05:11 implement, Runde 2 3 Fixes umgesetzt; der korrigierte Test schlägt nachweislich fehl, wenn der Code bricht
- 07:13 review, Runde 2 1 Finding
- 07:27 converge, Runde 2 1 Fix, zurück zu implement
- 08:23 implement, Runde 3 Fix umgesetzt; sein neuer Test war vorher rot, danach grün
- 09:30 review, Runde 3 Keine Findings
- 11:04 converge, Runde 3 Keine offenen Findings
- 11:44 acceptance Besteht im Browser gegen jedes Akzeptanzkriterium
- 11:59 commit Ein Commit: 5 Dateien, +128 -5
KI schreibt den Code. Im Review staut er sich
Mehr Pull Requests können dieselbe Review-Kapazität überfordern. Eine Factory kann feste Prüfungen und ein Agenten-Review vor das menschliche Urteil schalten. So wartet weniger vermeidbare Arbeit in der Schlange.
Wie viel Autonomie möglich ist, entscheidet die Qualität des Engineering-Systems um die Agenten herum.
-
Context Engineering
Fachwissen, Standards, Beispiele und Grenzen liegen in Schichten im Repository. Jeder Lauf startet mit dem Kontext, mit dem euer Team auch sonst ausliefert.
-
Architekturgrenzen
Domänengrenzen, Module und API-Verträge begrenzen, was eine einzelne Änderung berühren kann. Je kleiner der Radius, desto leichter lässt sich die Arbeit der Agenten prüfen.
-
Tests
Tests sind ausführbare Spezifikationen. Sie zeigen Agenten und Menschen, ob eine Änderung hält, ohne dass jemand nur interpretieren muss.
-
Quality Gates
Build, Typen, Linting, Tests, Sicherheitsprüfungen und Coverage folgen festen Regeln. Ein Gate prüft Belege gegen eine Regel, die sich nicht verschiebt.
-
Feedback
Korrekturen, die ihr immer wieder von Hand macht, werden zu Regeln, Tests oder Beispielen. Jeder Lauf und jeder Vorfall in Produktion verbessert den Kontext für den nächsten.
Menschen verantworten, was die Factory ausliefert
Menschen verantworten, was die Factory ausliefert
Wer betreibt die Factory, wenn sie steht?
Eine benannte Person oder ein Plattformteam kümmert sich um Agenten, Kontext und Gates wie um jede interne Plattform. Diese Person oder das Team stimmt mit den Produktteams ab, was die Factory als Nächstes übernimmt, und ändert eine Regel, wenn die Belege es verlangen.
Was wird aus unseren QA-Engineers und Analyst:innen?
Entwicklung, QA und Analyse wachsen zu einer Engineering-Rolle zusammen. QA wechselt vom Prüfen einzelner Ergebnisse dahin, die Qualität der Factory und ihrer Gates zu verantworten.
Fallen Planning, Refinement und Review weg?
Nein. Sie behalten ihren Zweck, nur der feste Termin fällt weg. Die Produktleute bestimmen das Tempo, also findet Refinement statt, sobald die Arbeit es braucht, und das Daily wird zur kurzen Retro darüber, wie die Agenten gearbeitet haben.
Wie viel entscheiden die Agenten selbst?
So viel, wie euer Feedback-System trägt. Wie viel Autonomie sicher ist, hängt von Codebasis, Quality Gates, Deployment-Modell und Betriebsverantwortung ab, und sie wächst nur dort, wo die Gates halten.
Menschen wählen Ziele, Grenzen und das Risiko, das sie tragen wollen, und verantworten jede Änderung, die in Produktion geht.
Findet euren ersten Engpass, bevor ihr baut
Das Factory Readiness Assessment erhebt eure Baseline, findet den Engpass, der zuerst zählt, und empfiehlt die nächste Entscheidung für einen echten Wertstrom.
Gespräch buchen (öffnet in einem neuen Tab)