[crazygringo]

It's because the term itself got overapplied by people critical of LLMs -- they dismissed all LLM-assisted coding as "vibe coding" because they were prejudiced against LLMs.

Then lots of people were introduced to the term "vibe coding" in these conversations, and so naturally took it as a synonym for using LLMs for coding assistance even when reading the code and writing tests and such.

Also because vibe coding just sounds cool.

[kelipso]

Lol, I say I am vibe coding even when I create little code snippets through AI that I have read and understood every line. It’s a fun term!

[habinero]

I mean, that's the joke. "vibe coding" only sounds cool if you don't know how to code but horrific if you do.

[NitpickLawyer]

> "vibe coding" only sounds cool if you don't know how to code but horrific if you do.

Disagree. Vibe coding is even more powerful if you know what you're doing. Because if you know what you're doing, and you keep up with the trends, you also know when to use it, and when not to. When to look at the code or when to just "vibe" test it and move on.

[tinfoilhatter]

What does "vibe" testing code entail exactly? Apparently you don't look at code when you're "vibe" testing it based on this statement:

> When to look at the code or when to just "vibe" test it and move on.

I'm really curious how you're ensuring the code output by whatever LLM you're using, is actually doing what you think it's doing.

[NitpickLawyer]

I stick by the og definition, in that when vibe coding I don't look at the code. I don't care about the code. When I said "vibe test it" I meant test the result of the vibe coding session.

Here's a recent example where I used this pattern: I was working on a (micro) service that implements a chat based assistant. I designed it a bit differently than the traditional "chat bot" that's prevalent right now. I used a "chat room" approach, where everyone (user, search, LLM, etc) writes in a queue, and different processes trigger on different message types. After I finished, I had tested it with both unit tests and scripted integration tests, with some "happy path" scenarios.

But I also wanted to see it work "live" in a browser. So, instead of waiting for the frontend team to implement it, I started a new session, and used a prompt alongt he lines of "Based on this repo, create a one page frontend that uses all the relevant endpoints and interfaces". The "agent" read through all the relevant files, and produced (0 shot) an interface where everything was wired correctly, and I could test it, and watch the logs in real-time on my machine. I never looked at the code, because the artifact was not important for me, the important thing was the fact that I had it, 5 minutes later.

Fun fact, it did allow me to find a timing bug. I had implemented message merging, so the LLM gets several messages at once, when a user types\n like\n this\n and basically adds new messages while the others are processing. But I had a weird timing bug, where a message would be marked as "processing", a user would type a message, and the compacting algo would all act "at the same time", and some messages would be "lost" (unprocessed by the correct entity). I didn't see that from the integration tests, because sometimes just playing around with it reveals such weird interactions. For me being able to play around with the service in ~5 minutes was worth it, and I couldn't care less about the artifact of the frontend. A dedicated team will handle that, eventually.

[QuercusMax]

This is one of the things I've seen it be very useful for: putting together one-off tools or visualizations. I'm not going to maintain these, although I might check them into version control for historical reference.

I recently ran across a package in my team's codebase that has a bunch of interrelated DB tables, and we didn't already have a nice doc explaining how everything fits together - so I asked the AI to make me a detailed README.md for the package. I'm currently reviewing that, removing a bunch of nonsense I didn't ask for, and I'm going to run it by my team. It's actually pretty good to start with because the code and DB models are well documented, just piecemeal all over the place, and half of what the AI is doing is just collating all that info and putting it in one doc.

[bigstrat2003]

If you know how to program, vibe coding is useless. It only ever can produce worse results than you could've made yourself, or the same results but with more effort (because reviewing the code is harder than creating it).

[QuercusMax]

Depends on what you're doing. I've found it extremely useful for creating the boilerplatey scaffolding I'm going to be copying from somewhere else anyway. When I actually get into the important logic and tests I'll definitely write those by hand because the AI doesn't understand what I'm trying to do anyway (since it's usually too novel).

[crazygringo]

Right but there are tons of examples of things that started out as insults or negative only to be claimed as the proper or positive name. Impressionism in painting, for a start. The Quakers. Queer. Punk. Even "hacker", which started out meaning only breaking into computer systems -- and now we have "Hacker News." So vibe coding fits in perfectly.

In other words, everyone's in on the joke.

[stonemetal12]

> Even "hacker", which started out meaning only breaking into computer systems

No. The Etymology of Hacker in the technical scene started at MIT's Tech Model Railroad Club in the late 1950s/early 1960s, "hack" described clever, intricate solutions, pranks, or experiments with technology.

A hacker is one who made those clever solutions, pranks, and technology experiments. "Hacker News" is trying to take it back from criminal activity.

[crazygringo]

TIL, thanks! Growing up I was only aware of the criminal version -- I didn't realize it grew out of an earlier meaning. I just saw the shift in the tech scene in the 1990s and more broader culturally in the 2000s with "life hacks" and hackathons. What's old is new again...