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

101–110 of 178 posts

Re: I know when you're vibe coding

#101

Post by philipp-gayret »

ceuk wrote: post #85
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…

Fair enough. For me compacting conversation always feels a bit weird; I have no way to tell what it effectively deleted from the context but I (very) regularly have it re-read and update CLAUDE.md as part of the process or after "discussions" with the LLM so I would guess that might be why it follows patterns in it a bit stricter for me than for most. It would be nice if the tool took care of that automatically.

Re: I know when you're vibe coding

#102

Post by aspenmayer »

ffsm8 wrote: post #96
aspenmayer wrote: post #86

Earlier quoted context omitted.

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

The other thing about documentation is that it inevitably goes stale. So the question becomes: is no documentation better or documentation that can be - potentially - entirely out of date, misleading or subtly wrong, because eg they documented the desired behavior vs actual behavior (or vice versa). I'm generally pro documentation, I'm just fully aware that internal documentation the devs need to write themselves and…

I think there’s a natural tendency to want to document the process for those who have the work assigned to them, and some folks will self-assign it because they see the value.

Knowledge transfer through technical writing doesn’t always manifest itself if it isn’t part of the work process at the time you have that in your mental context. It’s hard to have that context to write the docs if you’re context switching from working on something else or not involved at that level, so it’s hard to just drop in to add docs if there isn’t some framework for writing ad hoc docs for someone to fix up later.

I don’t have experience at traditional employers though so I can’t speak authoritatively here. I’m used to contracts and individual folks and small business. Having human readable documents is important to me because I’m used to folks having things explained on their level, which requires teaching only what they need and want to know to get their work done. Some folks don’t even know what they need when they ask me for help, so that’s its own process of discovery and of documentation. I’m used to having to go to them where they are and where the issue is, so there was no typical day at the office or out of it. Whatever couldn’t fit through the door, I had to go to myself. I’ve had to preserve evidence of potential criminal wrongdoing and document our process. It taught me to keep notes and to write as I work.

I think most places do have some kind of process for doing this, and I suspect the friction in doing the thing is part of the issue, and the fact that it’s difficult thankless work that doesn’t show up on most tracked metrics is part of the issue.

If docs were mandated they would get done. If someone’s job was to make sure they were done well, that would help. I guess folks could step up and try to make that happen and that might be what it takes to make that happen.

Re: I know when you're vibe coding

#103

Post by anshumankmr »

tayo42 wrote: post #43
anshumankmr wrote: post #17

Earlier quoted context omitted.

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

If a commit was done a year or so back, then 20 commits would probably prove insufficient, and if say a team member is supposed to use some existing helper method already present in the codebase, which is easier to tell a person to use instead of an LLM writing another function to perform that same operation which is inefficient.

And even if you juiced up a context length of an LLM to astronomical numbers AND made it somehow better at parsing and understanding its context, it will not always repeat said capabilities in other codebases (see for example o3 supposedly being the top of most benchmarks but it will still fumble a simple variation mother-is-a-surgeon puzzle).

I am not saying its impossible for a company to figure this out, but it will be incredibly hard.

Re: I know when you're vibe coding

#105

Post by avhception »

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…

Sometimes I feel like watching people dig a hole until it starts filling with groundwater. They then start bailing the water out with buckets. They're very busy doing that, so the actual digging work slowly grinds to almost zero. I stand at the edge of the pit, trying to talk to them about electrical pumps and drainage solutions and get yelled at: "I don't have time for your nonsense, can't you see I'm busy bailing water here!?"

Re: I know when you're vibe coding

#106

Post by neurostimulant »

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…

> Also, I make it work the same way I do: I first come up with the data model until it "works" in my head, before writing any "code" to deal with it. Again, clear instructions.

But then it's not vibe coding anymore :)

Re: I know when you're vibe coding

#107

Post by otikik »

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 think "junior programmer" (or "copilot") oversells the AI in some cases and undersells it in others. It does forget things that a regular person wouldn't, and it does very basic coding mistakes sometimes. At the same time it's better than me at some things (getting off-by-one errors when dealing with algorithms that work on arrays). It also has encyclopedic knowledge about basically anything out there on the internet. Red-black Trees? Sure thing. ECS systems for game programming? No problemo, here are the most used libraries.

I have ended up thinking about it as a "hunting dog". It can do some things better than me. It can get into tiny crevasses and bushes. It doesn't mind getting wet or dirty. It will smell the prey better than me.

But I should make the kill. And I should be leading the hunt, not the other way around.

Re: I know when you're vibe coding

#108

Post by palata »

woolion wrote: post #72
palata wrote: post #27

A risk with vibe coding is that it may make a good developer slightly faster, but it will make bad developers waaaay faster. Resulting in more bad code being produced. The question then is: do the bad developers improve by vibe coding, or are they stuck in a local optimum?

So, I was wondering when I would see that... from my experience, I would say it also makes mediocre developers bad ones very fast. The reason being a false sense of confidence, but mostly it's because of the sheer volume that is produced. If we want to be more precise, I think the main issue is that the AI-generated code lacks a clear architecture. It has no (or very little) respect for overall information flow, and…

To echo the article, I don't want to know it was written with an AI. Just like I don't want to see that it was obviously copy-pasted from StackOverflow.

The developer can do whatever they want, but at the end, what I review is their code. If that code is bad, it is the developer's responsibility. No amount of "the agent did it" matters to me. If the code written by the agent requires heavy refactoring, then the developer has to do it, period.

Re: I know when you're vibe coding

#109

Post by apabepa »

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…

For me it is difficult to give good code comments just when code is written. The problem is solved, the tricky parts if any are internalized. I dont mind reading code so just documenting what the code is doing does seldom bring value. The important thing is to document why the code does things in an non obvious way and unintuitive scenarios and edge cases etc.

When revisiting code is the best time to add comments because then you will find out what is tricky and what is obvious.

Code reviews are also good for adding code comments. If the people reviewing are doing their job and are actually trying to understand the code then it is a good time to get feedback where to add comments.

Re: I know when you're vibe coding

#110

Post by MoreQARespect »

ffsm8 wrote: post #96
aspenmayer wrote: post #86

Earlier quoted context omitted.

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

The other thing about documentation is that it inevitably goes stale. So the question becomes: is no documentation better or documentation that can be - potentially - entirely out of date, misleading or subtly wrong, because eg they documented the desired behavior vs actual behavior (or vice versa). I'm generally pro documentation, I'm just fully aware that internal documentation the devs need to write themselves and…

>The other thing about documentation is that it inevitably goes stale.

Not if you generate reference docs from code and how-to docs from tests.

Post reply on HN