Live data from Hacker News

Vibe coding creates fatigue?

tabulamag.com

71–80 of 174 posts

Re: Vibe coding creates fatigue?

#71
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…

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…

> It sounds like you've never worked a job where you aren't just supporting 1 product that you built yourslef

In my 40 years of writing code, I’ve worked on many different code bases and in many different organisations. And I never changed a line of code, deleted code, or added more code unless I could run it in my head and ‘know’ (to the extent that it’s possible) what it will do and how it will interact with the rest of the project. That’s the job.

I’m not against using AI. I use it myself, but if you don’t understand the scope fully, then you can’t possibly validate what the AI is spitting out, you can only hope that it has not fucked up.

Even using AI to write tests will fall short if you can’t tell if the tests are good enough.

For now we still need to be experts. The day we don’t need experts the LLMs should start writing in machine code, not human readable languages

> I do not need to understand the full stack.

Nobody said that. It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important.

Not understanding the thing you’re changing isn’t pragmatism.

Re: Vibe coding creates fatigue?

#72
post #28

Earlier quoted context omitted.

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

Maybe read the original definition: https://x.com/karpathy/status/1886192184808149383 Or here: https://en.wikipedia.org/wiki/Vibe_coding Not looking at the code at all by default is essential to the term.

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.

Re: Vibe coding creates fatigue?

#73
post #52
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…

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

> What makes a code worthy of trust is passing tests

(Sorry, but you set yourself up for this one, my apologies.)

Oh, so this post describes "worthy code", okay then.

https://news.ycombinator.com/item?id=18442941

Tests are not a panacea. They don't care about anything other than what you test. If you don't have code testing maintainability and readability, only that it "works", you end up like the product in that post.

Ultimate example: Biology (and everything related, like physiology, anatomy), where the test is similarly limited to "does it produce children that can survive". It is a huuuuuge mess, and trying to change any one thing always messes up things elsewhere in unexpected and hard or impossible to solve ways. It's genius, it works, it sells - and trying to deliberately change anything is a huge PITA because everything is interconnected and there is no clean design anywhere. You manage to change some single gene to change some very minor behavior, suddenly the ear shape changes and fur color and eye sight and digestion and disease resistance, stuff like that.

Re: Vibe coding creates fatigue?

#74
I find vibe coding similar to visiting a country where I don't know the local language very well.

Usually that requires saying something, seeing if the other person understands what I'm saying, and occasionally repeating myself in a different way.

It can be real tiring when I'm with friends who only speak the other language so we're both using translator tools and basically repeating that loop up to 2-3 hours.

I've found the same situation with vibe coding. Especially when the model misunderstands what I want or starts going off on a tangent. sometimes it's easier to edit the original query or an earlier step in the flow and re-write it for a better result.

Re: Vibe coding creates fatigue?

#75
In my experience, it depends on the task. As a hobby, I develop personal projects (mostly web apps) where I'm not an expert in the relevant technology. In this case, LLM-assisted coding is empowering - and I don't think it's Dunning-Kruger, as I can understand the generated code, and it "feels" good enough given my 20+ years' experience in software engineering.

However, when it comes to my professional work on a mature, advanced project, I find it much easier to write the code myself than to provide a very precise specification without which the LLM wouldn't generate code of a sufficiently high quality.

Re: Vibe coding creates fatigue?

#76
post #58

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

Even asking it to do little tests, Claude 4.5 Sonnet Thinking still ends up writing tests that do nothing or don't do what it says will do. And it's always fucking cheery about it: "you're code is now production-ready!" and "this is an excellent idea!" and "all errors are now fixed! your code is production-ready!" and "I fixed the compiler issue, we're now production ready!" ...almost as if it's too eager to make its…

Yeah that aggressive sycophancy is incredibly annoying. Someone telling me I'm being a fucking idiot is more useful then "what a fantastic observation! You're so right" for the millionths time.

Even using it to spitball ideas can be a problem. I was using Claude to bounce ideas off of for a problem I was working on it, and it was dead set a specific solution involving a stack and some complex control logic was correct, when it reality it would have made the entire solution far more complicated. All I really needed was a sliding window into an array.

Re: Vibe coding creates fatigue?

#77
If you're automating code generation but not automating verification, there will be a mismatch.

Maybe the fatigue comes from that mismatch?

The classical vibe coder style is to just ignore verification. That's not a good approach as well.

I think this space has not matured yet. We have old tools (test, lint) and some unreliable tools (agent assisted reviews), but nothing to match the speed of generation yet.

I do it by creating ad-hoc deterministic verifiers. Sometimes they'll last just a couple of PRs. It's cheap to do them now. But also, there must be a better way.

Re: Vibe coding creates fatigue?

#78
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 the agent was doing, and when it seemed to go off the rails I would have to do a bunch of research to figure out how to steer it.

Now, none of that was bad, because I learned a lot, and I think it is a great way to familiarize oneself with a new stack, but if I want to move really fast, I still pick mostly familiar stuff.

Re: Vibe coding creates fatigue?

#79

Earlier quoted context omitted.

I've also seen the term. You've been permanently banned for 12 hours. Instead of temporarily suspended. Whatever happened to the word suspended for temporary and ban for permanent and places say permanent with an expiration date.

My favorite one of these is "electrocuted" meaning "to be killed by electricity". Nobody alive has ever been electrocuted, but you will meet people who claim to have been.

The modern definition includes "injured", so plenty of living people have been electrocuted.

Re: Vibe coding creates fatigue?

#80
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…

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 commonly forked template of this piece of code has this in its boilerplate? I don't know. Do you?

How can you make sure the code works in all situations if you aren't even familiar with the language, let alone the framework / API and protocol?

    * Do you know that in Java you have to do string.Equals instead of == for equality? 
    * Do you know in Python that you assigning a new value to a function default persists beyond the function? 
        * And in JavaScript it does not? 
    * Do you know that the C# && does not translate to VB.NET's And?
Post reply on HN