I Worked on 54 Repositories in One Month

In August 2026, I had commits landing in 54 different repositories. In September, 48. In the first three weeks of October, 37.

I’m one developer. I’ve been working with coding agents since April 2025, and for more than a year I’ve been building and using Festival to keep the work organized across projects. By October 21, 2026, 3,723 pull requests opened through my personal and agent accounts during that period had been merged.

Fifty-four repositories in a month

August accounted for 2,768 commits across those 54 repositories. Twenty-eight of them received at least ten commits that month. Over the full eighteen months, the local code scan found 19,679 commits by my identities.

These charts cover 151 repositories available on this machine where I or my agents made commits. They include repositories in Obedience Corp, Blockhead Consulting, Guild Ventures, and Shrapnel, plus my personal ones. I also worked on other machines, so these charts can miss work recorded elsewhere. A repository counts once per month when one of my identities has a commit in it.

The amount of work is absurd. In my first post about this, I described eight projects in seven weeks. I was working ten to fourteen hours a day on a backlog of things I’d wanted to build for years. Eighteen months in, I’ve kept taking on projects while continuing the ones I already had. Each new project adds to the releases, debugging, integration work, and maintenance I’m already handling.

How I keep the work moving

In those first seven weeks, I was already trying to manage three to five projects at once with hundreds of Markdown documents. I kept telling agents where to find their instructions. I archived finished tasks by hand so the next session wouldn’t pick up an obsolete plan.

With this many projects, keeping track of where each one stands becomes a job of its own. Each new session needs the goal, earlier decisions, what’s finished, and what still needs checking. So do I when I come back to a project.

Camp keeps related repositories, research, decisions, and work records together. I track goals as work items. Intents capture work, designs lay out an approach, and explorations investigate questions. I can also define custom types. This article is a blog work item, with its drafts, research, and review history in one place.

A festival is the type of work item I use for larger goals. It breaks the work into phases, sequences, tasks, and checks, with a plan and progress record that carry across sessions. Smaller work can use a short description or a standalone workflow.

I choose the structure based on how big the goal is, what could go wrong, and the model doing the work. Even a small change needs careful review if a mistake would be expensive. A different model may need a different task breakdown or more checkpoints for the same goal. Straightforward work can stay lightweight.

camp workitem brings those types into one view, so I can find the goal and its records when I return. Fest supplies the next task or workflow step. The plan and progress stay in files with the project.

I run independent sessions on different projects. I decide what to build, work through the architecture, and review results. I can focus on another project while an agent continues its work, then step in when it needs a decision. When a session ends, the next one has a place to pick up.

The local inventory contains 451 festivals across 28 workspaces, with 302 marked complete. Intents, designs, explorations, and custom work items have not been tallied here. The festival inventory itself includes development plans, research, examples, and repeated workflow runs.

Festival Activity inspected 345 local repositories and found 30,302 commits and 41,619 Festival progress events in its broader scan. Those events record steps through the work; they are separate from the count of completed plans. The retained event history begins in December 2025.

One developer, three GitHub identities

I created obey-agent and veronica-agent to get the noise out of my own GitHub account. I was producing work at the scale of a large team, and I needed identities like a team for things like code reviews. In my experience, agents seem to catch more issues when they think they’re reviewing someone else’s code.

The separate identities have also come in handy for reviewing my own work: the reviewing account can request changes on PRs opened by another account. GitHub returns 1,055 pull-request review contributions for obey-agent in this period. These accounts are part of how I work, so the measurements include all three identities.

In a manager-worker experiment, I ended the run at 37 of 67 tasks because the worker rushed checks and I had to review the manager as well as the implementation. I usually give each project its own session and a work item I can inspect.

What a festival looks like

The GIF below shows a festival for building a coding-practice library in the CodeSignal Practice Simulator. One goal is organized into seven phases, eight sequences, and 50 tasks.

The tree shows how the work fits together. Phases divide the goal into major stages, from understanding and planning the work through implementation, verification, and review. Within implementation phases, sequences group related tasks. As the replay runs, completed work gets checked off, active work is highlighted, and upcoming work stays visible.

Review gates are part of that same structure. The “Judge” rows show the judge hook checking evidence at approval checkpoints.

This gives me a record to return to when I switch projects: how the goal is divided, what’s finished, and what still needs work or review. The public azx camp has another festival replay for work on my Helix fork.

What eighteen months added up to

Across the three accounts, I opened 3,826 pull requests between April 1, 2025 and October 21, 2026. By that date, 3,723 had merged, six were still open, and 97 had closed without merging.

I pulled those counts from GitHub across personal and organization repositories, including private ones each account could access. They don’t depend on which repositories I have on this machine.

GitHub records 41,055 contributions across those accounts, with activity on 470 distinct days. That includes private contribution counts.

Alongside Festival, I’ve been building a local voice assistant, connecting software to physical devices, and writing tools for running agents. The CRE Risk Router took second place in Autonomous Agents at Chainlink Convergence.

In the first post I said development had become fun again. I got into software to build cool things, and a lot of the things I wanted to build were too much to take on alone. I’m still working through that backlog. The CodeSignal build records and azx camp are public examples you can read and run.

Appendix: the local code inventory

The table below lists every scored repository from the camp leverage-all scan I ran on this machine on October 21, 2026. I worked on other machines too, so this inventory covers the code available here and can omit work from elsewhere. The expanded scan found 166 repository identities across all 28 registered camps and returned 151 with commits by the selected identities. All 151 had activity in the reporting window. Repository ownership is unrestricted, and inactive camps are included, so Shrapnel’s Hermes and Hermes Infrastructure appear here too. The code and dollar columns measure the current checkout; the commit column covers each repository’s full selected-author history, which reaches back to June 2023.

Across the reporting window, those repositories contain 19,679 commits by my identities, 13,427,862 text lines added, and 3,104,098 deleted. The additions include documentation, generated and imported files, and work I later replaced. The October 21 code inventory estimates 6,486,582 current code lines attributable to those identities. That includes code imported for existing-site work: two archived website exports account for 2.15 million lines. Thirteen repositories have more than 100,000 attributable code lines; another 39 have between 10,000 and 100,000.

Scroll within the table to see every row. The downloadable report also contains each repository’s monthly activity.

All scored repositories

Current code is attributed using the selected identities’ share of Git blame. Dollar rows are rounded independently; the subtotal uses unrounded estimates. Separate repositories may share ancestry or copied code.

The native Camp reports

I also ran camp leverage --json --no-commit in all 28 registered camps, including the three inactive ones. These are the native reports’ project counts and code estimates. Projects can appear in more than one camp, and native code counts use a different scope from the personal attribution in camp leverage-all. Adding these rows would overstate the portfolio. They are included so the per-camp output is available alongside the deduplicated scan.

All 28 Camp reports

Numbers and sources

The first article reported 219,400 code lines across eight projects and a $7.76 million COCOMO development-cost estimate. The current local inventory of 151 repositories is 6.49 million attributable code lines with a $232.2 million estimate under the same kind of model. It includes older and archived work, imported site exports, and current development. That figure models the development effort represented by the code; it is not revenue, savings, or a valuation of the projects.

All current measurements were captured October 21, 2026. The activity window runs from April 1, 2025 through October 21, 2026. My first coding-agent project began April 28, 2025, so this is roughly eighteen months of use, displayed in nineteen calendar-month bins. October is partial in every chart.

The commands and raw output are retained in the campaign’s article research. The public measurement file contains all 151 code-inventory rows, all 28 native Camp summaries, monthly activity, and coverage notes. Local paths, author email addresses, and raw private GitHub items are excluded from that export.

camp leverage-all --author-name lance --author-name obey-agent \
  --author-name veronica-agent --timeline month --json
camp leverage --json --no-commit

The code scan used camp leverage-all 0.3.0 and scc 3.7.0. The initial command excluded inactive camps. For the expanded capture, I changed its registry discovery from camp list to camp list --all, leaving scoring, identity resolution, and deduplication unchanged. The original output, source revision, and one-line patch are retained in the research. It estimates attributable code from selected authors’ share of current Git blame, and scales each repository’s organic COCOMO estimate by the same share. The model uses a $56,286 annual wage and 2.4 overhead multiplier. The unrounded total is $232,173,391.71. Working-tree changes can affect the snapshot, and the scan was not atomic across repositories.

The command reports 514.60× modeled “full leverage,” dividing 20,626.63 estimated person-months by 40.08 elapsed months of selected-author history. Elapsed calendar time is not measured working time. I have not used that ratio as a demonstrated productivity multiplier or charted its retrospective dollar allocations as earnings. The $636 subscription cost from the first article covered seven weeks; I have not reconciled spending for the longer period.

The expanded scan includes Shrapnel, plastix, and pair-programming, the three inactive camps. It returned one error for a linked ClipSync checkout whose path capitalization differed from Git’s reported root; the same remote was scored through My_Tools. One absent project path was reported as stale. The downloadable data preserves the scan’s incomplete status and coverage notes. Code imported in a Git commit can be attributed to that commit’s author: the two archived website exports contribute 2,148,933 lines to this inventory across five commits. That is existing code brought into the work, not a claim that agents wrote those lines.

The Camp and Festival Activity reports also cover records available on this machine. Festival Activity was rebuilt with all 28 registered roots, explicitly adding the inactive camps. Its 345 scanned repositories include workspaces and repositories without matching commits, so that is a coverage count. The 451 festivals are a current inventory that includes examples and repeated workflow runs; “completed” means marked complete in retained records. The manifest reported 59 warnings about malformed audit records, duplicate record IDs, and markers outside workflow directories, with no skipped sources. GitHub was queried separately as lancekrogers, obey-agent, and veronica-agent, with no repository-owner filter. PRs have one author, so those author counts are added once; status was checked at capture, and the creation window does not require every merge to have occurred inside it. The contribution-calendar total sums account activity and can include shared underlying work; active days are deduplicated by date. The review-contribution count uses GitHub’s returned review category, which can omit restricted details.

Repository counts show breadth within a month, not how many agents ran simultaneously. GitHub contributions, PRs, local commits, current code size, and Festival records measure different things. The charts keep those measures separate.