- Model/Version (e.g. GPT 5.5):
- Harness/Version (e.g. codex-cli 0.142.3):
Slop Driven Development
Some Ruminations aimed at team leads and eng management
Our lives are now awash with slop: the deluge of low-effort content on the timeline, the generated article that fills five hundred words without saying anything. Slop has come to mean low-effort output, but it also means the low-effort collaboration with AI that produces it. “Claude, write me a blog post, make no mistakes,” yields different results than a prompt with specific points to hit, notes on length and tone, and a nudge toward Ishiguro’s restraint.
Most slop you can scroll past. The stuff in your codebase you can’t. You review it, you merge it, you maintain it, and it compounds with interest. That’s the version of slop I want to talk about, and it’s a different problem precisely because you can’t mute it.
Telling AI code from human code in a diff is hard, and harder still when you don’t know to look. Distinguishing high-effort AI work (better model, harness, prompt) from low-effort, in a single PR review, is harder yet. By the time it has compounded enough to be obvious, unwinding is its own large project. What separates the veteran from the novice is understanding the agent's failure modes and safeguarding against them. But that understanding lives in the process behind the code, and process is invisible unless someone surfaces it.
You can’t manage what you can’t see. Openness is the cheapest way to see it.
None of what follows is an attempt to justify or refute using AI. It’s a look at what its presence means for software development, not for the individual engineer, but for the cat herders trying to corral them.
It’s Inevitable
Whatever your personal stance, it’s high time to get used to AI being around.
It’s likely already futile to ban it. Doing so will only push engineers to use it in less transparent ways. At this point the only way out, if that’s the direction you want to travel, is through.
When AI use goes underground, you lose sight of how people are prompting, and that’s exactly the signal you need to spot the failure modes it introduces. Worse, velocity usually rises, so you end up with more code to review and less insight into how it was made.
Consider what that does to review. You shouldn’t review machine output the way you review a person’s since they tend to fail in different ways. Agents hallucinate, game metrics, and often lack the perspective humans have, meaning that they ignore edge cases humans have an easier time noticing.
That miscalibration is the real cost of opacity, and it isn’t something an engineer can fix alone. You don’t have to like AI, but if you want to steer your team’s efficiency, you’ll need to at least create an environment where it’s safe to say “this part came from an agent.”
Bake-Off
The biggest thing openness buys you is that it turns the AI question from an ideological one into an empirical one.
You don’t have to argue about whether agentic coding helps in your particular niche. You can run the experiment and read the answer off the codebase. When the team can see what was generated and what wasn’t, you can correlate it with what meets your standards and what doesn’t. The approaches compete in the open and the results settle the argument. That’s the bake-off.
To read those results, though, you have to know not just what was generated but how, and the how varies enormously. The gap between a novice’s prompt and a professional’s is vast: the veteran knows the pitfalls to steer the agent around, and it shows up most clearly in how seriously they take testing.
My background is mostly in Solidity, which is niche, but the principle isn’t. A novice asks for an implementation and, if you’re lucky, a couple of tests. A professional has the agent test rigorously: fuzzing, invariants, edge cases enumerated and checked, full simulations of the system, sometimes a formal verification pipeline (Certora and friends) or a static analyzer like Slither wired into the loop. Same model, same task, wildly different output, and the difference is entirely in what the human knew to ask for. I’ve watched that kind of prompt produce test suites better than the engineer would have written by hand, for the part of the job everyone treats as a chore. That last part is worth dwelling on, because it inverts the usual story about slop. AI isn’t the source of low quality there. Driven by someone who knows what to demand, it’s a floor under the rigorous, tedious work humans habitually skimp on.
All of which is the argument for sharing prompts. Said out loud, a team’s best practices propagate: the novice learns to demand testing the way the professional does, and the floor comes up. But sharing does a second thing, the one that matters most to a reviewer. It tells them how the code was made.
Write it into the PR. Here’s a simple proposal for what should go in the description:
The prompt, or enough of it to convey the intent and the constraints
The model and the harness
Anything notable about the approach: where the human stepped in, what got left to the agent
There’s a version of this where the experiment comes back negative. That is still a win. Say your team runs the bake-off and finds that agentic coding genuinely doesn’t fit your work. You now know that with evidence, and you can stop pouring time into it. Compare that to the closed, anti-AI team that happens to be right: they’re right by accident and they can’t prove it. The coders, meanwhile, aren’t convinced they should pass up all the time they could save by offloading to Claude, so they don’t. The ban just means the bosses no longer know about it, and the war gets re-fought at every new hire. Evidence ends the argument. A decree only postpones it, or worse, drives it underground.
That’s the part I’d press on if you’re skeptical.
Openness doesn’t mean you need to be suddenly pro-AI. It means you’re pro-evidence.
If you’re convinced the whole thing is slop, you should want the bake-off most of all, because it’s how you get to prove it with data instead of vibes.
Feel free to run it again in a month. The whole landscape will have changed by then.
The Firehose
Another pitfall is trying to keep up too hard, on the promise that each new tool will add another X% to output.
The firehose is relentless. New models, harnesses, skills, MCPs, loops, frameworks, orchestration layers, more every week. A new model usually isn’t a paradigm shift, but it can still meaningfully change a workflow, so it’s tempting to chase all of it. We all know the feeling of spending ten hours of research to automate one hour of work, and AI hands you an enormous number of opportunities to do exactly that.
Here is where openness helps again: nobody has to drink the whole firehose alone. If the team shares what it finds, you can distribute the scouting. One person tracks model releases, someone else kicks the tires on a new harness, and the signal reaches everyone without everyone having to follow everything. The per-person cost of keeping up drops.
It also means the team has more insight into someone teetering on the edge of the deep water. This way, when teammates can see you’re posting Garry Tan’s latest skill drop at 3 AM, they can pull you back before you drown.
There’s a fine line between standing on the cutting edge and getting lacerated by it.
The rest is opinion, so take it as such. Things I’d track closely: major model releases and new features in the major harnesses. Take a look at what people are saying about the new models, since they each have their own strengths and weaknesses. Vet skills instead of blindly incorporating them, especially with frontier models. Frontier models have gotten very good at figuring out things on their own, meaning skills can actually make them perform worse. Even outside of the frontier, a number of skills I’ve looked at are overly verbose, burning through tokens you could have saved. They can make for inspiration sometimes. I’d mostly ignore the churn of MCPs and frameworks until one proves it’s worth the attention by sticking around for a bit. Timebox exploration so it doesn’t quietly become a new job. Setting an agent to give you a weekly digest should be enough.
The Treadmill of Doom
A subtler pitfall is trusting AI’s read on its own progress.
In my experience, AI has a hard time with two things: calling a project finished (ask it what’s left to do and it will always find something), and placing a project anywhere outside the rough band between forty and eighty percent complete. Put those together, let someone use AI to estimate readiness, and you get a treadmill: the project is reported at eighty percent week after week while somehow generating an endless stream of remaining work.
This is the same shape as the firehose, and openness mitigates it the same way. The more people who know about a quirk like this from their own experience, the less it bites, and that knowledge compounds as the team talks and as more of them build the intuition firsthand. On a closed team the dynamic runs backwards. Even when individuals have the nuance, they tend not to share it, partly so as not to throw the engineers using AI under the bus, and the AI-authored work gets pushed without being flagged as such, which keeps everyone else from building the very experience that would let them catch it. They can’t learn the tell because they don’t know they’re looking at it.
Conclusion
Believer or not, it’s worth fostering an open environment around AI use on your team. It’s going to happen anyway, and this way you and your team can actually see what you’re dealing with. That visibility is what lets you build the rules and the tools to make the most of it, or to figure out where and how to avoid it.
As usual, communication trumps all.