What is a slop grenade?

What is a slop grenade? It’s when someone uses AI to create a big chunk of work that looks polished and drops it into the workflows of other people, who then have to deal with it. Creating that information is cheap now and judging it isn’t, and that gap creates a perverse incentive inside organizations. Tobi Lütke made the term popular on The Knowledge Project. I got asked about it in an interview, from my side as a fractional AI CTO, and my answer was that it depends on the setting. A startup and a corporation produce very different grenades.

What is a slop grenade? The short answer

How does a slop grenade show up in a startup?

Take a startup where a group of one or two developers worked on a feature or a service alone. After ten months, a lot of it is familiar to the developer who built it and very hard for anyone else to onboard into. Bringing someone new in can be a complete disaster, because there are blocks of information that are either irrelevant or outdated. There might be deployment instructions that are already obsolete and describe a previous setup. There might be artifacts, scratches or preproduction versions of some pieces of the codebase, that are hard to remove because you don’t understand whether they’re still relevant.

Even if you do understand it, getting rid of it sometimes requires refactoring the codebase. And a refactor can be biased by the current state of the service, which is the part I find most interesting.

Why does an AI refactor inherit the original design?

Say you want to refactor a module because it has some complexity or something else you don’t like. You write the new version, and what you find out is that your result is still grounded in the first implementation. If you’re using an LLM or an agent to refactor the codebase, I would make this claim: your baseline implementation, which could be completely off or full of bad patterns, can shift or drift the result of the refactor. The output still depends on what was there before. It’s the same anchoring problem I described in legacy code is not the spec.

The interviewer put it as cleaning up the mess while still carrying over the original flawed assumptions. That’s right. Surface-level issues can be fixed. Deep-layer defects get shipped along with the AI refactor, they’re hard to spot immediately, and over a period of time they can drift your service in the wrong direction. You only catch them with very deep due diligence, which takes a lot more time than generating short workarounds and saying “let’s patch the code so it passes the build.”

Whose job is it to catch it, the AI’s or the new developer’s?

It’s kind of both. Sometimes a new developer can spot a bad decision while onboarding into the codebase and fix it right away. Some patterns are obvious: hardcoded credentials, missing security checks, a lack of validation, no database transactions, missing indexes, a bad database schema. But if those practices compounded over time, it’s hard to address all of them. You can address the surface-level gaps, the code quality layer. The deeper design decisions are harder to see and take a lot more work to change.

What’s the difference between a slop grenade and a slop ticking bomb?

The interviewer asked where the line is between acceptable tech debt and a genuine slop grenade, for a startup with ten months of AI-accelerated code. I’d separate the terms.

A slop grenade is a bowl of nonsense, bad decisions and gaps, or artifacts with zero added value. Documentation for a database migration from twelve months ago, for a schema that isn’t relevant anymore. We don’t need it, but it’s still in the codebase. It takes a lot of time for agents to process, and a lot of time for humans to understand why there’s so much documentation about something that doesn’t matter.

A slop ticking bomb is different. It adds a small defect, usually spread across multiple abstractions and modules. It’s an overly complicated implementation, or it uses a framework someone could call slopish. Since it was already committed and implemented, it’s much harder to remove, because the system has been tested by users or under real workloads. When you spot that decision, removing it means validating that everything works exactly the same without it in production and that you haven’t broken anything else.

It can be as simple as a UI. If you spot a sloppish icon set in your frontend and replace it, you can call that a quick win. It still requires testing across different browsers and screens to make sure the new icons don’t break anything. The same goes for the backend: you can replace a framework that’s clearly slopish, and it still takes a lot of effort to validate in production. You can claim this work should be cheap after AI, since AI does it. It still takes a lot of cognitive and mental effort to make sure you’ve reviewed everything, that it works, and that the previous bad decision hasn’t spread or done collateral damage elsewhere in the codebase.

How does a slop grenade show up in a corporate team?

That’s a much messier situation. It depends on the organization’s values and engineering culture. I’ve seen different approaches to management that optimize different metrics. In some cases it’s the number of PRs you merge in a week, or PR turnaround time. They expect you to make small pull requests and optimize for visibility of the work. You can also game that. If you use an agent to generate many small pull requests to fit the metric, or a certain number of PRs per day, or a certain amount of documentation, that obviously creates slop grenades.

Documentation is a big one. You end up documenting systems that don’t need documentation, or some layer of management requires you to comment your codebase excessively. I’ve seen people throw slop grenades as excessive documentation for almost obvious code. My approach is that code should need very little documentation, especially for non-trivial stuff it should explain why and not how. One sentence on why this code was added, or why this specific method exists, is much more useful than redescribing the implementation. You can read the code, jump to the reference and see exactly what it does, unless it’s a very exotic algorithm you can’t find on Google. Verbose documentation that nobody needs pollutes the context window for search and for agents.

Then there are requirements like “we’re adding this, so it needs 100% coverage.” 100% coverage with new tests is impractical sometimes, and it can drag in a legacy database. Say you add a new feature that’s one endpoint. On the surface it looks like a real task, but the endpoint is a simple database query over tables and columns that already exist. The developer implements ten different tests to validate a lot of stuff, which adds an extra 20 seconds of unit test duration for one reason or another: fixture setup, a non-optimal test, or something else, and those tests are also generated by AI.

Now imagine shipping features like that on a weekly basis. After a quarter or six months, you end up with unit tests that take 30 minutes to execute. That’s a lot of CI time, a lot of developer frustration, and it’s hard to refactor.

Then a fresh developer comes in and wants to add a new endpoint, and the suite takes 30 minutes to pass. Yes, you can run a selected group of tests that takes one minute for the feature you just added. You still have to verify that the entire backend path, with migrations and everything else, passes. If you have a complex CI/CD on top, that’s a lot of frustration. Then come the pull request reviews. You pass the local tests, push to CI, wait the full run, and get a comment saying “I don’t like the word you used in this comment, use ‘structure’ instead of ‘data structure’.” Some ridiculous nitpick. If you address nitpicks in separate commits from several different reviewers, you end up wasting hours of your time and focus just to fix silly things. Spread that across a team of seven developers and they all waste that time.

Slowly you get a ticking bomb and a pile of slop grenades made of things that shouldn’t exist. A fresh developer who wants to fix it doesn’t know which tests are relevant, which aren’t, and which can easily be dropped. It takes much more effort to work out whether we can simplify this, remove it and speed it up.

So as a fractional CTO I would avoid these metrics and ask whether the system is simple. Any domain problem can be complex. We take that for granted and it’s not a subject of debate. We can still implement a simple solution for a complex problem, and we can build fast software instead of slow software. Simple and fast usually means we took the right architectural and technical decisions. If something doesn’t feel simple or fast, there’s a defect at the decision layer, the technology layer or the execution layer, or it’s overengineered and not properly managed.

The interviewer pushed back on three points, and they’re fair. A system can be simple and fast because it ignores important requirements, so the better question might be whether it’s appropriately complex. 100% coverage isn’t always the villain, because sometimes those extra tests are the only thing preventing a production bug, and the problem is measuring the wrong thing. And accumulation is the real mechanism: one test doesn’t kill you, a thousand small decisions can, and AI makes each of those decisions cheaper and faster.

Is the root cause of slop the incentives?

It’s a combination. The corporate structure creates the wrong incentives: maximize AI usage, maximize lines of code shipped to production, maximize the number of unit tests or reach 100% coverage, follow a playbook. There’s no one-size-fits-all fix. What I would definitely do is create a quality gate for complexity, for the artifacts a developer produces.

Some engineers, engineering managers and QA managers try a simple strategy: measure the number of bugs or incidents observed in production per release, as the quality of that release. Frankly, that’s a broad metric. It depends on whether you report every issue you observe and how you sort them by severity. A bug reported by an annoyed customer and a transient database timeout reported automatically by Sentry are completely different things, and their volume, intensity and impact are completely different too.

The right thing to track is whether a feature leads to the customer outcomes we planned for it, and whether the developer’s change caused any impact on the production environment. You want to minimize that exposure. The number of issues is a secondary metric. I would watch on-call and production disruption. If we had an incident in production caused by a certain feature, or on-call pushback from shipping it, that clearly says something was missing when we implemented it.

What I’d avoid is reducing the software developer to simple metrics: lines of code shipped, number of unit tests, hours worked, how many diagrams the technical spec has. Ask whether the software satisfies customers, and whether it’s simple, fast and maintainable. Those are the quality metrics, and they should come from your software and your organization.

The interviewer added two nuances. Bug counts can be useful as signals instead of a raw number, and more bugs sometimes means better visibility or a healthier reporting culture. And customer satisfaction and maintainability can pull in opposite directions: a customer might love a quick fix that the engineering team can barely support.

How do you measure quality instead of activity?

I would measure maintainability like this. If you have a complete feature to deliver, how many times did you have to rework it, fix it or change it, outside of the customer changing the requirements? Some areas have a lot of drifting experiments and product feedback where you need to adjust and collaborate. But for system parts like authentication or permissions, which you can settle in concrete requirements, count how many times you had to rework, rewrite, re-architect or change it. That’s a usable proxy for the quality of the solution.

The interviewer pushed on two spots: no rework doesn’t always mean good design, it might mean nobody touched it, and five small fixes aren’t the same as one huge one. I agree a feature nobody uses and nobody reworks isn’t a success. My claim is about live features. If a feature is actively used, you shipped it once and never had to revisit it, and you never had a severe correction from production, that’s perfect execution.

Does AI make slop better or worse?

It can make it better for experienced developers and worse for inexperienced ones, since they can essentially plant slop grenades in the process without knowing it. And it usually takes time to detect. If you’re experienced at filtering slop, you can say right away that something isn’t relevant and shouldn’t pass code review. Sometimes you can only see it in hindsight: from feedback, from how new developers onboard into your project and get frustrated, from the number of production incidents, or from the number of times you had to come back and revalidate parameters in a module an AI wrote. That’s what makes it dangerous. There’s no immediate feedback loop telling you how to handle these scenarios, which is why verifying AI code is the bottleneck now.

What do you do first on a team that feels brittle and slow?

In corporate settings, some slowdown is normal. A legacy service is a set of decisions somebody else made in a certain context. You can’t expect changing it to be as fast as building something new from scratch, where you have the full context, don’t need to onboard into anything and can implement it very fast. On a legacy codebase, shipping one feature per day per developer, or even one per week per developer, can be really good velocity. Changing an existing system is always harder than working on something new that you own end to end.

The interviewer suggested three things to look at, and I’d take them. Time to understand: if a developer spends days figuring out where to make a simple change, that’s a smell. The ratio of output to validation: if AI writes something in 20 minutes and the developer spends two days testing and second-guessing it, the speed is an illusion. And patterns: if the same modules keep tripping up several good engineers, that points to AI artifacts more than individual performance.

For due diligence on a team that claims AI doubled their productivity while the developers say in private that the code is harder to live with, I’d collect the feedback first. Then I’d simplify and check whether you can rewrite the system from scratch, with a fresh approach and without the silo of bad decisions taken before. That used to be a risky and expensive call. Now it’s fairly normal practice to collect the data, recalibrate your approach and reimplement from scratch, since writing it usually goes fast. The existing test cases or integration tests become your harness for the new release, and they can raise the quality of the new decisions.

Numbers to sanity-check against your own team

These are estimates to validate on your own codebase. Nobody measured them yet. They came out of the same interview as hypotheses, and they’re the set I’d start checking.

Which frameworks help defuse a slop grenade?

I think all of these, in combination and in the right ratio, are practical in a corporate setting.

The fourth is a rewrite-versus-refactor decision tree. If you have specs, tests and stable boundaries, compare the cost of refactoring against a clean reimplementation plus migration. That threshold keeps moving toward the rewrite as writing code gets cheaper.

One safeguard: if every checklist becomes its own slop, we lose the point. So these sit inside one loop focused on controlling complexity, instead of maximizing speed. Spot the friction. Diagnose whether it’s complexity or a context problem. Decide whether to refactor, rewrite or remove. Then check that it actually reduced the effort without hurting production or customer outcomes. Keep it proportional to the size of the problem.

So, what is a slop grenade?

It’s AI-generated work that looks finished and costs other people more to judge than it cost you to make. In a startup it’s the outdated docs, scratch code and inherited design that the next developer has to untangle. In a corporate team it’s the extra PRs, comments and tests that the metrics asked for. It grows when you reward visible activity. Measure whether live features stay unreworked and production stays quiet instead, and keep the system simple and fast. If you’re already sitting on ten months of it, that’s the kind of cleanup a fractional AI CTO is for, and should you hire one covers how to tell.