Vibe Coding Is Just Managing an Intern
The short version
I thought building a game would mostly be ideas. The ideas turned out to be the easy part, and the expensive mistakes are the ones nobody argues with.
I have been building a video game this year, mostly to find out what I do not know. The answer so far is a lot.
I went in assuming the hard part would be coming up with things. What the enemies should do, how a level should feel, what makes a fight fun. That part has been fine. I have no shortage of ideas.
The hard part is that I am not really writing the game. I am asking for it.
HOW I THOUGHT IT WOULD GO
my idea -> computer builds it -> game
HOW IT ACTUALLY GOES
my idea -> intern builds it -> I test it
^ |
|__________________________________|
this loop is most of the jobThe intern
The closest thing I can compare it to is managing a very fast, very willing intern.
The intern is genuinely good. It knows more than I do about most of what I ask for. It never gets tired, it never pushes back on a boring job, and it turns work around faster than I can review it.
It also never says "are you sure about that?"
That is the part I did not see coming. When you hand a person a bad assumption, there is a decent chance they squint at it. It does not match something they remember, so they ask. The intern does not squint. It takes what you gave it and starts immediately, at full speed, with total confidence.
So my mistakes do not sit still. They get built on.
The mistake
Months ago I wrote one line in my own project notes. It described a setting on my character files, and it said that setting meant one thing when it actually meant close to the opposite.
Small error. I read a number correctly and wrote the wrong word next to it.
Then I moved on, and everything after that stood on top of it.
That note said, in effect, that the pile of animations I already owned could never be used on my own characters. So I planned around not having them. I wrote a spec that assumed it. I chose what to build next based on it. The intern read that note at the start of every session, believed it completely, and helped me plan around a problem I did not have.
I owned about seventy animations the entire time. Walking, running, attacking, getting hit. The exact things I had been trying to work out how to replace.
Finding it took an afternoon. The work stacked on top of it had to be pulled apart and thrown out.
What I actually learned
Making games is harder than I expected, and not for the reason I expected. It is not hard because the code is hard. It is hard because a game is a few hundred small assumptions leaning on each other, and you cannot tell which one is wrong by reading it.
You find out by testing. Actually running the thing. Watching it move.
I keep wanting to skip that, because asking for a feature is fast and checking it is slow. But the checking is not overhead around the work. It is the work. Asking was never the bottleneck.
The intern will believe anything I tell it, which makes me the expensive part.
If I could tell myself something six months ago it would be this. You are not going to get stuck because you ran out of ideas. You are going to get stuck because you were confidently wrong about something small, and nobody in the room was in a position to argue with you.
Brian Franke
brian@coasterlogic.com