AI Slop Is a Leadership Problem

I don't have deep, hands-on expertise in the Linux kernel, eBPF, or seccomp. A year ago that sentence would have ended a project before it started. Last month it barely slowed one down.

A customer had a container-escape and privilege-escalation exposure they couldn't articulate cleanly. I couldn't have written the detection for it by hand - not without weeks of reading. But I could define the problem precisely and scope the risk, and that turned out to be the part that mattered. From there I used AI to map how specific CVEs turn into local privilege-escalation and container-escape paths, to point at the components that are historically the soft spots, and to stand up a first-iteration PoC that actually detects and prevents some of those behaviors. Not in weeks. In an afternoon.

This is the part everyone writes about: the barrier to building fell through the floor. I want to write about the part underneath it, which moved in the opposite direction - and about why the slop everyone complains about is not really a model problem.

The tempting framing is "AI made me faster." That undersells and misdescribes it. AI didn't make me faster - it multiplied whatever I brought to it. Good judgment, tenfold. Sloppy scoping, tenfold. A precise question gets a precise system; a vague one gets a confident, well-formatted wrong answer that costs more to unwind than it saved.

So the leverage is real, but it is leverage on the input. The tool amplifies taste and it amplifies the lack of it with equal enthusiasm. That's the first thing worth being honest about.

Here is the paradox I keep running into. The time it takes to reach a working solution has collapsed. The time it takes to reach real understanding has not moved at all.

Building a PoC in an afternoon does not mean I understand the vulnerability in an afternoon. Truly understanding it - reading the code, reproducing the failure by hand, knowing the failure modes, checking what it costs in CPU, memory, and disk at scale, knowing exactly when the model is hallucinating with confidence - that still takes the same work it always did. The demo is cheap. The understanding is not. And the gap between those two things is widening every month.

That gap used to be invisible because you couldn't ship anything without first crossing it. Now you can.

Which brings me to the claim I actually want to make. AI slop is not created by AI. It is created by lack of direction.

A model can generate a plan. It can write the first PoC. It can summarize the CVEs and produce ten plausible architectures before lunch. What it cannot do is know which one is worth doing. It doesn't know the customer's real pain. It doesn't know which constraint actually matters and which one only sounds important. It doesn't know which engineer will turn a rough direction into something solid, and which one will get buried in a promising dead end for a week. It doesn't know when a prototype is good enough to learn from and when it is dangerous to trust.

That layer - direction - used to be hidden inside execution. When building was slow, the people who could push the work forward by hand naturally controlled where it went, too. AI pulled those two things apart. Execution became cheap to generate. Direction did not. And when direction is weak, the amplifier does not save a team; it just produces more confident noise, faster.

Which raises a question I don't have a clean answer to.

Do I still need to know how to debug a kernel by hand? Or do I need to understand the system well enough to define the right problem, ask the right questions, design the right tests, and reject the wrong answers - and let one agent debug while another verifies? (Some day, plausibly, the same agent doing both.)

I don't think the answer is "no, expertise is obsolete." I also don't think it's "nothing has changed." Both of those are comfortable and wrong.

Under all of this, one instinct still works: you can feel AI slop. You can feel it when someone hands you a clean-looking architecture and can't explain a single tradeoff in it. You can feel it when the buzzwords are all present and the failure modes are all absent. You can feel it when someone is selling confidence instead of substance.

A year ago I would grill anyone who tried to bluff their way through a deep technical conversation, and I'd enjoy it. Today I'm asking a genuinely harder question. If someone isn't the best kernel developer in the room, but their AI-assisted result actually works - it scales, it holds up under CPU and memory pressure, it's tested properly, and it solves the customer's real problem - does it matter who, or what, wrote it?

As long as we can define what a good result is, what a rigorous test looks like, and how the thing should behave under load, and the customer is genuinely, not performatively, happy - I'm no longer sure the authorship of the first draft is the interesting question.

(An aside, because honesty is cheap and I'll spend it here: nearly every AI-written post I read contains the phrase "but this is not the interesting part." I noticed it only after catching myself writing it. Take that as a small, useful reminder that the amplifier runs on all of us.)

So does experience still matter? More than before - but not for the reason it used to.

It used to matter because experienced people could hold the whole stack in their heads and execute it by hand, bit by bit. That's no longer the scarce skill. What's scarce now is knowing what shouldn't be trusted - which output is a working prototype and which is a dangerous illusion, which test is load-bearing and which is theater, where the model is confidently wrong.

This isn't new territory for me, it's just louder. It's the same instinct behind Anvil - a vulnerability-research system where AI agents do the repetitive glue work and deterministic infrastructure decides what is actually true - and behind the argument that agent authority can't be probabilistic even when the model is. In Anvil, standing up a fuzzing campaign against a new library - mapping the codebase, finding the API nobody had fuzzed, writing the harness, fixing the build - used to be the weeks of scaffolding that decided whether a campaign happened at all. Now it starts from a single prompt, and the engineering starts after the first crash, not before.

I distrust dashboards when they replace understanding. I've started to distrust prototypes for the same reason. A result that works is the beginning of the argument, not the end of it.

For years, the most valuable person in a technical room was the one who held the deepest implementation details - the one who could read the kernel source, debug the weird crash, name the exact syscall that mattered. That person still matters. But the leverage is no longer concentrated there.

When time-to-solution collapses, the bottleneck stops being "can someone build a first version?" It becomes a different list of questions. What problem is actually worth solving? What does the customer really need? Which risk matters, and which one only sounds scary? Which engineer should own which piece? Where should AI accelerate the work, and where should it be treated as untrusted input? What tests prove the result is real?

That is not generic management. It is technical direction, and it needs both ends of the stack at once: enough low-level understanding to feel the bluff in the output, and enough high-level judgment to know whether the work matters at all.

It is also where teams will struggle most, because good engineers built their identity on being the person who knows every bit and byte. To them the amplifier can feel like cheating, or like slop - and sometimes it is slop. But avoiding it is not a strategy. The job now is to get a team using it without lowering the bar: explore faster, don't think less; reach understanding sooner, don't route around it; multiply strong engineers, don't replace their judgment with autocomplete. An organization amplifies exactly the way an individual does. Point it at sharply defined problems and it multiplies the team; point it at vague ones and it multiplies the noise.

Because the model can generate options, but it doesn't know which option matters. It can produce a PoC, but it doesn't know whether the PoC is good enough for the customer. It can summarize a CVE, but it doesn't know whether that CVE is a real product risk or another well-formatted rabbit hole. That judgment is still human - and in a world where generating work is cheap, deciding what work is worth doing is the scarce skill.

We're moving from an era of manual execution to an era of technical direction. I don't think everyone needs to know every bit and byte anymore. I'm increasingly sure someone in the room still has to know exactly which bits and bytes are the ones that will hurt us - and that's a different kind of knowing, one the amplifier can't hand you.