I made the first commit to my project, called claude-mpm, on July 24, 2025. It was a multi-agent project manager built on top of Claude Code: a Python package that gave you specialist agents, a ticket workflow, a thin memory layer, and a way to route work between them. Building the agents was most of the work, because at that time Claude Code had no notion of a subagent. You wrote your agents as Markdown, loaded them yourself, and orchestrated the handoffs by hand.
Custom subagents shipped in Claude Code on July 25, 2025, the day after that first commit.
I’m not telling this story because of that coincidence. I’m telling it because it marks a moment. In July 2025, multi-agent orchestration was something novel. A year later it’s commonplace. And that single move (capability migrating out of the code you write and into the tool you run) is a line connecting the past twelve months in agentic coding, measurable in two of my own repositories.
TL;DR
Same author, same subscription, two eras. claude-mpm (Python) took roughly twelve months and 4,552 commits, with memory and search either hand-rolled or bolted on from outside. trusty-tools, a 25-crate Rust monorepo with first-class memory, semantic search, worktree orchestration, and PR review, came together in about two months.
The budget held. The developer improved, but the harness and the models leapt. I spent the year getting better at driving a team of agents. Even so, most of the difference sits with the tooling, not with me. Both projects ran on the same Claude Max subscription. What changed underneath was the frontier model and everything Claude Code learned to do on its own.
A year ago you hand-built the PM layer. Agents-as-Markdown, an external vector-search dependency, a memory subsystem you maintained yourself. Working in tickets felt like an edge.
Now the harness carries it. Subagents nest and run in the background, worktrees are a native flag, skills and memory and search are first-class. Ticket-driven development is table stakes. Running many worktrees against one repo is my working model now.
The safe extrapolation: The observed path is tickets → worktrees → many concurrent sessions per repo. If the next year rhymes with the last, the harness manages more parallelism than a person can hold in their head.
A year ago: you built the orchestration yourself
claude-mpm was shaped by what the harness couldn’t do at that time.
The frontier models in late July 2025 were Claude Opus 4 and Sonnet 4, which had reached general availability on May 22, 2025. Claude Code itself was about two months into GA, capable but young. Subagents didn’t exist until the day after I started. Agent Skills wouldn’t launch until October 2025. There was no native worktree support. If you wanted isolated parallel work, you ran git worktree add yourself and wired it up by hand. MCP was maybe eight months old. Memory and semantic search were not primitives the harness handed you.
So we (claude-mpm and me) built all of it. The agents were Markdown templates the package loaded and orchestrated. The ticket workflow lived in the CLI. Memory was thin by necessity, a couple of files under src/claude_mpm/memory/, and even that was on its way out. The changelog shows the memory hooks being removed and handed off to an external successor rather than maintained in-tree. Semantic search wasn’t native either. It came in as an outside dependency, mcp-vector-search, referenced across dozens of files. Worktree awareness existed at the level of a consumer that knew the concept, not a subsystem that owned it.
That was the state of the art then, and it worked. Over about twelve months claude-mpm accumulated 4,552 commits (roughly 380 a month) and grew into a real system: multiple MCP channel servers built into the Python package, a plugin path exposing 56-odd skills, agent templates for a spread of specialist roles. Ticket-driven development, routing discrete units of work through a queue instead of narrating one long conversation, felt like an advance at the time. You had to construct the scaffolding to get there, and the scaffolding was the hard part of the project.
Now: the harness carries it
trusty-tools took its first commit on May 19, 2026. It was still under active development the day I pulled these numbers. In roughly two months it reached 1,726 commits on main, about 860 a month. Same author, same Claude Max subscription, a different era.
That first commit wasn’t a blank slate. It already carried claude-mpm’s PM scaffolding, and one absorbed component holds claude-mpm session logs dated May 11, a week before the new repo existed. The Python predecessor was building its Rust successor. Then the successor began building itself: on July 6 the commit attribution switched to “generated with trusty-mpm,” in a commit that was fixing trusty-mpm’s own guard for its own subagents. Three days later the instructions moved out of CLAUDE.md into trusty-mpm’s own convention. About seven weeks were built by its predecessor before it took over its own development.
A lot shipped in that window. The frontier moved to Claude Opus 4.8 (late May 2026) and Claude Sonnet 5 (end of June 2026), with a Mythos-class model, Fable 5, arriving in June at a million tokens of context. The million-token context window had gone GA at standard pricing in early 2026. Inside Claude Code, subagents now nest several deep and run in the background by default. /fork and /subtask landed in mid-2026, and a native --worktree flag had arrived in 2026. The harness I was building on top of in mid-2026 was a different animal from the one I started claude-mpm against.
And trusty-tools reflects that, because it didn’t have to build the parts the harness now provides. It could spend that effort building capabilities further out. The result is a 25-crate workspace consisting of about 600K lines of Rust. The pieces claude-mpm hand-rolled or imported are now first-class crates of their own:
Memory is trusty-memory, a dedicated crate with knowledge-graph operations, “dream” consolidation that compacts and reorganizes stored facts, multiple namespaced memory “palaces,” and chat-session persistence. claude-mpm had no equivalent. Its two-file memory layer was being handed off precisely because maintaining that by hand no longer made sense.
Search is a first-class crate (semantic, lexical, and knowledge-graph search, call-chain lookup, typeahead, indexing) rather than an external MCP dependency referenced across the codebase.
Worktree orchestration is heavy and native to the design:
EnterWorktree/ExitWorktreeas real operations, and fifteen-plus simultaneous live worktrees as the ordinary way of working, not a party trick.Ticketing is a dedicated subsystem spanning GitHub issues and JIRA, not an example command.
And then the crates with no claude-mpm analogue at all: PR and diff review, git analytics, a code intelligence layer, a TUI, an embedding daemon.
It also has an original (not meta) harness called trusty-code (still a work in progress but early indications are that it will perform similarly to open-code), and a personal agents harness called trusty-agents. Both leverage many of the same orchestration tools that trusty-mpm uses, which is why I’m including them in the package.
On top of that sits a catalog of 37 specialist agents over five foundation layers, and a live skill catalog surfacing more than 190 skill names, triple claude-mpm’s 56. The prompting style changed too. A year ago you spent your prompt budget teaching the model how to be an agent. Now you spend it telling a competent agent what you want, because the harness supplies the how (in the form of memory, search, specs, and tickets).
Speaking of, ticket-driven development, the edge a year ago, is now the assumed baseline. The frontier moved up a level: many worktrees against a single repo or monorepo, several sessions of work in flight at once.
The measured contrast
Two projects, one author, one subscription. Here’s the comparison. Effort and wall-clock framing are estimates. Commit counts and dates are exact. The productivity story they imply is inference.
Time to build a comparable system: claude-mpm ~12 months versus trusty-tools ~2 months, roughly a sixth of the wall-clock time.
A more capable system (25 crates with first-class memory, search, worktree orchestration, PR review, and git analytics) came together in about a sixth of the calendar time.
Commit velocity: claude-mpm ~380/month versus trusty-tools ~860/month, roughly 2.3x, though squash-merges across many worktrees likely undercount trusty-tools’ true activity.
Velocity roughly 2.3x per month. A year of tech-lead work sharpened the exact skills this way of working rewards, driving a team, now a team of agents, and holding SDLC discipline as the branches multiply. And it shows in the git record, not just in my own say-so. Three signals I can actually measure. Commit messages that name a driving issue or decision rose from roughly one commit in ten to about nine in ten. The code now logs why, not only what. The eight near-identical agent files I copy-pasted early in claude-mpm collapsed into one composed base definition, a fix I started mid-project and carried further into trusty-tools. And architecture decision records went from essentially none to eighteen numbered ADRs plus a per-crate decisions taxonomy, a habit that matured across both projects rather than one trusty-tools invented. Developer growth and harness capability compound. They push the same direction. But even with that, a person going from good to better doesn’t buy you a sixth of the calendar time. The impressive part is still the tooling.
Capability checklist across three columns, a year ago, now, and a speculative year from now, for orchestration, memory, search, worktrees, skills, ticketing, and PR review.
Every row that read “you build this” a year ago reads “the harness provides this” now. Multi-agent orchestration: hand-built then, native flag now. Memory: thin and hand-maintained then, a knowledge-graph crate now. Search: external dependency then, first-class now. Worktrees: DIY shell commands then, a --worktree flag and fifteen live trees now.
The harness now enforces the workflow, not just supplies the parts. Spec-linked documentation was a prompt hint in claude-mpm, off by default. In trusty-tools it’s a build-blocking lint gate (trusty-sld-lint) wired into CI and pre-commit. Documentation that fails the build, not documentation you’re reminded to write. Ticket discipline hardened the same way: that rise in issue-referenced commits now sits inside a codified chain (spec → issue → PR-linked-to-issue → review gate → squash-merge), process-enforced, not yet a hard check that rejects an unlinked PR. And claude-mpm’s main branch required zero approvals and no passing checks, protected in name only. trusty-tools’ main requires a review approval and six passing CI checks, with an LLM review pass (trusty-review) as a named gate. A year ago a disciplined developer chose these. Now the harness refuses to merge without a review and passing checks.
A word on the subscription plan
Claude Max was announced in April 2025 at $100/month (Max 5x) and $200/month (Max 20x), with usage shared across chat and Code. Those price points appear to have held from then through mid-2026. The most visible change over that whole span was the five-hour rate limits for Claude Code, which Max subscribers draw on, being doubled in mid-2026. More headroom, not a different product tier.
So the input that stayed roughly constant was the money and the person. The input that changed was the model quality and the harness capability. When you hold the developer and the budget still and the output grows by this much, the variable that moved most would be the model and the harness (mostly the model, though in my experience good memory and search make a huge difference), even granting the developer improved and the language changed.
A year from now
The trajectory has a clear shape: tickets → worktrees → multi-session parallelism. Working in tickets was novel in mid-2025 and is common sense now. Native worktrees arrived in early 2026 and, within months, running many of them at once became my working model rather than a demo. Each step took a workflow that used to live in the developer’s head (tracking the units of work, isolating the parallel branches) and moved it into the tool. There are no hard adoption statistics for this progression. I’m describing a tooling timeline and a direction, not a measured majority practice. The tooling timeline itself is real, though: worktree support arriving across editors and agents through late 2025 and into 2026 follows the same curve.
The next frontier isn’t hard to name. If tickets became common sense and worktrees became my working model, the thing after worktrees is many concurrent sessions against one repo or monorepo. Enough parallel work in flight so that no human is tracking all of it, and the harness keeps the branches, the memory, and the review gates coherent. The /fork and /subtask primitives that landed in mid-2026, and subagents running in the background by default, are early moves in exactly that direction. The developer’s job shifts further from writing the steps toward specifying the outcome and reviewing the merge.
That’s not a prediction of artificial general anything. It’s the same migration, run one more turn: complexity leaving the code you write by hand and entering the tool you run. A year ago the hard part of the project was the scaffolding. This year it’s the harness. Next year it’s the coordination of more parallel work than one person can follow. So that one person gets pushed further up into the spec and the design.
What a difference a year makes
I built claude-mpm, and I’m very proud of it. For its moment it was a good answer to a real constraint. That’s the ordinary fate of scaffolding once the platform grows the feature underneath it, the design working as intended.
The measure of the year isn’t that I got better, though I hope I did. It’s that the same person, on the same max plan, with the same working habits, could build a materially more capable system in a fraction of the time, because the models got sharper and the harness absorbed the work that used to be mine to do. Twelve months of hand-built PM layer on one side, two months of composing first-class parts on the other. Same author. Same subscription.
What a difference a year makes.
Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.
Related reading:
It’s the Harness, Stupid — Why orchestration, not raw model quality, drives the spread in outcomes — the mechanism underneath this whole comparison.
What Is Harness Engineering? (And Do You Need to Learn It?) — The durable skill under the tooling: designing the loop, not just the scaffolding.
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.