Two years of one repository, 2,210 merged PRs, recomputed from git. What a flock of AI coding agents actually changed — and why MindFlock runs them on my own laptop instead of a vendor's VM.
Before I ran AI coding agents, a typical pull request of mine was 68 lines across
4 files. Now it's 873 lines across 13.
You should find that alarming. I did. A workflow that makes diffs an order of
magnitude bigger is, on the face of it, a machine for manufacturing code nobody reads — and the reason most "AI made me 10× faster" posts don't survive a hostile reader is that they stop right here, at the volume number.
So here's the row I was afraid to compute. Across the same 2,210 merged pull requests: the share that touch a test went from 5% to 88%. One in twenty, to nine in ten.
That's the number that turns bigger diffs into a finding instead of a confession. If the extra volume were an agent padding, coverage would have stayed flat or fallen. It went up 17×.
And one more, which is the actual point:
My ticket throughput barely moved. 43 closed per month before agents, 55 now.
I did not start shipping more tickets. I started shipping much more finished tickets — tests included — in about the same number of them. All the change is inside a ticket, which is precisely the thing per-ticket velocity dashboards cannot see.
This post is what produced that, how it's measured, and the one design decision I'd defend hardest: all of it runs on my own laptop.
The full numbers, and the method
One developer's repository, two years, recomputed from git and the tracker's API rather than estimated or remembered.
| before agents 2024-07 → 2025-12 |
one agent at a time 2026-01 → 03 |
a flock 2026-04 → 07 |
|
|---|---|---|---|
| Tickets closed per month | 43 | 53 | 55 |
| Median source lines per ticket | 114 | 168 | 979 |
| Median source lines per PR | 68 | 210 | 873 |
| Median files per PR | 4 | 7 | 13 |
| PRs that touch tests | 5% | 58% | 88% |
| Peak branches in flight in one day | 16 | 13 | 31 |
| Reviewed source per engaged half-hour | 72 | 208 | 453 |
That last row is the headline if you want one: 6.3× more reviewed source code per half-hour at the keyboard, at a flat ticket rate.
How each is derived, because a number you can't check is a number you shouldn't
believe:
-
Source only. Lockfiles, generated and minified files, images, CSVs, notebooks,
dist/,vendor/,node_modules/and DB dumps are excluded. They're under 1% of the lines in the recent period, so they're not what moved. - Medians, never means. One month contains a single 1.6 M-line bulk import that wrecks every average in the dataset.
-
Per-PR diff =
git diff <base> <branch-tip>at the merge commit, from the local clone, for all 2,210 merged PRs by one author. - Engaged half-hour = a distinct 30-minute window containing at least one commit on one of those branches.
That last definition is worth dwelling on, because it works against me. In the recent period some of those commits are an agent's while I was making coffee, which inflates the denominator. 6.3× is a floor. It also holds between 5.5× and 7.2× for every reasonable choice of era boundary.
Two things that got worse
- Wall-clock cycle time got longer. The tracker's start→done clock measures review, QA and deploy queues, and no coding tool touches those. If you're being sold "faster tickets," ask which clock.
- It isn't free. 13.5 billion tokens went through agents on this machine over 46 logged days.
Why a flock, and not just one agent
Look at the middle column again. Adopting one agent roughly tripled the size of a typical change — 68 → 210 lines. Going from one agent to several multiplied it by four again on top of that. The second step was the bigger one.
The reason isn't throughput, and this surprised me: an average day is 5–8 branches in flight in both eras, and always was. What moved was the ceiling — 16 → 31.
Parallelism isn't something you use all day. It's what you need on the days when six things are half-finished at once, and those were exactly the days that used to cap out. Raising that ceiling meant one place to see every session, one worktree each so they can't step on each other, reliable per-agent state (working / idle / needs-input), and the next git step always one button away.
That tool didn't exist the way I wanted it, so I built it. It's called
MindFlock, it's Apache-2.0, and it's been my daily driver for
three months.
What it does
When a ticket is assigned to me in GitHub Issues, Jira, Linear, Shortcut or Asana, within about 20 seconds and with nothing typed:
- It gets its own git worktree on its own
feature/<ticket>/<slug>branch, cut from a cached clone so the second ticket doesn't re-clone the repo. - Dependencies install before the agent starts — auto-detected for Python/uv
repos, one declared
setup_commandsline for anything else. - An agent CLI launches already seeded with the ticket: title, description, acceptance criteria mined out of the markdown, and the comment thread.
- It appears in a grid as a live terminal with a stage badge, beside every other session.
Then I do the part that needs a human — read the diff — and drive it home with one click each: commit (which runs in that session's own terminal, so I watch the hooks fire), push, open the PR, merge.
Pull requests that come back with review comments become sessions the same way, on the PR's own branch, with the unresolved inline review comments as the prompt. Outdated threads and top-level PR chat are skipped, and a PR is left alone until it's at least 15 minutes old, so a branch you just pushed doesn't get jumped on.
Over 38 days: 38 tickets provisioned into sessions with nothing typed, 22 hours median from provisioning to a merged PR, 42 of my own PRs triaged for review comments.
The design decision: it runs on your machine
Assigning a ticket and getting a PR back isn't rare anymore — it's first-party at GitHub, Google and Atlassian, plus Devin and Cursor. They work. They also share one property:
| where the agent runs | your repo is cloned to | |
|---|---|---|
| Devin (Cognition) | vendor sandbox | Cognition |
| Google Jules | vendor VM (no self-host option) | |
| GitHub Copilot coding agent | Actions runner | GitHub |
| Cursor background agents | vendor sandbox | Cursor |
| Atlassian Rovo Dev | remote sandbox | Atlassian |
Every row ends with a machine I don't own holding a checkout of my repository. For a side project, fine. For client code under an NDA, or anywhere someone has to answer "which third parties process this source" in writing, that column is the conversation.
MindFlock has no cloud in the middle: no service, no account, no sandbox with a copy of your repo. The engine is a process on your laptop bound to 127.0.0.1; the agents are the same CLIs you already run in a terminal, launched into a worktree on your own disk, on your own subscription.
The honest boundary
I'm not going to tell you your code never leaves your machine. That claim is false for anything that wraps a hosted agent CLI, including this. claude sends code to Anthropic and codex sends it to OpenAI, exactly as they do when you run them yourself in that repo.
What's true is that MindFlock adds no hop and no third party. The vendor call is one you were already making; nothing new gets a copy. Everything MindFlock itself touches over the network, in full:
| It calls | When | What it sends |
|---|---|---|
| Your tracker's API | every ~20 s while ingestion is on | nothing — read-only. Never comments, never moves a status |
api.github.com |
polling your own PRs for review comments; the PR/merge buttons | what gh would send if you ran it |
aipricing.guru |
at most once a day, for the cost display's price table | nothing. Falls back to a built-in table offline |
| your git remote | only when you click push | your commits, over the remote your repo already has |
ntfy.sh or your own instance |
only if you switch phone push on | the notification text |
| GitHub Releases | the desktop app's update check | nothing |
No analytics, no telemetry, no crash reporting, no license check, no phone-home of any kind. The tree is public — grep it rather than believing me.
And if that one remaining call is the one you can't make, close it. Point sessions at a model you serve yourself (Ollama, LM Studio, any OpenAI-compatible server) and there's no code egress at all: no API key, no subscription, nothing crossing the network. That applies to ingested sessions too, so a ticket can go from assigned to committed without leaving the machine. Works with codex, aider and goose, which have native local-model support. claude speaks only the Anthropic API, so it has no
local route — and mindflock doctor says so out loud instead of letting a session quietly keep using it.
What it never does by itself
A pipeline you can't trust is worse than none:
- Every git action is your click. Commit, push, open PR, merge. You write the commit message; the PR body is filled from your commits.
- Your tracker is read-only. No comments, no status transitions. A bot that edits shared tickets turns its mistakes into other people's confusion.
- Only your own pull requests get picked up for review work.
- No inbound endpoint. It polls, so there's no webhook to configure and no secret to rotate.
- Ingestion is a switch, off until you flip it, and it stays where you left it.
Every agent CLI is just a TOML file — binary, launch args, prompt seeding,
activity-detection hooks, pricing — so Claude Code, Codex, Antigravity, aider, OpenCode, Cline, Goose or something nobody's heard of all get the same state detection
and cost tracking. Adding one is a config change, not a patch.
Who this is for, and who it isn't
If the vendor-VM row is a blocker for you — contract work under NDA, regulated code, a security review that asks who sees source — you get this loop on hardware you already own, and with a local model you get it with zero egress.
If you maintain something on GitHub Issues, it's the cheapest on-ramp: gh is already authenticated and origin is already right, so ingestion is one switch and no config.
If you already run several agents by hand, it's a decent parallel-agent workspace and plenty of my days never touch a ticket — + New, pick a repo and an agent, type a prompt, get another isolated worktree beside the rest. Same grid, same diff view, same guided git bar, same phone UI. A tracker is a source of sessions, not a requirement for them.
Where I'd point you elsewhere. If you want the cloud, you're right to — work continuing while your laptop is shut, someone else's compute paying for tokens, a fleet grinding one backlog. Those are real and MindFlock has none of them. If you're Mac-only and want native, Conductor is SwiftUI and solid. If you live in the terminal, Claude Squad
is a mature multi-agent TUI, and Claude Code's own Agent Teams plus worktrees are free and already installed.
And the obvious objection: yes, you could build the intake half yourself. A workflow on issues.assigned, running an agent CLI on a self-hosted runner, gets you issue → PR on your own hardware. OpenHands' resolver does it today off a fix-me label, self-hosted and MIT. A handful of local orchestrators now poll trackers too. If a label-triggered CI job covers your case, use it — it's less software to trust. What I wanted and didn't find was the personal version: assignment to me, across five trackers rather than one repo's Actions
config, landing in a supervised grid where the diff and the whole git loop are in front of me rather than in a run log. That's the part I built, and it's a difference of shape, not of capability.
Try it
Visit:
both have download links. A github star would also be very appreciated if you like the project. It lets me know there is interest so I will continue developing
Desktop app for macOS, Windows (engine runs in WSL2) and Linux is on the
releases page. You need git, tmux and an agent CLI; gh is optional and only makes the PR buttons one click. mindflock serve tailscale prints a QR code — the phone UI carries the same diff view and guided git bar, so you can read and approve work from a phone.
Where it stands
One person, evenings and weekends, as-is under Apache-2.0, no support SLA,
hobby-project response times. Better to know that now than after you've wired up a board.
The Shortcut connector is the best-tested because it's the one I use daily — so if you run Jira or Linear against a real board, a bug report from you is worth more to me than anything else you could send. Same for the table above: it's an July 2026 snapshot of a space that moves weekly. If a cell is wrong, open an issue and I'll fix it.
Thanks
I really appreciate any feedback or comments you have on MindFlock. I use it everyday for my job and I get a lot of added value from it. I've open sourced it and shared it with you all so you can benefit as well as help me to continue to improve a tool that is useful to all of use. Thanks everyone :)
Top comments (0)