3 ms·

I wonder how many "behind the curve/not super modern" corporations were using Bun or Deno to begin with. Part of me thinks it's a mild overreaction. It's not l

I wonder how many "behind the curve/not super modern" corporations were using Bun or Deno to begin with. Part of me thinks it's a mild overreaction. It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Is it because it was an irresponsible thing to do? Maybe? I don't know, I see both sides.

dahs12 4mo ago
It isn't about users auditing Linux. The Bun developers don't audit "their own" (stolen) vibe code output. How would anyone know if it is secure?
worble 4mo ago
> It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? That's basically Torvolds full time job?
- cookiengineer 4mo ago
  > That's basically Torvolds full time job? It's actually more like 50 devs, each of them specialized in their own field, with 20+ years programming experience. And even they make mistakes sometimes (see the recent TOCTOU exploit wave). What vibecoders never get: it's about stability of software. Nobody will rely on your vibecoded project if even you yourself don't give a damn about any API stability or API contracts. If you expect others to use vibecode assistants to use your software/library... then what was the reason in the first place to write it, if it's effectively not solving a problem? The whole points of dependencies and packages goes out of the window once the library maintainers start to use slopcoding practices.
nicoburns 4mo ago
> As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Because the chances that they had a test suite that was actually comprehensive enough to guarantee correctness through this kind of refactor are approximately zero. Normally we combine tests with careful "correctness by construction" design work and code review because we know that tests aren't sufficient.
atty 4mo ago
> as long as the tests pass To be pedantic, tests prove that the code passes the test suite, nothing else. They do not prove by themselves that the code is correct, secure, maintainable, efficient, etc. Those are much harder to measure and have a ton to do with organization, architecture, culture, shared knowledge of the maintainers, etc. All of which is lacking during and after this rewrite.
thesz 4mo ago
> As long as the tests pass and the performance doesn't regress... AMD had 20+ million tests for their FPUs back in the day of Intel's FDIV bug and ACL2 found bugs in their implementations of floating point computation. Agentic vibe coding is not an application of ACL2 theorem prover to anything. Agentic vibe coding is an opposite of it, it will make its way to pass the tests with any means necessary, be it patching the code, the tests, or expected results. > it's secure You can't say that before formal verification. Which is an opposite of what vibe coding is.

dahs12 4mo ago

It isn't about users auditing Linux. The Bun developers don't audit "their own" (stolen) vibe code output. How would anyone know if it is secure?

worble 4mo ago

> It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? That's basically Torvolds full time job?

cookiengineer 4mo ago
> That's basically Torvolds full time job? It's actually more like 50 devs, each of them specialized in their own field, with 20+ years programming experience. And even they make mistakes sometimes (see the recent TOCTOU exploit wave). What vibecoders never get: it's about stability of software. Nobody will rely on your vibecoded project if even you yourself don't give a damn about any API stability or API contracts. If you expect others to use vibecode assistants to use your software/library... then what was the reason in the first place to write it, if it's effectively not solving a problem? The whole points of dependencies and packages goes out of the window once the library maintainers start to use slopcoding practices.

nicoburns 4mo ago

> As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Because the chances that they had a test suite that was actually comprehensive enough to guarantee correctness through this kind of refactor are approximately zero. Normally we combine tests with careful "correctness by construction" design work and code review because we know that tests aren't sufficient.

atty 4mo ago

> as long as the tests pass To be pedantic, tests prove that the code passes the test suite, nothing else. They do not prove by themselves that the code is correct, secure, maintainable, efficient, etc. Those are much harder to measure and have a ton to do with organization, architecture, culture, shared knowledge of the maintainers, etc. All of which is lacking during and after this rewrite.

thesz 4mo ago

> As long as the tests pass and the performance doesn't regress... AMD had 20+ million tests for their FPUs back in the day of Intel's FDIV bug and ACL2 found bugs in their implementations of floating point computation. Agentic vibe coding is not an application of ACL2 theorem prover to anything. Agentic vibe coding is an opposite of it, it will make its way to pass the tests with any means necessary, be it patching the code, the tests, or expected results. > it's secure You can't say that before formal verification. Which is an opposite of what vibe coding is.