Live data from Hacker News

Vibe coding creates fatigue?

tabulamag.com

101–110 of 174 posts

Re: Vibe coding creates fatigue?

#101
post #89
post #49

Earlier quoted context omitted.

Words changed meaning all the time through history, it just happens faster.

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.

"seeking to create drama for attention"

I do not think that is a new thing in human history, too. But sure, the internet amplified it a lot.

Re: Vibe coding creates fatigue?

#102

Earlier quoted context omitted.

Agreed. Some strategies that seem to help exist, though. Write extensive tests before writing the code. They serve as guidance. Commit tests separately from library code, so you can tell the AI didn't change the test. Specify the task with copious examples. Explain why yo so things, not just what to do.

Yeah, this is where I start side-eying people who love vibe coding. Writing lots of tests and documentation and fixing someone else's (read: the LLM's) bad code? That's literally the worst parts of the job.

I also get confused when I see it taken for granted that "vibe coding" removes all the drudgery/chores from programming. When my own experience heavily using Claude Code/etc every day routinely involves a lot of unpleasant clean up of accumulated LLM slop and "WTF" decisions.

I still think it saves me time on net and yes, it typically can handle a lot on its own, but whenever it starts to fuck up the same request repeatedly in different ways, all I can really do is sigh/roll my eyes and then it's on me alone to dig in and figure it out/fix it to keep making progress.

And usually that consists of incredibly ungratifying, unpleasant work I'm very much not happy to be doing.

I definitely have been able to do more side projects for ideas that pop into my head thanks to CC and similar, and that part is super cool! But other times I hit a wall where a project suddenly goes from breezy and fun to me spending hours reading through diffs/chat history trying to untangle a pile of garbage code I barely understand 10% of and have to remind myself I was supposed to be doing this for "fun"/learning, and accomplishing neither while not getting paid for it.

Re: Vibe coding creates fatigue?

#103
post #21

Earlier quoted context omitted.

Can you share why it was non-trivial? I'm curious about how folks are evaluating the quality of their solutions when the project space is non trivial and unfamiliar

A little bit of Dunning-Kruger maybe?

Dunning-Kruger isn't what you think it is[1]

[1] https://skepchick.org/2020/10/the-dunning-kruger-effect-misu...

Re: Vibe coding creates fatigue?

#104

Earlier quoted context omitted.

> "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.

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.

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.

Re: Vibe coding creates fatigue?

#105

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 ma…

> rarely or never looking at the code generated.

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.

Re: Vibe coding creates fatigue?

#106

Earlier quoted context omitted.

If you do this on your personal stuff, eh, I wouldn't do it, but you do you. But we're seeing that this becomes OK in the workplace, and I don't believe it is. If you propose these changes that would've normally taken you 2 weeks as your own in a PR, then I, as the reviewer, don't know where your knowledge ends and the AI's hallucinations begin. Do you need to do all of these things? Or is it because the most commonl…

A lot of that stuff can be handled by linters and static analysis tools.

What are some examples of linters / static analysis catching hallucinated solutions to problems?

I feel like it would just yield a well-formatted, type safe incorrect solution, which is no better than a tangled mess.

Re: Vibe coding creates fatigue?

#107
post #10

I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. It was a non-trivial project, and I had to be paying attention to what the agent was doing because it…

> I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. You didn’t find that to be a little too much unfamiliarity? With the couple of projects that I’ve worked on that were developed using an “agent first” approach I found that if I added too many new things at once it would put me in a difficult space where I didn’t feel confident enough to evaluate what…

SwiftKotlinDartGo blur together by now. That's too many languages but what are you gonna do?

I was ready to find that it was a bit much. The conjunction of ATProto and Dart was almost too much for the coding agent to handle and stay useful. But in the end it was OK.

I went from "wow that flutter code looks weird" to enjoying it pretty quickly.

Re: Vibe coding creates fatigue?

#108

Earlier quoted context omitted.

There's something exhilarating about pushing through to some "everything works like I think it should" point, and you can often get there without doing the conscientious, diligent, methodical "right" way of doing things, and it's only getting easier. At the point where everything works, if it's not just a toy or experiment, you definitely have to go back and understand everything. There will be a ton to fix, and it m…

> I'm not a professional SWE It was already obvious from your first paragraph - in that context even the sentence "everything works like I think it should" makes absolute sense, because it fits perfectly to limited understanding of a non-engineer - from your POV, it indeed all works perfectly, API secrets in the frontend and 5 levels of JSON transformation on the backend side be damned, right ;) Yay, vibe-coding for…

>> even if it takes longer than the programming the conventional way, who cares, right?

Longer than writing code from scratch, with no templates or frameworks? Longer than testing and deploying manually?

Even eight years ago when I left full-stack development, nobody was building anything from scratch, without any templates.

Serious questions - are there still people who work at large companies who still build things the conventional way? Or even startups? I was berated a decade ago for building just a static site from scratch so curious to know if people are still out there doing this.

Re: Vibe coding creates fatigue?

#109
Claude Code latency is at the unfortunate balance where the wait is long enough for me to go on twitter, but not long enough to do anything really valuable. Would be more productive if it took minutes or under 5-10 seconds.

Re: Vibe coding creates fatigue?

#110

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 ma…

There was a huge discussion on this a few weeks ago, seems still far from settled: https://news.ycombinator.com/item?id=45503867

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.

Post reply on HN