Comment by nailer
11 days ago
> 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?
11 days ago
> 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?
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.
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
1 reply →
This is just a coined term; definitions evolve over time based on usage
4 replies →
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
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.
1 reply →
Just another Monday in 2026.
The blind leading the blind.
I'm sure it will be called Systems Programing . Because Rust.
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.
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).
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.
[dead]