The Agentic Coding Bottleneck Isn't Where You Think

The Bottleneck Moved

Anthropic's forward deployed engineers put it plainly: code modernizations that used to be scoped as multi-year, all-hands efforts now finish in months or weeks. The organizational work on either side hasn't shrunk the same way. Every change to a critical banking system still goes through change management, review, and approval, because regulators and auditors require it. Those processes were built on the assumption that a human wrote each change and a human would review each diff.

Once agents accelerate the writing, the bottleneck shifts from producing changes to mobilizing the organization around them. That's the sentence that matters. The code was never the hard part. The hard part is everything that has to happen before a change is trustworthy enough to merge.

Start with the work that happens before an agent writes a line: defining what done means.

Defining "Done" Before You Start

Every modernization project needs a target, and the target decides which of three kinds of modernization you're doing.

Modernization type	What changes	Risk profile	Typical advocate
Transform	Stack swapped, behavior held constant	Lowest	Teams closest to production who want to contain risk
Reimagine	Behavior, requirements, and tech debt all on the table	Higher	Engineers who lived with the codebase, plus business stakeholders with new requirements
Uplift	Modernize in place on the live codebase, partition by partition	Medium	Systems that can't go down, or codebases changing faster than a parallel copy can track

The tension between these is predictable. People closest to production want a transform, because swapping the stack while holding behavior constant is the safest possible change. Engineers who have lived with the codebase want a reimagine, because this is their one chance to pay down debt. Business stakeholders see an opening to name new requirements. If you leave this unresolved, it resurfaces later as an argument over whether a given change is "correct."

Understanding the current system first helps. Extracting what the old code actually does, mapping dependencies, and documenting workflows that nobody remembers building tells you what to keep, drop, or change. Claude can do much of that discovery with the code modernization plugin's assess, map, and extract-rules commands, which mine business rules with source citations. But discovery alone won't capture everything a legacy system does. Interviews with business users and developers fill those gaps, and the quality of that context shapes every decision downstream.

The counterweight to all this debate is risk. Cost reduction, in Anthropic's experience, is rarely the driving goal of these projects. Risk reduction is: unpatched vulnerabilities, unsupported runtimes, a shrinking pool of engineers who understand the system. When stakeholders disagree over how much risk a change can carry, the risk of not modernizing is what anchors the decision.

The Certificate: Evidence an Agent Can Produce

The certificate is the set of conditions every modernization change must meet before it counts as done. Each condition has to be checkable without a human in the loop, so the agentic workflow can iterate on a change until it meets the bar, or flag it for human review when it can't.

What goes into the certificate depends on the target, but it usually draws from CI tests, static analysis, integration suites, and whatever telemetry exists. Older systems often have thin test coverage, flaky tests, and little observability. If the evidence base is weak, one of the most useful things you can do is use Claude to build the missing evidence: stand up a prod-parallel environment, build a replay harness, write more tests.

Write the certificate with the people who will review and promote changes. Their early involvement is what earns buy-in at review time. A good test: would they be comfortable merging on the certificate's evidence alone? If they see their own bar in it, the promotion policy can be lighter.

Promotion Policy: Review at Agent Speed

Agents produce changes far faster than any human team can review them diff-by-diff. The promotion policy is a tiered review path, written down and agreed in advance, that sets the depth of human review per change. Without it, the modernization stops at the review queue.

A few rules hold across organizations. Get subject-matter experts involved early to tune the certificate, rather than at the end. Use their sign-off on sample changes as justification for lighter review where confidence is high. Fit the policy into your existing change-management process wherever you can.

The speed-versus-depth tradeoff is real. A modernization racing to a hard deadline, like a runtime losing support, needs a faster policy with lighter human review and an explicit agreement to accept more risk per change. A longer timeline can afford deeper review. Lock that in before the work starts.

Quick Take: Agentic coding didn't make review obsolete. It made the certificate and the promotion policy the primary engineering artifacts, because they're what let you trust changes you'll never read in full.

One trap here is regulated environments. Individual approvers hesitate to sign off because they personally carry the risk of a bad change, while leadership carries the larger risk of an aging system. Anthropic's advice: have the directive come from the top, and agree on it beforehand, so responsibility for a bug that reaches production is shared rather than pinned on whoever approved the change. Nobody wants to be the person who merges the bad diff alone.

Context: What Your Assistant Knows That Your Teammate's Doesn't

The enterprise process solves correctness. A separate problem is context portability. One developer described it better than any product spec I've read: their AI took months to learn how they think, code, and ship. When a teammate joined the project, their AI started from zero. Same codebase, same conventions, none of the context.

That's the missing layer in AI tooling. Every assistant today treats memory as a product feature locked inside one account. Claude remembers things for you. ChatGPT remembers things for you. Nobody else can get at it, not your teammate, not your other tools, not even you in a greppable format. A designer in Cursor builds up months of component conventions; a backend developer in Claude Code has none of it. Switch tools and you start over. Onboard a new teammate and their AI spends weeks re-learning what yours already knows.

The memshare project treats AI memory as a data type instead: plain JSON files you own, not a feature of someone else's chat product. Capture happens in conversation, the AI calls a memory_set tool when it learns something. Export produces a bundle, the recipient previews it and imports item by item, and every export runs a PII scan at export time, not write time. The architecture is the point:

The memory store is the product. The MCP server is one adapter over it, the CLI is another. No database, no server. grep works, diff works, git works. If MCP disappeared tomorrow, the data still sits in a folder.

The honest risk, as the author notes: nothing in MCP can force a model to call a tool, so capture can quietly fail. They built a stats command that shows a flat line when capture stops firing, so you know within days.

Key Numbers The Joplin CLI harness ships with a 134-test validation baseline, the kind of coverage you want when an agent drives notebook and attachment operations unattended. The FreeCAD harness exposes 258 commands across 17 groups, which is how an agent gets fine-grained control of a CAD tool that was never designed with an API. The Zotero harness pairs 48 unit tests with 7 end-to-end tests, enough to catch regressions across library management and citation workflows. The Obsidian harness matches that shape at 48 unit and 7 E2E tests. And when the Wasmer interviewer required manual review, it took 3.5 hours to refresh enough to catch 7 bugs.

Community feedback here was sharp and specific. Someone pointed out that a memory file saying "we chose Postgres" goes stale when the team migrates, and no tool warns the next reader. The author's response: one file per UUID, last write wins, no history, but with an expiresAt TTL you can set explicitly. They also flagged that sharing an AI's context without control is a terrible idea, which is why the consent model has four gates: tagging at creation, PII scanning before anything leaves the machine, preview that runs the same code path as the real export, and per-item recipient acceptance.

Tool Access: Make Software Agent-Ready

Context portability solves one half of the tooling gap. The other half is access: agents can only use what they can call. The CLI-Anything project's thesis is that the CLI is the universal interface for both humans and agents. Text commands match LLM format, --help flags provide self-describing documentation agents can discover, structured JSON output eliminates parsing complexity, and deterministic results enable predictable behavior.

The project wraps desktop and backend software into agent-native CLI harnesses: GIMP, Blender, FreeCAD, LibreOffice, Obsidian, Zotero, Godot, Zoom, even Slay the Spire II. A seven-phase generator analyzes a codebase, designs command groups, and builds a Click CLI with REPL and JSON output. A CLI-Hub registry lets agents discover and install harnesses autonomously, and a meta-skill means the agent can find the right CLI for a task without a human pointing at it.

The registry news is a running list of security hardening and test additions. Zoom downloads were fixed to pull from direct URLs, XML parsing routes untrusted input through defusedxml, and a Sketch CLI token-file handler was hardened against path traversal and symlink escapes. That's the unglamorous work that makes agent-driven tooling safe to run, and it's easy to miss when you're watching demos.

The harness question is showing up everywhere now. On r/LocalLLaMA, someone asked which harness gets the most out of Qwen 3.8: Qwen Code reportedly gets more out of the model and has more power-user features, while OpenCode wins on working with multiple models more easily. Different agents, different strengths, same underlying problem. The projects consolidating around MCP, SKILL files, and CLI registries are the ones betting that a common protocol beats any single vendor's lock-in.

Configuration Sprawl and the Template Answer

With dozens of agents, commands, MCP servers, hooks, and settings floating around, configuration has become its own kind of code. That's what claude-code-templates addresses: a catalog of over 100 ready-to-use agents, slash commands, settings, hooks, skills, and MCP integrations, installable with a single npx command.

The component taxonomy shows the shape of the problem. Agents are AI specialists for domains like security auditing or React performance. Commands are custom slash commands like /generate-tests or /optimize-bundle. Skills are reusable capabilities with progressive disclosure, meaning the agent loads only what's relevant. Hooks are automation triggers like pre-commit validation. MCPs are external service integrations for GitHub, PostgreSQL, Stripe, AWS.

The aggregator model is where the value sits. The project pulls from Anthropic's official skills, Jesse Obra's superpowers workflow skills, wshobson's agents, and a collection of scientific skills for biology, chemistry, and medicine, each retaining its original license. Same pattern as CLI-Anything's registry: agent tooling is fragmenting fast, and the winners are the discovery layers that let you search, preview, and install components across sources.

What Happens to Manual Review Skills

The uncomfortable question. A developer interviewing at Wasmer posted a brutally honest account that got a lot of traction. They had spent the night before prepping demos, had a durable workflows system converted to run on Wasmer Cloud, an MCP deployment to edge, a dashboard showing it all. The interview went great. Then came the manual code review: a tiny cache file, and they choked.

The part that should worry everyone is what happened next. They flagged a mismatch, a SHA-256 hash paired with a 16-byte array, and knew something was wrong just by looking at the code. But they couldn't articulate what. As they put it: my brain knows THERE'S SOMETHING HERE, but I can't explain it. They'd gotten so used to selecting a block of code and having the AI fix it that the vocabulary of explanation had atrophied. A file create inside an async loop, a missing borrow for anyhow context, an await without the right number of question marks. All things they would have caught cold six years ago.

The community reaction split roughly in half. One camp argued the hiring process is stuck: they're testing whether you can be a human linter, and the skill that matters now is building infrastructure that proves the AI's context is structurally sound. The analogy floated was structural engineering versus laying bricks: the engineer designs the blueprint and lets simulation software verify the math. The other camp pushed back hard, pointing at idempotency bugs in payment gateways and saying for critical paths, you still review raw code. I found the pushback more convincing. I barely caught a payment idempotency bug myself a few months ago, and I wouldn't have if I'd trusted the generated code wholesale.

The author's own take is the fairest one: errors didn't slip past them during AI-assisted work. They knew where the issues were, hovered over them, recognized them by sight. What they lost was the ability to explain. That's a different skill than review instinct, and right now the hiring market still treats it as the entry ticket.

Common Pitfalls

Skipping the certificate because the code looks right. Agents produce plausible diffs faster than any human can read them. Without an automated, human-checkable bar, review becomes a bottleneck and every change gets the same shallow scrutiny. The certificate is what lets you trust a diff you never fully read.

Letting individual approvers carry the risk alone. In regulated environments, a reviewer who merges a bad change owns it. Unless the promotion policy directive comes from leadership and is agreed in advance, you'll get hesitancy or a de facto veto at every merge. The risk of not modernizing has to be carried by the organization, not the approver.

Fixing individual changes instead of the workflow. When the pilot surfaces issues, modify the workflow, not each output. The goal is confidence that at scale, changes meet the certificate almost everywhere. If you hand-edit outputs during the pilot, you learn nothing about the system that produces them.

Scaling before measuring. Token costs vary wildly with model choice, codebase complexity, and retry rates. Several cheap attempts that fail the certificate can cost more than one expensive attempt that passes. Run the modernization on a small slice, measure token usage, extrapolate, and treat anything the pilot couldn't see, like live-codebase reconciliation, as an unknown.

Ignoring memory staleness. A memory that says "we chose Postgres" is a liability six months after the migration. memshare's own author admits there's no active staleness warning, and bundles can hand a teammate a dead decision with no signal. If you share AI context, treat timestamps and explicit re-validation as part of the data: "last touched" and "last confirmed correct" are not the same fact.

One Thing to Remember

The pattern across all of this is that agentic coding moved the hard work sideways. Writing code is cheap now. Defining what correct means, proving it, sharing the context that makes it possible, giving agents safe access to the tools, and keeping humans able to verify what they didn't write: that's the job. Every project in this space that works has a certificate, a promotion policy, or a consent model at its center. The ones that don't produce a lot of code and very little trust.

The Bottom Line

Three scenarios, three answers.

If you're modernizing a critical system, adopt the certificate and promotion policy pattern from Anthropic's field engineers before you let any agent touch the codebase. Write the certificate with the reviewers, pilot on a small slice, measure token usage, and fix the workflow rather than the outputs. That's the difference between a modernization that lands in months and one that dies in the review queue.

If you're building tooling for agentic workflows, build on MCP and the CLI as the universal adapters. memshare, CLI-Anything, and the template catalogs all converge on the same bet: portable context, discoverable tools, and a common protocol. If your tool works only inside one assistant's account