Slop Ships. That's the Problem.

Greptile called it "AI slopware": AI-generated code that is technically functional but structurally incoherent, shipped into production because it passed tests and nobody had time to look closer. The term is new. The pattern isn't.

The problem isn't that AI generates bad code. It generates code that works in the test environment, passes the reviewer who is moving too fast, and ships. Six months later, the accumulation of locally correct, globally incoherent decisions has produced a codebase where bugs are untraceable and every change introduces unexpected side effects.

This is not hypothetical. This is the collapse pattern I start from whenever I design anything.

The Distinction That Matters

AI-generated code is working code. It is not safe code. These are different properties, and conflating them is how you end up with a production codebase that passes CI and cannot be debugged.

Working code satisfies the test cases that exist. Safe code is correct for the cases you haven't thought of yet, fails loudly when it's wrong, and has failure modes that are predictable enough to fix. The gap between working and safe is where most production incidents live.

I have a specific rule: write the skeleton and interfaces manually, let AI fill the interior of understood patterns. The reason is structural, not preferential. The skeleton is the contract. It defines what the code is supposed to do, how the pieces relate, where the abstraction boundaries sit. If I let AI write the skeleton, I inherit its model of the problem — which is often plausible and wrong for my specific context.

The interior — the implementation of a well-defined function, the body of a well-scoped class — can be generated. The contract was already established. If the generated code is wrong, the contract fails loudly and the location of the failure is clear.

What ships as slop is mostly codebases where the contracts were never established. Where the architecture was also generated, or accumulated without design. AI is very fast at accumulating code. It's equally fast at accumulating technical debt that nobody can debug later, because there was no explicit model that the code was supposed to satisfy.

The Enterprise Backlash

SiliconAngle reported in April 2026 that enterprises are pushing back against rapid AI coding agent adoption — demanding governance frameworks and control structures before scaling. This is not institutional caution for its own sake. It's the delayed recognition that "it works" and "it's maintainable" are different properties, and the market has been optimizing aggressively for the first one.

The backlash will take the form of review mandates, architectural audits, and tooling that tracks the provenance of generated code. None of that fixes the underlying problem. The problem is that teams have been generating code without first establishing what the code is supposed to do.

Governance can slow the slop. It can't retroactively create the architecture that should have been designed before the tool was run.

What to Actually Do

Start every AI-assisted implementation session by writing the interface. The function signature, the type contracts, the expected behavior — in code, not in a prompt. Then generate the implementation against that contract.

This sounds slow. It is slower than typing a description into a chat interface and running the output. It is much faster than debugging a codebase where the implicit contracts were never made explicit, because that debugging session has no end point.

The teams that will have maintainable codebases in 2027 are not the ones that didn't use AI. They're the ones that treated AI as a capable tool for implementation and a useless tool for design. Design first, generate second, review against the design.

Everything else produces slop eventually. The only question is how long it takes to become visible.

The Signal in the Backlash

The enterprise backlash is actually a useful correction signal. When large organizations — the ones with the most to lose from unmaintainable codebases at scale — start demanding governance frameworks before expanding AI adoption, that's not risk-aversion. That's organizations that have seen the output up close and decided the tradeoff needs to be managed more carefully.

The governance frameworks they're building are mostly wrong. Review mandates don't fix codebases that lacked architecture. Provenance tracking doesn't retroactively create contracts. But the underlying concern is correct, and the small companies and solo builders who internalize it before it becomes a production incident will be in a better position.

The way to internalize it is simple and unglamorous: before using any AI coding tool on a non-trivial problem, write a document that describes what the code is supposed to do, how it should fail, and what the system looks like when this piece is added to it. Not a long document — sometimes a few sentences per function. The discipline of writing it forces the clarity that prevents the slop. The AI fills in the implementation. The document is the contract. The review is against the contract.

That process is slower than generating immediately. It produces codebases that remain debuggable two years later. The tradeoff is obvious. Most teams are still not making it.