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

81–90 of 178 posts

Re: I know when you're vibe coding

#81

Post by staunton »

JoRyGu wrote: post #65
nosianu wrote: post #61

Earlier quoted context omitted.

> most of these things can happen for poorly documented large codebase. Documentation does not help beyond a point. Nobody reads the documentation repeatedly, which would be needed. When you keep working on a project, and you need a new function, you would need to check or remember every single time that such a function already exists or might exist somewhere. You may have found it when you read the docs months ago,…

I'm sorry, but this is selling good engineers very short. If you didn't nest your utils folder 8 folders deep, it seems pretty obvious that one should check the utils folder before writing another utility function. This stuff should also be caught in code reviews. Maybe the new guy didn't know that util function existed, but surely you did when you reviewed their MR? Obviously mistakes like that can happen, but I've…

> should also be caught in code reviews

Assuming they even have code reviews - in your experience, in a situation where the person writing the code didn't check if it already exists, the reviewer will check that and then tell them to delete their already finished implementation and use that existing thing?

Re: I know when you're vibe coding

#82

Post by grim_io »

These problems read like they are a product of outdated ai assisted practices.

I can imagine stuff like this happening when copy pasting from/to ai online chat interfaces, but not in a properly initialized project.

The agent will read all the crappy, partly outdated documentation all over the project and also take the reality of the project into consideration.

It's probably a good idea to also let it rewrite the programmer facing docs. Who else is going to maintain that realistically?

Re: I know when you're vibe coding

#83

Post by wheybags »

JoRyGu wrote: post #65
nosianu wrote: post #61

Earlier quoted context omitted.

> most of these things can happen for poorly documented large codebase. Documentation does not help beyond a point. Nobody reads the documentation repeatedly, which would be needed. When you keep working on a project, and you need a new function, you would need to check or remember every single time that such a function already exists or might exist somewhere. You may have found it when you read the docs months ago,…

I'm sorry, but this is selling good engineers very short. If you didn't nest your utils folder 8 folders deep, it seems pretty obvious that one should check the utils folder before writing another utility function. This stuff should also be caught in code reviews. Maybe the new guy didn't know that util function existed, but surely you did when you reviewed their MR? Obviously mistakes like that can happen, but I've…

I wouldn't say you should explicitly check, necessarily. More like, you go to implement the widget and when you open the appropriate file to get started, it's already there.

Re: I know when you're vibe coding

#84

Post by bubblyworld »

Personally I think caring is the resource in extremely short supply here and I don't think vibe coding has much to do with it causally. AIs are just tools - basically all of the issues the author has raised are present with human juniors too, and can be resolved quite easily with a little more guidance/interaction in both cases. I don't think AIs are universally causing people to care less about quality output, although that may be true for some people who didn't care much in the first place.

The common counter-argument here is that you miss out on training juniors, which is true, but it's not always an option (we are really struggling to hire at my startup, for instance, so I'm experimenting with AI to work on tasks I would otherwise give to a junior as a stop-gap).

Another aspect to consider is that what we used to consider important for software quality may change a lot in light of AI tooling. These things aren't absolutes. I think this is already happening, but it's early days, so I'm not sure what will play out here.

Re: I know when you're vibe coding

#85

Post by ceuk »

philipp-gayret wrote: post #67

All major AI assistants already come with ways to not have any of these issues. Claude Code has /init, Cursor comes with /Generate Cursor Rules, and so on. It's not even context engineering: There are out of the box tools you can use not to have this happen. And even if they do happen: you can make them never happen again, with these same tools, for your entire organization - if you had invested the time to know how…

CC very regularly ignores very explicit stuff in CLAUDE.md for me, and I know I'm not the only one. The cycle of compacting/starting new conversations feels like a sisyphean spiral of the same undesirable behaviour and I've yet to find a satisfactory solution despite a lot of effort to that end.

I don't think it's fair to dismiss this article as a superficial anti-ai knee jerk. The solutions you describe are far from perfect

Re: I know when you're vibe coding

#86

Post by aspenmayer »

godelski wrote: post #71
elashri wrote: post #57

Earlier quoted context omitted.

To be honest, most of these things can happen for poorly documented large codebase. I work on academic research project that have docs that tells you basically that the code is self documented. And give one or two pages about configuring CMake and build the project and another page on how to benchmark the throughout. But the internal quirks and the expected convention you will need to figure it on your own. New peopl…

> docs that tells you basically that the code is self documented Anytime someone tells me the code is self-documented I hear "there's no documentation." The most common programmer's footgun I don't have time to document | ^ v | Spends lots of time trying to understand code We constantly say we don't have time to document the code. So instead we spend all our time reading code and trying to figure out what it does, to…

> why it is also weird that we'd rather have pay raises through switching companies than through internal raises

How does the saying go, something like “show me the incentives and I’ll show you the outcome?”

> That's like trying to fix the damage from the footgun with a footgun.

If you value your money/time/etc, wouldn't the best way to fix the damage from footguns be by preventing the damage to you in the first place by not being there if/when it goes off?

I think your point is well put, I’m just trying to follow your reasoning to a conclusion logical to me, though I don't know if mine is the most helpful framing. I didn’t pick the footgun metaphor, but it is a somewhat useful model here for explaining why people may act the way they do.

Re: I know when you're vibe coding

#87

Post by irb »

pulse7 wrote: post #49
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 ...

This is the only thing that makes junior programmers worthwhile. Any task will take longer and probably be more work for me if I give it to a junior programmer vs just doing it myself. The reason I give tasks to junior programmers is so that they eventually become less junior, and can actually be useful.

Having a junior programmer assistant who never gets better sounds like hell.

Re: I know when you're vibe coding

#88

Post by raduan »

I think people should care more about the adherence of code to a specific spec.

And by definition of this, you should care about the spec.

How code looks like, doesn't matter that much, as long it adheres to the spec.

Re: I know when you're vibe coding

#89

Post by uyzstvqs »

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 personally see the LLM as a (considerably better) alternative to StackOverflow. I ask it questions, and it immediately has answers for my exact questions. Most often I then write my own code based on the answer. Sometimes I have the LLM generate functions that I can use in my code, but I always make sure to fully understand how it works before copy-pasting it into my codebase.

But sometimes I wonder if pushing a +400.000 lines PR to an open-source project in a programming language that I don't understand is more beneficial to my career than being honest and quality-driven. In the same way that YoE takes precedence over actual skill in hiring at most companies.

Re: I know when you're vibe coding

#90

Post by Sebalf »

frizlab wrote: post #40
nojs wrote: post #31

In my experience pretty much all of these issues stem from a combination of short context windows and suboptimal “context engineering”. If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. The biggest challenge is how to construct the right context for each request, and keep it clean until the feature is finished. I expect we will see a lot of improv…

> If the agent has a clean, relevant context explaining what global functions are available it tends to use them properly. STOP! The agent does not exist. There are no agents; only mathematical functions that have an input and produce an output. Stop anthropomorphizing LLMs, they are not human, they don’t do anything. It might seem like it does not matter; my take is it’s primordial. Humans are not machines and vice-…

Frankly, this take is so reductionistic that it's useless. You can substitute "mathematical functions" with "biochemistry" and apply the exact same argument to human beings.

What I'd like is for people to stop pretending we have any idea what the hidden layer of an LLM is actually doing. We do not know at all. Yes, words like "statistics" and "mathematical functions" can accurately describe the underlying architecture of LLMs, but the actual mechanism of knowledge processing is not understood at all. It is exactly analogous to how we understand quite a lot about how neurons function at the cellular level (but far from everything, seeing as how complicated and opaque nature tends to be), but that we have no idea whatsoever what exactly is happening when a human being is doing a cognitive task.

It is a fallacy to confuse the surface level understanding of how a transformer functions, to the unknown mechanisms that LLMs employ.

Post reply on HN