The Fastest Way to Make Slop
I was talking with my partner recently about something she was using AI to accomplish. She mentioned that sometimes it just wasn't moving fast enough. That prompted me to tell her, "If it doesn't have the right context, the speed doesn't matter. The iteration is the magic."
I've been thinking about that conversation because I see a similar expectation developing in organizations. An executive sees what AI can do and starts imagining how much faster everything should happen. If something that used to take a week can now be generated in an afternoon, shouldn't we be able to move dramatically faster?
Sometimes, yes. But I think there's something important missing from that expectation.
Generating something has become cheap. Understanding what needs to be done, making good decisions about how to approach it, and determining whether the result is actually useful haven't become nearly as automatic.
When we skip those parts, we get slop.
It's easy to see how it happens. Someone asks an agent to build something, gets a result, and realizes it isn't quite right. So they issue another instruction, then another, and another. But if the underlying problem wasn't understood in the first place, those instructions can compound the confusion. Eventually, you've produced a substantial amount of work without necessarily getting any closer to the outcome you wanted.
The problem isn't that the agent wasn't fast enough. It's that nobody took the time to work through the problem.
This is why I think iteration is the magic. Not because you can keep asking an agent to try again, but because each iteration is an opportunity to learn something. You can provide better context, challenge an assumption, discover a constraint you hadn't considered, or recognize that you were solving the wrong problem altogether.
I don't think the answer is to slow everything down, either. Speed is incredibly useful when you're experimenting, learning, and testing ideas. You can explore approaches that wouldn't have been practical before, get feedback quickly, and discard things that don't work. Even established processes benefit from that kind of experimentation.
But speed should help us learn and make better decisions, not become a substitute for them.
One thing I've been practicing is spending more time on the front end of a task. I try to understand what I'm actually trying to accomplish, provide enough context, and think through what a good outcome looks like. Then I let the agent work, inspect what comes back, and adjust based on what I've learned.
That might sound slower than immediately asking an agent to start building. Sometimes it is. But it also means I'm spending less time correcting work that never needed to be done.
We talk a lot about how AI can help us accomplish the same work in a fraction of the time. I think there's another possibility worth paying attention to: using the same amount of time to produce substantially better work.
If you're leading a team or building something with AI, that's the distinction I'd encourage you to make. Don't just ask how quickly something was delivered. Ask whether the team understood the problem, what they learned along the way, and whether the result actually works.
Otherwise, we're just getting really good at making slop faster.