How I Avoid Throwing Slop Grenades
Tobi Lütke, Shopify's CEO, was on The Knowledge Project recently talking about "slop grenades":
We call those 'slop grenades' that people toss at each other. That's definitely a bad thing.
He's talking about low-effort AI output that nobody has read. For example, an engineer prompts the AI to implement a feature, then opens a pull request to toss it over the fence for a colleague to review.
Sure, that sucks. But I think a slop grenade is a symptom, the same way a code smell is. A code smell points at a problem somewhere in the code. A slop grenade points at a problem somewhere in the process. A "process smell", I guess.
If an engineering team keeps producing slop grenades, something in their Software Development Lifecycle is letting them through. Or, at least, not stopping them.
In the same interview, Lütke puts the blame on the engineer:
you're just letting AI do the work for you.
I see things a little differently.
I could have thrown a few grenades myself. I recently spent a long time on a big migration, and over that time I generated hundreds of pull requests with AI. One day I created around 60. In theory, every one of them could have been a grenade.
But I put a lot of work into making sure they weren't. Most of that work happened before I generated any code. I spoke to each team first and talked about the changes I was making to the systems they owned. I used their feedback to shape the guardrails in the workflow that produced the pull requests. So every pull request they received already had their input baked in.
Then I let AI do its thing.
I didn't expect it to be perfect, though. It created draft pull requests, and I treated them as a starting point that still needed shaped. And, in the beginning, a lot of what I got was slop.
So I worked in small batches. I went through every single pull request myself, looking at what went well and what didn't, and fixing what didn't. Then I used what I learned to improve the workflow, so the next run wouldn't hit the same problem.
Sometimes I added unit tests. Other times I tightened a feedback loop or rewrote the instructions. Early on, I had to adjust a lot of pull requests. I only assigned a pull request to a team once I was happy with it. That means some never got past me.
If anything, I was the one flooding myself with slop grenades. I was the de-slopper. I never saw that as a bad thing, because I treated the slop as feedback. That only worked because the slop landed on me: the guy who could change the workflow.
Volume was the other problem. I could generate 60 pull requests in a day, but no team was able to review that much. So I spaced them out, and only sent a team what it could keep up with. I also took a little more time to group related changes, so a team got them together where possible.
Going to the teams first was deliberate. I expected it to prime each team for the changes, so we'd aligned our thinking before any code arrived. Looking back, I think I knew by intuition that this could give me some of the benefits of pairing. And it worked. It was only on reflection that I understood why.
Pairing gets a review for free. The second person watches the first write the change, so by the time it's done, they already understand it and can merge it. It takes two people to make one change, and the reason it works is the shared understanding.
That's the part of pairing I needed. AI was writing the code, so nobody needed to share a keyboard. And because I'd pulled the shared understanding forward, I could have it with every team at once. Every team had someone who knew what changes were coming, what to accept and what to reject. If slop did reach them, they could say "that isn't what we agreed, and it's not coming into our service." It was like pairing with everyone, and it got me fast reviews from every team.
This only works if a team can say no.
Some companies are relaxing ownership boundaries in the name of throughput. They open the gates and let any engineer approve any change, all so they can merge code faster. The result is code landing in a team's service without anyone from that team approving it. I've seen it happen, and I've written about it before. Without the ability to say no, a team can't reject a slop grenade.
I love the name, though, because it captures what happens. Someone pulls the pin with a quick prompt, tosses the result over the fence, and walks away. It might blow up in production. Even if it doesn't, it goes off the moment someone has to read it, because reviewing slop takes far more time and energy than it took to make. On my migration, the grenades went off on my desk instead.
A version of this problem existed before AI. A careless engineer could always write a low-effort change, skip running the tests or checking it worked, and drop it on a team who had no idea it was coming. With AI, they don't even have to write the code, and they can do it dozens of times a day. That's an extraordinary amount of ability to produce slop. As engineers, we have to be responsible with how we integrate it into our processes.
Some engineers will take that on themselves, like I did, but not everyone is going to be that mindful. And that's why processes exist. A process is a set of steps we can repeat to get a consistent outcome.
This is the part that frustrates me. Leaders give everyone 10 projects and expect them to juggle them all at once. Then they remove the ability for teams to say "no, this is slop". They allow a Software Development Lifecycle where slop grenades are possible, then complain when they happen. That makes slop grenades a process problem that management and leadership own, more than a problem with any individual engineer.
I also see a lot of people joking about pair programming, like it's something we used to do. We paired for a reason, though, and it stopped slop getting into a code base. We have a lot more of that problem now than we used to.
I look at slop grenades the same way an old manager of mine looked at every failure: a problem with our systems and processes.
What stopped slop reaching a reviewer before AI?
I suspect for a lot of teams the answer is "not much". If we don't want slop grenades, we shouldn't build a process that makes them possible.