The editorial argues software engineering is currently running Repenning and Sterman's experiment in real time. AI coding tools pull throughput forward (20-46% more code shipped) while pushing the costs of comprehension, review, and architectural coherence into the future — a textbook capability-trap accelerant where the bill arrives after attribution becomes impossible.
Modeling Analog Devices' semiconductor operation as a stock-and-flow system, the authors show that capability decays without investment while pressure flows from defects. Under deadlines, teams rationally cut capability investment, which produces more rework and more pressure — the loop closes and the system oscillates between competence and crisis rather than converging on quality.
When a manager pivots from process improvement to firefighting, throughput rises in the short term because slack labor is liberated. The manager attributes the gain to their decisive intervention and concludes capability-building was indulgent — but the model shows they will be proven wrong only later, when attribution back to the original decision is no longer possible.
By submitting the 2001 PDF to HN, the poster surfaced a management-journal paper to a technical audience that wasn't reading CMR in 2001. The 243-point score signals the community agrees the systems-dynamics framing of capability decay is newly relevant — likely because of AI coding's impact on engineering practice.
A 25-year-old paper from MIT Sloan is sitting at 243 points on Hacker News. Nelson Repenning and John Sterman's *Nobody Ever Gets Credit for Fixing Problems That Never Happened* (California Management Review, 2001) is back in front of an audience that wasn't reading management journals in 2001 — and the timing is not coincidental.
The paper studies Analog Devices' semiconductor manufacturing operation, but the math is the point. Repenning and Sterman model the organization as a stock-and-flow system: capability is a stock that decays without investment; pressure is a flow that responds to defects. Under deadline pressure, teams cut investment in capability building; reduced capability produces more rework; more rework produces more pressure; the loop closes and the system oscillates between competence and crisis instead of converging on "do it right." They call this the capability trap, and they show that organizations get into it through entirely rational local decisions.
The knife-twist of the paper is the self-confirming attribution error. When a manager pivots from process improvement to firefighting, short-term throughput goes up — because the manager just liberated a chunk of slack labor. The manager observes the improvement, attributes it to their own decisive intervention, and concludes that the previous focus on capability building was indulgent. The model says they will be wrong, but they will be wrong *later*. By the time the bill arrives, attribution is impossible.
The reason this paper is resurfacing in 2026 is that software engineering has spent eighteen months running the experiment Repenning and Sterman warned about. AI-assisted coding is a textbook capability-trap accelerant: it pulls throughput forward and pushes the cost of comprehension, review, and architectural coherence into the future. The promise is 20-46% more code shipped. The cost — slower debugging, atrophied review skills, codebases nobody fully understands — accrues quietly on a different ledger.
Sterman, who literally wrote *Business Dynamics* (the textbook), is brutal about why smart organizations fall into this: the feedback loop that punishes investment is faster and louder than the loop that rewards it. A refactor that prevents an outage in Q3 is invisible. The engineer who's paged at 3am during the outage that *did* happen gets the postmortem mention, the bonus, and the promotion. The engineer who deleted the gnarly code path six months earlier — preventing the page entirely — gets nothing, because nothing happened.
The community reaction on the HN thread is essentially a chorus of recognition. One commenter: "This is every SRE org I've worked at." Another: "We have a name for the people who do this — 'invisible engineers' — and we lose them at exactly the rate the model predicts." The paper's framework also explains the FAANG pattern where promotion committees reward incident-response heroics: the system is selecting for firefighters because the metrics it can see *only* show firefighting.
The deeper point — and the one most engineering leaders miss — is that the trap is structural, not cultural. You cannot "value prevention" your way out of a capability trap, because the feedback that drives the loop is faster than any cultural intervention. Repenning and Sterman show in their simulations that exhortation, training programs, and even explicit prevention metrics fail when the underlying pressure-to-capability ratio is wrong. The fix has to be at the flow level: explicit, defended, non-negotiable capacity for improvement work, large enough that the loop reverses.
Three concrete moves, all of which the model predicts will actually work:
Track the counterfactual. Most incident-management tools record MTTR, MTTD, incident count. Almost none record *prevented* incidents. Add a field to your postmortem template: "What earlier work made this incident smaller or shorter than it would have been?" Tag the engineer who did that work. Surface it in promo packets. This is not vanity — it's the only way to give the prevention loop the same signal strength as the firefighting loop.
Defend capability time as a hard reservation, not a goal. Google's 20% time, the "engineering excellence Friday," the explicit refactor sprint — these work when they are scheduled and unkillable. They fail the moment a PM is allowed to cash them in for a deadline. The paper's math says any percentage of improvement time that can be borrowed against will eventually be borrowed to zero.
Audit your promotion criteria for self-confirming bias. If your last four staff-engineer promotions were people who led visible incident response, you are running the trap in HR. Find the engineers whose teams have the lowest incident rates and ask what they did. If the answer is boring, that's the signal — the absence of fire is the artifact.
The paper is 25 years old and the dynamics haven't changed because they can't change — they're consequences of how feedback works, not of any particular industry or technology. What's new in 2026 is that AI tooling has compressed the timescales: the gap between "ship fast now" and "pay for it later" used to be quarters, and is now weeks. That makes the trap easier to fall into and easier to see. Teams that ship 46% more code without building 46% more capability to maintain it are running the Repenning-Sterman model in fast-forward, and the back half of that curve is going to be visible in the 2027 incident reports. The engineers who'll come out ahead are the ones quietly doing the prevention work nobody is currently giving credit for. That has always been the trade. The paper just makes the math explicit.
I've been in those companies where "struggling departments" ended up getting all the praises and raise in budgets the following quarter because of the heroic saves they did, and raising awareness on how important they are... For stuff they totally caused on themselves.Meanwhile, my pe
There are a lot of things like this.My favorite is how elegant solutions often look simple in retrospect. So if you noodle on a problem for a while and then come up with a clever solution: once you explain it to someone they'll be like, "yeah, of course."Meanwhile the guy next to you
I had this problem at a previous job. I spent almost all of my time taking care of the behind the scenes administrative work (scheduling meetings, making sure that people had the information they needed to come into the meetings prepared, etc.). However, when performance review came around I was tol
I began migrating from network/hardware/IT work and into marketing after nearly 2 years of heavy lifting getting ready for Y2K. In the end, "nothing happened," so all that time and money was wasted, according to nearly every company I worked with. Even had one demand a full refun
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The title reminds me of an interesting ancient Chinese anecdote. And it is also a bit ironic that Toyota has gotten itself into some scandals recently (https://www.bbc.com/news/articles/c1wwj1p2wdyo).King Wen of Wei asked Bian Que:“Of you three brothers, all physicians, who