I know when you're vibe coding • Hacker News Board

Re: I know when you're vibe coding

#11

Post by atleastoptimal » Thu, Jul 31, 2025, 5:55 AM UTC

voxl wrote: post #8

atleastoptimal wrote: post #4

This is all true. The best way to treat LLM's as they are now is one step above the abstraction offered by compiled languages over assembly. You can describe something in plain english, note its explicit requirements, inputs and outputs, and an LLM can effectively write the code as a translation of the logic you are specifying. Using LLM's, you are best served minimizing the entropy they have to deal with. The transf…

No, LLMs are not an "abstraction" like a compiler is. This is bullshit. LLMs are stochastic token generators. I have NEVER met someone in real life that has produced something I wouldn't throw in the trash using LLMs, and I have had the displeasure of eating cookies baked from an LLM recipe. No, LLMs will not get better. The singularity bullshit has been active since 2010s. LLMs have consumed the entire fucking Inter…

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

Re: I know when you're vibe coding

#12

Post by anshumankmr » Thu, Jul 31, 2025, 6:08 AM UTC

Zanfa wrote: post #10

LLMs would also need to use historic commits as context, rather than just the current state of the codebase in isolation. Most codebases I've worked with go through migrations from a legacy pattern A to a newer and better pattern B, used across different parts of the codebase. Rarely can these migrations be done in a single go, so both patterns tend to stick around for a while as old code is revisited. Like the HTTP…

That would assume a commit message is implemented correctly, and isn't like "Updated this file" or "Bugfix"

Re: I know when you're vibe coding

#13

Post by wldlyinaccurate » Thu, Jul 31, 2025, 6:10 AM UTC

anshumankmr wrote: post #12

Zanfa wrote: post #10

LLMs would also need to use historic commits as context, rather than just the current state of the codebase in isolation. Most codebases I've worked with go through migrations from a legacy pattern A to a newer and better pattern B, used across different parts of the codebase. Rarely can these migrations be done in a single go, so both patterns tend to stick around for a while as old code is revisited. Like the HTTP…

That would assume a commit message is implemented correctly, and isn't like "Updated this file" or "Bugfix"

I think the parent comment means "commits" in the sense of the actual changeset; not just the message.

Re: I know when you're vibe coding

#14

Post by occz » Thu, Jul 31, 2025, 6:13 AM UTC

I've noticed this as well.

I've also noticed that the effort to de-slop the shit-code is quite significant, and many times eats the productivity gains of having the LLM generate the code.

Re: I know when you're vibe coding

#15

Post by arduanika » Thu, Jul 31, 2025, 6:17 AM UTC

subarctic wrote: post #7

Setting up a linter, formatter and having a lot of strict type checking are really helpful when using an llm to generate code, just like they are when you start receiving contributions from people who don't know or don't agree with the style rules that you implicitly follow. As are tests. Basically anything automated that helps ensure the right style and behaviour of your code becomes very useful with coding agents a…

I believe you that these tools help a lot, but they would not prevent ~any of the examples listed in the article (under "The smell of vibe coding").

Re: I know when you're vibe coding

#16

Post by anshumankmr » Thu, Jul 31, 2025, 6:18 AM UTC

voxl wrote: post #8

atleastoptimal wrote: post #4

This is all true. The best way to treat LLM's as they are now is one step above the abstraction offered by compiled languages over assembly. You can describe something in plain english, note its explicit requirements, inputs and outputs, and an LLM can effectively write the code as a translation of the logic you are specifying. Using LLM's, you are best served minimizing the entropy they have to deal with. The transf…

No, LLMs are not an "abstraction" like a compiler is. This is bullshit. LLMs are stochastic token generators. I have NEVER met someone in real life that has produced something I wouldn't throw in the trash using LLMs, and I have had the displeasure of eating cookies baked from an LLM recipe. No, LLMs will not get better. The singularity bullshit has been active since 2010s. LLMs have consumed the entire fucking Inter…

> LLMs have consumed the entire fucking Internet and are still useless.

They aren't useless. Otherwise, ChatGPT would have died a long time back

> Where the fuck is the rest of the data going to come from?

Good question. Personally, I think companies will start paying more for high quality data or what is at least perceived as high quality data. I think Reddit and some other social media companies like it are poised to reap the rewards of this.

Whether this will be effective in the long run remains to be seen.

Re: I know when you're vibe coding

#17

Post by anshumankmr » Thu, Jul 31, 2025, 6:20 AM UTC

wldlyinaccurate wrote: post #13

anshumankmr wrote: post #12

Earlier quoted context omitted.

That would assume a commit message is implemented correctly, and isn't like "Updated this file" or "Bugfix"

I think the parent comment means "commits" in the sense of the actual changeset; not just the message.

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)

Re: I know when you're vibe coding

#18

Post by thenoblesunfish » Thu, Jul 31, 2025, 6:21 AM UTC

The author is undermining their own point by calling the vibe code "maintainable", when the whole point of the post is that it's not.

Re: I know when you're vibe coding

#19

Post by manmal » Thu, Jul 31, 2025, 6:25 AM UTC

thenoblesunfish wrote: post #18

The author is undermining their own point by calling the vibe code "maintainable", when the whole point of the post is that it's not.

The main gripe seems to be duplication of semantics across the codebase, and loss of centralized configurability. Makes sense, since LLMs can’t fit a whole codebase into their context and are not aware of shared behavior unless you tell them it exists.

Re: I know when you're vibe coding

#20

Post by nickm12 » Thu, Jul 31, 2025, 6:25 AM UTC

atleastoptimal wrote: post #4

This is all true. The best way to treat LLM's as they are now is one step above the abstraction offered by compiled languages over assembly. You can describe something in plain english, note its explicit requirements, inputs and outputs, and an LLM can effectively write the code as a translation of the logic you are specifying. Using LLM's, you are best served minimizing the entropy they have to deal with. The transf…

This is a false analogy. LLMs do not "compile" natural language to high level code in the same way that a compiler or interpreter implements a high-level programming language in terms of machine instructions (or, for that matter, how a CPU implements machine instructions in hardware).

Programming and machine languages aim for a precise and unambiguous semantics, such that it's meaningful to talk about things like whether the semantics are actually precise or whether the compiler has a bug in failing to implement the spec.

Natural language is not just a higher level of abstraction on our existing stack. If a new model comes out, or you even run an existing model with a new seed, you can get different code out that behaves differently. This is not how compilers work.