The reading room · Digna Legi
The broken windows theory of coding agents
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The article is grounded mainly in one team's experience and self-reported workflow numbers, not an independent cross-company study.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Coding agents can compress codebase decay from years into days by replicating weak patterns before review habits catch up.
AI brief · Checked against source text
The main idea
The central claim is not that AI-written code is uniquely bad, but that agent speed changes the failure mode: weak patterns replicate before review habits can catch up. The author argues that code review used to force engineers to understand, discuss, and align on implementation standards; once that forcing function disappeared, human comprehension and pattern hygiene degraded even while output rose sharply.
Some background helpful. Basic familiarity with pull requests, code reviews, and AI coding agents.
Go a little deeper
Review was a comprehension forcing function
The useful distinction is between looking at generated code and being forced to understand it. Human review made authors able to answer questions, defend choices, and notice whether agent output fit local standards. When review became optional, the author says the team still inspected code, but the depth of understanding fell because nothing required sustained attention or explanation.
Speed breaks old quality processes
The author’s numbers matter less as universal benchmarks than as a mechanism: process cost that was tolerable at low throughput becomes a bottleneck when generated work multiplies. A team that once reviewed every change drifted toward almost none because minutes-to-production became addictive and agent review itself started feeling too slow.
Disposable work can still create durable risk
The article separates validation work from infrastructure: disposable onboarding, UI, and current-product features got lighter review, while infrastructure stayed more carefully examined. The stronger supported conclusion is a risk, not a proven causal chain: if lightly reviewed code remains visible to agents, it can become an available pattern for later generation, especially where better examples are missing.
Plan review may move scrutiny upstream
The author does not claim manual code review can simply continue unchanged. The tentative alternative is to review more plans before agents produce large changes, while still sampling completed pull requests. That shifts human attention from line-by-line inspection toward design direction, but the author admits the process is not yet worked out.
A case from the article
The Lovable hackathon collapse
In the hackathon example, the team initially completed most of a referral-system prototype quickly, including scraping, scoring, Slack integration, and an admin area. On the final day, small improvements triggered repeated bugs, slowness, and stress. The example illustrates the article’s core mechanism: fast early progress can mask fragile accumulated patterns until every fix creates another failure.
How the case is made
The case is made through team observation, internal PR and review metrics, a quoted engineer’s cleanup note, and a hackathon analogy.
Where the idea has limits
The author’s proposed remedies are explicitly unsettled: optional review on a small share of pull requests and heavier plan review are presented as current bets, not solved practice.
A question to take away · from Digna Legi
Which parts of your codebase are agents treating as examples, even though no human ever meant them to become standards?
What the original adds
The source adds a staged account of review collapse, internal claims about pull-request volume rising from 4 to 28 per day, review coverage dropping near zero, and output increasing about eightfold.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.