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

111–120 of 178 posts

Re: I know when you're vibe coding

#111

Post by jononor »

apabepa wrote: post #109
godelski wrote: post #71

Earlier quoted context omitted.

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

There is a hack for that: write the comments before and/or as you write the code. When things are still unclear, weird. Of course do a final pass on them to ensure that they are correct and useful in the end. This is one example of document as-you-go, instead of doing it after "the work" is done. I find it generally leads to better outcomes. Doing documenting only at the end is in many ways the worst way to do it.

Re: I know when you're vibe coding

#112

Post by darkwater »

lbriner wrote: post #95
godelski wrote: post #74

Earlier quoted context omitted.

I think you're missing the author's thesis > Is speed the greatest virtue? If speed is the greatest virtue then yeah, all that stuff will happen. But if it isn't, then that stuff will happen at a much lower frequency. Because, all the stuff mentioned is just tech debt. Debt doesn't go away, it accrues interest. If speed is all that matters then you need exponential output, as your output needs to offset the debt. If…

I think you are misusing the phrase "tech debt" like many people do. Not everything that is not perfect is Tech Debt, some of it is just pragmatism. If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing, might never need any maintenance attention and will never be paid down before the codebase is replaced in 10 years time. Same with people writing code in…

> Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again.

Thing that many people do without even realizing they are incurring in tech debt. This kind of developers are the one that will just generate more tech debt with an LLM in their hands (at least now).

Re: I know when you're vibe coding

#113

Post by freilanzer »

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

The learning is in the model versions.

Re: I know when you're vibe coding

#114

Post by jeanloolz »

otikik wrote: post #107
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 intern…

That hunting dog analogy is epic and perfectly matches my experience.

Re: I know when you're vibe coding

#115

Post by CompoundEyes »

I’ve been working with Claude Code subagents for the first time this week and I have one that purposefully goes through code analyzing it for human maintainability, over-architecting, too many clever one liner tricks, meaningful variable names, ease of debugging, cognitive load, class sizes and so on. It had some interesting analysis about a few of the classes being heavy in requiring domain knowledge and suggested documentation / onboarding for that particular area. I’m interested to see where this goes. The code will be in production this aspect is important to me. Gold plating is in reach with LLMs why not?

Re: I know when you're vibe coding

#116

Post by QuantumNoodle »

raggi wrote: post #9

This is a story of a bad LLM user (in this context), which is perhaps implied by “vibe coding” but folks should be aiming higher. Making people review slop is lazy, rude and disrespectful.

You just claimed reviewing slop is not pleasant (and I agree). So the LLM user has to review the slop, and then the team has to review the iterated-until-not-slop final commit(s). Where in this scenario does anyone _write_ code - the most enjoyable part of the job? Job satisfaction is going to plummet (mine has) and the next generation of software engs is going to be incompetent. Just look at the generation that grew up with ipads/phones. Many of them do not know what a "file" is in college (source, colleagues who are professors).

Re: I know when you're vibe coding

#117

Post by oc1 »

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?

A whole new generation will discover the term net-negative programmer again ;)

Re: I know when you're vibe coding

#118

Post by mns »

> But people want a good cup of coffee, even if they have to wait a little bit for it.

I think the author is vastly underestimating what the majority of people actually want. It took me a lot to get this, but for many people, quick/cheap will always trump quality.

Re: I know when you're vibe coding

#119

Post by 0_____0 »

mns wrote: post #118

> But people want a good cup of coffee, even if they have to wait a little bit for it. I think the author is vastly underestimating what the majority of people actually want. It took me a lot to get this, but for many people, quick/cheap will always trump quality.

the ubiquity of keurig machines really does speak to this.

Re: I know when you're vibe coding

#120

Post by shepherdjerred »

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

Post reply on HN