The reading room · Digna Legi
Slop-Creep: When Building Gets Cheaper Than Thinking
/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 evidence contains a strong argument and one study reference; academic support is limited, and some observations rely on personal or organisational experience.
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
AI can make building cheaper than judgment, producing slop-creep: systems and features created before anyone asks whether they should exist.
AI brief · Checked against source text
The main idea
The central claim is that AI agents have lowered the cost of building faster than they have lowered the cost of judgment. The author calls the result slop-creep: systems, features, abstractions and infrastructure built before anyone seriously asks whether they should exist. This is tolerable for disposable startup experiments, but dangerous inside companies where software sticks, gains users, and becomes maintenance obligation.
Go a little deeper
Friction used to filter ideas
The essay’s strongest mechanism is not that AI produces bad code, but that code production once imposed a practical test of seriousness. When building took weeks, weak ideas often died before they became systems. With agents, the weak idea can be shipped first and questioned later, shifting the burden from pre-build judgment to post-build cleanup and maintenance.
The human can become only a relay
The author’s “meat proxy” concept separates using AI from abdicating understanding. The problem is the person who forwards generated text or code without reading, checking, or understanding it. In that mode, the human no longer supplies judgment across levels of abstraction, especially the crucial refusal to build at all.
Startups and companies absorb slop differently
The essay avoids treating all AI-built throwaway work as equally harmful. A startup or weekend project can fail cheaply and disappear. A large company cannot shed internal software as easily: once another worker depends on it, even a tiny tool becomes something someone must own, update, explain, and rescue when context changes.
Local automation can become shadow infrastructure
The finance example shows how seemingly helpful automation can drift outside the organization’s normal engineering path. Scripts and pipelines created by non-technical users may live outside version control, depend on knowledge the creator barely understands, and pass to successors as unexplained obligations. The productivity gain is real, but so is the accumulation of fragile ownership.
A case from the article
Waddle’s tattoo-artist customer relationship tool
The author’s company built Waddle, a customer relationship management tool for tattoo artists, but the failure was not technical. Tattoo artists already used Instagram for outreach, a shared Google calendar for clients, and cash or E-Transfers for payment. The case illustrates slop-creep’s product version: it is now easier to build a polished vertical tool than to verify that the target market wants such a tool.
How the case is made
The case is made through workplace observation, a cited knowledge-worker study, the author’s failed startup experience, and a concrete finance-workflow scenario.
Where the idea has limits
The argument allows that cheap failure is useful for startups and side projects; its warning is mainly about persistent organizational systems, not every fast prototype.
A question to take away · from Digna Legi
Where has cheap implementation in your organization removed useful friction rather than merely reducing waste?
What the original adds
The original gives more texture on “meat proxies,” the author’s Waddle experience, and the finance-team accumulation pattern that turns local automation into inherited operational burden.
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.