Summen, an den drei Kundenprojekten: 127 gemergte Tickets und 539 ausgeführte Agenten-Aufgaben seit Juni 2026.
Aktuelle Version, seit dem 19. August getrennt gemessen: 0.4% menschliche Commits auf Branches und 2% der Tickets mit menschlicher Freigabe, an denselben Kundenprojekten.
Tempo: ein Median von 54 Minuten vom ersten Commit bis zum Merge, an derselben aktuellen Version und denselben Kundenprojekten.
Die Aufgabe
Dutopilot liefert Kundenprojekte mit derselben Pipeline, die es verkauft. Alle Zahlen auf dieser Seite wurden an drei Kundenprojekten gemessen: der Website eines Salesforce-Dienstleisters, der Website von serpent.cloud und einem Monorepo mit Salesforce- und nativem iOS-Code. Keine wurde am eigenen Repository von Dutopilot gemessen. Das Ziel: virtuelle Dutopilot-Teammitglieder tragen die routinemäßige Lieferarbeit, die Menschen des Kunden behalten die Entscheidungen.
Vor der Pipeline lag die Routinearbeit an einem Ticket bei Menschen: Jemand schrieb den Plan, baute die Änderung, las den Pull Request, jagte fehlgeschlagenen Checks hinterher und klickte auf Merge. Diese Arbeit ist nötig, und das meiste davon wiederholt sich.
Vorher und nachher
| Schritt | Vorher | Jetzt |
|---|---|---|
| Plan | Eine Person schreibt ihn. | Ein Agent schlägt ihn vor. Eine Person gibt ihn frei, wenn die Änderung neu oder riskant ist. |
| Build | Eine Person. | Ein Agent, auf einem eigenen Branch. |
| Checks | Eine Person wartet darauf und jagt Fehlern hinterher. | Ein gemeinsames Urteil. Fehler gehen direkt an einen Fixer-Agenten. |
| Review | Eine Person aus Ihrem Team, wenn sie Zeit hat. | Getrennte virtuelle Dutopilot-Teammitglieder als Reviewer, bei jedem Pull Request. |
| Merge | Eine Person klickt auf den Button. | Der Pull Request mergt sich selbst, sobald alles grün ist, unter Branch-Schutz. |
| Produktions-Release (bei diesen Kundenprojekten) | Eine Person entscheidet. | Eine Person entscheidet weiterhin. |
So funktioniert es
Jedes Ticket aus dem Projektboard durchläuft neun Stufen: Architect, Planner, Implementer, Gate, drei Reviewer, Autofixer und QA. Drumherum legen Menschen einmal pro Projekt die Freigabepunkte fest, die Pipeline übernimmt das Ticket vor der ersten Stufe, und nach der letzten gibt eine Person das Produktions-Release frei. Diese drei sind keine Stufen. Das Ticket zeigt, wo es steht.
- Architect: schlägt einen Plan auf Dateiebene, die Datenflüsse und einen Testplan vor, bevor Code entsteht. Eine Person gibt ihn frei, wenn die Änderung neu oder riskant ist.
- Planner: macht aus der freigegebenen Architektur eine geordnete Aufgabenliste für den Implementer.
- Implementer: schreibt die Änderung auf einem eigenen Branch.
- Gate: führt die automatischen Prüfungen am Pull Request aus und liefert ein einziges Urteil.
- Erster Reviewer: Ein getrennter Agent liest die Änderung für sich.
- Zweiter Reviewer: Ein weiterer getrennter Agent liest die Änderung unabhängig.
- Dritter Reviewer: Ein dritter getrennter Agent liest die Änderung unabhängig.
- Autofixer: behebt, was ein Check oder ein Reviewer gefunden hat, danach läuft das Gate erneut.
- QA: Die Änderung wird in Staging oder Test gemergt, und die QA testet das Ergebnis.
Bei diesen Kundenprojekten erreicht gemergte Arbeit die Staging- oder Testumgebung, und eine Person gibt das Release in Produktion frei. Dutopilot baut auch sein eigenes Produkt auf dieselbe Weise.
Ein Ticket, vom Board bis zum Merge
Das ist ein beispielhaftes Ticket aus den Website-Projekten, um zu zeigen, was jede Stufe liefert: "Branchenfilter auf der Fallstudien-Seite ergänzen".
| Schritt | Was passiert |
|---|---|
| Ticket | Eine Produktperson schreibt es mit dem gewünschten Ergebnis und dem, was „fertig“ bedeutet, und markiert es als bereit. |
| Architect und Planner | Der Architect nennt die Dateien, die er ändert, und die Tests, die er ergänzt, und der Planner listet die Aufgaben auf. Eine Person gibt frei, weil sich dadurch das Verhalten einer Seite ändert. |
| Implementer | Der Implementer baut die Änderung auf einem eigenen Branch und öffnet einen Pull Request. |
| Schranke | Lint, Build und Tests laufen. Ein Test schlägt fehl. |
| Autofixer | Der Autofixer erhält das Fehler-Log, behebt den Code, und die Schranke wird im nächsten Lauf bestanden. |
| Reviewer | Die Reviewer hinterlassen Kommentare. Der Autofixer beantwortet sie, und die Checks laufen erneut. |
| QA | Der Pull Request wird in Staging oder Test gemergt und die QA testet das Ergebnis. |
| Release (eine Person) | Bei diesen Kundenprojekten gibt eine Person das Release in Produktion frei. |
Im aktuellen Release liegt die mediane Zeit vom ersten Commit bis zum Merge bei 54 Minuten.
Wenn etwas fehlschlägt
Fehler gehören dazu, deshalb plant die Pipeline sie ein. Ein fehlgeschlagener Check oder ein Review-Befund geht mit dem genauen Log oder Kommentar an einen Fixer. Ein Test, der zufällig fehlschlägt, wird wiederholt und repariert, damit er gute Arbeit nicht blockiert. Seit dem 19. August hat die Pipeline 150 Schrittfehler selbst behoben. Kommt ein Fix nicht mehr voran oder steigt das Risiko, hält der Lauf an und das Ticket fragt eine Person.
Ergebnisse
| Kennzahl | Ergebnis | Zeitraum und Umfang |
|---|---|---|
| Gemergte Tickets | 127 | Seit Juni 2026, alle drei Projekte |
| Ausgeführte Agent-Aufgaben | 539 | Seit Juni 2026, alle drei Projekte |
| Menschliche Commits auf Branches | 0,4 % | Aktuelles Release, seit 19. August |
| Tickets mit menschlicher Freigabe | 2 % | Aktuelles Release, seit 19. August |
| Mediane Zeit vom ersten Commit bis zum Merge | 54 Minuten | Aktuelles Release, seit 19. August |
| Von der Pipeline reparierte Stufenfehler | 150 | Aktuelles Release, seit 19. August |
Alle Zeilen stammen aus den drei Kundenprojekten. Die ersten beiden Zeilen sind Summen über den gesamten Zeitraum. Die übrigen Zeilen werden nur an der aktuellen Version gemessen, die beiden Gruppen sind also nicht zum Vergleich gedacht.
Was Menschen weiterhin tun
- Über die Architektur von allem Neuen oder Riskanten entscheiden, bevor Code entsteht.
- Änderungen in Bereichen freigeben, in denen ein Fehler teuer ist.
- Über das Release in Produktion entscheiden, bei diesen Kundenprojekten.
- Antworten, wenn ein Ticket anhält und eine Entscheidung erbittet.
Die Freigaben legen Sie selbst fest. Der Ratgeber Welche Schritte brauchen eine Freigabe zeigt, wie Teams sie einrichten.
In der Praxis sind das eine Produktperson, die Tickets schreibt und ordnet, ein Engineer, der Pläne und sensible Änderungen freigibt, und eine Delivery-Leitung, die über Releases entscheidet. In der übrigen Zeit muss niemand zuschauen, und das Ticket sagt, wann eine Person gebraucht wird.
Jeder Kunde bekommt einen Forward Deployed Engineer
Ein Forward Deployed Engineer von Dutopilot arbeitet vom ersten Tag an mit Ihrem Team. Er schreibt nicht Ihren Produktcode. Er passt die Pipeline an Ihre bestehende Arbeitsweise an.
- Onboarding: Er verbindet Ihre Tools mit Ihnen und wählt den ersten Teil des Backlogs aus.
- Ticket-Reife: Er vereinbart mit Ihrem Product Owner eine kurze Ticket-Vorlage, damit Agenten klare Aufgaben bekommen.
- Freigaben und Schranken: Er legt fest, welche Pläne und welche Teile des Codes eine Person brauchen, passend dazu, wie Ihr Team prüft.
- Laufende Verbesserung: Er geht mit Ihnen festhängende Tickets und Ergebnisse durch und verschiebt Schranken, wenn das Vertrauen wächst.
Was das für Ihr Team bedeutet
Ein Claude-Ultra-Konto liefert etwa 50 mittelgroße Tickets pro Woche (im Schnitt etwa 25 geänderte Dateien pro Ticket), etwa 200 im Monat, wenn genug virtuelle Dutopilot-Teammitglieder darauf laufen. Im Solo-Tarif hält das kleinere Dutopilot-Team (bis zu 3 virtuelle Teammitglieder) ein Konto bei etwa 100 Tickets im Monat; im Team-Tarif sind es etwa 200 Tickets im Monat pro verbundenem Claude-Ultra-Konto. 8 virtuelle Dutopilot-Teammitglieder können etwa 50 Tickets an einem einzigen Tag abschließen, was etwa das KI-Wochenkontingent eines Kontos verbraucht. Jeder Agent in einem Tarif ist ein virtuelles Teammitglied. Jedes virtuelle Teammitglied kann in jedem Tarif Hunderte Sub-Agenten parallel ausführen, und Enterprise begrenzt die Zahl der Agenten nicht. Die Tarife werden nach virtuellen Dutopilot-Teammitgliedern berechnet, nicht nach Nutzern: Ihr ganzes Team kann Dutopilot nutzen. Dutopilot arbeitet für Ihr Backlog mit Jira, Linear, Notion, GitHub Issues und Azure DevOps, für Ihren Code mit GitHub, GitLab, Bitbucket und Azure DevOps, mit Slack und mit Claude Code, Codex, OpenCode und Oh My Pi als KI. Um es an einem Ausschnitt Ihres eigenen Backlogs zu sehen, buchen Sie einen Termin.