The 'I' in AI Doesn't Stand for Intelligence: A Developer's Take on Vibe Coding

If you think the “I” in AI stands for “Intelligence” literally, the way a software developer would define it, think again. Seriously. Think again.

I’ve seen many small disasters happen because someone treated an AI coding assistant as a human replacement for technical judgment. Not “a tool that writes code faster.” A replacement. Social media has a cute name for this: vibe coding. Suddenly everyone’s a software developer. They’re not.

The task was simple

I asked an AI coding assistant to do one thing: deploy the last commit from my current working branch. That’s it. No branch changes, no cleanup, no “improvements.” Just take what’s here and ship it.

Instead, it quietly switched to main because, somewhere in its training, it picked up the assumption that master/main is always the source of truth and the safe default to fall back on. Then it started doing manual git surgery, switching branches back and forth, rechecking the state, redeciding, burning tokens the entire time. What should have taken seconds turned into a slow-motion detour through branches I never asked it to touch.

It’s hard not to notice the incentive alignment here: the more “exploring” and “double-checking” an agent does, the more tokens get billed. I can’t prove intent, but the pattern is convenient for whoever’s selling the tokens.

What should have happened

Anyone who actually knows the Git workflow can do this in minutes, with zero ambiguity:

git checkout -b deploy-branch      # create a new branch
git reset --hard <commit_before_unwanted_commits>
git cherry-pick <latest_commit_hash>

Update the Capistrano config to point to deploy-branch

cap production deploy

Six steps. No branch archaeology. No “allow me just double check main first.” No wasted tokens re-deriving context that was already given to it. Just: isolate the one commit that matters, put it on a clean branch, deploy that branch.

That’s the difference between a tool that executes your intent and one that substitutes its own assumptions for your instructions.

Why this matters more than it sounds

This isn’t really a story about one bad git command. It’s about what happens when people let a language model make judgment calls it wasn’t asked to make:

  • Silent scope creep. You asked for a deploy. You got a branch switch, extra reads, and “helpful” exploration you never approved.
  • Assumptions standing in as confirmation. “Master is probably the base branch” is a guess dressed up as a fact. In a real workflow, that guess should be a question, not an action.
  • Cost with no warning. Every unnecessary branch check and reread is a token spent and time spent on work nobody asked for.
  • Trust erosion. Once an assistant does something you didn’t ask for, you have to start re-checking everything else it touches. That’s the opposite of the productivity gain it’s supposed to provide.

The actual lesson

AI coding tools are extremely good at typing fast and pattern-matching against enormous amounts of code they’ve seen before. That is genuinely useful. It is not the same as understanding your intent, deployment process, or branch strategy.

If you’re a developer using these tools day to day, treat every non-trivial action- branch changes, resets, force operations, anything that touches shared or production state- as something the assistant ought to state plainly and let you approve, not something it quietly decides on your behalf. If it starts “exploring” when you asked for one specific action, that’s not thoroughness. That’s it filling in gaps with assumptions you didn’t give it permission to make.

And if you’re new to this and calling yourself a developer because an AI wrote your app for you: learn the fundamentals anyway. Git, deploy pipelines, how your own infrastructure actually works. The day the assistant guesses wrong on something that matters, you’re the one who has to know what “right” looks like.

Yes, this is about you, AI. Do better.


Need someone who actually double-checks the branch before deploying? That’s kind of my whole job. Reach me at kevin@kevinhq.com.


← Back to Homepage


Get occasional breakdowns

When I find something worth writing up — a fix, a pattern I keep seeing in client stores, something that actually moved revenue — I send it out. No schedule. No filler.