There probably needs to be some settled discussion on what constitutes "vibe coding." I interpret this term as "I input text into $AI_MODEL, I look at the app to see my change was implemented. I iterate via text prompts alone, rarely or never looking at the code generated."
vs. what this author is doing, which seems more like agent assisted coding than "vibe" coding.
With regard to the subject matter, it of course makes sense that managing more features than you used to be able to manage without $AI_MODEL would result in some mental fatigue. I also believe this gets worse the older you get. I've seen this within my own career, just from times of being understaffed and overworked, AI or not.
Yes, I'm getting increasingly confused as to why some people are broadening the use of "vibe" coding to just mean any AI coding, no matter how thorough/thoughtful.
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.
> "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.
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.
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.
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).
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).
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.
> 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.
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...
Like people using “bricked” to signal recoverable situations. “Oh the latest update bricked my phone and I had to factory-reset it, but it’s ok now”. Bricked used to mean it turned into something as useful as a brick, permanently.
I'm not sure how common this is in other countries, but Americans would rather add another definition to the dictionary for the misuse before they'd ever tolerate being corrected or (god forbid) learning the real meaning of a word. I got dogpiled for saying this about "factoid" the other day here, but sometimes when people misuse words like "bricked" or "electrocuted", the ambiguity does actually make a difference, meaning you have to follow up with "actually bricked permanently?" or "did the shock kill him?", meaning that semantic information has been lost.
The two examples the grandparent post mentioned are not really evolution, but rather making everything sound bombastic and sensationalist. The end game for that trend is the cigarette brand ad billboard in Idiocracy, where a half-naked muscular man glares at you angrily and going "If you do not smoke our brand, f* you!"
Yes but before 2005 we didn't have Reddit, so we didn't have people who learned about prescriptivism from there and think it means all discussion about taste and style is immoral.
There is a world of difference between natural semantic drift and blatant disregard for accuracy by someone seeking to create drama for attention.
Not to mention all the attempts we see nowadays at deliberate redefinition of words, or the motte-and-bailey games played with jargon vs. lay understandings of a concept.
Personally I think "vibe-coding" has semantically shifted to mean any AI-assisted coding and we should just run with it. For the original meaning of vibe-coding, I suggest YOLO-Coding.
> There probably needs to be some settled discussion on what constitutes "vibe coding." I interpret this term as "I input text into $AI_MODEL, I look at the app to see my change was implemented. I iterate via text prompts alone, rarely or never looking at the code generated."
Agreed. I've seen some folks say that it requires absolute ignorance of the code being generated to be considered "vibe coded". Though i don't agree with that.
For me it's more nuanced. I consider a lack of review to be "vibed" related to how little you looked at it. Considering LLMs can do some crazy things, even a few ignored LOC might end up with a pretty "vibe coded" feelings, despite being mostly reviewed outside of those ignored lines.
I agree, i'm saying any code it produces. Eg if you ignore 95% of the LLM's PR, are you vibe coding? Some would say no, because you read 5% of the PR. I would say yes, you are vibe coding.
Ie you could say you vibe'd 95% of the PR, and i'd agree with that - but are you vibe coding then? You looked at 5% of the code, so you're not ignoring all of the code.
Yet in the spirit of the phrase, it seems silly to say someone is not vibe coding despite ignoring almost all of the code generated.
The question is, to what purpose are you looking at those 5%? I reckon it’s because you don’t really trust the vibes. In that sense, you’re not vibe-coding.
If that's the case i feel like we need some other term. As you're saying that someone who ignores 95% of the written code is not vibe coding. That to me says we need a term that describes "i ignored almost all code" type of "coding" that LLMs provide.
I don't care about the 5% difference. I care about the bulk, the amount of bugs and poor logic that can slip in, etc. I have no attachment to the term "vibe coded", but it's useless to me if it doesn't describe this scenario.
I don't see a distinction. Vibe coding is either agent assisted coding or using chatbots as interpreters for your design goals. They are the same thing.
My interpretation is that you can look at the code but vibe coding means ultimately you're not writing the code, you're just prompting. It would make sense to prompt "I'd like variable name 'bar' to be 'foo' instead." and that would still be vibe coding.
I think the difference between the two is shrinking by the day. At this point I almost never need to address anything with the LLM's solution and could easily just go straight to testing for most things.
The key difference is still the prompts and knowing what to reference/include in the context.
> I think the difference between the two is shrinking by the day. At this point I almost never need to address anything with the LLM's solution and could easily just go straight to testing for most things.
Do you believe that atrophy is not a real thing?
I've found that LLMs massively over-engineer things, regardless of the prompt used. How do you counter that without going back and forth at least a few times?
I don't "believe" in anything. I'm just describing my situation, where I'm trying to find ways to improve the solutions but seldom find any. It's purely an observation and not me advocating for one thing or another.
I still check the output but it is starting to feel like a sanity check more than a code review.
vs. what this author is doing, which seems more like agent assisted coding than "vibe" coding.
With regard to the subject matter, it of course makes sense that managing more features than you used to be able to manage without $AI_MODEL would result in some mental fatigue. I also believe this gets worse the older you get. I've seen this within my own career, just from times of being understaffed and overworked, AI or not.