Greed

Infamous for it's bad UX? This thread is genuinely the first time I've ever heard this, all of my extended circles were overjoyed when Discord came onto the scene and displaced the patchy, hodgepodge UI's of Mumble, Ventrilo, IRC, Skype simultaneously. Both from a feature and a visual perspective it was a breath of fresh air for the programmers, gamers, and casuals alike for everyone I know. Maybe the only thing that still survives alongside it for the folks I know as a preferred communication channel is sporadic Whatsapp among the EU guys and iOS group chats for the Americans locked into the Apple ecosystem.

What about it makes it terrible UX for you? Feature set seems to get better every year as far as I'm concerned, inclusion of ads aside.

In the context of what I was replying to:

> This is a chicken and egg problem I find hard to resolve with LLMs. If we're pushed to delegate most work to them, how do you build that expertise?

Learning from LLM written code is significantly and meaningfully different from struggling on your own or learning from more experienced human co-contributors. Especially in a large, complex, iteratively developed codebase.

Worse, once you're in that situation you are now at the juxtaposition of: "I did this. I understand what my reasoning was, and now I know why it is wrong and how to fix it" vs. "An LLM did this, I don't know why it did this, I'm not sure what it was trying to do or what pattern it followed and I'm not sure how to make it better because I didn't write or understand the original implementation either"

Is it impossible to learn and gain experience this way? Not at all. But it's definitely not equivalent.

But how would you know? If you're an inexperienced developer you may well end up ingraining bad patterns without even realizing it.

What if the code sucks, because it was vibe coded by an LLM over a dozen disparate sessions?

Will second this, as someone that took the same path. Alternatives like Fastmail are so, so cheap when compared to the headache of building, maintaining, and troubleshooting a DIY stack. For something as fundamental as email you really want to choose the solution that gives you NO problems, rather than some solvable but troublesome problems at regular intervals.

Just too critical of a component in most people's lives to accept any level of unknowns in.

Hats off to the folks behind this for keeping such a cool project alive! This, ReactOS, and TempleOS have been my answer to the question of: "what should I install if I'm looking for something interesting?" for at least a decade. Obviously for vastly different reasons.

What is your definition of "known to be a clown"? I'm not sure how one would even begin to evaluate that at scale. Or what practical impact that would actually have for anything but the most critical of dependencies that might be too difficult to swap at will.

Hyperbole, yeah, but top 10% undesirable leads is literally thousands of people?

I couldn't imagine following the communities of even the top ten dependencies of one of our (many) projects very deeply. Every single one of them is having divisive conversations in threads like this all the time that never really lead anywhere or sum up to anything meaningful.

You're implying that reckless rewrites within the JS ecosystem are a novel event, or more specifically that surprise language changes over a short period of time are. And yet... I can think of at least six times in which exactly this has happened and little fuss was made because the polarizing element of "AI" was not involved. Not just JS to Typescript, but to Dart, Go, C, Rust, Zig, Nim etc.

From any reasonable perspective, this is business as usual in the house of cards we all operate in. Perhaps the sensationalization would be justified if the lang migration wasn't one of less correct -> enforced correctness by default?

To your point in general about maintainers holding a mental model of the runtime: I would challenge that to say that it is very likely that there is no developer who holds a complete mental model of an entire runtime at any given point. As with anything of this scale you understand individual parts in their entirety and have general assertions about the rest until specifically revisited, even if you are the sole developer. In this case specifically, Bun has been largely AI driven for quite a while anyway so it is even more unlikely that the developers ever had a complete picture in the first place. If you trusted them before, then nothing has changed.

It's not lost on me that code logic can be subtly incorrect even as tests are passing either, but there isn't exactly a lot of grey area in this particular context. Does your code compile or not? If it builds as expected, then your own unit tests will highlight the difference.

Enough to make judgement calls on them based on the individual Twitter posts of each of their developers? Absolutely not!

If I go beyond the initial vetting, that's a minimum of 30+ projects multiplied by however many contributors each. Without even mentioning all of their sub dependencies. It's a pipe dream to think you can ever have a complete picture of the motivations and political machinations of your entire dependency tree.

I don't have the personal investment that you appear to have with Bun, but why does this matter? Do you scrutinize the rest of your dependencies this way?

Much of working in the JS / NPM ecosystem is already pure faith on un-vetted dependencies, and this appears no different pre or post LLM rewrite. If it satisfies the intended goal and API contract it originally did, is there any difference? Were you carefully reading the original source code before?

As others have mentioned: battery, build quality, Linux-ish ecosystem. If I could get all three in another laptop I would go for it, but nothing comes close at the moment. There was a very brief moment in time where the XPS came close, and then the M series rolled out and eradicated the competition on performance + battery life.

Would definitely tend to agree. Whenever I read complaints about accuracy of LLMs with complex systems, it has generally been from those that aren't thinking very critically about how they're using them in the first place. If you were to replace that LLM with a real human junior, would you really walk away for a few weeks and then assume the solution given was correct by default when you got it back? Obviously not. So you identify and gatekeep the most critical parts ahead of time, make error correction part of the process, and chunk the Giant, Complex Thing into Smaller, Achievable, Verifiable Things.

LLMs are proving to be very much force multipliers of the kind of developer you already are, and of those who report a 10x increase in productivity they're probably all being genuine. Whether that 10x is of careful, thoughtful choices or reckless rough-shod slop though is really an artifact of the developers themselves. I've been saying from the beginning that your effectiveness with LLMs is roughly equivalent to your ability to get effective results out of a real team of human contractors.

Getting Opus to call something local sounds interesting, since that's more or less what it's doing with Sonnet anyway if you're using Claude Code. How are you getting it to call out to local models? Skills? Or paying the API costs and using Pi?

Assuming you ran the gamut up from what you could fit on 32 or 64GB previously, how noticeable is the difference between models you can run on that vs. the 512GB you have now?

I've been working my way up from a 3090 system and I've been surprised by how underwhelming even the finetunes are for complex coding tasks, once you've worked with Opus. Does it get better? As in, noticeably and not just "hallucinates a few minutes later than usual"?