Vibe coding vs AI-assisted coding (and which one I actually do)

“Vibe coding” showed up as a cute phrase and then tried to become a methodology. I get why. Typing a wish into a chat and watching files appear feels like the future. It sounds fun, and low-effort with nice rewards. It also sounds like a toy, honestly.

It is also not what I do when I ship.

I use AI constantly. Named agents, jobs, gates, the whole bench. That is AI-assisted coding. It rhymes with vibe coding the way a tech rehearsal rhymes with opening night: related room, different stakes.

Vibe coding (as I hear people use it)

Rough definition: you steer by feel. Prompt, skim, accept, prompt again. The “spec” lives in the chat scroll. Success is “it runs” or “it looks right.” Architecture is whatever the model emitted while the mood was good. You don’t have to have any serious clue about how it’s programmed; your agents handle all that, right?

Sometimes that is fine. Throwaway scripts. Spike that will die by Friday. Learning a new API surface with training wheels. Prototype where you want to see the basic look/feel and get an idea of how it will function before you go too far down the path.

Problems start when vibe becomes the default for anything with secrets, sync, money, or other humans depending on it. Then “it feels right” is not a test plan. It is hope with syntax highlighting.

AI-assisted coding (what I mean)

AI-assisted coding assumes you are still the engineer.

• You decide the job and the non-goals.
• You choose what goes in the spec, and approve the tech stack.
• You pick the thin slice.
• You route work (research vs build vs verify).
• You read the diff until you can explain it.
• You own push, publish, dependency bumps, and “no, we are not skipping hygiene.”
• You treat the model as a fast junior with infinite stamina, not as the author of record.

I wrote about the security half of this in real security vs security theater. Same spine: humans keep the dangerous verbs. Assistance is not abdication.

How they differ in practice

	Vibe coding	AI-assisted coding
Spec	Chat vibes	Written intent, even if ugly
Done	Feels right / demos	Explained change + checks you trust
Failure mode	Mystery repo with unknown code	Known tradeoffs
Speed	Fast until it isn’t	Fast and reviewable
Ego story	“The AI built it”	“I built it with help”

The last row matters more than people admit. If you cannot claim the work, you also cannot debug it at 1am.

Which I do

AI-assisted. Loudly. Happily. Not ashamed of the help.

I am not interested in cosplaying a world where competent people pretend they never open a chat. I am interested in a world where “I used agents” and “I understand this system” can both be true.

That means:

• Phase gates (discover before dig).
• Dependency Hygiene before “flutter create and vibes.”
• Separate parking lots from product homes.
• Prompts as job descriptions, not magic spells.
• If I’m unsure what changed, I ask, then I agree or disagree, then I say it can ship when it’s what I think is ready to go.
• More hygiene before shipping. Does the code need to be refactored? Have you thought through secuity implications? Are there any annoying defects that need to explicitly either be backlogged or fixed?

Could I vibe a widget on a Saturday? Sure – I can and I have when I wanted something quick and dirty. Do I vibe the mail sync path or a pre-build gate? No. That is how ordinary projects get ordinary incidents, instead of incidents being an extraordinary happenstance.

The not-so-exciting conclusion

Vibe coding optimizes for momentum without the heavy effort. AI-assisted coding optimizes for momentum, too, but it’s less about decreasing the amount of effort you do, and more about putting the effort and focus on the places where humans should be in the loop.

I like momentum. I like sleeping. I like being able to look a hiring manager, a cast, or future-me in the eye and say what the software does, and how I engaged with its creation.

Instruments, not vibes. The line was about products. It is also about how the code got there.

~ Trish