Twelve weeks, one developer, 279 merge requests
Between 20 August and 13 November 2026 the author of Mergehand used it for daily work on two projects: a commercial web product maintained by a team, in six repositories, and Mergehand itself. These are the numbers from the production database – counted, not estimated.
This is our own use, not an independent customer study. It shows what one developer did with the tool, including the parts that needed a human.
The short version
- 203 of 231tasks reached a merge request. Of the rest, 11 were dropped by the developer, 8 ended as an analysis, 7 were turned into an epic and 2 were still running.88 % · tasks started in the period
- 268 of 279merge requests opened by Mergehand are merged. In the team product, where colleagues review the code, it is 142 of 153.96 % · 6 still open, 5 closed unmerged
- 4.4 minfrom starting a task to a plan ready for approval.median · 213 tasks
- 36 minof agent work from the start of a task to its first merge request. On the clock, with the waiting for approvals, it was 1 h 45 min.medians · 198 and 202 tasks
- 868findings raised by the independent review inside the task, before any merge request existed.386 review passes · 202 tasks
- 1,612code review runs on 635 merge requests in ten repositories; 378 of them were written by other people.median run: 2 min
From ticket to merge request
A task runs unattended between the two approvals. From the approved plan to a result ready for approval – implementation, review, fixes and testing – the median was 27 minutes.
| Measured | Median | Middle half of tasks | Tasks |
|---|---|---|---|
| Start → plan ready | 4.4 min | 3.2 – 7.2 min | 213 |
| Plan approved → result ready | 27 min | 16 – 47 min | 200 |
| Agent work up to the first merge request | 36 min | 22 – 58 min | 198 |
| Start → first merge request, on the clock | 1 h 45 min | 54 min – 3 h 53 min | 202 |
Per calendar week, the median was 12.5 tasks started and 16.5 merge requests opened.
What the review caught before anyone saw the code
Inside every task, a fresh agent that did not write the code reviews it, and another one tests each acceptance criterion. Before the first merge request of a task existed, these reviews raised 868 findings in 386 passes, followed by 264 fix passes and 272 test passes. 125 of 202 tasks had at least one finding; the median task had two.
The loop does not catch everything. After the push, an independent code review of the new merge request runs automatically – and on 166 of 215 such merge requests it still found something. That is why it runs every time, and why its findings go back to the same task for a fix: of the findings decided so far, 341 of 427 were fixed this way.
Where the human stepped in
- Plans. 201 plans were approved. 52 of them with a single click; the other 149 after at least one message – an answer to the agent's question, a question back, or a request to change the plan.
- Questions. In 101 of 203 tasks the agent stopped at least once to ask instead of guessing.
- Results. 122 of 201 results were approved as first presented. The other 79 were questioned or sent back before the push.
- After the merge request. 170 of 203 tasks were reworked at least once after the merge request was open – review comments from colleagues or a changed mind. The median was two reworks.
The two approvals are not a formality. They are where most of the developer's time went, and where the task was steered.
Code review of other people's merge requests
Most code review runs were not about Mergehand's own code: 378 of the 635 reviewed merge requests were written by colleagues. A run took two minutes at the median, and the first review of a merge request found at least one thing in 453 of 632 cases.
Findings are drafts that only the reviewer sees. Since the application started recording what happens to each one, the developer published 260 of 301 decided findings on colleagues' merge requests – 252 as written, 8 after editing – and deleted 41.
What these numbers are not
- Not a team rollout. One developer on one runner. How a whole team works with Mergehand is not in this data.
- Not time saved. Nobody measured how long the same work would have taken without the tool, so we do not claim a number.
- Not all independently accepted. In the Mergehand project the developer merges their own pull requests. The team product, with 142 of 153 merge requests merged, is the more independent half.
- Not a cost figure. The work ran on the developer's own AI subscription, which Mergehand does not see or bill.
How we measured
- All figures are aggregates from the production database, taken on 13 November 2026, for tasks and review runs started since 20 August 2026. A test project is left out.
- Times are medians; the middle half is the range between the 25th and the 75th percentile. No outliers were removed.
- A task reached a merge request when Mergehand opened at least one for it. A merge request counts as merged by its state at the code host.
- Agent work is the time the agent and the server were working, without waiting for the human.
- What happened to each code review finding is recorded since October 2026; earlier findings are not counted in those two figures.