Die meisten Firmen, die Werkzeuge für die Software-Auslieferung verkaufen, bauen ihr eigenes Produkt auf die alte Art und bitten Sie dann, dem Werkzeug zu vertrauen. Wir machen es umgekehrt. Das Produkt von Dutopilot wird von Dutopilot gebaut. Sein Repository ist mit dem gehosteten Dienst genau so verbunden, wie es das eines Kunden wäre. Tickets liegen auf einem Projekt-Board, und Agenten planen, bauen, prüfen, testen, korrigieren und mergen sie. Jeder Merge in den main-Branch wird in die Produktion ausgeliefert.
Das eigene Produkt von Dutopilot, seit dem 29. September
Unsere ersten Kundenprojekte, auf dem aktuellen Release seit dem 19. August
Dieser Artikel zeigt, wie das in der Praxis funktioniert: das Setup, was mit einem einzelnen Ticket passiert, wie täglich Dutzende Änderungen von Menschen und Agenten im selben main-Branch landen, ohne sich gegenseitig auszubremsen, was passiert, wenn etwas schiefgeht, und was die Menschen auf unserer Seite weiterhin tun. Außerdem zeigt er, was wir gemessen haben und was wir gelernt haben, das Sie in Ihrem eigenen Team nutzen können.
Ein Wort dazu, was Dutopilot ist, damit der Rest verständlich wird. Dutopilot ist ein Managed Service und Software as a Service in einem. Es ist eine Schicht über Coding-Agenten: Es betreibt Claude Code, Codex, OpenCode und Oh My Pi auf Ihrem eigenen KI-Konto, auf dedizierter Cloud-Infrastruktur, und jeder Kunde bekommt einen Forward Deployed Engineer, der es rund um Ihr Backlog einrichtet und Sie weiter begleitet. Jeder Agent ist ein virtuelles Dutopilot-Teammitglied, und jedes kann in jedem Plan Hunderte paralleler Sub-Agenten ausführen. Sie behalten das Projekt-Board, das Sie bereits nutzen. Die Agenten erledigen die Auslieferungsarbeit.
Warum das Produkt mit sich selbst gebaut wird
Es gibt drei Gründe, und der erste ist kein Marketing.
Der erste Grund ist Ehrlichkeit. Ein Auslieferungswerkzeug, das nie die Arbeit seines eigenen Herstellers getragen hat, wurde nicht am anspruchsvollsten Kunden getestet, den es gibt: einem, der täglich seine Meinung ändert, vage Tickets schreibt, in Eile mergt und jede langsame Minute bemerkt. Wenn unser eigenes Produkt auf ein hängendes Review wartet, spüren wir das noch am selben Nachmittag. Dieser Druck ist eine bessere Testsuite, als wir sie absichtlich schreiben könnten.
Der zweite Grund ist die Geschwindigkeit des Feedbacks. Wenn ein Agent stockt, sich im Kreis dreht oder eine Änderung liefert, die wir nicht akzeptieren würden, ist die Person, die Dutopilot reparieren kann, dieselbe, die das Problem gerade gespürt hat. Zwischen Schmerz und Reparatur liegt keine Support-Warteschlange. Ein Fehler, den wir finden, wird sofort ein Ticket auf dem Board, und die Korrektur folgt durch dieselbe Pipeline.
Der dritte Grund ist ein Beleg, den Sie prüfen können. Wenn wir sagen, dass die Pipeline viele gleichzeitige Änderungen aushält, beschreiben wir unser eigenes Repository, in dem Menschen und Agenten den ganzen Tag in denselben main-Branch mergen. Wir beschreiben kein Demoprojekt, das gut aussehen soll.
Nichts davon heißt, dass jeder Kunde genau unser Setup erwarten sollte. Kunden wählen ihre eigenen Freigaben, ihr eigenes Board und ihre eigenen Repositories. Übertragbar ist die Methode: Ein Ticket geht hinein, eine geprüfte und gemergte Änderung kommt heraus, und eine Person greift nur an den Freigaben ein, die für Sie zählen.
Sehen Sie es an Ihrem eigenen Backlog
Buchen Sie ein Gespräch: Ein Forward Deployed Engineer zeigt Ihnen, wie dieses Setup bei einem Ihrer Projekte aussehen würde. Oder starten Sie kostenlos mit dem Solo-Plan.
Das Setup: ein Board, ein Repository und eine klare Aufteilung der Arbeit
Das Setup ist bewusst schlicht, denn ein Kunde muss es nachbauen können.
Das Projekt-Board
Jede Arbeit beginnt als Ticket auf einem Projekt-Board. Auf dem Board sagen Menschen, was sie wollen: eine neue Fähigkeit, eine Korrektur, eine Textänderung. Ein Ticket wird in normaler Sprache geschrieben, so wie Sie eine Kollegin oder einen Kollegen briefen würden. Es muss keine Spezifikation sein. Fehlt etwas Wichtiges, fragt der Planungsschritt nach.
Das Repository
Der Code des Produkts liegt in einem Repository, das der gehostete Dutopilot-Dienst über eine Berechtigung liest und ändert, genau wie bei einem Kunden. Unser Repository bekommt keine Hintertür. Wenn ein Schritt bei uns funktioniert, funktioniert er über denselben Weg, den Ihr Repository nutzen würde.
Jede Änderung ist ein kleines, eigenständiges Stück Arbeit, das direkt in den main-Branch geht. Wir führen keine langlebigen Integrations-Branches und am Ende keine große gesammelte Release-Änderung. Kleinere Stücke bedeuten kleinere Reviews, leichteres Rückgängigmachen und keinen Stau, bei dem ein spätes Stück zehn fertige blockiert.
Was Menschen tun und was Agenten tun
Die Aufteilung ist einfach gesagt. Menschen entscheiden, was sich lohnt und wo ein Mensch Ja sagen muss. Agenten erledigen dazwischen die Auslieferungsarbeit.
- Menschen: schreiben und priorisieren Tickets auf dem Board, beantworten Fragen, die ein Agent nicht allein klären konnte, geben die Schritte frei, die sie hinter einer menschlichen Freigabe behalten wollten, und treffen Produktentscheidungen.
- Agenten: klären das Ticket, planen es, teilen es auf, wenn es groß ist, schreiben Code und Tests, prüfen gegenseitig ihre Arbeit, führen die Qualitätsprüfungen aus, reparieren Fehler, mergen und deployen.
Dahinter stehen Ihre KI-Konten. Dutopilot betreibt Claude Code, Codex, OpenCode und Oh My Pi mit Ihrem eigenen Abonnement oder Schlüssel, sodass die Kosten der KI-Arbeit auf ein Konto gehen, das Sie kontrollieren, und Sie genau sehen, wohin sie fließen. Die Agenten in Ihrem Plan teilen sich nicht einen einzigen engen Kanal. Jeder Plan-Agent verhält sich wie ein virtuelles Dutopilot-Teammitglied, der Teile einer Aufgabe an so viele parallele Sub-Agenten übergeben kann, wie die Arbeit braucht.
Das Leben eines Tickets, Schritt für Schritt
So läuft es für ein Ticket ab, vom Moment, in dem es bereit ist, bis zum Moment, in dem es live ist. Ein Ticket durchläuft insgesamt neun Stufen: Architekt, Planer, Umsetzer, Gate, drei Reviewer, Autofixer und QA. Wir beschreiben den Weg in der Reihenfolge, in der Sie ihn sehen würden. Die sieben nummerierten Schritte unten fassen diese neun Stufen zusammen, und die acht Karten im Bild zeigen denselben Weg.
1. Klären und Planen
Wird ein Ticket als bereit markiert, liest ein Agent es zusammen mit den Teilen des Repositorys, die es betrifft. Seine erste Aufgabe ist nicht, Code zu schreiben. Seine erste Aufgabe ist zu prüfen, ob sich das Ticket bauen lässt: Ist das Ziel klar, gibt es Widersprüche, fehlt eine Entscheidung, die nur eine Person treffen kann?
Ist das Ticket klar, machen ein Architekt-Agent und ein Planer-Agent daraus einen Plan: was zu ändern ist, in welcher Reihenfolge, was schiefgehen könnte und woran man erkennt, dass es funktioniert. Ein großes Ticket wird in kleinere Tickets aufgeteilt, die jeweils für sich gebaut, geprüft und ausgeliefert werden können. Die Aufteilung zählt: Kleine Tickets sind schneller fertig und im Review günstiger, und ein Problem in einem hält die anderen nicht auf.
Fehlt etwas, das nur eine Person entscheiden kann, fragt der Agent in einfachen Worten am Ticket nach. Eine Antwort in den eigenen Worten der Person genügt. Niemand muss besondere Formulierungen lernen.
2. Bauen in einer isolierten Sandbox
Das Bauen findet auf dedizierter Cloud-Infrastruktur statt, in einer Sandbox, die nur für dieses eine Ticket gemacht ist. Die Sandbox bekommt eine frische Kopie des Repositorys, erledigt die Arbeit und wird danach verworfen. Nichts aus dem Lauf eines Tickets kann in den eines anderen gelangen.
In der Sandbox schreibt ein Coding-Agent (Claude Code, Codex, OpenCode oder Oh My Pi, auf Ihrem Konto) die Änderung und die passenden Tests. Weil die Arbeit auf Sub-Agenten verteilt wird, kann einer die Datenseite übernehmen, während ein anderer die Oberfläche macht und ein dritter die Tests schreibt, alle in derselben Sandbox. Bevor irgendetwas geschrieben wird, führt die Sandbox den aktuellen main-Branch in ihre Arbeitskopie ein. Warum dieser Moment wichtig ist, erklären wir im Abschnitt über das Arbeiten im großen Maßstab.
3. Unabhängiges Review
Ist der Build fertig, wird die Änderung als Pull Request geöffnet, der üblichen Form, eine Änderung zur Prüfung vorzuschlagen. Die Reviewer sind eigene Agenten, die den Code nicht geschrieben haben. Sie lesen die Änderung mit frischem Blick, vergleichen sie mit dem Ticket und dem Plan und suchen nach Fehlern, übersehenen Fällen, riskanten Abkürzungen und Änderungen, die über das Ticket hinausgehen.
Reviewer und Autor zu trennen hat denselben Sinn wie bei Menschen. Ein Autor liest, was er schreiben wollte. Ein Reviewer liest, was tatsächlich dasteht.
4. Qualitäts-Gates
Parallel zum Review laufen mehrere Qualitäts-Gates. Ein Gate ist eine automatische Prüfung mit klarem Ergebnis, bestanden oder nicht bestanden: die Tests, die Typ- und Stilprüfungen, eine Prüfung, ob die Änderung das betrifft, was der Plan vorsah, und Prüfungen etwa zu Sicherheit und zum Aussehen der Seiten.
5. Die Selbstreparatur-Schleife
Findet ein Reviewer ein Problem oder schlägt ein Gate fehl, geht das Ticket nicht an eine Person zurück. Es geht in einen Reparaturschritt. Ein Reparatur-Agent liest den genauen Fehler, ändert den Code und schickt die Änderung erneut durch Review und Gates. Diese Schleife wiederholt sich, solange sie Fortschritte macht. Kommt derselbe Fehler ohne Fortschritt immer wieder, ändert sich der Ansatz, statt dasselbe noch einmal zu versuchen, und lässt sich das Problem trotzdem nicht lösen, hält das Ticket mit einer klaren Erklärung an, mit der eine Person handeln kann.
6. Merge
Sind alle Gates grün und ist das Review sauber, wird die Änderung in main gemergt. Der Merge ist ein Squash-and-Merge, sodass jedes Ticket ein sauberer Eintrag im Verlauf wird, der leicht zu lesen und leicht rückgängig zu machen ist. Haben Sie eine menschliche Freigabe vor dem Merge gewählt, wartet das Ticket stattdessen auf diese Freigabe und sagt der Person genau, was sie freigibt.
7. Deployment
Bei unserem eigenen Produkt ist ein Merge in main ein Release: Das Deployment startet von selbst und bringt die Änderung in die Produktion. Das Ticket wird erst geschlossen, wenn die Arbeit tatsächlich live ist und geprüft wurde, nicht schon beim Merge des Pull Requests. Schlägt eine Deployment-Prüfung fehl, wird das wie jeder andere Fehler behandelt: Es kommt als Arbeit zu den Agenten zurück, nicht als Nachricht, die darauf wartet, dass eine Person sie bemerkt. Bei Kundenprojekten endet die Arbeit in Staging oder Test, eine Person veröffentlicht, und das Ticket ist dort abgeschlossen.
Ein durchgespieltes Beispiel (illustrativ)
Illustratives Beispiel. Dies ist ein erfundenes Ticket, das den Ablauf zeigt. Es ist kein Protokoll einer bestimmten Änderung.
Das Ticket: „Zeige das nächste Abrechnungsdatum auf der Kontoseite an, damit Kunden den Support nicht mehr fragen, wann sie als Nächstes belastet werden.“
Planung. Der Agent liest das Ticket und den Code der Kontoseite. Er bemerkt, dass das Ticket nicht sagt, was Kunden mit einem kostenlosen Plan sehen sollen, und stellt eine Frage am Ticket. Eine Produktperson antwortet in einem Satz: nichts anzeigen. Der Architekt schreibt einen kurzen Plan: das Datum in die Kontodaten aufnehmen, es auf der Seite anzeigen, es bei kostenlosen Plänen ausblenden und Tests für beide Fälle ergänzen. Die Änderung ist klein genug, um als ein einziges Ticket ausgeliefert zu werden.
Bauen. Eine Sandbox startet mit einer frischen Kopie des Repositorys und führt den aktuellen main-Stand ein. Ein Coding-Agent ergänzt das Feld, ein zweiter Sub-Agent passt die Seite an, ein dritter schreibt die Tests. Danach öffnet er einen Pull Request.
Review und Gates. Ein Reviewer-Agent weist darauf hin, dass das Datum in einem festen Format angezeigt wird, obwohl das Produkt fünf Sprachen spricht. Ein Gate meldet außerdem einen fehlenden Test für einen Kunden, dessen Plan am letzten Tag eines Monats verlängert wird. Beide Befunde gehen in den Reparaturschritt.
Reparatur. Ein Reparatur-Agent nutzt die sprachabhängige Datumsformatierung, die das Produkt bereits hat, und ergänzt den fehlenden Test. Die Änderung durchläuft Review und Gates erneut, und alles ist grün.
Merge und Deployment. Die Änderung wird in main gemergt, das Release geht raus, und die Prüfung auf der Live-Seite besteht. Das Ticket wird geschlossen. Keine Person hat einen Code-Editor geöffnet, und die einzige menschliche Eingabe war ein Satz am Ticket.
Möchten Sie diesen Kreislauf auf Ihrem Projekt-Board?
Ein Forward Deployed Engineer richtet das Board, das Repository und die gewünschten Freigaben ein und begleitet Sie, während die Agenten die Auslieferungsarbeit übernehmen. Buchen Sie ein Gespräch oder starten Sie kostenlos mit dem Solo-Plan.
Arbeiten im großen Maßstab: viele Tickets, viele Personen, ein main-Branch
Ein einzelnes Ticket in einer sauberen Pipeline ist der leichte Fall. Der echte Test sind viele Tickets gleichzeitig, während auch Personen in dasselbe Repository mergen.
In unserem Repository sind viele Tickets gleichzeitig in Arbeit, jedes in seiner eigenen Sandbox, und unsere eigenen Leute mergen ihre Änderungen den ganzen Tag in main. Jeder dieser Merges verändert, wie main aussieht. Ein System, das nur funktioniert, wenn sich jeweils eine Änderung bewegt, würde die meiste Zeit mit Warten verbringen. Jedes virtuelle Dutopilot-Teammitglied kann in jedem Plan Hunderte paralleler Sub-Agenten ausführen.
Warum nichts darauf wartet, dass ein Branch aufholt
Eine verbreitete Regel in Softwareteams besagt, dass ein Branch auf dem Stand von main sein muss, bevor er gemergt werden darf. Bei wenigen Personen ist das ein kleines Ärgernis. Bei Dutzenden Änderungen, die den ganzen Tag eintreffen, wird es zur Falle: Sobald irgendeine Änderung gemergt wird, ist jede andere offene Änderung wieder veraltet und muss aktualisiert und neu geprüft werden. Bei viel Betrieb endet diese Schleife nie, und die Leute verbringen ihren Tag damit, Aktualisieren-Schaltflächen zu drücken.
Wir lehnen diese Regel bewusst ab. Stattdessen führt jeder Agent den aktuellen main-Stand genau dann in seine Arbeit ein, wenn er ihn braucht: bevor er Code schreibt und noch einmal kurz vor den abschließenden Prüfungen. Der Agent stellt selbst sicher, dass seine Arbeit zum aktuellen main passt, statt darauf zu warten, dass jemand seinen Branch aktualisiert.
Hat sich main während der Arbeit bewegt und berühren sich die beiden Änderungen nicht, ist nichts weiter nötig. Kollidieren sie, löst der Agent den Konflikt in seiner eigenen Kopie, führt die Prüfungen erneut aus und macht weiter. Den Preis zahlt die eine Änderung, die tatsächlich kollidiert hat, und nur dann, wenn sie kollidiert. Alle anderen bleiben in Bewegung.
Derselbe Gedanke gilt für jede gemeinsam genutzte Ressource
Denselben Test wenden wir auf alles an, was sich mehrere Änderungen teilen: den Pool der Sandboxes, die Zahl der Anfragen, die wir an den Code-Host senden dürfen, die KI-Konten, die Warteschlange der Arbeit. Die Fragen sind immer dieselben. Funktioniert das auch mit Dutzenden Schreibenden gleichzeitig? Endet jede Wartezeit von selbst? Wächst der Aufwand je Durchlauf mit der aktiven Arbeit und nicht mit der Größe des gesamten Backlogs?
Ein Design, das für ein Ticket nach dem anderen richtig ist, aber stockt oder eine Person braucht, wenn viele Tickets eintreffen, ist für uns ein falsches Design, so sicher es auch wirken mag. Das ist der erste Test, den jede Entscheidung an unserem eigenen Produkt bestehen muss, und der Grund, warum das Setup standhält, wenn ein Kunde ein stark genutztes Repository anbindet.
Wie viele Tickets ein KI-Konto tragen kann, steht weiter unten unter „Heutige Zahlen“.
Wenn etwas schiefgeht
In jeder Auslieferungs-Pipeline geht etwas schief. Ein ohnehin instabiler Test schlägt fehl, ein Dienst ist kurz nicht erreichbar, ein Agent versteht ein Ticket falsch, eine Änderung kollidiert mit einer anderen. Entscheidend ist, was danach passiert und ob zuerst eine Person es bemerken muss.
Zuerst Selbstreparatur
Die meisten Fehler behandelt die oben beschriebene Reparaturschleife. Eine fehlgeschlagene Prüfung wird von einem Agenten gelesen, verstanden und behoben und dann erneut geprüft. In unseren ersten Kundenprojekten haben Agenten 150 Stufenfehler selbst repariert (die Zahlen stehen im Abschnitt zu den Zahlen). Jeder davon ist ein Moment, in dem in einem klassischeren Setup eine Person einen roten Build hätte bemerken, herausfinden müssen, wessen Problem er ist, und einer Korrektur hinterherlaufen müssen.
Fehler, die Dutopilot bei sich selbst findet, werden zu Tickets
Dutopilot beobachtet sein eigenes Verhalten. Erkennt es bei sich einen Fehler, zum Beispiel ein Ticket, das ohne Grund wartet, oder einen Schritt, der immer wieder auf dieselbe Weise fehlschlägt, meldet es das Problem als Ticket auf seinem eigenen Projekt-Board, so markiert, dass klar ist, dass es vom System kommt. Dieses Ticket wird dann von denselben Agenten wie jedes andere geplant, gebaut, geprüft und gemergt. Der Kreislauf im Diagramm oben ist real: Das Verhalten in der Produktion fließt zurück auf das Board und von dort in die nächste Änderung.
Deshalb vertrauen wir dem Setup auch in unserem eigenen Repository. Ein Problem lebt nicht in jemandes Erinnerung oder in einem Chat-Verlauf. Es ist ein Ticket, mit Verantwortlichem, Plan und Status.
Einige echte Beispiele für Fehler, die Dutopilot gegen sich selbst gemeldet und dann behoben hat. Es hat selbst gemeldet, dass eine Scheduler-Schleife hing, und sie behoben. Das Dashboard forderte einmal einen Kunden auf, sein Setup zu korrigieren, obwohl der Fehler bei Dutopilot selbst lag, und das wurde korrigiert, sodass die richtige Seite genannt wird.
Stopps, die eine Person allein lösen kann
Manchmal ist es richtig, anzuhalten und nachzufragen. Eine Entscheidung fehlt, eine Wahl hat Folgen oder eine Freigabe, die Sie gewählt haben, braucht einen Menschen. Hält Dutopilot an, messen wir uns an einem Maßstab, den wir Selbstbedienung nennen: Die Person, die die Meldung liest, muss den Stopp allein lösen können, ohne Dokumentation und ohne unsere Hilfe.
- Die Meldung sagt in einfachen Worten, was passiert ist, noch vor jedem technischen Detail.
- Sie sagt, wessen Problem es ist: die eigene Änderung oder das Setup.
- Sie nennt das eine, was die Person tun kann. Wo es eine sinnvolle Voreinstellung gibt, übernimmt Dutopilot sie und sagt es der Person, mit einer einfachen Möglichkeit zum Rückgängigmachen.
- Eine Antwort in den eigenen Worten der Person funktioniert. Es gibt keinen Spezialbefehl und keine Handarbeit an irgendetwas.
Das technische Detail (der Name der Prüfung, die betroffene Einstellung) steht zuletzt, für die Administration. Muss eine Meldung gekürzt werden, entfällt zuerst das technische Detail, nie die einfache Erklärung.
Was Menschen weiterhin tun
Automatisierung, die so tut, als wären Menschen überflüssig, ist nicht glaubwürdig, und das haben wir nicht gebaut. Menschen tun weiterhin die drei Dinge, die nur Menschen tun können.
- Die Arbeit auswählen. Was auf das Board kommt, in welcher Reihenfolge und was gar nicht lohnt. Priorität ist eine unternehmerische Entscheidung. Ein Agent kann den Aufwand schätzen. Er kann nicht wissen, was Ihr Markt in diesem Quartal braucht.
- Dort freigeben, wo Sie es festgelegt haben. Sie bestimmen, welche Schritte hinter einer menschlichen Freigabe bleiben: ein Plan, ein Design, ein Merge, ein Release. Eine Freigabe, die Sie wählen, ist eine echte Freigabe. Die Agenten warten darauf und sagen der freigebenden Person genau, was sie freigibt. Schritte, die Sie nicht gewählt haben, entscheidet Dutopilot, wenn es sich sicher ist, mit klarem Protokoll und einer einfachen Möglichkeit, die Entscheidung rückgängig zu machen.
- Produktentscheidungen treffen. Ob es eine Funktion gibt, wie sie sich anfühlen soll, welchen Kompromiss man eingeht. Agenten machen aus diesen Entscheidungen funktionierende Software. Das Urteilsvermögen dahinter ersetzen sie nicht.
Das Ergebnis ist ein anderer Arbeitstag. Menschen verbringen ihre Zeit mit Entscheidungen und Prioritäten. Sie lesen kurze Erklärungen statt langer Diffs. Sie müssen keine Builds mehr beaufsichtigen.
Die Zahlen
Zahlen helfen nur, wenn sie genau sagen, was sie zählen. Wir nennen zwei getrennte Gruppen und vermischen sie nicht.
Über unsere ersten Kundenprojekte
Diese Zahlen stammen aus unseren ersten Kundenprojekten. Sie wurden nicht am Repository von Dutopilot selbst gemessen, und wir stellen sie auch nicht so dar. Zahlen für unser eigenes Repository werden getrennt gemessen und erscheinen weiter unten in einem eigenen Kästchen.
Seit Juni 2026
Seit Juni 2026 haben Agenten über unsere Kundenprojekte hinweg 127 Tickets gemergt und 539 Agenten-Aufgaben abgeschlossen. Diese Projekte sind serpent.cloud, die Website eines Dienstleistungsunternehmens und ein Monorepo, das Salesforce und eine native iOS-App vereint. Die letzten beiden werden hier nicht namentlich genannt. Jedes Projekt hat sein eigenes Setup und seine eigenen Freigaben, und bei Kundenprojekten endet die Arbeit in Staging oder Test, und eine Person entscheidet, wann veröffentlicht wird. Lesen Sie die Zahlen als Breite, nicht als Tempo eines einzelnen Projekts.
Auf dem aktuellen Release, seit dem 19. August
Eine zweite, engere Gruppe wurde an denselben Kundenprojekten mit dem aktuellen Release gemessen, ab dem 19. August:
- 0,4 % der Commits auf den Arbeits-Branches stammten von einem Menschen. Der Rest wurde von Agenten geschrieben.
- 2 % der Tickets brauchten eine menschliche Freigabe.
- 54 Minuten betrug die mittlere Zeit vom ersten Commit bis zum Merge.
- 150 Stufenfehler haben die Agenten selbst repariert.
- 9 Stufen bilden den Weg eines Tickets.
Der niedrige Anteil an Tickets mit Freigabe ergibt sich daraus, wie diese Projekte ihre Freigaben eingestellt haben. Es ist eine Einstellung, keine Obergrenze. Wer bei jedem Merge einen Menschen möchte, kann das haben, und die Zahlen sehen dann anders aus, aus eigener Entscheidung.
Die Zahlen von heute
- Ein Claude-Ultra-Konto liefert etwa 50 mittelgroße Tickets pro Woche (etwa 25 Dateien je Ticket), also etwa 200 im Monat, wenn genug virtuelle Dutopilot-Teammitglieder darauf arbeiten.
- 8 virtuelle Dutopilot-Teammitglieder können an einem einzigen Tag etwa 50 Tickets abschließen, was etwa das wöchentliche KI-Kontingent eines Kontos verbraucht.
- Seit dem 29. September haben die Agenten von Dutopilot 497 Änderungen am eigenen Produkt von Dutopilot selbstständig gemergt und dabei mehr als 375 Tickets geschlossen.
- Im Solo-Plan hält das kleinere Dutopilot-Team (bis zu 3 virtuelle Teammitglieder) ein Konto bei etwa 100 Tickets im Monat. Im Team-Plan sind es etwa 200 im Monat für jedes Claude-Ultra-Konto, das Sie verbinden.
Wir verbessern Dutopilot jeden Tag, deshalb sind das die heutigen Zahlen (November 2026) und kein Durchschnitt über vergangene Monate. Die Kapazitätszahlen gelten für das Produkt, nicht als Messwerte aus Kundenprojekten.
Erkenntnisse für Ihr Team
Das sind die Erkenntnisse aus dieser Arbeitsweise, die für jedes Team gelten, das Auslieferungsarbeit an Agenten übergeben möchte.
Tickets für eine fähige Kollegin oder einen fähigen Kollegen schreiben
Die Qualität des Ergebnisses folgt der Qualität des Tickets. Ein Ticket, das das Ziel, die Zielgruppe und das Erfolgskriterium nennt, wird gut umgesetzt. Ein Ticket mit „Dashboard verbessern“ löst zuerst eine Rückfrage aus. Das ist ein gutes Ergebnis und günstiger als ein falscher Build.
Jede Änderung klein halten
Kleine Tickets bestehen das Review schneller, scheitern seltener und lassen sich leicht rückgängig machen. Ist eine Arbeit groß, teilt der Planungsschritt sie auf. Wehren Sie sich nicht gegen diese Aufteilung. Eine große Änderung ist ein Risiko, das Sie sonst tagelang mit sich tragen würden.
Getrennte Agenten prüfen lassen
Der Agent, der den Code schreibt, sollte nicht der Agent sein, der ihn freigibt. Ein unabhängiges Review findet Fehler, die der Autor nicht sieht, und die Befunde gehen direkt in die Reparaturschleife, statt auf dem Schreibtisch einer Person zu landen.
Prüfungen als einfachen Code umsetzen
Alles, was eine eindeutige richtige Antwort hat, etwa ob ein Test bestanden wurde oder ob sich eine Datei geändert hat, sollte von gewöhnlicher Software entschieden werden, nicht von der Meinung eines Modells. Nutzen Sie Modelle für Aufgaben, die Urteilsvermögen brauchen: eine Änderung lesen und entscheiden, ob sie zum Ticket passt.
Von Anfang an für viele gleichzeitig planen
Eine Pipeline, die für ein Ticket schnell ist und bei zehn stecken bleibt, ist nicht schnell. Prüfen Sie jede Regel am Fall mit viel Betrieb: kein Warten darauf, dass ein Branch aktuell ist, kein gemeinsamer Slot, der nie freigegeben wird, keine Wartezeit, die nur eine Person beenden kann.
Menschliche Freigaben bewusst wählen
Legen Sie fest, welche Schritte eine Person brauchen, und machen Sie diese Freigaben verbindlich. Alles andere sollte von selbst weiterlaufen, mit einem klaren Protokoll. Eine Freigabe, die ausgewählt ist, aber leicht umgangen werden kann, bringt den Menschen bei, Freigaben zu ignorieren.
Einen Stopp als Nachricht an einen Kunden behandeln
Schreiben Sie jede Meldung bei einem Stopp so, als würde sie jemand lesen, der das Werkzeug nie gesehen hat. Wenn diese Person nicht allein darauf reagieren kann, ist die Meldung nicht fertig.
Was das für Ihr Team bedeutet
Sie müssen kein Setup wie unseres selbst betreiben, um davon zu profitieren. Die praktische Variante ist eine betreute.
Sie behalten Ihr Projekt-Board und Ihre Repositories. Dutopilot verbindet sich damit (Jira, Linear, Notion, GitHub Issues oder Azure DevOps für das Backlog, GitHub, GitLab, Bitbucket oder Azure DevOps für den Code, Slack für Benachrichtigungen), und Ihr eigenes KI-Konto bezahlt die KI-Arbeit, sodass die Kosten in Ihrer Hand bleiben. Die Agenten laufen auf dedizierter Cloud-Infrastruktur, die wir betreiben, und jedes Ticket bekommt seine eigene Sandbox. Jedes virtuelle Dutopilot-Teammitglied in Ihrem Plan kann Hunderte paralleler Sub-Agenten steuern, in jedem Plan. Die Zahl der Tickets in Arbeit folgt der Zahl der virtuellen Dutopilot-Teammitglieder in Ihrem Plan (Solo bis zu 3, Team bis zu 15, Enterprise ohne Limit) und Ihren Freigaben. Die Pläne werden nach virtuellen Dutopilot-Teammitgliedern berechnet, nicht nach Nutzern: Ihr ganzes Team kann Dutopilot nutzen.
Der Forward Deployed Engineer
Jeder Kunde bekommt einen Forward Deployed Engineer, einen Ingenieur von unserer Seite, der mit Ihnen arbeitet und kein Support-Schalter ist, vor dem Sie sich anstellen. Er verbindet Ihr Board und Ihre Repositories, liest Ihre Codebasis und Ihre Konventionen, richtet die gewünschten Prüfungen und Freigaben ein und stimmt die Agenten auf Ihre Arbeitsweise ab. Er bleibt auch nach dem Start: Er beobachtet, wie Ihre ersten Tickets laufen, greift ein, wo Agenten ins Stocken geraten, und hilft Ihnen zu entscheiden, wann eine Freigabe gelockert oder verschärft werden sollte.
In der Praxis bedeutet das: Sie bekommen virtuelle Dutopilot-Teammitglieder und einen Ingenieur, der weiß, wie man sie in Ihrer Codebasis zum Laufen bringt, statt eines Werkzeugs, das Sie allein erlernen müssen. Der beste erste Schritt ist klein: ein Projekt, ein paar Tickets und die Freigaben, mit denen Sie sich wohlfühlen.
Starten Sie mit einem Projekt
Buchen Sie ein Gespräch, um zu sehen, wie das Setup auf Ihrem Repository aussehen würde, oder starten Sie kostenlos mit dem Solo-Plan.
Häufig gestellte Fragen
Baut Dutopilot Dutopilot wirklich selbst?
Ja. Das Repository des Produkts ist wie das eines Kunden mit dem gehosteten Dutopilot-Dienst verbunden. Tickets auf dem Projekt-Board werden von Agenten geplant, gebaut, geprüft, getestet, korrigiert und gemergt, und jeder Merge in main wird in die Produktion ausgeliefert.
Sind überhaupt Menschen beteiligt?
Ja. Menschen wählen die Arbeit aus, geben die Schritte frei, die sie bewusst hinter einer menschlichen Freigabe behalten wollen, und treffen Produktentscheidungen. Dazwischen erledigen Agenten die Auslieferungsarbeit.
Was passiert, wenn ein Agent etwas falsch macht?
Ein Reviewer oder ein Qualitäts-Gate fängt es ab, und ein Reparatur-Agent behebt den Fehler und schickt die Änderung erneut durch die Prüfungen. Lässt sich das Problem nicht lösen, hält das Ticket mit einer klaren Erklärung an, mit der eine Person allein weiterkommt.
Kann ich dasselbe Setup auf meinem eigenen Backlog betreiben?
Ja. Sie behalten Ihr Projekt-Board und Ihre Repositories, und Dutopilot betreibt Claude Code, Codex, OpenCode und Oh My Pi auf Ihrem eigenen KI-Konto. Ein Forward Deployed Engineer richtet es rund um Ihr Backlog und die gewünschten Freigaben ein.
Wie landen viele Tickets und viele Personen in einem einzigen main-Branch?
Jeder Agent führt den aktuellen Stand von main genau dann in seine Arbeit ein, wenn er ihn braucht, statt zu warten, bis sein Branch aktualisiert wird. So wartet keine Änderung auf eine andere, und ein stark genutztes Repository bleibt in Bewegung.