Totals, on the three client projects: 127 tickets merged and 539 agent tasks run since June 2026.
Current release, measured separately since 19 August: 0.4% human commits on branches and 2% of tickets needing a human approval, on the same client projects.
Speed: a median of 54 minutes from first commit to merge, on the same current release and client projects.
The challenge
Dutopilot delivers client projects with the same pipeline it sells. Every figure on this page was measured on three client projects: the website of a Salesforce services company, the website of serpent.cloud, and a monorepo that holds Salesforce and native iOS code. None of them was measured on Dutopilot's own repository. The goal was to let Dutopilot virtual team members carry the routine delivery work and keep the client's people for the decisions.
Before the pipeline, the routine work of a ticket sat with people: someone wrote the plan, built the change, read the pull request, chased failing checks and clicked merge. That work is necessary, and most of it is repetitive.
Before and after
| Step | Before | Now |
|---|---|---|
| Plan | A person writes it. | An agent proposes it. A person approves it where the change is new or risky. |
| Build | A person. | An agent, on its own branch. |
| Checks | A person waits for them and chases failures. | One combined verdict. Failures go straight to a fixer agent. |
| Review | One person on your team, when they have time. | Separate Dutopilot virtual team members as reviewers, on every pull request. |
| Merge | A person clicks the button. | The pull request merges itself when everything is green, under branch protection. |
| Production release (on these client projects) | A person decides. | A person still decides. |
How it works
Each ticket from the project board goes through nine stages: architect, planner, implementer, gate, three reviewers, autofixer and QA. Around them, people set the human gates once per project, the pipeline picks up the ticket before the first stage, and a person releases to production after the last. Those three are not stages. The ticket shows where it stands.
- Architect: proposes a file-level plan, the data flows and a test plan before any code is written. A person approves it where the change is new or risky.
- Planner: turns the approved architecture into an ordered list of tasks for the implementer.
- Implementer: writes the change on its own branch.
- Gate: runs the automated checks on the pull request and returns one verdict.
- First reviewer: a separate agent reads the change on its own.
- Second reviewer: another separate agent reads the change independently.
- Third reviewer: a third separate agent reads the change independently.
- Autofixer: repairs what a check or a reviewer found, and the gate runs again.
- QA: the change merges to staging or test and QA tests the result.
On these client projects, merged work reaches the staging or test environment and a person releases to production. Dutopilot also builds its own product the same way.
One ticket, from board to merge
This is an illustrative ticket from the website projects, to show what each stage produces: "Add an industry filter to the case studies page".
| Step | What happens |
|---|---|
| Ticket | A product person writes it with the outcome and what done looks like, and marks it ready. |
| Architect and planner | The architect posts the files it will change and the tests it will add, and the planner lists the tasks. A person approves, because it changes how a page behaves. |
| Implementer | The implementer builds the change on its own branch and opens a pull request. |
| Gate | Lint, build and tests run. One test fails. |
| Autofixer | The autofixer receives the failing log, fixes the code, and the gate passes on the next run. |
| Reviewers | The reviewers leave comments. The autofixer answers them and the checks run again. |
| QA | The pull request merges to staging or test and QA tests the result. |
| Release (a person) | On these client projects, a person releases to production. |
On the current release, the median time from first commit to merge is 54 minutes.
When something fails
Failures are expected, so the pipeline plans for them. A failed check or a review finding goes back to a fixer with the exact log or comment. A test that fails at random is retried and repaired, so it does not block good work. Since 19 August the pipeline has repaired 150 stage failures on its own. When a fix stops getting closer, or the risk goes up, the run stops and the ticket asks a person.
Results
| Measure | Result | Period and scope |
|---|---|---|
| Tickets merged | 127 | Since June 2026, across all three projects |
| Agent tasks run | 539 | Since June 2026, across all three projects |
| Human commits on branches | 0.4% | Current release, since 19 August |
| Tickets that needed a human approval | 2% | Current release, since 19 August |
| Median time from first commit to merge | 54 minutes | Current release, since 19 August |
| Stage failures repaired by the pipeline | 150 | Current release, since 19 August |
All rows come from the three client projects. The first two rows are totals for the whole period. The other rows are measured on the current release only, so the two groups are not meant to be compared with each other.
What people still do
- Decide the architecture of anything new or risky before code is written.
- Approve the changes in the areas where a mistake is costly.
- Release to production, on these client projects.
- Answer when a ticket stops and asks for a decision.
The approvals are your choice. The guide on choosing which steps need approval shows how teams set them.
In practice that is a product person writing and ordering tickets, an engineer approving plans and sensitive changes, and a delivery lead deciding on releases. The rest of the time nobody has to watch, and the ticket says when a person is needed.
Every customer gets a Forward Deployed Engineer
A Forward Deployed Engineer from Dutopilot works with your team from the first day. They do not write your product code. They fit the pipeline to the way you already work.
- Onboarding: they connect your tools with you and choose the first slice of the backlog.
- Ticket readiness: they agree a short ticket template with your product owner so agents get clear work.
- Approvals and gates: they set which plans and which parts of the code need a person, to match how your team reviews.
- Ongoing improvement: they review stalled tickets and results with you, and move gates as trust grows.
What this means for your team
One Claude Ultra account delivers about 50 medium-sized tickets a week (about 25 files changed per ticket on average), about 200 a month, when enough Dutopilot virtual team members run on it. On Solo, the smaller Dutopilot team (up to 3 virtual team members) keeps one account at about 100 tickets a month; on Team, you get about 200 tickets a month per Claude Ultra account you connect. 8 Dutopilot virtual team members can finish about 50 tickets in a single day, which uses about one account's weekly AI allowance. Each agent in a plan is a virtual team member. Each virtual team member can run hundreds of parallel sub-agents, on every plan, and Enterprise has no limit on how many agents you run. Plans are priced by Dutopilot virtual team members, not by users: your whole team can use Dutopilot. Dutopilot works with Jira, Linear, Notion, GitHub Issues and Azure DevOps for your backlog, with GitHub, GitLab, Bitbucket and Azure DevOps for your code, with Slack, and with Claude Code, Codex, OpenCode and Oh My Pi as the AI. To see it on a slice of your own backlog, book a call.