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

131–140 of 174 posts

Re: Vibe coding creates fatigue?

#131

Post by Kiro »

JohnMakin wrote: post #3

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…

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.

Re: Vibe coding creates fatigue?

#132

Post by observationist »

closewith wrote: post #121
lukan wrote: post #44

Earlier quoted context omitted.

"It was a non-trivial project, and I had to be paying attention to what the agent was doing" There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.

Vibe coding is the name for LLM assisted coding, whether you like it or not.

Not all LLM assisted coding is vibe coding. Vibe coding goes something like , throw it a prompt, then repeat "it works" or "it doesn't work" or "it works, but I want Feature XYZ, also" or repeated "ok, but make it better."

Vibe implies missing knowledge or experience - LLMs are a great equalizer, on the level of handguns or industrialization. Everyone can use them, some can use them well, and the value of using them well is enormous.

A real SWE is going to say "ok, now build a new function doing XYZ" and in their agents.md they'll have their entire project specs and baseline prompt framework, with things like "document in the specified standard, create the unit test, document how the test integrates with the existing features, create a followup note on any potential interference with existing functionality, and update the todo.md" and so forth, with all the specific instructions and structure and subtasks and boring project management most of us wouldn't even know to think of. Doing it right takes a lot of setup and understanding how software projects should be run, and using the LLMs to do all the work they excel at doing, and not having them do the work they suck at.

I only know the binary "that works" or not, for most things I've vibe coded. It'd be nice to have the breadth of knowledge and skills to do things right, but I also feel like it'd take a lot of the magic out of it too, lol.

Re: Vibe coding creates fatigue?

#133

Post by devnullbrain »

lukan wrote: post #49
iLoveOncall wrote: post #37

Earlier quoted context omitted.

Words don't have meaning in 2025. A negative but courteous remark is "slamming", a tweet is an "attack", etc. So yeah I'm not surprised that people conflate any use of AI with vibe-coding.

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

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.

Re: Vibe coding creates fatigue?

#134

Post by closewith »

Nashooo wrote: post #125
closewith wrote: post #121

Earlier quoted context omitted.

Vibe coding is the name for LLM assisted coding, whether you like it or not.

One means (used to mean?) actually checking the LLM's output one means keep trying until it outputs does what you want.

That's the original context of the Andrej Karpathy comment, but it's just synonymous with LLM assisted coding now.

Re: Vibe coding creates fatigue?

#135

Post by QuercusMax »

bigstrat2003 wrote: post #95
NitpickLawyer wrote: post #69

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.

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

Re: Vibe coding creates fatigue?

#136

Post by closewith »

observationist wrote: post #132
closewith wrote: post #121

Earlier quoted context omitted.

Vibe coding is the name for LLM assisted coding, whether you like it or not.

Not all LLM assisted coding is vibe coding. Vibe coding goes something like , throw it a prompt, then repeat "it works" or "it doesn't work" or "it works, but I want Feature XYZ, also" or repeated "ok, but make it better." Vibe implies missing knowledge or experience - LLMs are a great equalizer, on the level of handguns or industrialization. Everyone can use them, some can use them well, and the value of using them…

While that was the original intent when Andrej Karpathy coined the term, it's now simply synonymous with LLM assisted coding. Like many previously pejorative terms, it's now become ubiquitous and lost its original meaning.

Re: Vibe coding creates fatigue?

#137

Post by QuercusMax »

NitpickLawyer wrote: post #104
tinfoilhatter wrote: post #93

Earlier quoted context omitted.

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

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.

Re: Vibe coding creates fatigue?

#138

Post by [deleted] »

closewith wrote: post #121
lukan wrote: post #44

Earlier quoted context omitted.

"It was a non-trivial project, and I had to be paying attention to what the agent was doing" There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.

Vibe coding is the name for LLM assisted coding, whether you like it or not.

[deleted]

Re: Vibe coding creates fatigue?

#140

Post by colechristensen »

prmph wrote: post #90
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'…

So why can't the deterministic part of the agent program embed in all these checks?

It absolutely can, I'm building things to do this for me. Claude Code has hooks that are supposed to trigger upon certain states and so far they don't trigger reliably enough to be useful. What we need are the primitives to build code based development cycles where each step is executed by a model but the flow is dictated by code. Everything today relies too heavily on prompt engineering and with long context windows instruction following goes lax. I ask my model "What did you do wrong?" and it comes back clearly with "I didn't follow instructions" and then gives clear and detailed correct reasons about how it didn't follow instructions... but that's not supremely helpful because it still doesn't follow instructions afterwards.
Post reply on HN