Live data from Hacker News

I know when you're vibe coding

alexkondov.com

131–140 of 178 posts

Re: I know when you're vibe coding

#131

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 :)

Is that a bad thing? What do we call this?

Re: I know when you're vibe coding

#132
post #95

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…

Code that demands to pay off its dept isn't non-working code, it's rather code that exceeds one's ability to maintain it properly (your mention of "unreadability" included). Whether a PR introduces debt isn't always known and often times has to be discovered later on, depending on how fast its maintainers fluctuate and the ecosystem advances.

That said, tech debt isn't paid by developers individually, it's paid by organizations in developers time. Only in rare cases can you make a deliberate decision for it, as it grows organically within any project. For example, most python2 code today that used niche libraries with outdated docs that have been taken offline in the meantime has to be considered expensive tech debt nowadays.

Re: I know when you're vibe coding

#133
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…

Not only do people do these things, they put their work on github. Which is where the LLM learns to do it!

Re: I know when you're vibe coding

#134
post #79
post #69

Earlier quoted context omitted.

> They aren't useless. Otherwise, ChatGPT would have died a long time back Isn’t the entire industry being fuelled by orders of magnitude more VC funding than revenue?

Isn't that an argument against the sustainability of the LLM business model rather than their usefulness? People use them because they are useful, not because they are VC funded.

When the product is free, that put the barrier at ground level. I have more confidence in Kagi userbase, than OpenAI’s.

Re: I know when you're vibe coding

#135
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…

Identifying such almost-duplicate code is an open opportunity for LLMs.

Re: I know when you're vibe coding

#136
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 once inherited a project that had three separate classes for storing time, each with their own methods to convert between each other.

I can think of reasons for this (e.g. storing date/time as it was originally represented 100, 1000 years ago in a historical context vs storing live time for present-day time calculations vs storing non-timezone time for, say, operating hours relative to subject's location), so this statement alone doesn't show fault.

Re: I know when you're vibe coding

#137

Earlier quoted context omitted.

>No, LLMs will not get better. What makes you so sure of this? They've been getting better like clockwork every few months for the past 5 years.

I don't claim that they won't get better, but they certainly haven't gotten better. From the original release of ChatGPT to now, they still suck in the same exact ways.

I don't think they have gotten better either (at least in the past 1 year), because I remember how much better ChatGPT or even Claude used to be before. Perhaps they are nerfed now for commercial use, who knows.

Re: I know when you're vibe coding

#138
post #69

Earlier quoted context omitted.

> They aren't useless. Otherwise, ChatGPT would have died a long time back Isn’t the entire industry being fuelled by orders of magnitude more VC funding than revenue?

>Isn’t the entire industry being fuelled by orders of magnitude more VC funding than revenue? Because people want to use it, right? And it is a matter of time before they start limiting the ChatGPT "free" or "logged out" accounts, I feel. In the consumer AI chat apps, it is still the dominant brand, at least in my anecdotal experience, and they will basically make the Plus version the one version of the app to defini…

I think they are already limiting / nerfing "free" vs "logged out" vs "paid" vs "non-commercial".

Re: I know when you're vibe coding

#139
post #40
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-…

We have used the term "agent" in AI for some time.

> The main unifying theme is the idea of an intelligent agent. We define AI as the study of agents that receive percepts from the environment and perform actions.

This is from Artificial Intelligence: A Modern Approach by Stuart J. Russell and Peter Norvig.

Re: I know when you're vibe coding

#140
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…

My entire (decades) career I worked primarily in small start up teams, and even when people didn't see eye to eye, they always maintained these kinds of basic practices. I think a lot of disagreement on these expectations is rooted in the size and "tight-knit"ness of your team.
Post reply on HN