AI & ML
Slop-Creep: When Building Gets Cheaper Than Thinking
Brandon Sovran Dev.to (EN Zone)
2 views
The agents are slowly building systems we won’t be able to maintain.
“That’s a great idea!”, “We should go with X instead of Y”, “Z is what we should do here”.
I’ve noticed everyone around me, including myself, delegating more and more thinking over to the machines [1]. The cost of mistakes used to be massive. We used to sit down and think hard about real problems and build solutions to solve them. Now that software has become absurdly cheap to produce, we can generate solutions faster than we can find problems for them… but should we?
Slop-creep is the gradual accumulation of systems, abstractions, features, and infrastructure that never needed to exist, made possible because agents have made them cheap enough to build before anyone seriously asks why.
I see engineers just going to Claude and putting in a problem to the “table-top fortune-telling machine” and getting back the first solution. No thinking, no experiments, just straight to the machine and trusting whatever it says as the truth. There’s already some evidence that the more we trust these machines, the less thinking we do ourselves. A Microsoft Research and Carnegie Mellon study of 319 knowledge workers, covering 936 real-world uses of generative AI, found that higher confidence in the AI was associated with less critical-thinking effort [2]. Which seems fairly obvious when I look around at how we’re using these things at work.
Enter the meat proxies
A “meat proxy” is a person who copies and forwards AI-generated text or code without reading, checking, or understanding it, coined by engineer Niklas Gruhn [3]. The agent acts as a black box and spits back a solution to whatever problems you have. Humans are just the interface between agents and other people at the company. With a meat proxy present or not, agents simply aren’t smart enough yet to say “No. Don’t build that” at multiple levels of abstraction. So whether you delegate all your tasks to an agent fleet or sit there clicking enter in your terminal mindlessly, you are slowly contributing to the slop-creep.
Why do we care? Coding is cheap now!
This is where I think agents have changed something more fundamental than how quickly we can write code. Implementation used to have enough friction that bad ideas often died before someone spent three weeks building them. Now you can just build the bad idea. Most of the time without even reading the underlying code or system. Systems are slowly becoming more complex unnecessarily. We used to have an incentive to make things smaller and more maintainable. Slop isn’t new. The rate at which we can produce it is. It’s true that the bar for accepting sloppy code has gone up since an army of agents can always fix it, but where is that bar? The new bar for slop is somewhere above us, but I believe we are running wild without care for the slop-creep wave that is incoming.
I thought AI was good for ideation?
It’s true we can test ideas faster. But these “experiments” seem to keep popping up one after another. I see more slop everywhere. My Instagram feed is full of CRMs for increasingly specific industries, many of them looking like the same generic Claude slop with a slightly different coat of paint.
I’ve thought about this problem for a while because of my own company, Waddle. With Waddle we failed, but not due to any technical challenges, it was due to poor product-market fit. To shed a bit more light on this, we had built a CRM for tattoo artists. The problem wasn’t the engineering, even before AI we had that perfected. The issue was that no tattoo artists actually needed a CRM. They were more than happy using Instagram for outreach and a shared Google Calendar for their clients. Cash and E-Transfers 4 were even preferred! Who needs credit card connections when they don’t even want to accept them as payment in the first place? Not to say there isn’t a market for our CRM somewhere, but the space wasn’t exactly empty, and tattoo-specific CRMs didn’t exist for a reason, the market was extremely hard to crack.
A few years ago there were natural limits on how many of these products could exist because building software actually took time. You had to care enough about the problem to spend months making the thing. Now we can reverse the process: build the CRM first, pick an industry, then go searching for the problem it supposedly solves.
For startups, I actually think this is mostly fine. Build faster. Test things. Find out nobody wants your AI-powered CRM for alpaca farmers and kill it. The ability to fail cheaply is one of the best things agents have given us.
So then the problem isn’t with startups creating slop? Nope. Startups and your Sunday projects die (along with my own). The problem is where tiny pieces of slop grow… and become sticky.
Corporate slop
What worries me is what happens when we start behaving like sloppy startups inside large companies.
A startup can die. A weekend project can get deleted. Software inside a large organization has a habit of sticking around. You build another internal service because Claude says that’s the clean architecture. Someone introduces another abstraction. Another database. Another agent. Another framework. Someone decides you need a migration because the existing system doesn’t fit the architecture Claude suggested. Each decision is cheap enough in isolation that nobody has much incentive to say no.
Because implementation is quickly becoming the easy part. Thinking about the big picture, asking tough questions and running experiments that actually challenge your assumptions still requires us to do the work.
The “creep” in slop-creep
When you build something in the corporate world it tends to become sticky. Once another worker relies on what you have built you are on the hook to maintain it. This used to happen at the team level, with shared systems built to solve problems for lots of people. Now, more and more individuals can build their own solutions for much smaller, more specific problems.
This does deliver immediate business value. This does unblock teams and let them continue driving solutions forward. But what it starts doing is lowering how many people you are solving a problem for, and how many solutions each person in the company owns.
Take a simple example. Say the finance team needs to generate a quarterly report. Previously, they might coordinate with data engineers to build the necessary pipelines, then use some centralized platform to download the data and manually validate it across three different documents.
It’s a fairly slow process, so we start using AI to optimize it. First, the validation. The non-technical users get agents to help them build scripts that speed up the manual work. Great. The humans can now do more, so they take more on and continue automating pieces of their workflow. Productivity per employee rises sharply!
Then a new workflow for another part of the business gets introduced.
Instead of going through the old, slow process of working with the data team, building a pipeline and getting everything into the centralized platform, the finance team can just build it themselves. So they do.
Now the pipeline that validates three new reports lives in some system, most likely outside of Git, tied to knowledge that the owner of the pipeline barely understands themselves. The machines own the implementation; the person who created it loosely maintains it. It works, though, so everyone keeps moving.
Then that finance employee leaves.
Their successor inherits the reports, the scripts, the pipeline and all the extra work their predecessor was able to take on because of them. Except they don’t inherit the understanding of how any of it works. The system needs updates as the business shifts, they hand it off to agents to try and accommodate, it diverges more from the golden path, it becomes less about finance and more about engineering.
Source: Image by the author.
These solutions between people and agents start building out dependencies. We’re on the fast track to turning every young business into a legacy tech giant, full of tangled services and critical domain context that disappears when the person who built them leaves.
What can we do about it?
Slop-creep isn’t inevitable! Leaders simply need to act now and stop rewarding delivery for the sake of it, and start rewarding long-term visions that deliver value not just today, but tomorrow. People within corporations have always fought for more scope and impact. Hacking some grand project together using AI-generated docs and architecture, setting AI-generated measures of success and value added, shipping a system the AI wanted, not humans, this is what scares me.
So stop, close all your agents and really take a while to think before acting. Write the design doc yourself, come up with solutions yourself, ask other humans for feedback (and make sure they actually read it and don’t act as meat proxies!). Once you do all that you can ask the agents for feedback to tune it, but remember that there is still a reason you have a job and the agents can’t take over just yet: we are paid to think.
So think.
Originally published on Awaiting Input on September 6, 2026.
References
[1] The Twilight Zone — “Nick of Time”
[2] Microsoft Research — “The Impact of Generative AI on Critical Thinking”
[3] Niklas Gruhn — “Meat Proxies”
[4] Interac — Send and Receive Money With Interac e-Transfer
Read original: https://dev.to/awaiting_input/slop-creep-when-building-gets-cheaper-than-thinking-29fa
← Previous
The LoRA won on its own moods, and the held-out tradeoff stayed visible
Next →
Engineering the WingZone POS: State Management for Group Ordering & Dual Receipts in Kotlin
Related
Ich habe mein eigenes Repo angegriffen — mein PR-Bot hat den Angriff selbst blockiert
AI & ML
3
DEV Community
A beginner's guide to the Qwen3.8-Flash-Next model by Qwen on Huggingface
AI & ML
1
DEV Community
Translating 300-Page Books with Claude: Taming Token Limits and Context Windows
AI & ML
2
DEV Community
Which to Use: MCP, Function Calling, or Plugins
AI & ML
0
Dev.to (EN Zone)
Comments0
No comments yet — be the first