Who presses the button

You read it everywhere now: AI slop. The automatically generated mush, texts that all sound the same, images with six fingers, code nobody has read.

It exists, sure. But I think people are looking at the wrong thing.

It's a tool

AI is a tool, just like the computer was when it first showed up in homes and offices. It does things automatically that let you get where you wouldn't get on your own: you'd lack the skills.

It has no consciousness of its own, at least for now: the singularity hasn't arrived yet. So you use it. And as with any tool, the more powerful it is, the better you do.

What it doesn't take away is your judgement of the result. Maybe you can't write that piece of code, but you know perfectly well whether what came out works, whether it's what you wanted, whether it makes sense.

Judge the result

That's why I judge work made with AI by how it turned out. Not by the fact that AI was involved.

And how it turned out tells you how skilled the person who made it is. The tool didn't decide anything: someone asked, someone looked at the result, someone found it good enough to publish.

Whose output is it

Which brings us to the point: who owns what an AI produces? The AI, or the person who asked for it?

I'd say the person. An image made with Photoshop wasn't made by Photoshop: it was made by whoever used it. Nobody would argue otherwise, and nobody would blame Photoshop for a botched photomontage.

AI should work the same way. We should start attributing things made with AI to the people who made them. For better and for worse: the credit for a good result, and the responsibility for a bad one.

What comes out belongs to whoever presses the button. AI doesn't make slop: people who settle for it, and then publish it, do.

An idea multiplier

The home page of this site says tail -f ideas.log. It isn't just a joke: I've always had lots of ideas, and almost all of them stayed right there.

Because to make them real I was always missing a piece: a piece of know-how, and above all time. Time is the thing you should never underestimate. When you have to build something, you have to account for how long it takes, and often the numbers don't add up.

Now I can check whether an idea works in a fraction of the time. And it isn't true that something that used to take a week now takes half a day: with frontier models, the really powerful ones, it takes a minute.

That's how this site was born, along with Compass (an app that tells me which ship to play in World of Warships: Legends) and term-warships (a naval battle game in the terminal). Without AI they would still be lines in that log.

Here too, though, you need to know the tool: not every model does everything, and you have to know which one to use for what.

In passes, like a render

The other thing that makes the difference is how you use it.

If you make a vague, very generic request, you get something vague and very generic. Some people may be fine with that. But if you want a real result, you have to iterate on it.

It works like the passes of a render: at first there are big chunky blocks, then the blocks get more and more defined, until the image comes out. AI is the same. It gives you a result right away, and you iterate on it, bringing it into focus pass after pass, until it's the way you want it.

That focusing is the real work. And the tool doesn't do it.

Checking what comes out

To bring something into focus, though, you need to know where the result falls short. And that's why there are ways to check it.

I work in IT, so I'll talk about what I know. First of all, with AI I can write end-to-end tests that check things work the way I expect. Then I can add a whole set of external systems: code checks, security checks, checks on plenty of other things. It's more automation layered on top of AI, adding a pinch of verification (sometimes a big pinch), and whatever it finds becomes the next pass to make together with the AI to fix what needs fixing.

And then there's something I always do: I open what was generated and look at it. Not at the detail of each single function, but at the shape, the structure, the way the repository is organised. For example:

• the documentation is there, and it's organised, with written milestones;
• there's a README that actually says something, with a quick start;
• there's a way to automate the tooling: for me that's a nice mise.toml in the project, with a task for everything the AI does automatically.

That last point matters. If the AI runs commands it made up for the job, I have it put them in a task file. That way the knowledge isn't locked inside the tokens the AI burns on every run: it lives in the project. We're back to turning tokens into tools: the more things become tools, the less you depend on AI, and the more you use it for what it is, a multiplier.

I already touched on this in AI and PEBCAK: the problem, when there is one, sits between the chair and the keyboard. So does the credit, when there is any.