Be that as it may, it would seem absurd if we start calling distillation out as antagonistic, but don't do the same for the SOTA models being trained on human-created data.
This does not really match my observations. While it does feel to me the sentiment is shifting towards a more negative one, overall HN feels reasonably balanced between those that are pro-AI and those anti-AI (with the middle ground somewhat absent).
Unlike what many other comments here seem to suggest, HN seems much more pro-AI than what I see in real life amongst developers - at least where I live.
And I do think many users would care more than we might think, but unlike art etc. it is often more difficult to tell.
Responses seem to be very "either or" as usual on such topics.
I think it should be possible to appreciate how impressive this is on one hand, while also discussing the limitations of the approach.
Everyone can probably agree that getting this far without LLMs would have taken substantially longer and required a huge amount of work.
But what is then the end result?
Personally, for me it would still be hard pass on using a 1M LoC LLM-migrated language runtime - I have seen CC do enough crazy things to still be wary of any code without a human in the loop. It simply plays too fundamental a role in the tech stack. Others might feel differently, and time will tell how things play out.
Even if this does play out as optimistically as one can imagine, would it then mean I can go and migrate some of my enterprise codebases the same way? I doubt it.
Bun has the nice feature that it has an extensive set of black box / E2E tests that don't themselves need migrating. Most projects in the wild seem to be much more reliant on unit and integration tests that are part of the codebase itself, and would therefore also need to be migrated and be subject to mistakes in the migration process.
It also seems fairly rare that test suites are good enough to guarantee that the program will work as expected in all cases. I am yet to come across a larger enterprise codebase where the tests were good enough to make human review and even manual testing fully redundant. To be honest I doubt that is the case for Bun either, but I don't know enough about bun to conclude that.
I think a notable difference is that the AI that is portrayed in most sci-fi (that I have read/watched anyway) tend to be "logical machines" that act deterministically based on the data available to them.
What we got are "statistical machines" that tend to do the right thing under the right conditions, but can go completely off the rail every now and then.
The former are more akin to a generalization of computers as we typically think of it, whereas the latter is something else. Maybe that something else is closer to human behavior in some ways, but also so very different - unlike humans, where you get to know people, build relationships, know who to trust in what ways, and so forth, you can never really trust an LLM with any critical tasks without close supervision.
I feel like using an LLM to do serious work is a bit like us using our brains language centre for the same job - like a very elaborate collection of stock phrases. I'm impressed that it works at all but it doesn't really feel like the right tool for the job. I think the robot of the future will have some more logical cortex doing the thinking, with an LLM in front of it handling the communication.
Code quality tends to have an impact on more than just aesthetics - and Claude Code certainly feels like a buggy mess from an end user's perspective.
Of course people still use Claude Code, but that is certainly because of the underlying models first and foremost. Most products don't have such a moat and would not nearly see as much tolerance from end users. If the Max subscriptions could be used with other harnesses, I am sure Anthropic would have to compete harder on the quality of the harness (to be fair, most AI based tooling seems pretty alpha these days, but eventually things will stabilize).
Polish is not everything, clearly, but it is a factor, and I feel Claude Code is maybe the worst example to use here, as it doesn't at all generalize to most other products.
I strongly doubt that is going to be the case - picking up these tools is not rocket science, even if you want to be able to use them fairly effectively. In addition, there is so much churn in AI tooling these days that an early investment might not really be worth a lot in the longer run.
On the other hand, hands-on experience in programming and architecture is currently a must-have to use the tools effectively - and continuing without AI in the short term might just buy an inexperienced engineer some time to learn, and postpone skill atrophy for an experienced engineer.
Of course, who can know what the future looks like, but I doubt a "wait and see" approach is that dangerous to anyone's career.
Asking it to do something isn't exactly complicated. At the very least, it's way easier than actually coding so why would you expect people to struggle with writing? There's no skill required in using LLMs, that's kinda the point.
Someone might feel different about a (future) community owned and managed LLM than one controlled by Altman, Musk, and similar. It would be nice to feel like we're building something together instead of funding the oligarchy and accelerating the collapse of civilization.
One where articles like this talk about a 10x increase in productivity, where the sentiment on HN is that all software can now be vibe coded without review, where AGI is right around the corner.
And another reality where we don't really see any measurable difference in productivity betweens that have gone all in on LLMs and those that haven't, where the current SOTA models still produce bad quality that needs a lot of guidance and revision, where mediocre engineers that never cared about quality in the first place now use these tools to produce even more mediocre code, where the most talented engineers get bogged down reviewing low quality LLM-generated PRs, and so on.
Maybe a bit exaggerated, but OP definitely lives in a very different reality from the one I am seeing. So different that I find it extremely hard to believe.
Even if we assume that LLMs become good enough for this to be true (some might feel that is the case already - I disagree, but that is beside the point), there is no reason why OSS maintainers should accept such outside contributions that they would need to carefully review, as it comes from an untrusted source, when they could just use the tools themselves directly. Low effort drive-by PRs is a burden with no upside.
The problem is the increasing review burden - with LLMs it is possible to create superficially valid looking (but potentially incorrect) code without much effort, which will still take a lot of effort to review. So outright rejecting code that can identified as LLM-generated at a glance, is a rough filter to remove the lowest effort PRs.
Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.
Not necessarily a bad idea, but I think the bigger issue here and now is the increasing assymmetry in effort between code submitter and reviewer, and the unsustainable review burden on the maintainers if nothing is done.