The week the repo outgrew me#
career-ops went live earlier this year. In April it took off: 12,000+ stars in 2 days.
With the stars came the workload. On one documented night alone: 9 new PRs and 11 new issues before breakfast.
While I held a full-time job as Head of Applied AI at a software company, my realistic budget for open source was about 4 hours a week. A repo this size wants a full-time maintainer. Career-ops is now my primary focus — but the 4-hour discipline is what shaped the system, and the fleet still does the mechanical work.
So I rebuilt how the repo gets maintained. My job changed shape: I run the system that does the work, and I keep the decisions.
The fleet#
Each agent is a persistent Claude Code session in its own tmux window, with its own memory. They coordinate through file-based IPC: JSON request/response files in a shared directory, with polling. The coordination layer is files: a decoupled state machine where every message is a readable artifact and every decision leaves a trace you can replay. It scales to a 59,000-star repo and still debugs with cat.
| Agent | What it does |
|---|---|
| Maintainer agent | The orchestrator: triage, PR review briefs, merge mechanics, releases, issue lifecycle |
| Discord agent | Community announcements and channel management, handed off as digests with drafts included |
| Web agent | Owns the first-party web layer; web PRs get labeled and routed to it |
| Dogfood agent | Runs the tool as a real user in a clean clone and files structured friction reports |
| Ephemeral verifiers | Read-only fan-outs in isolated git worktrees: parallel PR testers, adversarial reviewers, claim checkers. They report evidence and stop there. |
Two loops run unattended and survive reboots. An early-morning triage-prep pre-classifies the overnight flow, drafts included. An hourly delivery-watch detects when a contributor actually pushed after an ask: it watches the branch head change, because the "updated" timestamp also moves on comments and produces false positives.
The split is strict. Agents classify, test, watch, measure and draft. I decide what enters the core, merge order, governance and releases. Agents propose with evidence attached. The last word is mine.
The gates#
Letting AI merge unsupervised would be negligence. Every gate below exists because something real broke first:
Test before deciding, on a clean checkout.
Every PR runs against the full suite locally before any decision. And for environment-dependent code, clean-environment CI is the arbiter: a local run once passed while CI failed, because my populated working copy never exercised the "user files missing" path.
The first-timer gate.
First-time contributors' CI runs get explicitly approved and waited on until green. Never admin-bypassed. One PR went through the gate twice in a single day because updating the branch reset the approval. We waited twice.
Live CodeQL for anything that parses text.
A security fan-out once approved a parser PR; the live CodeQL check then blocked it with a high-severity double-escaping finding the agents structurally could not see. CodeQL catches classes of bugs the test suite never exercises.
Adversarial review for plugins.
Community plugins get reviewed by multiple independent agents instructed to break them: network egress, path traversal, ToS posture. The registry pins each plugin to a reviewed SHA, so users only ever install code a review approved.
Announcements gated on exit code.
A public "Merged! 🚀" posts only after the merge command returns success. A premature announce burned us twice before this became law.
Claims verified before public action.
Anything that would trigger a request-changes, a close, or an edit to a sensitive file gets reproduced against the real diff first, whether the claim came from an agent, a contributor, or my own grep.
Sensitive-file tiers and a written data contract.
Files are classified by blast radius; critical-file changes without prior discussion get closed by policy. PRs that touch user data are rejected outright.
Security and isolation#
Agents run third-party code at machine speed, so the boundaries have to be explicit. Git worktrees isolate the file system. They do not isolate the runtime: when an agent tests a contributor's PR, that code runs on my machine, the same trade-off every OSS maintainer accepts the moment they check out a stranger's branch.
The defenses are layered by trust. Code passes GitHub Actions and live CodeQL in GitHub's own sandbox before any agent touches it locally, and a first-time contributor's CI won't even run without explicit human approval. A pre-merge gate lists every sensitive file a diff touches before deep testing starts. And the test agents themselves are stripped down: read-only by contract, with every external tool stripped out (chat integrations, MCP servers included), which keeps the blast radius small.
What's missing, said plainly: least-privilege service accounts are on the roadmap, not in place. That gap is real, and it's next on the hardening list.
When the infrastructure fails#
The design principle that holds everything together: GitHub is the canonical state. Everything local (session files, briefings, the logs) is a re-derivable cache plus an append-only record. A session that dies gets rebuilt, and the orchestrator's first phase re-checks every item against GitHub before acting, because a PR can merge or close while nobody was looking.
One rule here took a real incident to learn. An unsupported flag plus a silenced stderr made a watcher swallow its own error, and it reported "no contributor deliveries" as a success, for hours, on an active afternoon. It got caught because the result contradicted what the day felt like. The rule since: the command that feeds a decision never silences its errors, and a failed check reports "could not verify" rather than "nothing found".
The memory that compounds#
Three artifacts make each session smarter than the last.
An append-only decision log: 700+ rows, every action recorded with date, reason and contributor. A lessons file: 31 rules, each one a real failure distilled into a check that loads at boot. And contributor dossiers: a trust ledger with explicit tiers (Participant → Contributor → Triager → Trusted), merge counts and notes.
Some lessons, paraphrased. Announce only after success (#10). Re-fetch a contributor's current head before pushing to their fork; a rejected push means stop (#16). For parsers, the live static-analysis gate is required (#18). Never @-mention a handle you didn't read from a tool result in the current session (#24: the agent once invented one, and fixed it within a minute).
My favorite failure: git worktrees isolate the working tree but share .git/FETCH_HEAD. In one parallel fan-out, concurrent fetches overwrote it and an agent analyzed the wrong PR entirely. The adversarial verify step caught the cross-wired verdict before anything went public. The rule (each agent fetches to an isolated, per-PR named ref and cross-checks the pinned SHA) went into the lessons file and hasn't recurred.
Agents fail. The system is built so their failures are cheap to catch and never repeated.
The fleet itself is versioned the same way. Prompts, skills and rules are text files in git, so a behavior change is a readable commit, and skills load at invocation time, so changes land hot with zero downtime. Worth admitting: the skills have no formal test suite yet. Their quality mechanism is the learning loop itself, and so far it has held, because a real failure becomes a written rule and the rule becomes boot-time context.
One documented day: July 2, 2026#
Opening state at 09:05: 53 open PRs, 74 open issues, +9 PRs and +11 issues overnight, main green.
By the end of the day:
v1.16.0 cut and live:
13 features, 7 fixes. The dogfood agent had found a user-facing break in the published release; that report became the argument to cut now.
16 PRs merged.
Among them: 3 community plugins registered at once after 3 independent adversarial approvals; an analytics feature built with a FAccT 2026 research paper as the spec; and a human-in-the-loop reshape audited line by line (zero network calls, exact domain allowlist).
~25 issues triaged,
~8 warm closes with credit, 6+ precise request-changes. Every new PR and issue received a substantive first response the same day. Zero ghosting.
GitHub Trending, #5 overall.
The Trending card read "322 stars today"; by midday the count was at ~408 against a ~190/day baseline.
My total involvement: one sitting, about an hour, 8 decisions. Cut the release. Promote the first co-maintainer to write access (announced only after the grant call succeeded; see lesson #10). Decline a root-folder reorg, because path stability is a feature when 11,000+ forks depend on your paths, and harvest the good part (an ARCHITECTURE.md) with credit to the proposer. Close a 7-PR architecture spine from a high-volume contributor, warmly and RFC-first: velocity doesn't buy architectural authorship. Two of the day's eight decisions became written doctrine in ARCHITECTURE.md the same evening.
Everything left on my plate at day's end: two Discord clicks, drafts pre-written by the fleet.
The dogfood loop closed the same day too. One field report, 13 findings. 1 direct fix, 11 precisely scoped issues filed. 3 of those issues came back as community PRs and merged before midnight.
What the fleet catches that I would miss#
The macOS bug CI couldn't see.
A test crashed only on macOS: mkdtempSync returns a path under /var, which is a symlink to /private/var, and a guard failed silently. Ubuntu CI was green the whole time. The local full-suite gate caught it, the contributor got the diagnosis with the exact fix, and came back with a PR adding a 3-OS CI matrix (#1719 → #1762).
10 merges, 3 collisions, 0 breakages.
One morning this week had 10 PRs to land, and 3 clusters of them touched the same files. The briefing's collision map set the safe merge order and re-validated CI after each landing.
The audit loop.
A community member reported CV formatting drift. The fix shipped in v1.18 (#1388). The user came back with a commit-pinned audit of what remained (#1736). The agent re-verified each finding against that morning's main and found one already resolved by a merge the auditor couldn't have known about. Another contributor shipped "Closes #1736" within hours (#1759). The agent's job there was routing, so no one duplicated work.
The human save.
A success story once arrived with a title so generic it looked like spam. The read-the-body-before-classifying rule saved it. It ended up celebrated in the community's success-stories channel.
The numbers#
As of July 10, 2026:
| Metric | Value |
|---|---|
| GitHub stars | 59,535 |
| Forks | 11,818 |
| Contributors | 169 |
| Merged PRs | 530 |
| Releases since the April launch | 21 (latest: v1.18.0, July 7) |
| Test suite | 1,667 assertions, 0 failing (Jul 2026) |
| Discord members | 4,100 |
| Weekly traffic | 26,831 unique visitors · 8,680 unique cloners — 32% view→clone (Jul 2026) |
| Worldwide rank | one of the ~350 most-starred repositories on GitHub (warpchart, Jul 2026) |
| Human attention budget | ~4 hours/week |
That view→clone rate is the number I watch. Stars measure applause; clones measure use.
DORA's 2025 State of AI-assisted Software Development measured what most engineering teams now feel: AI lifts individual output (98% more merged PRs) while organizational delivery metrics stay flat. Their headline finding is that AI amplifies the system it lands in. The gap between those two numbers lives in everything this article describes: review, trust, memory, gates. This repo is that gap closed in public, at 59,000-star scale, on 4 hours a week.
The community runs on the same principles#
The 4,100-member Discord gets the same discipline as the codebase, with lighter gates. A community-brain agent sweeps the channels and distills chat into a queryable ledger: recurring pains, feature requests, promises made. New requests get deduped against existing issues, and what survives becomes labeled issues and RFCs on the public roadmap. A grounded FAQ bot answers setup questions from the repo's own docs, with zero hallucinated answers observed so far, and hands off to a human when the docs don't cover it.
The gates are lighter here because the error budget is bigger: a wrong FAQ answer gets a human correction, where a wrong merge would get a revert and a post-mortem.
This year the community reported its first member landing a job with the tool. Adoption is a system, and this one closes its loop in public.
Making your repo agent-friendly#
The fleet took months to harden. The foundations underneath it transfer to any repo, and most of them are context engineering:
Rules files
that brief an agent the way you'd brief a senior engineer joining the project: conventions, architecture, gotchas, commands, boundaries. In practice: CLAUDE.md and AGENTS.md, now an open standard used by 60,000+ projects.
A test suite the agent can treat as ground truth.
If your tests lie, agents amplify the lie at machine speed.
Written contracts instead of tribal knowledge:
a data contract, sensitive-file tiers, a documented review checklist. "No" works better as policy than as mood.
Logs that compound:
an append-only decision log and a lessons file. A failure either becomes a written rule or it repeats.
Isolation for parallelism:
git worktrees plus per-task named refs. Shared state is how agents cross-contaminate.
Gates where trust is thin:
first-timers, parsers, anything that acts in public.
Start with the first two and a single triage agent. The fleet is what that grows into.
Where this breaks#
Ambiguity.
Agents misread intent when a diff and its issue disagree. That's exactly why they propose and I decide.
Verification.
My unit of review shifted from diffs to evidence: test output, audit trails, adversarial verdicts. Building the habit of demanding evidence took longer than building the agents. The industry is starting to call this the verification bottleneck: 2025 data across hundreds of orgs shows merged PRs nearly doubling while review time climbs 91%. The gates above are what that problem looks like solved for one repo.
Voice.
Anything in my own name (announcements, thanks, public judgment calls) stays human. Readers can tell, and they should be able to.
Time.
This system is 31 distilled failures old. Day one will not look like this, and pretending otherwise would be selling you something.
From one repo to an engineering org#
Everything above has an organizational twin. Rules files are a golden path: the platform team's paved road, applied to agents. The collision map is CODEOWNERS logic that scales past human patience. The gates are a trust policy, written down and cheap to audit. The lessons file is a postmortem culture that compounds. And the propose-decide split is the same division a VP of engineering already runs between staff engineers and their teams, with the mechanical layer swapped out.
Where teams struggle is the system around the tools. That's the part that transfers, and transferring it is forward-deployed work: embed with a team, rewire how it ships, leave the capability behind.
The core concepts of agentic maintenance#
Six patterns, named so you can reuse them:
The orchestrator agent:
a central routing node that delegates specialized work and aggregates evidence into briefs a human can decide on.
The ephemeral verifier:
a short-lived, read-only agent spawned in an isolated git worktree to validate one thing, report evidence, and disappear.
The grounded watcher:
a persistent background loop that watches source-control or telemetry events and triggers work asynchronously, under the rule that a failed check reports "could not verify" rather than "nothing found".
The compound memory ledger:
an append-only log of decisions and distilled failures that loads into every new session, so each session starts smarter than the last.
The tool-stripped actor:
an execution agent deliberately denied every external tool (chat integrations, MCP servers included) to shrink the blast radius while it runs untrusted code.
The sequential quality gate:
a blocking checkpoint (CI green, live static analysis, human approval for first-timers) that halts the pipeline until a trust condition is met.
Together they make up agentic maintenance as this repo practices it.
Lessons#
Design from autopsies
Every gate exists because something real broke first. The system did not come from a whitepaper: it came from failures with dates and issue numbers.
Agents propose with evidence. Humans own the no
The fleet converts an unbounded stream of mechanical work into a bounded menu of decisions. Taking the last word away from the human is not automation: it is abdication.
A failure either becomes a written rule or it repeats
The lessons file loads on every boot. Memory that is not written down does not compound.
Boring contracts make agent speed safe
Pinned SHAs, path stability, data boundaries. The boring parts are what let agents move fast without breaking anyone.
The repo became the résumé
How a project is maintained demonstrates more than any interview could. This article is the receipt.
FAQ#
What is agentic maintenance?
Agentic maintenance is the practice of keeping a living codebase healthy through a fleet of AI agents that do the mechanical work — triage, testing, review briefs, release mechanics, community metrics — under explicit human direction. Three properties separate it from simply pointing a coding agent at a repository. First, gates: every consequential action passes a blocking checkpoint (clean-checkout tests, live static analysis, human approval where trust is thin), and anything public is verified before it happens. Second, evidence: agents never ask for trust; they attach test output, audit trails and adversarial verdicts, and a human decides on the brief. Third, compound memory: every real failure is distilled into a written rule that loads into every future session, so the system gets safer as it ages. In the reference implementation described in this article, agentic maintenance runs a 59,000-star open source repository on roughly 4 hours of human attention a week.
Can AI agents maintain a codebase by themselves?
No, and this system is designed on the assumption that they shouldn't. The agents handle volume: classifying the overnight flow, running test suites against clean checkouts, drafting review briefs, watching for contributor deliveries, measuring community health. Every consequential action passes through gates, and anything strategic (what enters the core, merge order, governance, releases, public judgment calls) lands on a human decision menu with evidence attached. It's division of labor: agents convert an unbounded stream of mechanical work into a bounded set of decisions. In my case that bound is about 4 hours a week for a repo with 59,535 GitHub stars and 169 contributors. Remove the human and what's left is unreviewed authority over other people's code.
How much does it cost to run an AI agent fleet like this?
Less than the phrase "agent fleet" suggests. The whole system runs on a Claude Code subscription plus commodity tooling: tmux for sessions, git worktrees for isolation, JSON files for inter-agent communication, GitHub Actions for CI. Everything lives on the laptop it runs on, without GPUs, a vector database or an orchestration platform. The genuinely scarce resource is human attention, which is the point: the design target was fitting a viral repo into roughly 4 hours a week of my time. If you're evaluating this for your own project, budget more for writing rules files and hardening tests than for compute, because context quality has been the binding constraint at every stage. Cost figures: subscription-based, as of July 2026.
Do AI agents replace open source maintainers?
They replace maintainer toil. Triage, rebases, test runs, dedup checks and status chasing stop consuming the week. What remains is judgment: project vision, contributor trust, architectural authorship, and the ability to say no warmly. On my documented specimen day, the fleet processed 16 merges, ~25 triaged issues and a release, while my contribution was 8 decisions in about an hour. One of those decisions closed 7 PRs from one of the project's most prolific contributors, RFC-first, because unowned architecture becomes debt. No agent should make that call, and none did. The maintainer keeps the role and loses the backlog.
How do you review AI-generated and human pull requests at this scale?
Three parallel axes. Automated code review handles tactical nits. CI runs the full suite (1,667 assertions today) plus CodeQL, dependency review and a privacy guard that rejects user data in PRs. The maintainer agent then builds a brief per PR: spec-fit against the originating issue, contributor history, collision map against other open PRs, and a local clean-checkout test run. I read briefs and evidence, and I read diffs only where the brief says trust is thin: first-time contributors, parsers, sensitive files. Merge order comes from the collision graph, and CI re-validates after each landing. The day that system handled 10 merges with 3 file-level collisions, main never broke.
What breaks first when you try this on your own repo?
Context, almost always. An agent dropped into a repo without rules files, current docs and trustworthy tests produces confident nonsense, and the temptation is to blame the model. In my logs, the early failures cluster into two families: missing context (the agent didn't know a convention any senior human would have been told) and missing gates (the agent announced, merged or claimed something before verification). Both have the same fix: write the context down, and gate the action on evidence. The subtler failures come later, from parallelism: shared git state let one agent analyze the wrong PR entirely. Isolate everything and pin every ref. Assume any claim can be cross-wired until verified.
Does this approach work for a small project, or only at scale?
The economics get better with scale, but the entry point is small. A repo with 10 issues a month needs a rules file, a test suite it can trust, and maybe one agent that triages and drafts replies. The fleet can wait. That's a weekend of setup. What scale changes is which parts become load-bearing: past a certain volume, the collision map, the delivery-watch and the compounding lessons file become the difference between shipping weekly and drowning. I'd start any repo, whatever its size, with the same two artifacts: a rules file that briefs the agent like a new senior hire, and tests that tell the truth.
This operating model, applied to your engineering team
I design and operate multi-agent systems in production: fleets that turn mechanical volume into bounded decisions, with gates, memory and evidence. I deploy this operating model embedded with engineering teams (forward-deployed). If your team is drowning in volume, let's talk.