[Canonical HTML page](https://githits.com/blog/how-i-build-githits-with-githits/)
[Back to blog](/blog.md)
November 13, 2026 · 16 min read
# How I build GitHits: the setup behind nearly 2,500 merged PRs in October
A look inside the agent setup I use to build GitHits: how a normal day works, the three workflows, and the conventions that keep it moving.
In October 2026 I merged nearly 2,500 pull requests from my GitHub account in the githits-com org, and opened about 2,600. Agents wrote all of them; I set direction, review and merge. This post covers how the setup works, what a normal day looks like, and how work moves from a thought to a merged change.
Cumulative Orca counters for my account, all GitHits work, from August 3 to November 12, 2026. Agent time is the running time of the agents, not mine.
Before I started using Orca, in early August, I used Superset and merged about 75 PRs a week. The chart below shows what happened after.
My own merged PRs per week in the githits-com org, from June 1 to November 11, 2026. Weeks start on Monday and use Helsinki time; the last bar is a partial week. Source: GitHub.
## The shape of the setup
The setup is layered. I sit at the top, but I am not in the loop for every edit. Below me, Grok Bot does initial research and runs a set of always-on topic agents. [Orca](https://www.onorca.dev) is the runtime: each agent gets its own git worktree, and the sidebar is where I see them all. Inside those worktrees, orchestrators plan the work, hand slices to implementers, and send the result through reviewers. Shared conventions, documentation in each repository, a fast test suite, CI on Avrea, and GitHits for dependency knowledge sit underneath all of it.
The setup in layers: I steer and merge, Grok Bot and its topic agents feed work into Orca, and every PR comes back to me.
The models are stable. Codex with Sol-6.1 orchestrates and implements, and Sol hands most of the changes to Luna subagents. Claude Opus 5.5 does the code reviews. For campaigns that span many PRs, Claude Opus coordinates the work and dispatches the Codex implementers.
A change starts either with me, sometimes after a Grok Bot research pass, or with a topic agent that notices something and dispatches an Orca agent on its own. I come back when a decision is needed or the PR is ready to merge.
## A normal day
On a normal day I am not writing code. I am watching the Orca sidebar, where dozens of worktrees can be active at once. As I write this, Orca lists 74 agent worktrees across our repositories, 52 of them in progress and 17 in review. In August I had about 16 agent worktrees running in parallel.
I watch for an agent that has stopped. It may have a plan for me to check, a product question, a failed check, or a PR that is ready. I act on that and go back to the list. Most of my day is unblocking and merging. The rest of the design aims to make those stops rare, and to reserve them for decisions that are mine to make, not mechanical questions the agent should have settled itself.
The other thing I check is pings from the topic agents. They tell me what they have noticed, and I tell them what work to dispatch to Orca agents. When our Vulnerabilities agent flagged the latest Node.js vulnerabilities and told me a fix was available, I told it to dispatch Orca agents to bump the version in all our affected repositories. That was one message from me, and the PRs showed up in the sidebar like any other work.
## Three ways work gets done
The path depends on the size of the task and how contained it is.
One rule holds for every size: plans and code get reviewed across model families. Claude reviews Codex’s plans, and Codex reviews Claude’s. I have seen that different models find very different things. When Codex first reviews its own work and Claude reviews it after that, they find many more relevant issues than an internal review alone. Without it, too much AI slop gets in.
For a small, contained task, the agent plans the work, orchestrates the change, and notifies me when the PR is ready. Planning is short: the problem, the approach, the acceptance criteria, and what not to touch. The orchestrating agent keeps the judgment-heavy parts and delegates mechanical slices to Luna subagents, one concern at a time, with a clear way to tell whether each slice worked. I see the work when the PR is up.
For a larger task, the agent first writes a plan for the overall approach and the phases. The destination should be clear, but detail belongs in the next phase or two; inventing steps for work we have not reached is guesswork. Before a Codex plan reaches me, a Claude agent has reviewed it. That pass strips out a lot of the stupid and extraneous things, so I check the destination, the phase boundaries, and the decisions that are mine to make. Then I tell the agent to orchestrate. A phase that is already clear can plan and run on its own, and if a product decision appears, the agent raises it to me instead of guessing.
Campaigns are the third path, for work we already know will take tens of PRs, often across more than one repository. A Claude Opus agent acts as orchestrator and integrator. It holds the plan and operates Codex agents through a plan and orchestration cycle: each Codex agent takes a phase, usually in its own worktree, and comes back with a PR. The Codex agents read the plan and report against it; they do not rewrite it. Implementation runs in parallel. Integration stays serial, in an order the orchestrator sets, and shared contracts stay with the orchestrator. The orchestrator raises decisions to me, and I steer overall progress without reviewing every slice.
## Topic agents
Grok Bot topic agents are the always-on layer, and they have been very helpful. They notice work, dispatch Orca agents directly, and follow up on the results. SRE watches monitors, metrics, infrastructure sizing and error logs. Vulnerabilities tracks vulnerabilities in our infrastructure and in the ecosystem, and posts curated findings. Security audits development and infrastructure changes. Code Quality watches repositories for quality and technical-debt problems. Documentation keeps docs and agent instructions consistent.
I also use Grok Bot for initial research before I hand work to Orca agents: a first pass on the question, the relevant code or library, and the shape of the change.
## GitHits in the loop
My agents use GitHits all the time. In October they made nearly 10,000 GitHits calls in about 2,200 sessions, mostly Codex through the MCP server in our CLI. Most of it was searching and reading real open-source source and docs, plus package checks for vulnerabilities, changelogs and upgrades.
When an agent works with a dependency, it checks the code instead of guessing from memory. For example, when agents were fixing how we pick Ruby gem versions, they read the RubyGems and Bundler source through GitHits. That surfaced a rule that is easy to get wrong from memory: if an app’s Gemfile asks for a beta version, Bundler accepts prereleases right away, but if a library’s gemspec asks for the same thing, a stable release still wins when one matches. I don’t have to push agents to find out instead of making things up. They check the source. If you want your agents to do the same, run `npx githits@latest init`.
## Conventions, documentation and audits
We keep a shared collection of conventions as the source of truth: baseline guidelines for architecture, planning, review, testing and documentation, with addenda per language. Every project points its agents at it, and the same collection holds the shared skills, so planning, orchestration and review mean the same thing wherever an agent starts.
The docs in each repository are written for humans and agents: the why, the decisions, and where to look, so an agent can make a sensible choice from a single read. When a change alters any of that, the agent updates the docs in the same change.
We also run recurring audits on the codebase to groom documentation, improve test quality and find gaps. Instruction drift is worse than missing instructions, because an agent will act confidently on a stale claim. The audits catch that.
## Review and guard rails
Code review follows the same pattern. An implementer first gets an internal preflight. Then a model from another family, usually Claude Opus 5.5, reviews the change with fresh eyes. A final check runs in a fresh context, so the last look is not a continuation of the same conversation. Reviews get a maximum of three rounds. If they do not converge, the work stops and waits for me.
Agents may commit, push, open a PR and run CI. Merge, release and deploy wait for my approval. Agents do not grow the scope or add machinery without asking, and they are supposed to fix the root cause rather than add a fallback.
## Tests and infrastructure
The other requirement is a test suite fast enough that an agent can wait for it. Agents run targeted tests locally, git hooks handle formatting and linting, and the full suite runs in CI on every push. As of November 12, 2026, our Elixir backend runs about 35,000 tests in under three and a half minutes. Our Rust indexing engine runs about 19,000 tests in roughly a minute and a half of test time, a little over four minutes including compile. Together the two suites gained about 4,900 tests in the ten days since November 2, while run times stayed flat or got shorter.
Our CI pipelines and benchmarks run on [Avrea](https://avrea.com/ci-runners), which gives us fast runners and the [`avr` CLI](https://docs.avrea.com/cli/), so agents can easily check and analyse how runs went. The tightest local limit has been my hardware. For a long time I was constrained by an older M1 laptop, where I had to limit parallel Rust compilations to two. I recently got a new Mac Studio that runs six parallel Rust compilations easily, so that will likely unlock more development speed.
## What that looks like in practice
[githits-scan](https://github.com/githits-com/githits-scan) is an example of agents talking to agents. It is an open-source command-line tool that scans a project’s dependencies and turns them into an SBOM, an audit or a license report. It is on Homebrew, and we wrote about the launch in [Introducing githits-scan](https://githits.com/blog/introducing-githits-scan/). Work on it was underway by mid-September, and it went public on November 5 with 0.3.0. 0.4.0 followed on November 9 and 0.5.0 on November 12. Every commit in the repository was written by an agent, including the early history we rewrote when we opened it up. Scan relies on GitHits package data, so when scan needs something the data does not have, the fix lives in another repository.
The clearest chain started with licenses. While scan was running against one of our own Elixir projects, the agent working on scan found that license data was missing for a lot of Elixir packages. It did not patch around the gap in the CLI. It dispatched an agent in the backend indexing repository, and that agent spawned deeper agents in the underlying components to fix the root cause for every package. When the data was right, the agent that owns our public API updated the API contract and told the scan agent the new data was available. I merged the PRs, but I did not carry anything from one repository to the next.
A smaller chain followed after launch. Scan’s audit output said a dependency was blocking, but not which one. The scan agent started a backend agent to add the missing `dependency_name` field, then a public API agent and the CLI change that used it ([scan pull request #9](https://github.com/githits-com/githits-scan/pull/9)). We are now working on a GitHub Action for scan, so the same checks can run in CI.
## What those PRs bought
A PR count says little on its own, so here is what October actually shipped.
On the surface you can touch, it was 16 CLI and MCP releases. Research became the stable default. Source diff and target resolution came out of experimental. The MCP server got one unified `grep` across packages, repositories and documentation. Upgrade reviews started classifying release-note evidence, vulnerability checks started covering unknown and transitive dependencies, and Launchpad repositories became indexable. The lockfile analysis API that [scan](https://githits.com/blog/introducing-githits-scan/) is built on landed too.
The biggest single chunk was not visible at all. About one in five of my October PRs went into one campaign: making indexing much faster for incremental refs, the everyday case where a repository moves forward and we should pay just for what changed. Most of that work shipped silently, behind feature flags. I started rolling it out in production on November 12. The first runs show incremental indexing 30% to 46% faster, and we will get more accurate numbers as the rollout widens over the coming weeks. Many PRs in a campaign like that are steps, and the visible result arrives in far fewer releases.
From a random sample of 500 of my October PRs, about two in five added capability, fixed bugs or made things faster. The rest were tests, benchmarks, refactors, documentation and infrastructure, the work that keeps the next change safe. About one in nine was something a user could clearly notice, because much of the new capability was built behind feature flags.
The setup isn’t perfect, and we also occasionally break things. In October we had one user-visible, code-related issue, on the [Index explorer](https://index.githits.dev/). At the end of the month, a bug made some of its lookups ask for a repository literally named `true`. Over five days, about 340 of the site’s roughly 16,000 backend requests failed because of it. Our MCP server had no measurable incident in that period. The review loop, the tests and our own daily use of the product keep the damage small and the fixes fast.
## What still needs me
I still haven’t automated myself away, and software engineering still isn’t dead. Agents lose track of what matters on a long stretch of work, and I have to reorient them. Writing code no longer limits throughput. My decisions do, and until recently so did the laptop. Campaigns absolutely drift if I stay away too long. Agents are not a replacement for good judgement.
A recent campaign on our indexing engine drifted constantly. The orchestrator stopped whole lanes of work because we had agreed to cut a release, even though those lanes could have kept going in parallel while the merges waited. It merged a PR that would trigger a fleet-wide reindex for some languages, while it knew a second PR to finish the change was still in progress. And it invented its own gates, such as requiring a 10% improvement to overall indexing performance, then dropped optimisation PRs that did not clear them. None of those calls were what we had agreed. Each looked locally reasonable to the agent, and each needed me to steer it back.
Agents do great tactical work, but most of the structural improvements to our index started with me pointing out that the possibility was there. Once it was named, the agents could research, evaluate, plan and implement it. Seeing it in the first place was still my job.
## From a personal harness to a software factory
This setup started as mine, and parts of it have spread. Olli-Pekka uses similar Orca flows. Nathan tried the same path and then moved to Grok Bot with Codex, which fits his product-surface work better. We are a small company and have not formalised this into a software factory, meaning an application or workflow that coordinates agent-driven development. I think many teams get there this way: one person’s setup gets shared, the rules get written down, and the team either grows it into an ad hoc factory or adopts a factory product. Olli-Pekka wrote about what that means for code review in [Someone still has to read the code](https://githits.com/blog/someone-still-has-to-read-the-code/).
GitHits helps at both scales. For one developer, the CLI and MCP server plug into the coding agent they already use. Inside a factory, the REST API lets the factory call GitHits from its own planning, coding, review and update steps. Its v1 contract is public for evaluation and not final yet. GitHits leaves coordination to whatever runs the agents and supplies the dependency context they need. There is more in [GitHits for software factories](https://githits.com/who-its-for/software-factories/).
If your agents work with open-source dependencies, run `npx githits@latest init` to configure the GitHits MCP server, or see the [setup guide](https://githits.com/init). If you are building your own factory, the GitHits REST API gives your agents the same data over HTTP. Orca is open source at [onorca.dev](https://www.onorca.dev).
[Engineering](/blog/tag/engineering.md) · [Agents](/blog/tag/agents.md) · [Workflow](/blog/tag/workflow.md)
Juha Litola — Co-founder, Chief Architect
Keep exploring
* [The Solution](/the-solution.md)
* [Documentation](https://docs.githits.com/)
* [Changelog](https://docs.githits.com/changelog/overview)
Get started
## GitHits in one command
Install GitHits or refresh an existing setup with the same command.
`npx -y githits@latest init`
Or connect directly
* [Claude connector](https://claude.ai/directory/githits)
* [ChatGPT plugin](https://chatgpt.com/plugins/plugin_asdk_app_6ae059be511481918e3573fb5885dbb8)
* [Cursor plugin](https://cursor.com/marketplace/githits)
- [Vercel connector](https://vercel.com/connect/githits)
- [Manus connector](https://manus.im/app#connectors/all/connector_8387945e-9687-4a71-86b4-8a220dbd5b6b)