Hacker News Reader

Hacker News

Comment by nailer | Hacker News Reader

Parent Full thread

nailer

> what looks like a massive undertaking for vibe coding

It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

View on HN

Did you look at the branch? This is vibed, even with the most liberal definition

https://github.com/oven-sh/bun/compare/claude/phase-a-port

This single commit is 65k lines of additions

https://github.com/oven-sh/bun/commit/ffa6ce211a0267161ae48b...

The definition is at https://x.com/karpathy/status/1886192184808149383 and no that does not match what is in the branch. Systemically migrating a code base using an LLM does not match the defintion of vibe coding.

There's a decent article by Simon Willison that talks about this: https://simonwillison.net/2025/Mar/19/vibe-coding/

> I’m seeing people apply the term “vibe coding” to all forms of code written with the assistance of AI. I think that both dilutes the term and gives a false impression of what’s possible with responsible AI-assisted programming.

You're right, all 750k lines of code added in a single day - definitely reviewed and completely understood.

This is just a coined term; definitions evolve over time based on usage

All language is "coined terms". The point is that if you dilute the definition of a term, you make the term useless. Evolution of a term isn't done automatically. Correcting terms such as these pushed the evolution in a more useful way. Also, evolution of language is not a magic spell that automatically forgives people on making language mistakes.

Then "vibe coding" is a useless term, if it just means "LLM-assisted coding". We might as well just say "LLM-assisted coding" or "AI coding" or whatever.

As much as I find the word "vibe" generally annoying (in all contexts), I actually really like "vibe coding" as "LLM did everything and I didn't even look at it". It's a succinct, useful way to describe that mode of doing things. Diluting it down to "LLM-assisted coding" makes it useless.

> Then "vibe coding" is a useless term

You're absolutely right.

Nah, I'm not big on these "it either matches the way ___ used it or it's useless" binaries. The term is the term, it's recent, and people are using various forms of the others you mentioned. People use it loosely, people use it specifically, this is the way for many colloquial terms, and definitions form around them and expand over time or change.

It sort of surprises me how uptight people are getting about a term that was mentioned on X last year and has since been tossed around to loosely imply that a machine did between zero and all of the work. Just because it doesn't match exactly does not mean it's useless, it maps to a concept, if the details are important and ambiguous, then elaborate.

The dilution of the term is a real problem sometimes.

But pointing your AI at an entire codebase to transpile pretty much entirely by itself? Yeah vibe coding is a fitting term.

Even if you wrote it a small essay on how to Rust. That improves the situation but doesn't change the core autonomy/hope of the task.

Here is the Wiktionary definition for curiosity.

> (programming, neologism) A method of programming in which a developer generates code by repeatedly prompting a large language model.

https://en.wiktionary.org/wiki/vibe_coding

Thanks. That helps us know not to take Wiktionary seriously.

I think the definition of vibe coding is a bit fluid, in this case I just meant it to be “code fully generated by AI, possibly not fully reviewed by human eyes”. I agree that this definitely not “coding based purely off vibes”, and the approach looks legit.

what would you call a fully uncommented commit with

"+27,939Lines changed: 27939 additions & 0 deletions"

of new rust code

Just another Monday in 2026.

The blind leading the blind.

I'm sure it will be called Systems Programing . Because Rust.

The commit would look exactly like that if it was a 100% deterministic transpilation (like Golang did with their original C implementation?).

This is obviously very different from that, but the way the commit looks doesn't make it so.

The question isn't whether or not you'd get the same line count with a non-LLM tool. The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code. And with a 75k line difference, that seems unlikely.

> The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code

Why? Do you think large changes not made by LLMs are also reviewed line by line?

It depends on what you mean by "vibe coding". Is AI coding based on an existing implementation vibe coding? What about only from a natural-language spec? How does manual reviewing affect whether or not it's vibe coding?

> How does manual reviewing affect whether or not it's vibe coding?

I think the most commonly-accepted definition of "vibe coding" is when you "forget that the (generated) code even exists"[0]. So vibe-ness entirely hinges upon whether you're manually reviewing. If you make/prompt changes based on what you observe in the generated code (rather than only based on runtime behavior), then you're not "vibe coding".

I think the other things you mentioned are orthogonal to vibe-ness.

[0]: https://en.wikipedia.org/wiki/Vibe_coding#Definition

In practice all use of AI rapidly becomes vibe coding. Even if someone says they're going to carefully manually review everything that's generated, within a couple of days they get bored and just click approve.

Not to mention that manually writing code is itself a process of understanding. It cannot be replicated by reading code, no matter how carefully.

While I'm sure you're speaking for many, this is definitely not true across the board.

This is just a matter of priorities - I use LLMs to write code every day and I have never put a single line of code up for review that I didn’t read and understand.

I use to do this and then do test manually to validate everything works as expected in my small open source project. But then over the time I saw that some bugs crept in which I was unable track since I was doing manual testing. So I wrote some e2e tests with playwright and I think that gives a bit relief (at least).

Reply on news.ycombinator.com