Three Feedback Loops That Will Eat Your Engineering Team

I’ve been writing a policy for AI-assisted development at an open-source project, and somewhere between “who’s responsible for code nobody read line by line” and “what happens when review capacity can’t keep up with production,” I realized I wasn’t writing a policy anymore. I was drawing a system dynamics diagram on the back of an envelope.

So I had Claude draw the actual diagram. And then write the blog post.

The Model

Five nodes, three feedback loops. The idea behind system dynamics is that you stop looking for individual causes and instead analyze the structure of the feedbacks: which loops reinforce each other, which ones brake, and where are the delays that make problems invisible until they’re already deep? If you’ve ever watched a team slowly lose control of their codebase, the structure here will feel familiar.

Nine nodes; three external forces, three internal feedback loops, and an output. Try clicking “Delivery Pressure” to increase it and watch the signal propagate through the system. Then click “Compliance” as a counterweight.

Loop 1: The Productivity Treadmill

More agent autonomy → more code output → higher expectations
→ pressure to use agents more → more agent autonomy

This is Jevons Paradox wearing a hoodie. Your team adopts coding agents. Velocity goes up. Management notices. “Great, we’ll plan for this capacity going forward.” Now the agents aren’t optional anymore; they’re the baseline. Any attempt to slow down and invest in comprehension runs into “but we shipped 3x last quarter.”

The pattern — efficiency gains consumed by raised expectations rather than converted to slack — is older than software. Ruth Schwartz Cowan documented it for washing machines: American housewives spent 52 hours per week on housework in the 1920s, and still 52 hours in the 1960s, after the washing machine, the vacuum cleaner, and indoor plumbing. The machines didn’t create free time; they created higher cleanliness standards. Clothes that were washed weekly were now washed after every wear. The technology got faster, the goalposts moved, the hours stayed the same. What’s new with coding agents is the speed at which the ratchet turns. With household appliances, the cycle took decades to settle in. Coding agents do it in sprints.

An eight-month ethnography at a US tech company, published in HBR by Ranganathan and Ye, documented exactly this cycle: AI accelerated tasks, expectations rose to match, AI dependency increased, workload intensified without time savings. Unsurprising to historians of technology; apparently news to the industry.

Loop 2: The Skill Erosion Spiral

More agent autonomy → less manual coding practice → lower skill
→ less ability to evaluate agent output → rubber-stamp reviews
→ unjustified trust → more agent autonomy

This one has a delay, and the delay is what makes it dangerous.

When the agent writes your code, you don’t practice writing code. When you don’t practice, your skills erode. When your skills erode, you can’t tell good agent output from bad anymore. When you can’t tell good from bad, everything looks fine — the code compiles, the tests pass, the PR gets approved. You trust the agent more. The agent gets more autonomy. You practice even less.

Clive Thompson’s “Coding After Coders” in the NYT Magazine documented a developer who noticed skill degradation after four months of heavy Copilot use. Four months. One quarter. One performance review cycle. The erosion starts before anyone thinks to measure it; by the time it becomes visible, the comprehension deficit is already deep.

The cruelest part: the people losing skill don’t know they’re losing it. The pieces are there in the research: AI-assisted workers produce better output (Dell’Acqua et al., Harvard/BCG), while separately, work on automation complacency shows that tool-assisted performance inflates self-assessed competence. The full combination isn’t yet established as a single empirical finding, but the direction is clear: the AI compensates for the deficit while hiding it. It’s giving Dunning-Kruger, but with better tools.

Loop 3: The Review Bottleneck (Your Only Brake)

More code output → more review burden → worse review quality
→ more bugs → less trust in agents → less agent autonomy
→ less code output

This is the balancing loop — the system’s natural brake. When code production outpaces review capacity, quality drops, bugs surface, trust erodes, and the team throttles back. In theory.

In practice, this loop has a fork in the road, and which branch your team takes depends on something that has nothing to do with technology: management culture.

Branch A (healthy): The review queue builds up. The team says “we can’t review this fast enough, let’s slow production to match.” Painful in the short term. Sustainable long-term. Almost nobody does this voluntarily.

Branch B (pathological): The review queue builds up. Someone says “just approve it, the tests pass, and it’s already 11pm.” Review is weakened. Short-term: velocity stays high, no visible problems, everyone’s happy. Long-term: you’ve disabled your only brake, and the reinforcing loops run unchecked.

Most organizations drift into Branch B — not because they’re stupid, but because the short-term incentives point that way, and the damage from weakened review has a delay. Security vulnerabilities in agent-generated code can sit undetected for months. By the time the consequences arrive, the cause is long lost in the fog.

The Tipping Point

There’s a relationship in this system that matters more than any individual metric: how much of your codebase is Comprehension Debt, relative to what the team actually still understands? Not a formal measure — more of a mental model. But a useful one.

Comprehension Debt is code in your codebase that nobody on the team understands well enough to modify, debug, or evaluate for correctness. It accumulates every time an agent produces code that passes review-by-vibes rather than review-by-understanding. Invisibly. Quietly. Like mold behind drywall.

Below a certain threshold, the team can manage. They might not understand every line, but they know the architecture, the design decisions, the failure modes.

Above the threshold, they’re flying blind. Changes in one module break things in another, and nobody knows why. Debugging becomes guesswork. The agent becomes indispensable — not because it’s good, but because nothing else can navigate the mess it helped create.

This transition isn’t a slope; it’s a cliff. One day the system is manageable. The next, a senior engineer leaves, and their portion of the codebase — the part only they understood, the part that was “just ask Maria” — becomes Comprehension Debt overnight. This scenario isn’t rigorously studied — but everyone who’s been in the industry long enough knows a version of it. The bus factor is real, even if nobody measures it.

What You Can Actually Do

I’m not going to pretend this is a listicle with five actionable takeaways. The dynamics are structural. But research on leverage points in systems suggests where to push:

Invest in the balancing loop. Review capacity is your only brake. Protect it. Fund it. Don’t let “the tests pass” substitute for “a human understood this” — or at least manage the Comprehension Debt consciously. If your review queue is growing faster than your review capacity, that’s not a review problem — that’s a quality problem. Act accordingly.

Make Comprehension Debt visible. You track technical debt (in theory, ja ja, ich weiß). Track comprehension debt too. Which parts of the codebase does nobody on the current team understand? That’s your actual risk register. I’ve been developing a labeling system — AI:RED through AI:WHITE — indicating how much human comprehension went into each artifact. It’s not perfect, but it makes the invisible visible. You can also flag it in a merge request.

Decouple output from expectation. This is a management conversation, not a technical one. “We shipped 3x with agents” does not mean “3x is the new baseline.” Some of that output should be converted to slack — time for comprehension building, deliberate practice, refactoring. If your management can’t understand this argument, show them the diagram. That’s what it’s for.

Accept the skill erosion delay. Your team’s skills are eroding right now, and you won’t notice for months. Build in deliberate practice: regular agent-free coding sessions — not as Luddism, but as the cognitive equivalent of physiotherapy. You don’t stop using an assistive device to prove a point; you exercise so you stay capable of working without it if you need to.

The System Doesn’t Care About Your Intentions

I use coding agents every day. I wrote this post with one. I am not arguing that you should stop using them. That ship has sailed, the harbor is closed, the ship is also on fire but somehow still faster than swimming. 🔥🐕☕ This is fine.

What I’m saying is: the system dynamics of adoption are not neutral. They have a direction, and that direction is toward more autonomy, less comprehension, and a team that feels productive while slowly losing the ability to judge its own work. If you don’t actively intervene in the feedback structure, the reinforcing loops will win. Not because anyone decided they should, but because that’s what reinforcing loops do.

Donella Meadows wrote that the most effective place to intervene in a system is at the level of paradigm — the mental model that generates the system’s goals and rules. And the current paradigm has a name: it’s accelerationism. The vibe shift in tech culture — from “move fast and break things” to “move fast and don’t even look” — is manifesting concretely: Andreessen’s Techno-Optimist Manifesto, Karpathy coining “vibe coding,” Shopify’s Lütke making AI usage a prerequisite before you’re even allowed to ask for headcount. That’s not just discourse; it’s the thing that drives the Delivery Pressure node in the diagram. Executives read the same narratives and act on them independently, creating coordinated behavior without coordination. DiMaggio and Powell called this institutional isomorphism in 1983; in 2026 it runs on Twitter¹ instead of management journals, but the mechanism is identical.

The alternative paradigm doesn’t have a catchy name yet, and that’s part of the problem. “Agents are a great cognitive extension of our capabilities, but only as long as we don’t hand them too much of our work” doesn’t fit on a slide. But it’s the one where your team still understands their own system next year.