The Shadow Backlog: How Agentic Code Generation Overwhelms System Architecture
TLDR: Agentic codegen makes generating a microservice a one-day event and designing one a one-quarter argument. Code velocity now outruns design velocity by orders of magnitude, and the difference accumulates as a shadow backlog: architectural debt in no ticket tracker, on no board, owned by no one. You can't out-review the volume. The leverage left is moving the review surface itself: paved roads, architectural linting, and shifting staff attention from lines to boundaries.
The Velocity Mismatch Nobody Charted
Every engineering org has two velocities, and for most of the industry's history they moved roughly together.
Code velocity: how fast working software gets written and shipped. Design velocity: how fast the org makes decisions about shape. Which patterns are standard, where boundaries live, what a "service" means here, when to say no.
For thirty years those were coupled by a hard physical constraint: writing code was slow. A team that wanted a new service spent real calendar time typing it into existence, and during that time reviews happened, conventions got argued about in PR threads, and a shared notion of "how we build things here" transmitted itself as a side effect of the slowness. Design velocity rode inside code velocity. Nobody had to plan for it. It was in the work.
Agentic code generation just unlinked them.
Generating a new microservice is now a one-day event. Designing what your organization means by "microservice" is still a one-quarter argument: meetings, ADRs, a pilot, a retro. That's not a tooling gap. Arguments between humans don't compress just because code generation did. So a ratio that held near 1:1 for three decades is suddenly 100:1 and still widening.
If the architecture of your org is the sum of all the code that exists in it, then who, right now, is actually authoring your architecture? Your design docs, or a fine-tuned autocomplete running 4,000 times a day?
What It Looks Like in the Wild
The pattern is so consistent across orgs that it deserves its own name. Here's the canonical version, assembled from real audits.
Three product teams, separately, each with good local intentions, ship new microservices in the same quarter. Each uses agentic generation to move fast, and each moves fast legitimately: good engineers, reasonable prompts, tests written, PRs approved. From inside each team, everything looks healthy. Velocity up. Delivery up. No incidents.
The system audit one quarter later finds three different logging frameworks, one structured JSON, one plain text, one logfmt with inconsistencies. All three agent stacks suggested different defaults, because the agents had no idea the other two teams existed. It finds fragmented error handling: one service with exceptions and enums, one with error codes in strings, one with a bespoke error-type hierarchy the agent invented on the spot. And it finds subtle domain-boundary breaches: service C calling service B's database directly "because the agent found the connection string and it was faster," duplicated utilities that already existed in a shared library, and a "shared" library three teams have now each forked slightly because regenerating the whole thing was easier than reading it.
Notice what didn't happen. Nobody made a bad decision. Every single decision, at the moment it was made, inside the team that made it, was locally reasonable. That's what makes the shadow backlog a principal-level problem and not a quality problem: it isn't caused by carelessness. It's caused by the absence of a global feedback loop that used to ride along with slowness.
When code took weeks, the inconsistency surfaced during writing. Someone would notice the new service's logging didn't match, because a human sat inside that gap long enough to look around. Agents don't look around. They generate whatever's locally coherent in the context they were given, at a speed that outruns every ambient feedback mechanism engineering orgs ever evolved.
So the debt accumulates. Quietly. Off-book. In no ticket. On no board. With no owner, no estimate, no priority, because it doesn't exist anywhere except everywhere. That's the shadow backlog: architectural debt that materializes at generation time, in thousands of small plausible decisions, and only becomes visible at integration time, audit time, or incident time, when it's already load-bearing and already expensive.
And it compounds, because the agents are learning from the output. Every inconsistency that lands becomes training context for the next generation, both for fine-tuned models and for the simpler mechanism that matters more, agents that read your repo and imitate what's in it. The shadow backlog isn't just accumulating. It's recruiting. Every deviation that lands makes the next deviation more likely, because it now looks normal.
You cannot out-review the volume. The only lever left is moving the review surface itself.
Fix 1: Paved Roads, Published Before Anyone Needs Them
The first fix inverts a long-standing assumption about developer tooling: instead of waiting for teams to make a mess and reviewing it, put the correct answer in the path of least resistance first.
The pattern is paved roads, an internal developer portal (Backstage-style) where the default way to build a thing already encodes the org's architectural decisions. Generate a new service from the portal and you get the sanctioned logging framework already wired, the standard error handling already in place, the observability stack already integrated, the dependency policy baked in. The default is the architecture.
Not mandatory. Gravity, not gates. The lesson from every org that's done this well: paved roads fail the moment they feel like bureaucracy. They work when deviating is possible but annoying enough to require a reason.
For agentic generation, the paved road does something new. When an agent generates "a new service," it no longer samples from "what a plausible microservice looks like across all of GitHub." It samples from your template. Your architectural decisions are the prior now, not the exception. A principal engineer's quarterly "what should a service look like here" decision, expressed once in a template, propagates into every generated artifact silently, without spending a single review-hour.
Fix 2: Architectural Linting, the Boundary as a Build Failure
Paved roads handle the greenfield. The second fix handles ongoing drift in the existing estate: turn architectural rules into deterministic checks that fail builds, before merge, before deploy, before any human or agent has to be the one to notice.
- Boundary rules as code. Tools in the ArchUnit / dependency-rule lineage: "no module under
data/may import fromhttp/," "the domain layer may not depend on any framework," "this service may not open a connection to that database." Enforced in CI. Not review guidelines. Build failures. - Dependency policy as gates. Banned libraries, license constraints, security-review-required packages, encoded the same way, so the agent that "just adds a dependency to make it work" gets stopped by a machine instead of noticed by a senior three weeks later.
- Custom AST checks for the rules that are genuinely yours. The conventions that matter most are too org-specific for off-the-shelf tooling: "every handler must propagate the request context," "no new top-level modules without an owner file," "money is always minor-unit integers." These are cheap to write as AST parsers, genuinely a senior engineer's afternoon, and they're the difference between rules that exist and rules that hold.
The design principle underneath: a rule a human has to notice is a rule that will eventually be missed. A rule a machine enforces is a rule that's just true. At agentic volumes that's not a quality difference, it's an existence difference. Anything not machine-enforced is, statistically, not enforced at all.
There's a second-order effect too, and it matters at the principal level. Once boundaries are machine-checked, review stops being the place they're defended. Every rule encoded as a build failure is attention returned to the conversations that actually need a principal: should this domain exist, is this the right contract, is this the right tradeoff.
Fix 3: Move Staff Review Up a Level
The third fix is the one that feels most career-personal, and it's what makes the other two sustainable: stop trying to review the volume at all.
The honest arithmetic: a principal reviewing agentic output line by line is a mop in front of a firehose. At a generous few hundred lines an hour of real architectural review, the volume outpaces any review team that exists, while the reviewer's time is the scarcest, most expensive resource in the org. This isn't a staffing problem. No staffing level solves it. It's a geometry problem, and the only solution is to change what the review surface is.
- Review domain models, not diffs. The decisions that scale happen at the schema and model level. A principal who reviews those is reviewing the thing every future generated artifact will inherit. A principal reviewing diffs is reviewing downstream consequences, one PR at a time, forever.
- Review data boundaries, not implementations. Data is where coupling actually lives, where audits fail, where security breaks. A boundary enforced at the data layer holds under any implementation churn above it.
- Review the API surface, not the code under it. Contracts are the stable shape of a system. They change slowly, they matter durably, and they're reviewable at a pace agentic volume doesn't invalidate. The implementation under a stable contract can churn as fast as the agents can churn it.
This isn't a demotion from code. It's a promotion from being the system's most expensive linter. Line-level review was always a workaround for the fact that architectural intent was hard to express mechanically. With paved roads encoding the defaults and lint rules enforcing the boundaries, the workaround is obsolete, and the principal's actual job, deciding what the system's shapes should be and holding that line against an entire org's momentum, is finally unblocked.
The Question Underneath the Question
Here's the version of this future that keeps principal engineers up at night, and it isn't hypothetical anymore:
How does your architecture hold up when 80% of the commits in your org are agent-generated?
Not "could you handle it." Are you handling it. At current adoption curves most orgs reading this are already past 40%, and the trend only goes one way. The three fixes above aren't AI-era inventions. They're the practices maturity models have recommended for a decade. What agentic generation did was change their return on investment from "good practice" to "load-bearing," because they're the only mechanisms in the org that scale down in cost as volume scales up.
The shadow backlog is already growing. The only choice left is who shapes it: the agents, one locally-reasonable decision at a time, or the architecture, expressed in the paths generation actually takes.
Your Turn
This one's a principal-level conversation, and the most useful data is always other people's audits. Bring yours.
- Are your teams shipping higher-value software, or a larger footprint of long-term technical debt? What metric would even tell you the difference? If you can't name one, that's the shadow backlog's signature: invisible to every dashboard that tracks delivery.
- How will your architecture hold up when 80% of commits are agent-generated? What percentage are you at right now, and do you actually know, or would you have to guess?
And the one I most want answered, because I've never heard it discussed publicly: who owns the shadow backlog at your org? When the audit finds three logging frameworks and a forked shared library, whose job is it formally? Or is it nobody's, which is how it stayed invisible until the audit?
Drop your audit stories in the comments. The "three teams, three frameworks, zero bad decisions" genre is becoming its own literature, and the more of it we share, the faster the rest of the industry learns to look for it.
Next in the series: Model ROI Economics. When frontier reasoning models are doing commit messages, and what that costs before anyone looks at the invoice.
Top comments (0)