The backend behind the new ideas I am working on is full of raw AI output. Inconsistent shapes, careless names, code I would never ship as is. I am not being lazy. I am choosing not to wrangle the model, because in R&D I would rather let it draw outside the lines and learn faster.
That choice lets me ship something usable to testers without burning weeks on endpoints I am going to throw away. The core experience gets my attention. The plumbing gets whatever the model handed me.
This is not an argument for lower standards. It is an argument for putting them in the right place.
What I Mean by AI Slop
Slop is a loaded word, so let me narrow it. I do not mean sloppy engineering. I mean raw model output with a short shelf life. Code, copy, schemas, glue, scripts. Things you let the AI generate to answer a question, not to last.
I lean into it not for typing speed, but because it lets me change my mind cheaply .
When I rename a resource or rethink a payload, I do not hand-update every consumer. I regenerate them. The cost of change is tokens. Compared to a world where every API decision felt load-bearing because cleanup was painful, the velocity is in another category.
That is the real shift. Not “AI writes my code.” More like “AI lowered the cost of being wrong about a shape.”
So the question is not whether slop is good or bad. It is where slop belongs.
Slop Belongs Where Learning Beats Polish
There is a zone where slop is the right answer. It looks like this:
- The cost of change is low.
- The blast radius is small.
- The thing is probably temporary.
- Almost nobody depends on it yet.
- You are still figuring out what you are even building.
Inside that zone, polish is a tax . You are paying for the durability of an idea you have not proven. Every hour spent making a prototype feel finished is an hour not spent learning whether anyone wants the thing.
Slop is great for prototype workflows built to test user behavior. For internal admin tools three people will ever touch. For backfill scripts that run once. For mock services and eval harnesses. For the rough draft of a feature you will rewrite the moment you understand it.
The point is not cheapness. The point is faster feedback. Slop buys you more shots on goal in the same week, and most of the value of early product work is in the shots, not the polish on any one of them.
The moment other people start relying on it, the math changes.
The Boundary Is Trust
This is the part to take seriously.
Slop is great where failure is annoying. Slop is dangerous where failure is trust-breaking. The boundary is not technical. The boundary is trust.
There are zones where I will not ship slop, no matter how convenient:
- Auth, sessions, permissions.
- Billing and anything that touches money.
- Data deletion, retention, and backups.
- Schema migrations against real customer data.
- Public APIs other people will integrate against.
Public APIs deserve a special mention. A rough internal API the model sketched out is your problem. A rough public API becomes everyone else’s problem the moment a customer integrates, and then it is your permanent problem. Bad shapes harden into legacy faster than anything else I have watched ship.
The discipline is being honest about which side of the line you are on. “Temporary” auth code has a way of becoming production auth code. Stopgap billing logic runs for two years. When AI slop quietly drifts across the trust boundary, you no longer have a prototype. You have a liability with a good origin story.
Clean It Up When the Shape Stops Moving
Slop is only useful if it stays temporary. The other half of the skill is knowing when to rebuild .
The triggers are not subtle once you look for them. Real users depend on it. Support tickets cluster around it. The same surface survives three product changes. Another engineer has to maintain it. Revenue flows through it.
When that happens, you rewrite. The instinct is to read it as failure. The truth is the opposite. The first version did its job: it told you which fields matter and which abstractions were noise pretending to be structure. You could not have written the real version on day one.
The day one of these ideas proves itself, the AI-slop backend gets rebuilt with a real sense of the API I need. The first pass was the research.
Slop is a tool, not a standard.The Craft Is Knowing the Address
The interesting question about AI in software was never “is the code good.” It is where you spend craftsmanship and where you spend speed.
Spend craftsmanship where trust lives, where change is expensive, and where other people depend on your decisions. Spend speed everywhere else, especially where you are still figuring out what you are building. This is the operational side of When Anyone Can Build, Judgment Wins. As building gets cheaper, the judgment of where to spend care matters more, not less.
You do not need to be ashamed of using AI slop in the right place. You need to know its address, and its expiration date.