Vibe coding and the people downstream

You’re familiar with this. You prompt the model for some scriptlet. You get forty lines back. You try it once. It does what you wanted it to. You do not read it.

Of course not. It renamed your files. You shut that tab. You’re a wizard who didn’t go to the ‘reading’ part of wizard school.

That’s what I think vibe coding was when it first made the rounds in early February. Surrender to the model. Take whatever it gives you. Don’t even read the code.

A few weeks later the definition has expanded to include any code touched by the model. That’s a pity. All words mean everything. “I used a computer” is what “everything” means when the word is “everything”. If you’re reading the output, trying it, and able to explain it to your coworker, you’re just using a new tool to program. “Vibe coding” is the part you’re not doing.

Mostly, I’m okay with that. If an afternoon of prototype can resolve a product-specific dispute that would have required a week of meetings? Great. If it’s a tool you use by yourself that’s buggy when you use it? Just you. That’s pretty awesome.

Things get weird when there’s other people. When a feature is in a product, there are users who didn’t see the code. There’s a teammate who will need to modify it six months from now. There’s an on call person who will first encounter it at an inconvenient time. Everyone there is silently betting that there was, at some point, some person who actually read.

It’s easy to violate this assumption if you’re using generated code since it looks done. It has comments on it. It has pretty names for variables. It’s here much quicker than you can even read. There’s a little voice telling you reading it’s rude to the speed. You haven’t raised the bar on shipped code (read it, see it work, put a name on it). It’s just easier to wriggle under.

Also prototypes tend not to die. Throw away one with a feature flag because the demo was cool. A customer because it has the flag on. A page in the middle of the night. I don’t think people ever choose to ship a prototype. It tends to happen to them like guest room gets converted to storage room.

So I’d rather call out the boundary than disallow or ignore it. Spikes are in their own corner of the world. Clearly marked. Separate from the main branch. We read whatever gets merged like normal code. Explaining “the model wrote it” isn’t an explanation for a pull request.

I’m mostly thinking about the noobs here. It’s easy to get really quick with churning out code but not quick at understanding it. And understanding hasn’t become cheaper. I’d tell them to use tools a lot. Read a lot. Mess with the output on purpose. Can you fix it yourself? Seems like a good thing to be for a while to know whether the generated code is correct or not.

What happens if you lose the model tomorrow? Could you keep this code running? I think about that for my own little scripts. And honestly? Most of them would just quietly die like houseplants.