Article · Field notes
Remedies for the Slop
30 May 2026 5 min read
More than ten engineers spent the better part of a week generating fixes for a production failure. What finally got them out was the slowest method available: agents off, read the code, line by line. That’s the team from my last post.
I’m not giving up the tools. I use them every day and I like the speed. What I want are rules for the moment speed starts producing work nobody owns, and those rules change with the size of the room.
If my name is on it
Start with the rule that sounds obvious and almost nobody honours: own what you ship. “The agent wrote it” isn’t a defence. If your name is on the PR, you’re accountable for every line as if you’d typed it, because the model won’t be the one paged at 3am. Owning it means you can explain it to someone who asks a hard question. If you can’t, you’re not done, however green the checks are.
That changes how you work with the agent. Reviewing a finished two-thousand-line diff doesn’t work. You skim, it looks right, you approve, and you’ve understood none of it. So stay in the loop while the work happens, not after. Pair with the agent: say what you want, watch what it does, stop it when it drifts, and keep the change small enough that you can still hold the whole thing in your head. A hundred lines you understand beats two thousand you don’t.
And when something breaks, fight the reflex to throw another agent at it. That’s how the hole gets deeper. Read the code yourself. It’s slow, and the engineers still willing to do it are becoming the most valuable people on their teams.
Somebody has to look for the lie
One disciplined person doesn’t survive contact with a team that isn’t. The thinking has to be built into how the team works rather than left to individual virtue.
What helps most is red teaming. Pick someone whose job, for that session, is to assume the system is already broken and find out how. It’s a different job from code review, and it runs on one standing question:
If this fails in production six months from now, what’s the most likely cause, and would we even notice?
An agent will never ask you that. It’ll generate the system, the tests, and a confident paragraph on why it’s fine. Whether it’s actually fine is a human call, and red teaming is where you make it.
Review against intent as well as correctness. Code that’s internally consistent and does the wrong thing sails through every automated check. Somebody has to keep the real goal in their head and hold the work up against it. Green tests can’t do that part.
Keep the units small and the trunk clean. Small PRs used to be a style preference. Now they’re what keeps a human able to review at all. Keep the main branch releasable, so a break stops the line and gets fixed before it compounds. And make room for review that isn’t tied to any single change, because most of the failures that take a system down live between PRs: the duplicated abstraction, the slow drift away from what you meant to build. Line-by-line review can’t see those.
At company scale, volume wins
Zoom out to the whole company and no single team is the problem. What bites you is that nobody can see across all of them at once, and the volume is now enormous.
Traceability comes first. Every change should trace back to the intent behind it, so that when something breaks, or an auditor asks, or a customer does, you can reconstruct why a thing exists and who decided it should. When humans wrote every line, that was implicit. With agents producing most of it, you make it explicit or you lose the thread.
Build in layers, because no single check is enough when the output is this fluent and there’s this much of it. Evals that block a merge on regression. Observability required before anything ships, not bolted on after. Progressive delivery, so a change meets real traffic in shadow, then a slice of users, before it meets everyone. Each layer is cheap next to the failure it catches.
Then there’s the slower structural work. Concentrate the hardest thinking on your most senior people instead of spreading it thin across everyone with an agent and a keyboard. The tool rewards judgment, and judgment is unevenly distributed.
Juniors used to learn the craft by writing production code, and they can’t anymore. Rebuild their path around the parts that still need a human: review, planning, design, and the discipline of understanding a system before you change it.
And measure the right thing. If your dashboard celebrates output volume, you’re measuring the disease. Count the defects that escape to production, the time it takes to actually understand an incident, the share of shipped code someone can explain. Those only move the right way when people are thinking.
The rule I keep is embarrassingly old-fashioned. If my name is on the change, I need to be able to explain it when the page arrives at 3am. The agent won’t be awake, embarrassed, or accountable. I will.