Stackslop: when AI makes overengineering free.

A friend recently walked us through a weekend project: an event-sourced inventory system with twelve microservices, a Kafka backbone, a vector database for semantic stock search, a custom internal DSL for pricing rules, and a Kubernetes cluster humming underneath it all.

It serves forty users. It replaced a spreadsheet.

The spreadsheet, to be fair, never went down.

Nothing about the new system is bad. The code is clean. There are tests. The architecture diagram is genuinely beautiful: the kind you'd happily put in a conference talk, which, not coincidentally, is where it ended up. And that's exactly why this failure mode needs its own name. It isn't sloppy work. It's immaculate work that nobody needed.

We call it stackslop.

Stackslop /ˈstak-släp/, noun. Impressive-looking, AI-accelerated over-architecture: systems built because they could be built, not because anyone needed them built. Characterized by nonstandard structure, premature scale, and a README more excited about the stack than the outcome.

You already know its relatives. AI slop fills your feed. Workslop fills your inbox. Stackslop fills your infrastructure. And to be clear about what it isn't: stackslop is not vibe coding. Vibe coding is careless writing. Stackslop is careful building of the wrong thing: reviewed, tested, documented, lovingly diagrammed. Sloppy code fails review. Stackslop passes with compliments.

Overengineering itself is old. We've had names for the milder strains: résumé-driven development, architecture astronauts, the eternal 'you are not Google' talk. What's new is the price.

For all of software history, overengineering had a natural predator: effort. You could want the microservice mesh, but you'd have to type it, debug it, and explain why the simple version wasn't done yet. Most grand designs died not because someone argued them down, but because Friday arrived first.

AI removed the predator. The elaborate version and the simple version now take roughly the same time to produce. The question 'is this worth the effort?' has stopped being asked, because the honest answer is 'the effort is trivial.' That question used to do the quiet work of an architecture review.

But the demo never shows the asymmetry: AI collapsed the cost of building, not the cost of owning. Every service still needs monitoring. Every novel pattern still needs the next person to learn it. Every dependency still has upgrades and 2 a.m. pages. We now mint complexity at near-zero cost and pay it back at full price, with interest, for years.

Economists have a word for what happens when something important suddenly looks free: malinvestment. Stackslop is malinvested complexity.

So how do you spot it? It hides well, because it's well-made. Look for these tells.

01. The architecture explains the tools, not the problem. If the diagram mentions Kafka before it mentions the customer, look closer.

02. Scale provisioning with no date attached. 'We might need it later': can anyone name the quarter in which later arrives?

03. Demo-strong, handover-weak. Magnificent in the walkthrough; nobody but the author can run it. The bus factor is exactly one, and the bus is a new job offer.

04. No one can finish the sentence: 'this exists so that ___ can ___ without ___.' If the blanks don't fill in one try, the system is the point, and that's the problem.

And one question that catches almost everything: would you have built it this way if no one would ever see the diagram?

The antidote is to make value the flex. We feel the stackslop temptation constantly; our tools make everything feel buildable by Tuesday. A few habits keep us honest.

01. Start from the value sentence. Every build begins: this exists so that ___ can ___ without ___. No filled blanks, no opened editor. The sentence becomes the first line of the README, above the stack, always.

02. Default to boring; budget the novelty. You get a couple of innovation tokens per project. Spend them where novelty pays the business, and pick the dullest proven option everywhere else. AI didn't add tokens to your budget. It just made it painless to blow them all at once.

03. Aim the AI at simplicity. The same model that scaffolds your microservice mesh is good at the opposite prompt: 'what is the most boring design that meets this requirement? What would you delete?' Make it argue for the four-file version before you let it build the forty-file one.

The slop family keeps climbing the stack: first feeds, then inboxes, now infrastructure. The pattern is the same: generation got cheap, evaluation didn't, and the burden moved downstream to whoever has to maintain the output. The fix is also the same: put the value question back in front of the generation step.

So coin it, spot it, say it in review: 'this is heading toward stackslop.' Not as an insult, but the way you'd say 'this function is getting long.' A code smell, scaled up. The engineers we admire most in 2026 ship systems that look almost disappointing, run unattended, and pay an invoice you can point to.

Build like nobody's watching the diagram.