When vibe coding, isn't the source code the prompt? - The Boston Diaries - Captain Napalm

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

I've been thinking about “vibe coding” (probably overthinking) and how that might effect development in odd ways. And by “vibe coding” I mean in its original meaning, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Since February, I've come across several projects, some commercial, that have been “vibe coded” in such a manner. And I found myself asking myself, what's the source code in this case? What file should be checked into source control? And my answer was “the prompts, of course.”

I have a project where I need to parse HTML, and I wrote some PEG code to do it. But the code I checked into source control wasn't the resulting C sludge that came out of the tool, but the PEG code itself—that is the source of … um … the source, as it were. If I want to change the parser, I don't change the C code, I change the PEG code and regenerate the C code. I don't necessarily care about the C code output, much like I no longer necessarily care about the assembly output from the C compiler. And there are many DSLs out there that “compile” into some other code like C or Rust, and in those cases, it's the file that contains the DSL that is checked into source control, not the resulting output of the tool.

So how is that any different from “vibe coding,” where “you fully give in to the vibes … and forget that the code even exists?” It's not the output that you necessarily care about, but the input. So, when “vibe coding,” the source code is the prompt or prompts. And it's that source code, the prompts, that you should therefore check into source control.

Leave a Comment