Power Tools

Photo by Milad Fakurian on Unsplash

There’s a movement growing online. You’ve probably seen it: badges on websites, declarations in bios, proud announcements in blog headers. ”100% human-written.” ”No AI was used in the creation of this content.” ”Made by humans, for humans.”

I understand it. I genuinely do.

The internet has a problem, and the problem has a name: slop.

The slop is real

Simon Willison — a developer I respect enormously, and someone who actively uses AI tools in his own work — popularised the term in mid-2024.¹ His definition is precise and useful: slop is AI-generated content that’s been mindlessly produced and thrust upon someone who didn’t ask for it. Not all AI output is slop. But the stuff that’s generated without thought, published without review, and inflicted on readers without care? That’s slop.

Merriam-Webster made it their Word of the Year for 2025. Usage of the term increased ninefold in a single year. That should tell you something about the scale of the problem.

And the examples are spectacular. Facebook flooded with AI-generated images of “Shrimp Jesus” reaching forty million viewers. Google’s AI helpfully suggesting you put glue on pizza. Microsoft’s AI travel guide recommending a visit to the Ottawa Food Bank as a tourist attraction. Thousands of people turning up to a non-existent AI-promoted Halloween parade in Dublin.

These aren’t edge cases. This is what happens when AI output goes from model to audience with nobody in between. No review. No editorial judgement. No human asking the most basic question: does this make sense?

The backlash isn’t irrational. It’s a reasonable response to an unreasonable amount of rubbish.

The bit where I don’t join the movement

Here’s the thing though: I use AI tools. Extensively. For writing, for development, for research. Every app I’ve shipped this year has been built with AI assistance. Several of the posts on this blog were drafted with it.

I’m not embarrassed about this. I’m not going to hide it. And I’m not going to stick a “made without AI” badge on my site, because it wouldn’t be true — and I’d rather be honest about my process than per-formatively pure about my tools.

But I also don’t generate content and publish it. That’s not what this is.

Mechanical tools and power tools

I’ve been writing code for a long time (over forty years and counting, yikes). I know how to build things the manual way — line by line, function by function, debugging by staring at a screen until the bug confesses. I still do that. That skill hasn’t atrophied. If anything, it’s more important now than it’s ever been, because you need to understand what the AI is producing before you accept it.

What’s changed is efficiency. AI is a power tool. A circular saw doesn’t replace a carpenter — it makes the carpenter faster. The saw doesn’t know what a bookshelf looks like. It doesn’t understand load-bearing joints. It can’t step back and decide that the proportions are wrong. But it cuts wood very quickly, and a skilled carpenter with a power saw will outproduce one with a hand saw every time.

The carpenter still needs to measure. Still needs to design. Still needs to know when the grain is going the wrong way. The power tool amplifies skill; it doesn’t replace it.

That’s how I use AI. I direct. I review. I iterate. I delete the parts that aren’t right — and there are always parts that aren’t right. The AI doesn’t know my voice, my standards, my audience, or the point I’m actually trying to make. It produces raw material. I shape it.

What I actually do

When I’m building an app, I describe what I want and why. The AI proposes an approach. I read it carefully, because I’ve learned that accepting AI suggestions without scrutiny is a reliable way to introduce bugs you’ll spend twice as long fixing. I modify, I redirect, I reject entire approaches. I test. I refactor. The final code is something I understand completely, because I wouldn’t ship it otherwise.

When I’m writing, the process is similar. I outline. I describe the tone, the argument, the structure. The AI drafts. I rewrite — sometimes lightly, sometimes from scratch. I cut paragraphs that don’t sound like me. I add specifics that only I would know. By the time something is published, it’s been through enough human judgement that the AI’s contribution is more scaffolding than structure.

This isn’t “AI-generated content.” It’s AI-assisted work, reviewed and refined by someone who cares about the result.

What I don’t do

I don’t hit “generate” and then blindly hit “publish.” I don’t use AI to produce volume for its own sake. I don’t paste a prompt into ChatGPT and copy the output into a blog post and call it done. I don’t ask for code and merge it without reading it.

If I did those things, the result would be slop. Guaranteed. Because slop isn’t a property of the tool — it’s a property of the process. A word processor doesn’t produce bad writing; a writer who doesn’t edit produces bad writing. AI is the same. The tool is neutral. The negligence isn’t.

The perception gap

There’s an interesting study from METR — a randomised controlled trial — that found AI tools actually caused a 19% slowdown for experienced developers working on their own codebases.² But here’s the kicker: those same developers believed they were 20% faster. They felt more productive while being measurably less so.

I find that study fascinating, because it illustrates exactly the risk. If you don’t pay attention — if you just accept what the AI gives you and assume it’s correct — you’ll produce more output that’s lower quality, and you might not even notice. You’ll feel productive. You’ll feel efficient. And you’ll be wrong.

The antidote is the same as it’s always been: attention. Review. Testing. Standards. The boring, unglamorous parts of the craft that no tool can automate away.

The honest trade-offs

I’ll be upfront about what’s uncomfortable. AI makes it trivially easy to produce content that’s good enough. And “good enough” can erode standards if you let it. The temptation to accept a passable paragraph instead of writing a precise one is real. The temptation to ship code that works instead of code you fully understand is real.

I fight that temptation by treating AI output with the same scepticism I’d apply to a Stack Overflow answer or a junior developer’s pull request. It might be right. It might be subtly wrong. It might be confidently, fluently, convincingly wrong. The only way to know is to actually engage with it.

Where this goes

AI isn’t leaving. The “no AI” badges are a statement of values, and I respect the values behind them, even if I don’t share the conclusion. The people putting those badges on their sites care about authenticity, about craft, about the human element in creative work. Those are things I care about too.

Where we differ is in whether using a tool diminishes the craft. I don’t think it does — not if you use it thoughtfully. A photographer who uses Lightroom isn’t less of a photographer. A musician who uses a DAW isn’t less of a musician. A writer who uses AI assistance isn’t less of a writer — provided they’re still writing.

The slop merchants aren’t writing. They’re not developing. They’re not creating. They’re generating. There’s a word for the difference, and I think it matters.

I use AI because it makes me more capable, not because it makes me less necessary. The craft is still the craft. The judgement is still mine. The standards are still mine. The mistakes — and there are always mistakes — are still mine to catch and fix.

If we have an AI slop problem, it’s not because the tools are bad. It’s because too many people are using good tools badly. The answer isn’t to reject the tools. It’s to raise the standard of how we use them.

Footnotes

1. Willison credits the poet and technologist “deepfates” with coining the term on X. His blog post draws an analogy to how “spam” became the universal word for unwanted email — slop fills the same role for unwanted AI content. ↩

2. The full study is worth reading. METR is a non-profit AI research organisation focused on evaluating frontier AI capabilities. Their methodology was rigorous: randomised, controlled, and conducted with developers who had years of experience on the specific codebases being tested. ↩