Let me get one thing out of the way first: I’m bullish on AI engineering. In many ways, aggressively so. I push my team hard on agent adoption, and I’d do it again tomorrow. Coding agents work. Claude Code, Cursor, and autonomous multi-agent setups generate working code at a pace that would have sounded like fiction three years ago. Roughly 46% of all code written by active developers is now AI-generated, and the teams sitting this out are making a mistake they’ll pay for. In my team, we’re at 90+%.
Precisely because I’m pushing hard, I wanted to understand where the failure modes are. So I built a causal loop model (with my new favorite AI tool, HebelAI) of what happens inside an engineering organization under aggressive agent adoption - not to argue for slowing down, but to see the trap before we’re in it. If you’re going to drive fast, you’d better know exactly where the road ices over.
Because there is a trap, and the 2026 numbers sketch its outline: teams with high agent adoption merge 98% more PRs, but review times are up 91% and PR sizes have grown 154%. Code churn - code rewritten or deleted within two weeks of being merged - nearly doubled, from 3.1% to 5.7%. And in mature codebases, experienced developers using AI assistance measured 19% slower on task completion, while believing they were about 20% faster.
None of this is an argument against the tools. It’s an argument about system design. Organizations that fall into the trap don’t fail because they adopted agents - they fail because they bolted agents onto feedback structures built for a slower era
Looking below the waterline
The classic systems-thinking iceberg is useful here, so bear with me for one framework.
At the surface, you have events: a critical bug takes production down, someone works a weekend, a deadline slips. One level down, patterns: code complexity climbing month over month while developers’ (felt) understanding of their own architecture declines. Below that, system structure: the feedback loops connecting tool usage, management expectations, review quality, and skill erosion. And at the bottom, the mental models that hold the whole thing in place - chiefly the assumption that code is an asset rather than a liability, and the belief that you can safely orchestrate systems you no longer understand in detail.
Most organizations respond at the event level. Postmortem, action items, move on. The model I built lives at the structure level, and that’s where the interesting stuff is.
The anatomy of the trap
The model has four clusters - AI adoption, knowledge & skills, code development & quality, and culture & steering - connected by a handful of feedback loops. Three mechanisms carry most of the story.
1. The competence flywheel
It starts well. Engineers pick up the tools, tool capability keeps improving, usage intensity climbs - in my model it sits at around 40% of working time, which matches what I see in practice. Heavy usage slowly builds a stock of AI competence: prompting, context engineering, a feel for where models fail. Greater competence leads to better results, which further drives usage. A reinforcing loop, and while it lasts, a very pleasant one.
This is the honeymoon phase of agent adoption, and I want to be clear: this flywheel is real value, not an illusion. The competence it builds - prompting, context engineering, knowing where models break - is a durable asset. The mistake isn’t riding the flywheel hard. The mistake is assuming it spins forever without maintenance.
2. The complexity brake and sinking skills
Then the system pushes back from two directions at once.
First, complexity. Production speed feeds a growing stock of code complexity, with a delay, which is what makes it treacherous. Code generated in minutes doesn’t automatically fit the architecture it lands in. Complexity drives review and test effort up, and since nobody’s week got longer, rising review effort throttles actual throughput. That’s a balancing loop, and it’s the one behind the 91%-longer-review-times statistic. Reviewing has quietly become the bottleneck of the whole profession. One study put it plainly: AI generates code at 140-200 lines per minute, while humans comprehend it at a maximum of 20-40 lines per minute. The gap between what we produce and what we understand compounds daily.
Second, and more dangerous: skill erosion. When engineers generate code rather than construct it in their heads, their understanding of the system drops. Researchers started calling this “cognitive debt” in early 2026, and it moved from anecdote to evidence fast. AI-assisted developers score 17% lower on comprehension tests of their own codebases, and 76% of developers admit they ship code they don’t fully understand at least some of the time.
Lower system understanding means more defects slip through - hallucinated logic, quiet architecture violations. Those defects force long debugging sessions, further inflating review effort and slowing everything down again. The loop closes.
3. The time-pressure spiral
The nastiest mechanism in the model sits at the boundary to management (this is where I learn about myself).
Management sees the first spike in production speed and, after a delay, ratchets up delivery expectations. In my model, that’s leading to 52 story points per sprint and climbing. Higher expectations produce time pressure on engineers. And under pressure, the team takes the one shortcut always available: it cuts review effort. Reviews get shallower, tests get skipped, and the sprint gets saved.
Here’s the ugly part: cutting reviews makes apparent velocity go up. Which feeds expectations further. Which raises pressure again. A reinforcing loop wearing a balancing loop’s clothes. Meanwhile, the skipped reviews let defects and complexity accumulate invisibly. The bill arrives 30 to 90 days later, which happens to be exactly the window where recent research finds AI-code failures surfacing in production. By then, nobody connects the incident to the sprint where the review discipline quietly died.
Two old archetypes, one new costume
If you’ve read your Senge (or use HebelAI), you’ll recognize both patterns.
Limits to Growth. The competence flywheel is the growth engine; the limit is the human brain’s fixed capacity to comprehend machine-generated code. When the limit binds, it shows up as exploding review effort - or, in organizations that panic, as compliance clampdowns where security teams simply block the tools. In the model, the governance variable currently sits at a lax 20 out of 100. It won’t stay there. The clampdown, when it comes, kills the flywheel abruptly instead of managing it.
Shifting the Burden. The symptom is missed sprint goals. The quick fix is to generate more code faster and trim reviews. The fundamental fix is refactoring, keeping the team’s mental model of the system alive, and resetting expectations around sustainable metrics. Every time the quick fix wins, the fundamental capability - deep understanding of the codebase - atrophies a bit more. Teams become agent-dependent: unable to localize a complex failure without tool assistance. I’ve watched this start to happen, including on teams I push hard myself. It’s uncomfortable to name because the individual choices all felt reasonable. Naming it is also the price of admission for pushing hard - you don’t get to demand speed and then act surprised by the failure mode that comes with it.
Where to intervene
Donella Meadows ranked intervention points by power: parameters are weak, information flows, rules are stricter, and goals and paradigms are strongest. Applied to where we are at the moment (mid-2026 engineering reality):
Change the information flows. Most management dashboards still run on throughput proxies - velocity, merged PRs, lines shipped, issues done. Those metrics are now actively misleading because agents inflate exactly those numbers. Track the review-to-generation ratio instead. If generating a change takes five minutes and reviewing it takes two hours, that imbalance is the single most important number in your organization, and almost nobody has it on a dashboard. Same for complexity trend lines: make the architecture decay visible so that today’s apparent speed is understood as a loan against tomorrow’s maintainability.
Change the rules. The spec-driven development movement got this right: writing a structured, versioned spec before unleashing an agent - explicit goals, constraints, acceptance criteria - trades an hour of thinking for days of agent thrash and weeks of review. Adoption is spreading fast, and I’d expect it to be the default for production code within two years. Add to that a review budget: a team merges only as much code per sprint as it can demonstrably review with rigor. Generation beyond the review limit blocks the pipeline. Yes, this caps output. That’s the point - it caps output at the level the team can actually absorb.
Change the goal. The system’s implicit goal today is feature throughput maximization. Replace it: maximize the team’s cognitive capacity. The asset is not the code - the asset is the shared, living mental model of the software in the heads of the people responsible for it. One practice I’ve seen work: reverse-engineering sessions where a developer explains agent-generated code to the team, out loud, without the agent’s help. It feels slow. It’s the opposite.
Change the paradigm. The strongest lever is retiring an old sentence: “software engineering is writing code.” It hasn’t been true for a while, and in 2026 it’s actively harmful. The job now is formulating intent precisely, verifying behavior rigorously, and managing system boundaries. This is also why the “product engineer” framing has taken off this year - as agents absorbed the mechanical work, what’s left and what matters is judgment: what to build, what not to build, and where the boundaries of the system belong. Engineers who internalize this use agents to orchestrate small, legible, well-bounded systems. Engineers who don’t use them to pile up code.
What I’d actually do
To be blunt about my own position: the answer to the trap is not less AI. Teams that respond to these risks by throttling adoption lose twice - they keep the old velocity ceiling and forfeit the compounding competence flywheel. The answer is pushing hard on adoption and rebuilding the feedback structure so the organization can absorb what the agents produce. Three moves, in order:
Trade a little pace for a lot of direction. Not a retreat - a pit stop. Explicitly reset delivery expectations for a quarter, out loud, from the top, so the team can rebuild system understanding without the time-pressure spiral punishing them for it. The model shows why only management can do this: expectations are the input to the whole spiral. Then raise them again, massively - on the new, sturdier foundation.
Reward code deletion. If your incentive system celebrates the developer who shipped three thousand lines this week and ignores the one who removed a dependency and deleted a module, you are paying people to dig the hole deeper. Agents make addition nearly free; that makes subtraction the scarce, valuable skill.
Tighten the feedback loops. Whoever pushes fast agent-generated code owns its production behavior - including the 2 a.m. page. Not as punishment, but as information flow. The model’s central pathology is delay: consequences arriving weeks after causes, at someone else’s desk. Shorten that delay, and the system starts teaching people the right lessons on its own.
The agents will keep getting better, and I intend to keep pushing my team to use them at the edge of what’s possible. That part was never in question. The question is whether we amplify that capability into durable systems or into the fastest-growing pile of unreviewed complexity in the history of the industry. The feedback structure decides - and the feedback structure is ours to change. The boldest move in 2026 isn’t maximum generation speed. It’s building the organization that can actually cash the checks the agents are writing.
And, one thing was always true, but only embraced in a few places, becomes even more important now: SW Engineering was never about the output or throughput - it was always about impact and the value delivered.
The causal loop model in this post covers four clusters: AI adoption & tools, knowledge & skills, code development & quality, and culture & steering, with reinforcing and balancing loops across roughly a dozen variables. Figures show excerpts; the values shown (40% AI usage intensity, complexity index 80, 15 bugs per sprint, and so on) are illustrative calibrations, not measurements.
Referenced developments and data:
Faros AI “AI Productivity Paradox” telemetry (10k+ developers) — 98% more PRs, 91% longer reviews, 154% larger PRs; churn figures via GitClear; summarized in AI coding agent productivity debates: the 2026 paradox
METR — the 19%-slower / feels-20%-faster gap for experienced developers in mature codebases
2026 Agentic Coding Trends Report (Anthropic) — delegation patterns and role-shift trends (qualitative)
The best engineers in 2026 aren’t the best coders — review as the new bottleneck
Cognitive debt: how AI coding tools erode developer skills — 17% lower comprehension scores, 140–200 vs. 20–40 LOC/min
Faster code, deeper debt? (arXiv, 2026) — technical debt in LLM-assisted development
The productivity–reliability paradox: spec-driven governance (arXiv)
The impact of AI on software engineers in 2026 (Pragmatic Engineer)
Agentic AI solved coding — and exposed every other problem (VentureBeat)