Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe coding creates fatigue?

tabulamag.com

Post reply on HN
Print view View original

51–60 of 174 posts

Re: Vibe coding creates fatigue?

#51

Post by pferde »

jmalicki wrote: post #45
louthy wrote: post #33

Earlier quoted context omitted.

> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you. This is ‘phoning…

Learning an unfamiliar aspect and doing it be hand will have the same issues. If you're new to Terraform, you are new to Terraform, and are probably going to even insert more footguns than the AI. At least when the AI does it you can review it.

No, you can not. Without understanding the technology, at best you can "vibe-review" it, and determine that it "kinda sorta looks like it's doing what it's supposed to do, maybe?".

Re: Vibe coding creates fatigue?

#52

Post by visarga »

louthy wrote: post #33
Zigurd wrote: 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…

> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you. This is ‘phoning…

>Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job.

Red flag again! If your protection is to "understand the implementation" it means buggy code. What makes a code worthy of trust is passing tests, well designed tests that cover the angles. LGTM is vibe testing

I go as far as saying it does not matter if code was written by a human who understands or not, what matters is how well it is tested. Vibe testing is the problem, not vibe coding.

Re: Vibe coding creates fatigue?

#53

Post by bongodongobob »

louthy wrote: post #33
Zigurd wrote: 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…

> But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you. This is ‘phoning…

It sounds like you've never worked a job where you aren't just supporting 1 product that you built yourslef. Fix the bug and move on. I do not have the time or resources to understand it fully. It's a 20 year old app full of business logic and MS changed something in their API. I do not need to understand the full stack. I need to understand the bug and how to fix it. My boss wants it fixed yesterday. So I fix it and move onto the next task. Some of us have to wear many hats.

Re: Vibe coding creates fatigue?

#54

Post by cxromos »

true in my case. when i get into the zone while coding, i can go on and on. while llm can help, there's a cognitive mismatch between coding directions to llm and reading the code when it comes to continuing coding. brain and the generated code aren't aligned. i prefer at the moment, after coding a feature, to see if it can be improved using llm. and it's of great help to write tests.

Re: Vibe coding creates fatigue?

#55

Post by crazygringo »

habinero wrote: post #43
crazygringo wrote: post #22

Earlier quoted context omitted.

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…

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

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.

Re: Vibe coding creates fatigue?

#57

Post by habinero »

Jeff_Brown wrote: post #8
zephyrthenoble wrote: post #4

I've felt this too as a person with ADHD, specifically difficulty processing information. Caveat: I don't vibe code much, partially because of the mental fatigue symptoms. I've found that if an LLM writes too much code, even if I specified what it should be doing, I still have to do a lot of validation myself that would have been done while writing the code by hand. This turns the process from "generative" (haha) to…

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.

Re: Vibe coding creates fatigue?

#58

Post by scuff3d »

A guy at work did a demo of an agent work flow for some higher ups (we have chatbots but haven't adopted agents yet). He raved about how after writing a several hundred line spec, being extremely specific about the technology to use, and figuring out where to put all the guardrails, he was able to get Claude to generate weeks worth of code. When all was said and done it was like 20k lines of code between implementation, tests, and helper tools. Along the way he acknowledged you have to keep a close eye on it, or it will generate functions that pass tests but don't actually do their jobs, tests that pass but don't test anything, and a bunch of other issues.

To people with little to no practical software experience, I can see why that seems incredible. Think of the savings! But to anyone who's worked in a legacy code base, even well written ones, should know the pain. This is worse. That legacy code base was at least written with intention, and is hopefully battle tested to some degree by the time you look at it. This is 20k lines of code written by an intern that you are now responsible for going through line by line, which is going to take at least as long as it would have to write yourself.

There are obvious wins from AI, and agents, but this type of development is a bad idea. Iteration loops need to be kept much smaller, and you should still be testing as you go like you would when writing everything yourself. Otherwise it's going to turn into an absolute nightmare fast.

Re: Vibe coding creates fatigue?

#59

Post by stuffn »

Zigurd wrote: 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 think the counter-point to that is what I experience.

I agree it can be energizing because you can offload the bullshit work to a robot. For example, build me a CRUD app with a bootstrap frontend. Highly useful stuff especially if this isn't your professional forte.

The problems come afterwards:

1. The bigger the base codebase generation the less likely you're going to find time or energy to refactor LLM slop into something maintainable. I've spent a lot of time tailoring prompts for this type of generation and still can't get the code to be as precise as something an engineer would write.

2. Using an unfamiliar language means you're relying entirely on the LLM to determine what is safe. Suppose you wish to generate a project in C++. An LLM will happily do it. But will it be up to a standard that is maintainable and safe? Probably not. The devil is in the mundane details you don't understand.

In the case of (2) it's likely more instructive to have the LLM make you do the leg work, and then it can suggest simple verifiable changes. In the case of (1) I think it's just an extension of the complexity of any project professional or not. It's often better to write it correct the first time than write it fast and loose and then find the time to fix it later.

Re: Vibe coding creates fatigue?

#60

Post by habinero »

colechristensen wrote: post #32
vidarh wrote: post #25

Earlier quoted context omitted.

Really, this. You still need to check its work, but it is also pretty good at checking its work if told to look at specific things. Make it stop. Tell it to review whether the code is cohesive. Tell it to review it for security issues. Tell it to review it for common problems you've seen in just your codebase . Tell it to write a todo list for everything it finds, and tell it fix it. And only review the code once it'…

Tell it to grade its work in various categories and that you'll only accept B+ or greater work. Focusing on how good it's doing is an important distinction.

It's very funny that I can't tell if this is sarcasm or not. "Just tell it to do better."
Post reply on HN