Five Months of Coding, in Numbers

I asked my coding agent to count what is in my repositories: code by language, Markdown documents by purpose, issues opened and closed, and lines changed since April 20. Here are the results.#

I typically have a single $200 MAX plan with Claude, though last month I started a $200 plan with Codex as well. I tend to use their frontier models, which burns through budget too fast, especially if I’m not careful cleaning up context.#

The period is April 20 through October 1, 2026: 165 calendar days, or about five and a half months. The inventory covers 15 repositories that use my Ariadne layout. It excludes personal capture repositories, third-party clones, packaging repositories, and duplicate worktrees.#

The current snapshot contains 914,206 lines of code in 4,395 files, and 1,175,758 lines of Markdown in 4,042 files. The issue trackers contain 1,228 issues, of which 852 are done, 306 remain open or active, and 70 are marked punt or wontfix.#

These numbers describe the repositories and their recorded activity. The current inventory includes work from before April 20; the change counts below are limited to the five-month period. Lines of code also include tests, comments, and blank lines.#

Code #

Go accounts for most of the source, followed by Lua and Python. The largest repositories by source size are Pair, Parley, and Ariadne.#

The per-repository breakdown is below. Small repositories with only a Makefile are included; adopting the layout does not mean a project has substantial implementation yet.#

Documents #

There is more Markdown than code in this snapshot. Issue files and plans account for 393,550 lines. The remaining 782,208 lines include documentation, skills, review reports, evidence, and research records. This is a broad record of development work; it should not be read as a count of documentation written for end users.#

Each cell below shows files / lines. Completed issue documents and archived plans are included.#

Here, “plans” means canonical workshop files named *-plan.md. Reviews and evidence stored beside plans are counted as other Markdown. Noncanonical planning documents can also fall into that category.#

Issues #

The issue counts come from unique IDs in the authoritative issue trackers, rather than the number of Markdown files. That is why the issue totals differ from the document counts above.#

“Still open” includes issues being worked on, blocked issues, and code-complete issues that have not been closed. I have kept punt and wontfix separate from done: they are terminal tracker states, but they do not represent completed implementation.#

The trackers retain 1,228 unique IDs; this is not a reconstruction of any records that may have been deleted or migrated away. Five issues lack creation dates, so 1,114 is a lower bound for issues created during the period.#

Of the issues known to have been created since April 20, 754 are now done. The tracker cards do not contain explicit closure dates, so this measurement does not establish how many issues were closed during the period.#

Commit activity since April 20 #

There were 13,380 non-merge commits reachable from the inspected mainline snapshots during the period. Across the counted source files, those commits added 1,097,761 lines and deleted 240,268 lines. Markdown added 1,523,445 lines and deleted 378,384 lines.#

The table shows additions and deletions separately. Rewriting the same file repeatedly contributes to both; these are activity counts, not a measure of useful output.#

The Markdown changes break down as follows:#

Spread across 165 calendar days, the averages are about 568 commits per week, 56,765 code lines changed per week, and 80,684 Markdown lines changed per week. “Changed” here is additions plus deletions. These averages include inactive days and do not measure hours worked.#

How the count was made #

The measurement used locally cached origin/main snapshots for files and commit history, and origin/issue-tracker for issue status. It did not fetch remotes, and it excluded uncommitted changes and work that had not reached the inspected mainline. The two branches are separate snapshots, so an issue card and its mainline document need not be at exactly the same stage.#

The file count includes regular tracked source and Markdown files. Symlinks, submodules, vendored dependencies, inherited seed copies, and identified generated source copies were excluded. Notebook JSON, configuration files, lockfiles, and data files were not counted as source code.#

The dependency exclusions also apply to historical changes. This matters: some dependencies were once tracked and later removed. Counting those removals would inflate the activity figures. In Kbench, the audit excluded 118,782 lines of copied public ARC game environments, along with generated solver snapshots, while retaining Markdown experiment records. Pair’s vendored terminal library was excluded too, including local patches within that dependency.#

Line counts are physical lines, including comments and blanks, rather than executable statements. Commit churn counts non-merge commits reachable from mainline in the date range. It excludes changes made only while resolving merges and excludes edits on the separate issue-tracker branch. Renames count changed lines, rather than treating an unchanged file move as a full deletion and addition.#

The large amount of Markdown is consistent with keeping issues, plans, reviews, and workflow records in the repositories. Its volume does not establish whether those records are useful. The same limitation applies to the source and commit counts: they give me a baseline for the scale and activity of this workflow, but judging the software still requires using it.#