Published In English
AI slop, vibe coding, and what AI-assisted engineering actually looks like
Three things that get called the same thing. The difference is not how much the model wrote. It is whether anyone can check the result, and who is on the hook.
I build software with AI agents every working day, and I also read a lot of code that was clearly produced by one. Those two sentences describe completely different activities, and we are running out of words to tell them apart. So here are the three that matter, in the order they usually get confused.
Slop is output nobody read
Slop is the article, the pull request, the documentation page or the image that was generated and then shipped without a human ever reading it. The defining property is not that a machine made it. It is that it arrived in front of you having passed through nobody.
That is why slop is recognisable even when it is technically correct. It answers a question nobody asked, in the register of a confident stranger, at a length nobody needed. In code it looks like a function that handles six cases when the caller has two, comments that restate the line below them, and a test that asserts the function returns what the function returns.
Vibe coding is accepting what you cannot evaluate
Vibe coding got its name in 2025, from Andrej Karpathy, for a specific and honest thing: building something by describing what you want, taking the diff without reading it, and running it to see. For a weekend project, a throwaway script or a language you do not know and do not intend to learn, that is a completely legitimate way to work. I do it too.
It becomes a problem at exactly one moment: when the thing stops being throwaway and nobody notices. The code is now in front of customers and the only person who could explain it is a model with no memory of writing it. The failure is not the speed. It is that the ability to evaluate the output was never built, and now there is nothing to fall back on.
The third thing has no good name yet
What I do is neither. The model writes most of the lines. I own every one of them, in the plain sense that when something breaks at midnight it is my problem and my explanation. Making that sustainable took three things, and none of them is a prompt.
First, a contract the agent reads before it touches anything. This site carries one: a document describing how the system is built, plus a library of longer documents for each area, loaded on demand. It is not a style guide. It records why each decision exists and what breaks if you undo it, because an agent that knows only the style will cheerfully refactor away the reason.
Second, every rule carries the incident that created it. The rule about secrets staying on the server sits next to the story of the integration whose keys were readable in the page source. The rule about never stacking two animation systems on one element sits next to the window that drifted off screen. A rule with its scar attached survives contact with a confident suggestion. A rule stated as a preference does not.
Third, verification that does not depend on anyone's confidence, mine or the model's. There is no CI here, so the gate is a command I run and a number I read:
pnpm exec tsc --noEmit
pnpm lint
pnpm build # the static page count should not drop unexpectedlyThen, for anything visible, the same change gets looked at in both themes, both languages, with reduced motion on and off, at a phone width and a desktop one. And wherever a judgement kept getting relitigated, it became a measurement instead: a contrast ratio, the clearance between a button and the fold on a phone, a ceiling on how much colour a 3D object may carry. You cannot argue with a number, and neither can a model.
The honest part
This is more work up front, not less. The contract for this site is tens of thousands of characters and the library behind it is bigger. Writing it down took time I could have spent shipping features, and it only pays back because the number of changes is large and the cost of a silent wrong one is high. For a script you will delete on Friday, none of it is worth doing. Vibe code it and move on.
If you are hiring someone, or paying someone, the tell is not whether they use AI. Everyone does now, and the ones who say they do not are usually just not saying so. The tell is what happens when you ask how they know it works. One answer is that it works. The other names the command, the number it printed, and the thing that is still unverified.