I know when you're vibe coding • Hacker News Board

Re: I know when you're vibe coding

#41

Post by _def » Thu, Jul 31, 2025, 7:01 AM UTC

buserror wrote: post #32

I personally treat the LLM as a very junior programmer. He's willing to work, will take instructions, but his knowledge of the codebase, and patterns we use is lacking strongly. So it needs a LOT of handholding, very clear instructions, description of potential pitfalls, and smaller, scoped tasks, and reviewed carefully to catch any straying off pattern. Also, I make it work the same way I do: I first come up with th…

I agree. Brings me to the question though, how to deal with team members that are less experienced and use LLMs. Code review needs much more work then to teach these principles. And most of the time people won't bother to do that and just rubber stamp the working solution.

Re: I know when you're vibe coding

#42

Post by imiric » Thu, Jul 31, 2025, 7:04 AM UTC

> I want people to care about quality, I want them to care about consistency, I want them to care about the long-term effects of their work.

Yeah, that's not happening.

LLMs enable masses of non-technical people to create and publish software. They enable scammers and grifters who previously would've used a web site builder to also publish native and mobile apps, all in a fraction of the time and effort previously required. They enable experienced software developers to cut corners and automate parts of the job they never enjoyed to begin with. It's remarkable to me that many people who have been working in this industry for years don't enjoy the process of creating software, and find many tasks to be a "chore".

A small part of this group can't identify quality even if they cared about it. The rest simply doesn't care, and never will. Their priorities are to produce something that works on the surface with the least amount of effort, or, in the case of scammers, to produce whatever can bring them the most revenue as quickly and cheaply as possible. LLMs are a perfect fit for both use cases.

Software developers who care about quality are now even a smaller minority than before. They can also find LLMs to be useful, but not the magical productivity booster that everyone else is so excited about. If anything their work has become more difficult, since they now need to review the mountains of code thrown at them. Producing thousands of lines of code is easy. Ensuring it's high quality is much more difficult.

Re: I know when you're vibe coding

#43

Post by tayo42 » Thu, Jul 31, 2025, 7:06 AM UTC

anshumankmr wrote: post #17

wldlyinaccurate wrote: post #13

Earlier quoted context omitted.

I think the parent comment means "commits" in the sense of the actual changeset; not just the message.

That is also problematic, cause a git diff will probably require an exponential gain in context length AND also the ability for the LLM to use said context effectively. That being said, a context length problem could be potentially be solved but it will take a bit of time, I think Llama4 had 10M context length (not sure if anyone tried prompting it with that much data to see how effective it really is)

Do all of the diffs need to be included? Can't you include like a summarized version of a few changes?

Like I don't memorize the last 20 commits, but I know generally the direction things are going by reading those commits at some point

Re: I know when you're vibe coding

#44

Post by otabdeveloper4 » Thu, Jul 31, 2025, 7:11 AM UTC

atleastoptimal wrote: post #28

otabdeveloper4 wrote: post #24

Earlier quoted context omitted.

No they haven't. The hallucinate exactly as much as they did five years ago.

Absolutely untrue. Claiming GPT-3 hallucinates as much as o3 over the same token horizon on the same prompts is a silly notion and easily disproven by the dozens of benchmarks. You can code a complete web-app with models now, something far beyond the means of models so long ago.

> caveats and weasel words

> "benchmarks"

Stop drinking the coolaid and making excuses for LLM limitations, and learn to use the tools properly given their limits instead.

Re: I know when you're vibe coding

#45

Post by otabdeveloper4 » Thu, Jul 31, 2025, 7:12 AM UTC

antihero wrote: post #35

otabdeveloper4 wrote: post #24

Earlier quoted context omitted.

No they haven't. The hallucinate exactly as much as they did five years ago.

They really don’t though.

Larger context lengths are awesome, but they don't fundamentally change the failure modes of LLMs.

Re: I know when you're vibe coding

#46

Post by dkdbejwi383 » Thu, Jul 31, 2025, 7:18 AM UTC

arduanika wrote: post #15

subarctic wrote: post #7

Setting up a linter, formatter and having a lot of strict type checking are really helpful when using an llm to generate code, just like they are when you start receiving contributions from people who don't know or don't agree with the style rules that you implicitly follow. As are tests. Basically anything automated that helps ensure the right style and behaviour of your code becomes very useful with coding agents a…

I believe you that these tools help a lot, but they would not prevent ~any of the examples listed in the article (under "The smell of vibe coding").

With cursor at least it recognises linter errors and failing tests and attempts to correct its own problems, with varying levels of success

Re: I know when you're vibe coding

#47

Post by lintfordpickle » Thu, Jul 31, 2025, 7:20 AM UTC

lmm wrote: post #26

> Because no one would write an HTTP fetching implementation covering all edge cases when we have a data fetching library in the project that already does that. > No one would implement a bunch of utility functions that we already have in a different module. > No one would change a global configuration when there’s a mechanism to do it on a module level. > No one would write a class when we’re using a functional appr…

>> No one would implement a bunch of utility functions that we already have in a different module.

to be fair on this one, and while I don't flat out disagree, lots of people reinvent utility functions simply because they don't know they exist elsewhere, especially on huge code bases. This seems to get mostly rectified within the PRs, when a senior dev comments on it - the problem then is, you've only increased the number of people who now know by 1.

Re: I know when you're vibe coding

#48

Post by merelysounds » Thu, Jul 31, 2025, 7:21 AM UTC

lmm wrote: post #26

> Because no one would write an HTTP fetching implementation covering all edge cases when we have a data fetching library in the project that already does that. > No one would implement a bunch of utility functions that we already have in a different module. > No one would change a global configuration when there’s a mechanism to do it on a module level. > No one would write a class when we’re using a functional appr…

I guess these things occur in workplaces that prioritize speed over maintainability anyway.

Re: I know when you're vibe coding

#49

Post by pulse7 » Thu, Jul 31, 2025, 7:26 AM UTC

buserror wrote: post #32

I personally treat the LLM as a very junior programmer. He's willing to work, will take instructions, but his knowledge of the codebase, and patterns we use is lacking strongly. So it needs a LOT of handholding, very clear instructions, description of potential pitfalls, and smaller, scoped tasks, and reviewed carefully to catch any straying off pattern. Also, I make it work the same way I do: I first come up with th…

The difference between LLM and a very junior programmer: junior programmer will learn and change, LLM won't change! The more instructions you put in the prompt, the more will be forgotten and the more it will bounce back to the "general world-wide average". And on next prompt you must start all over again... Not so with junior programmers ...

Re: I know when you're vibe coding

#50

Post by agile-gift0262 » Thu, Jul 31, 2025, 7:29 AM UTC

I don't think that it's people no caring. I think many (most?) of us are biased to accept what we already have that's working. I noticed that of myself when I tried programming with an LLM "agent". After all the fuzzing around, many iterations of novels I had to write as many prompts, once the LLM produced something that worked, I had to fight with my instinct of just pushing that for review.

I also noticed that the time I had to spend on reviews from some of my colleagues increased by 9 times (time tracked). So I don't know how much faster they are being at producing that code, but I think it's taking longer overall to get that ticket closed.