Vibe coding is not binary

There is a conversation I have had four or five times now, and it goes the same way each time. I describe how a piece of work actually got done - what the agent did, what I did, how much of the code I typed - and somewhere in the middle I watch the other person reclassify me. Oh, right. You vibe code.

I do not, in any sense that word is usually meant. But I understand why it lands there, because the only two boxes on offer are "serious engineer who writes the code" and "person who does not", and I no longer fit the first one. On the surface I look much more like someone describing an app to Lovable than like the engineer I was two years ago.

That surface is where the whole confusion lives. The binary sorted people by how much code they typed, and it worked for a while because typing volume used to correlate with everything else you cared about. It has stopped correlating.

The number that broke it for me

I went and measured what actually happens in a session, because I had a feeling about it and a feeling is not a finding.

Every agent session in this estate writes a transcript. Across all of them, from 12 July to 17 August 2026 - 37 active days, 152 sessions, 1,145 transcript files - there were 77,720 tool calls. Sorted by what the action was for:

Authoring code - edits plus new files - is 12.3% of everything that happens. Running things and reading the results is 67.6%.

So the work is not writing. It has not been writing for a while. The work is establishing what is true, changing one thing, and establishing what is true again. That is not a new activity: it is what senior engineers have always mostly done, and the ratio has simply become visible because something else is holding the keyboard.

Which is exactly why typing volume is now a broken proxy. Somebody who has never written a line of Go, describing an app to Lovable until it looks right, also authors very little by hand. If typing is the measure, the two of us are in the same box, and the box has stopped telling you anything about either of us.

What the word was actually reaching for

The useful thing inside "vibe coding" was never a claim about tooling. It was a claim about a relationship to consequences: code arrives, it appears to work, nobody checks, and nobody is on the hook when it does not. The AI was incidental. You could vibe code by hand, and plenty of people did.

Once you separate those, the interesting line is not how the code got written. It is two questions:

• Is verification something a person performs, or something you hope the output has?
• Who carries it when it breaks?

Both of those are answerable. Neither has anything to do with typing.

Verification is a step somebody performs

Not a property that shows up if the tooling is good enough. Two examples from this estate, both mine, both recent.

A draft post about replacing an observability stack carried the phrase "roughly a tenth of the memory". It came from an internal note nobody had checked. It was wrong, and it was sitting in a piece about engineering competence. Worse, the stack being compared against had already been deleted, so the original figure was unrecoverable - the paragraph now says the number does not exist rather than giving one. A wrong fact you wrote down travels much further than a wrong fact you said.

Separately: a passing DOM check once shipped a content area with zero height to production. Every element was present and correctly nested, and the whole thing occupied no space. elementFromPoint was perfectly happy. The lesson is unglamorous and absolute - screenshot the page, or you do not know what it looks like.

Neither failure would have been prevented by writing the code by hand. Both were prevented afterwards by adding a step a person is accountable for.

An instruction is not a control

This is the part I would keep if I had to throw the rest away, and it is the clearest measurable difference between the two ends of the supposed binary.

There is a rule in this estate: never pkill, killall or group-kill a dev process. It exists because on 7 June 2026 a group-targeted kill climbed the process tree and took down my whole desktop session. The rule is written down in three separate skill files, in capital letters, with the reason attached each time.

Across the same 37 days, the hook that enforces it refused a command 49 times, across 37 different sessions.

Sit with that. The instruction was clear, repeated, justified, and loaded into every one of those sessions. The thing it prohibits was still attempted roughly one and a half times per active day. Whatever a written instruction is, it is not a control.

So the guards are not there because I do not trust the agent. They are there because I have measured what trust is worth, and it is worth about 49 blocked commands a month. The distinguishing feature of working this way properly is not restraint. It is that the constraints are mechanical, they refuse rather than advise, and each one exists because something specific went wrong once.

That is the thing the Lovable comparison cannot reach, and it is nothing to do with the quality of the prompts at either end. It is the existence of a layer whose entire job is to say no, assembled from incidents that already happened to me.

The part that does not transfer at all

It cannot tell you what is worth building.

Every judgement in this estate about what to do next has been a human one, and on the occasions I have let a plausible generated roadmap stand, the result was well made and pointless. It is genuinely excellent at "here is how that would be built" and holds no view whatsoever on "should it be". That gap has not narrowed in the time I have been watching it, and I would not plan around it narrowing.

An engineer who has stopped typing has not stopped deciding. That is the whole distinction, and it is invisible from outside, which is why the vocabulary keeps failing.

So retire the word, or fix it

If "vibe coding" means "used AI", it now describes almost everyone and sorts nobody. If it means "shipped something nobody verified and nobody owns", it is a useful and slightly brutal term, and it applies to plenty of hand-written code too.

Pick the second meaning. Then the question you ask about a piece of work is not how much of it somebody typed. It is: what did you check, how did you check it, and what happens to you when it breaks.

I am fairly sure that is the only version of the question that was ever worth asking. The tooling just removed our ability to guess the answer by looking.