This is the English companion to the Japanese article on Qiita. The numbers in both come from the same frozen measurement snapshot (2026-07-10); methodology at the end.

TL;DR

• One developer + Claude Code produced 12,499 commits across 224 repositories in 222 days (2025-12-01 → 2026-07-10), totaling 11.56M lines of code (2.56M of it Rust).
• The highest-leverage configuration wasn’t a prompt trick. It was stopping the AI from judging its own productivity by human standards.
• The second pillar: quality enforced as numeric termination conditions, not vibes.
• The numbers can mislead, so their limitations are listed at the end — the same rule this workflow applies to its own reports.

The measured record

Measured 2026-07-10, across all my repositories — public, private, and local-only. Forks count only my own author commits; duplicate clones are excluded.

Implementation scale by product family — this chart deliberately excludes data and markup formats (JSON, YAML, Markdown…), because raw totals are dominated by generated data files and would overstate the point:

What it produced: the Ferro data-infrastructure suite (five products on AWS Marketplace, with per-product development records), a series of AWS security appliances, an open-source SBOM server (sbomhub), fifteen-plus MCP servers for game and creative tools, language-learning apps, and LLM research repositories.

The core problem: AI self-assesses by human standards

The biggest issue with running Claude Code hard isn’t capability — it’s miscalibrated self-assessment. LLMs learn “reasonable scope” from human development culture, so by default they propose human-team-sized work:

• “This refactor is large — let’s do Phase 1 today.”
• “We should split the rest across sessions.”
• “This looks like several weeks of work.”

That’s not humility; it’s an uncalibrated prior. Properly run, Claude Code sustains hundreds of commits on a peak day (338 measured) with quality gates on.

The fix: keep the AI’s own measured record in CLAUDE.md

My global CLAUDE.md carries a table of its own past throughput:

# Measured baseline (do not sandbag)
- 38 days: 17 repos, 14 GA tags, 3,560 commits, ~1.73M lines of Rust
- Peak 12h session: 7 repos, 281 commits, ~56K LOC
- Before proposing to split any task, check it against this record.

And the escape hatch is constrained:

# Splitting is legitimate ONLY for:
dependency cycles / untestable units / push-size limits.
Otherwise, run it to completion.

When the model wants to “be realistic,” it has to argue against its own git history. The point isn’t motivation — it’s a decision rule: a split proposal must name which of the three conditions applies.

The second pillar: no compromise, numerically defined

Volume invites the obvious question: is it slop? Quality here is not a tone request (“be careful”); it’s a set of termination conditions:

• Release gate: adversarial review repeated until zero new Critical/High findings for two consecutive rounds. The reviewer is a competitor’s model (Codex CLI) on purpose — same-vendor review shares blind spots with same-vendor writing.
• Every finding: reproduce → failing test → fix → green. Flaky tests get root-caused, never retried-until-green.
• Vocabulary rules — words carry preconditions:
  • “verified” is banned unless the change was driven end-to-end in the real flow. Tests green ≠ verified.
  • “X× faster” requires real-data benchmarks with stated conditions. House rule born from a real incident: a test-mode slice once showed our engine 16× faster where full mode showed it 23.4× slower. The incident is written into the rules, with its date.
  • “production-ready” requires the gate plus a written list of remaining work.
• Every report must end with known limitations and next-session scope, or it’s incomplete. The combination is deliberately asymmetric: maximum ambition in the work, conservative claims in the reporting.

Three war stories

Losing to Flink, in public. FerroFlow vs Apache Flink 1.20.1, single-node CSV scan→aggregate, identical on-disk CSV, both engines driven through the Flink SQL Gateway REST API: the first measurement had Flink ~2.3× faster. That losing baseline was saved, perf found the bottleneck (per-aggregate 30M-row batch copies, ~70% of time), and the optimized run inverted it to ~6× across all cores (~26→48M rows/s). The loss stays in the record next to the win, and the claim’s scope is that workload only.

A fuzz target that earned its keep in 60 seconds. Mid-session question: “did you exhaust every local check before the paid benchmark?” Honest answer: “no.” Two fuzz targets were added; the first found a real OOM bug (a 217-byte input inducing a 10^19-entry allocation) within its first 60 seconds. Fixed same session, re-fuzzed 1.5M iterations clean, crash input kept as a regression seed.

A flake that didn’t get retried away. A test flaked at ~2-4% in CI. Instead of loosening the assert, the vendored fork got temporary backtrace instrumentation to catch the real culprit — a merge policy invalidating the test’s assumption; the code comment claiming “single segment, no merges” was simply wrong. The fix held over 800+ runs including parallel bursts, then the instrumentation was reverted.

What the numbers do and don’t mean

1. Commits and LOC are proxy metrics. The corpus includes template fan-out (free/pro/editor editions of the same plugin; three editions of one search engine) and generated code.
2. Raw git insertions total 40.8M lines — that number is not used here because it includes 23M lines of public-domain book text from one data-heavy service. The honest ladder: Rust 2.56M < tokei 11.56M < raw 40.8M.
3. The 61,786 test annotations include generated tests. Quality claims rest on the gated subset: 13,283 tests passing on the flagship product’s diligence-gated release, a nightly fuzz farm (53 targets) that has self-found 17+ production DoS bugs fixed same-day, and mutation testing at 75.5%.
4. 83.3% Claude-marker coverage is a lower bound on AI involvement — and equally, nothing shipped outside human review loops.
5. External validation exists: a bug report to apache/avro-rs became an upstream-merged PR (2026-06).
6. This record spans multiple Claude model generations; per-model attribution is not possible.

Methodology

A single script emits one row per commit (repo, class, author-date, hash) across all 224 repositories into a canonical TSV, frozen as a snapshot on 2026-07-10; every published number derives from that file rather than from live repositories. Forks are author-filtered; duplicate clones excluded. LOC via tokei v13 (respecting .gitignore); test counts via git grep on tracked files only. The measurement scripts will be published once scrubbed; this page will link them.

— Y.U.