4 ms·
I mean, that's the joke. "vibe coding" only sounds cool if you don't know how to code but horrific if you do.
by habinero 10mo ago
I mean, that's the joke. "vibe coding" only sounds cool if you don't know how to code but horrific if you do.
- crazygringo 10mo agoRight 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 10mo ago> 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 10mo agoTIL, 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...
- NitpickLawyer 10mo ago> "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 10mo agoWhat 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 10mo agoI 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.