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

I know when you're vibe coding

alexkondov.com

Post reply on HN
Print view View original

141–150 of 178 posts

Re: I know when you're vibe coding

#141

Post by noodletheworld »

0x_rs wrote: post #36
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…

This. Reinventing the wheel at every opportunity, forgetting about or ignoring the expected way to do something, mixing patterns, you name it. The author may call it "vibe coding", that's fine but it has little to do with LLMs. The tool has the same amount of care anyone rushing to get something done, or that hasn't build the project themselves, or maybe doesn't have enough experience would. I can only assume it's a…

> The author may call it "vibe coding", that's fine but it has little to do with LLMs.

Humm.

Maybe if we say that this is not an issue from vibe coding it wont be?

Maybe if we pretend that maybe a naive junior would make these mistakes (true) we should be happy to accept them from senior developers (false)?

LLMs are extraordinarily bad at doing these things.

I’ve seen it.

You've seen it.

The OP has seen it.

You’re in a rush so you wrote some classes in a code base in a language which supports classes but has no classes in it?

Really? Did that get past code review before? Did you deliberately put up a code review that you knew would be rejected and take longer to merge as a result because you were in a hurry?

Of course not.

You did the bare minimum that still met the basic quality standards expected of you.

I get it. We all get it. When youre in a rush you cut corners to move faster.

…but thats not what the OP is talking about, and its not what I see either:

Its people putting up AI slop and not caring at all what the content was.

Just a quick check it compiled and the tests pass if youre lucky.

Too lazy even put a “dont use classes” in their cursor rules file.

Come on. The OP isnt saying dont use AI.

Theyre saying care, just a little bit about your craft ffs.

Re: I know when you're vibe coding

#142

Post by sshine »

shepherdjerred wrote: post #120
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…

You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves

It seems like people who use AI for coding need to reinvent a lot of the same basic principles of software engineering before they gradually propagate into the mainstream agentic frameworks.

Coding agents come with a lot of good behavior built in.

Like "planning mode" where they create a strong picture of what's to be made before touching files. This has honestly improved my workflow at programming from wanting to jump into prototyping before I even have a clear idea, to being very spec-oriented: Of course there needs to be a plan, especially when it will be drafted for me in seconds.

But the amount of preventable dumb things coding agents will do that need to be explicitly stated and meticulously repeated in their contexts reveals how simply training on the world's knowledge does not capture senior software engineer workflows entirely, and captures a lot of human averageness that is frowned upon.

Re: I know when you're vibe coding

#143

Post by ok123456 »

> No one would write a class when we’re using a functional approach everywhere.

They're not orthogonal. Closures and classes are dual forms of the same thing. There are cases where one is better than the other for a given problem.

Re: I know when you're vibe coding

#144

Post by cardanome »

shepherdjerred wrote: post #120
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…

You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves

Do those rules really work? I have added the rule to not not add comments and I still have to constantly remind the model to not add comments despite of it.

Re: I know when you're vibe coding

#146

Post by perrygeo »

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've seen developers add a second ORM library as a dependency, not because the first didn't do the job but because they just "forgot" about the first one and wanted to use the new hotness. Developers, just like LLMs, have biases that taint the solution space.

The key is that we all have an intuitive sense that this behavior is wrong - building a project means working within the established patterns of that project, or at least being aware of them! Going off half-cocked and building a solution without considering the context is extremely bad form.

In the case of human developers, this can be fixed on the code review level, encouraging a culture of reading not just writing code. Without proper guardrails, they can create code that's dissonant with the existing project.

In the case of LLMs, the only recourse is context engineering. You need to make everything explicit. You need to teach the LLM all the patterns that matter. Their responses will always be probabilistic token salad, by definition. Without proper guardrails, it will create code that's dissonant with the existing project.

Either way, it's a question of subjective values. The patterns that are important need to be articulated, otherwise you get token salad randomly sampling the solution space.

Re: I know when you're vibe coding

#147

Post by eddd-ddde »

perrygeo wrote: post #146
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've seen developers add a second ORM library as a dependency, not because the first didn't do the job but because they just "forgot" about the first one and wanted to use the new hotness. Developers, just like LLMs, have biases that taint the solution space. The key is that we all have an intuitive sense that this behavior is wrong - building a project means working within the established patterns of that project, o…

Heavy agree on your first paragraph. You spend one evening removing one unnecessary dependency only to see 5 more were added by next Monday.

I think soon enough we'll have a decent LLM that's capable of reviewing ALL changes to ensure they follow the "culture" we expect to see.

Re: I know when you're vibe coding

#148

Post by ewoodrich »

cardanome wrote: post #144
shepherdjerred wrote: post #120

Earlier quoted context omitted.

You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves

Do those rules really work? I have added the rule to not not add comments and I still have to constantly remind the model to not add comments despite of it.

I have a .roorules file with only about four instructions, one of which is an (unintentional) binary canary of very simple rule following at the end of a task. And another rule that’s a fuzzier canary as it is not always applicable but usually occurs a few times in a task so helps me confirm the rules are being parsed at all in case Roo has a bug.

All the models I’ve used (yes, including all the biggest, newest, smartest ones) follow the binary rule about 75% of the time at the very most. Usually closer to 50% on average, with odds significantly decreasing the longer the context increases as it occurs at the end of a task but other than that seems to have no predictable pattern.

The fuzzier rule is slightly better, I’m guessing because it applies earlier in the context window, at around 80% compliance and uses lots of caps and emphasis. This one has a more predictable failure mode of the ratio of reading code vs thinking/troubleshooting/time the model is “in its own head”. When mostly reading code or my instructions compliance is very high, when doing extended troubleshooting or anything that starts to veer away from the project itself into training data it is much lower.

So it’s hit and miss and does help but definitely not something I’d rely on as a hard guardrail, like not executing commands, which Roo has a non-LLM tool config to control. So over time I hope agentic runners add more detetministic config outside the model itself, because instructions still aren't as reliable as they should be and don't seem to be getting substantially better in real use.

Re: I know when you're vibe coding

#150

Post by x3n0ph3n3 »

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 have never seen a junior engineer make up API calls or arguments.
Post reply on HN