One person, eight hands

The title has a namesake, loosely. Ashtanga is Sanskrit for eight limbs, and the count fits, but Patanjali's limbs are stages of one inward discipline, restraint through absorption, and none of them multiply output. The closer icon is the thousand-armed Kannon, carved with an eye in each palm: many hands, and every hand carries its own act of seeing. Hold that image. It is the standard the verification section asks of these hands, and the practitioner count in both traditions stays at one.

The hero figure is every commit the studio has made since August 2024, one bar per week, split at the axis. Above the line, commits that carry a model's name in the trailer, shaded by generation as one took over from the next. Below the line, in ink, commits a person made alone. The bot heartbeat from a watchtower cron is removed from both sides. For two years the figure is mostly ink and mostly empty. From the week of 6 July 2026 the upper half goes vertical: 210, 410, 484, 225, 334, 162 and 519 agent commits a week, against 21, 2, 35, 74, 29, 0 and 4 from a person.

The shape is honest about what the studio is. The 2024 and 2025 portion of the line is one client app: a team burst in September 2024, then one to five commits a month from one engineer with a day job. Model trailers first appear in October 2025 and stay small, a few dozen commits across Opus 4.5 and 4.6, until July 2026 when the engineer started running many sessions at once across many repos. Everything the portfolio chart seems to say about output is a six-week event, and nothing in this data says it is sustainable. What would settle that is a series of hours-on-box against surviving output, week by week, which nobody has started keeping.

How the trailer became the author

The author class is the Co-Authored-By trailer and nothing else. A commit with a model in the trailer belongs to that model's generation; a commit with no trailer is a person alone. That rule overstates the person in both directions. When an engineer edits an agent's diff by hand before committing, the trailer stays and the commit reads as the model's. When an agent's work is committed from a session that dropped the trailer, it reads as the person's. The grouping is one pipeline over the log, and it is the thing to reproduce before trusting any bar in the figure.

for r in ~/Code/*/; do
  git -C "$r" log --all --no-merges \
    --format='%H%x09%ad%x09%(trailers:key=Co-Authored-By,valueonly)' \
    --date=short
done \
  | awk -F'\t' '{ c = ($3 == "") ? "human" : $3; n[c]++ } END { for (k in n) print n[k], k }' \
  | sort -rn

# 3,200 commits, 16 repos with more than 20 commits, as of 2026-08-22
# heartbeat commits from the watchtower cron are dropped before counting

One repo dominates. The chess product is 1,577 of the 3,200 commits and 92 percent of them carry a model trailer. The portfolio figure is mostly that one repo, with a six-week burst across the other fifteen laid on top. Nine of the sixteen repos were started on or after 9 July 2026, and six of those nine have had no commit for 20 days or more. Their median life is 16 days. The hero shows the cliff; it does not show that most of the repos in the cliff are already quiet, and a reader should hold both in mind at once.

What kind of commit it was

The velocity figure splits each week into features and fixes. Week of 6 July, 85 features to 31 fixes. Week of 13 July, 222 to 68. Week of 20 July, 177 to 202, and that is the crossover: the first week in the record where more commits repaired something than added something. The two weeks either side of it, 13 and 20 July, are also the only two weeks in which twelve repos were touched. Before them the count was one to six repos a week; after them, three to six. The pattern since is a near-even split: 86 to 102, 138 to 119, 60 to 59, 195 to 189.

The reading that fits is simple. Spreading the agents across twelve repos in a fortnight produced a lot of new surface, and the weeks after were spent paying for it. That is a reading, and the data is consistent with it, but the same shape would appear if the engineer had simply switched from building to polishing on 20 July for reasons unrelated to the spread. The figure cannot tell those two apart.

The mix figure puts the same labels on each author class. A person alone, 640 commits, is 31 percent feature and 20 percent fix with a median of 87 lines changed. Opus 4.8, 231 commits, is the builder: 56 percent feature, 19 percent fix, median 138 lines. Opus 5, 550 commits, is the repairer: 31 percent feature, 50 percent fix, median 136 lines. Fable 5, 1,522 commits, sits in between at 43 percent feature and 29 percent fix with a median of 109 lines. The three small classes, Sonnet 5 at 25 commits, Opus 4.5 at 20 and Opus 4.6 at 24, are too thin to read as anything beyond the fact that they exist.

Opus 5's fix share is the number that asks for an explanation, and the calendar gives a partial one. Opus 5's first commit is 24 July, four days after the crossover week, so the class arrived into a portfolio that already needed repairing and was pointed at it. Whether it was assigned the fixes or finds them by temperament is a question this data cannot answer, because the model and the period are confounded.

What the hands built

The specimen board answers the question the counts cannot: what kind of thing is a feature here. A third of everything is surfaces, the pages and panels and charts a user actually sees, and it is also the category where the person alone shows up most, because the last look at a screen stays human. The next tier is the machinery: pipelines and engines, platform and integrations, growth and onboarding. Two categories barely existed before the models arrived and are almost entirely theirs: languages, 70 of 70 commits model-co-authored, and agent ops, the verification tooling the agents built to check their own work. The specimens are quoted verbatim from the log, with their hash, so any of them can be pulled up with git show.

The fleet, as a grid

The grid is the same data arranged the way a portfolio operator reads it. Each product accrues capabilities down its own row while new rows keep appearing underneath, and the sum of every row is the brass curve: 1,193 capabilities across sixteen products, most of the slope inside the last eight weeks. The compounding shape is the one recurring-revenue charts are drawn in, and the caption is where that comparison has to stop. A capability here is a feature commit judged from its subject line. The site publishes no revenue, and a capability nobody uses compounds nothing.

One row is drawn in brass because it closes a loop. Flotilla is the studio's own fleet pattern packaged as a product: each product gets its own machine and a coding agent, and every step lands in git, which is the very history the rest of this grid is drawn from. The row is 26 capabilities in nine days and then quiet, which the previous section already taught you how to read.

How a subject line became a label

The feature and fix labels come from one model, Claude Opus 5, reading each subject line against a fixed rubric and returning one of seven labels. It judged 3,190 subjects in batches of 60 for about $1.82. The rubric is the whole instruction; the prompt around it is a sentence of framing and the list below.

feature   adds something a user or operator could not do before
fix       repairs behaviour that was wrong, broken or regressed
refactor  changes structure with no intended change in behaviour
docs      prose, comments, READMEs, briefs
data      content, fixtures, migrations of records, seed files
chore     deps, config, CI, formatting, version bumps
other     none of the above, or cannot tell from the subject

# judged: 3,190 of 3,200 subjects, batches of 60, about $1.82
# calibration: keyword rule confident on 614; judge agreed on 563 (92%)

Calibration came from a keyword rule. A subject with fix, bug, regression, crash or revert in it is a fix; one with feat, add, implement, introduce or ship in it is a feature. That rule is confident on 614 of the commits, and on those the judge agreed 563 times, 92 percent. The rule alone was never going to be enough, and the reason is itself a finding. It could label only 17 percent of the Fable-era subjects, because those subjects are prose titles rather than prefixed tags: a sentence written for a reader, with the verb somewhere in the middle if it is there at all. The later commits are written to be read, and a classifier built for tags cannot see them.

What we got wrong on the way

The first version of this data counted 125 heartbeat commits from a watchtower cron as a person. They had no trailer, so the rule made them human, and the human side of the recent weeks was inflated by a machine that commits a timestamp. The second version used the keyword rule for everything, and its coverage decayed from 37 percent of subjects at the start of the window to 5 percent at the end, silently, as the commit style changed under it. The definition of a feature had changed inside the window, which is the exact failure the studio's number discipline names, and a feature-fix velocity chart was a day from being published on top of it. The judge exists because the decay was caught on a coverage check, and the coverage check exists because the rule had to be written down before it could be run.

What the figures do not measure

Velocity here is commits. A feature commit is a subject line that says something was added; it is a long way from a shipped feature a user got. A fix commit says something was repaired; it is a long way from a bug a user hit. Lines changed are a size, and size is a poor proxy for value in either direction. The nearest thing to a value question this data can answer is churn: of the lines each class wrote, how many are still in the tree today.

The result is better for the models than we expected, with one large asterisk. Of the 569,966 lines Fable 5 wrote, 87 percent are in the tree today; Opus 4.8 is at 90 and Opus 5 at 84. The person alone is at 43 percent, and the earliest model generations sit at 38 to 56. The asterisk is age. Survival is confounded with time: the human lines are up to two years old and have had two years to be rewritten, while most model lines are weeks old. What the figure rules out is the strong sceptical reading, that the agent volume is a churn machine rewriting its own output inside the window. It does not rule out the same erosion arriving on the model lines a year from now. The first run of this measurement also counted image bytes as code, because git's diff calls a PNG binary and its blame does not, and survival came out over 100 percent; the text-only rule in the script exists because of that.

The claim this post can support is narrower. One engineer, over six weeks, directed models to land roughly ten times the commit volume the same engineer had ever produced alone, across more repos than one person could hold in their head, and the repair share rose to half within a fortnight of the spread. Six of the nine repos born in the burst are already quiet. Whether the three that are still moving justify the whole is a question for the churn number and for a series of hours-on-box that has not been started.