DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
60% Positive
Analyzed from 1788 words in the discussion.
Trending Topics
#code#bun#dead#llms#project#may#care#slop#node#more
Discussion (61 Comments)Read Original on HackerNews
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.
A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.
If you were an L6+, it was already not really about that.
It's kind of amazing to me that people think the only thing engineers do and the only value they bring is writing code.
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.
I believe it’s spelled Sisyphean.
How did they end up there? There was another project trying to savage what is left of Zig Bun and turned it into a smaller runtime. I hope may be the project could both work together.
https://nubjs.com
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
The mere enumeration shows how bad it is.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.
To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
Very funny to see a "no humans allowed" contribution policy, and the absurd part is that the rationale actually makes sense.
I'm interested to see where this goes. Is it possible to "deslop" something of this magnitude?
The tendency is that open source will die as a collective effort, except for some hardcore stakeouts. AI will become the repository owner. The rest of us just doesn't care enough.
This puts users in control.. just pay and you get your feature in a version generated just for you.
AI is already better than 90% of my colleagues, and none of them can write an exploit, or instantly draw on the breadth of information it can. So all they do is chaperone. Well, that will be gone too in a few years. What will remain are example repositories that serve as the starting point to add your own special feature. The curated set may well become private again, as a competitive advantage.
So Open Source transitions to Public Domain.
I'm not that optimistic for Bun with all the recent churn/slopcoding but the pitch of "use this one good TS tool for everything" is appealing.
What slop does Bun create or cause?
As a software engineer these days, I can't say i do not use Agent to help work done, but i am really a bit of tired to see so much solutions while not talk about what problem they are trying to really solve