Greed

> so you might as well use one of those.

Did someone say... Xonsh?! It's tough to give up the niceties of zsh and it's various plug-in ecosystems, but I would love to be able to use Xonsh [1] as a daily driver for exactly the reasons stated. It is already the language I lean on over bash for most utility scripts with its kitchen sink built-ins.

[1] https://xon.sh/

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"?

You would still have to do some pretty outstanding volume before that makes sense over choosing the "Enterprise" plan from OpenAI or Anthropic if data retention is the motivation.

Assuming, of course, that your legal team signs off on their assurance not to train on or store your data with said Enterprise plans.

But why? Spending several thousand dollars to run sub-par models when the break-even point could still be years away seems bizarre for any real usecase where your goal is productivity over novelty. Anyone who has used Codex or Opus can attest that the difference between those and a locally available model like Qwen or Codestral is night and day.

To be clear, I totally get the idea of running local LLMs for toy reasons. But in a business context the sell on a stack of Mac Pros seems misguided at best.

If 40k is the barrier to entry for impressive, that doesn't really sell the usecase of local LLMs very well.

For the same price in API calls, you could fund AI driven development across a small team for quite a long while.

Whether that remains the case once those models are no longer subsidized, TBD. But as of today the comparison isn't even close.

I don't think the concepts are as unrelated as you're suggesting, they both tend to operate on the premise that they can be more effective than others because they're able to bypass the lanes that everyone else is taking.

And you are highlighting exactly what I'm pointing out, which is that if your process is so rigid and overfit that your org is regularly missing out on obvious solutions then the thing you should be solving is the process rather than trying to create "wolves". The concept of a team needing someone that consistently "breaks the rules" so that you can do the right thing is a glaring red flag that you have a bigger picture problem.

I don't know that I care much for the mythologization of effective developers as "Wolves" and "10x-ers" which are this decade's equivalent of Ninja / Rockstar / Guru, but a similar less tech-centric version of that is just the concept of the "Maverick" within any organization and the parallels aren't too far regardless of the industry you're talking about. Outsized impact in undersold roles with a lot of heavy swinging soft power earned through merit.

It's strange to intentionally try to place or manufacture mavericks within your org for (at least) two reasons:

1. They're emergent phenomena. It's probably more valuable on average to examine WHY someone skipping all of your processes is effective than it is to make the conditions right for someone to become that maverick. Theoretically anyone CAN be that person, but unless something is actively going wrong it probably won't happen.

2. Process exists because it makes your org more efficient. When you start building your teams around the idea of someone explicitly being the maverick(s), ask yourself: "Who exactly is going to reconcile all of this against the framework that the entire rest of the company runs on? Is the rest of that person's team relegated to damage control and cleanup crew, and is that actually more effective than having an equivalent number of mid-level performers all pulling in the same direction?"

In the world of tech, the alleged 10x-er often manifests itself as: Tech Debt, but at High Volume™!

I was part of a user study on Azure back when it first rolled out-- they were looking for seniors with an AWS background to participate in UX research, and I remember walking out of that study with imposter syndrome for the very first time. Spent 60 minutes totally unable to do the thing I wanted to do when I was introduced to Azure for the first time, and I remember thinking... am I a fraud?

No! Not this time, at least. In hindsight everything was named and organized terribly and it hasn't improved much since.

I maintain to this day that the Zune was one of the best designed hardware and software platforms I've ever used. Probably the only truly design forward product that MS ever produced.

It's arguable, even if you're right, that the net loss to humanity is still far greater without these restrictions than with. Modern social media is leading to multiple generations of emotionally stunted, non-verbal children. Many of whom literally struggle to read.

If you haven't seen it in person, it is now incredibly common for children as young as 1 or 2 to be handed an iPad and driven down an algorithmic tunnel of AI generated content with multiple videos overlaid on top. I've seen multiple examples of children scrolling rapidly through videos of Disney characters getting their heads chopped off to Five Nights at Freddy's music while laughing hysterically. They do this for hours. Every day. It's truly horrifying.

Parents are just as poorly equipped at dealing with this as the children are, the difference being that at least their brains have already fully developed so that there is no lasting permanent damage.

Yes, this is the true dividing factor for me. The battery life of the new ARM laptops is an astounding upgrade from any device I have ever used.

I've been a reluctant MacBook user for 15 years now thanks to it being the de-facto hardware of tech, but for the first time ever since adopting first the M1 Pro and then an M2 Pro I find myself thinking: I could not possibly justify buying literally any other laptop so long as this standard exists.

Being able to run serious developer workflows silently (full kubernetes clusters, compilers, VSCode, multitudes of corpo office suite products etc), for multiple days at a time on a single charge is baffling. And if I leave it closed for a week at 80% battery, not only does that percentage remain nearly the same when resumed-- it wakes instantly! No hibernation wake time shenanigans. The only class of device which even comes close to being comparable are high end e-ink readers, and an e-ink reader STILL loses on wake time by comparison.

I'm at the point now where I'm desperately in need of an upgrade for my 8 year old personal laptop, but I'm holding off indefinitely until I discover something with a similar level of battery performance that can run Linux. As I understand it, the firmware that supports that insane battery life and specifically the suspend functionality that allows it to draw nearly zero power when closed isn't supported by any Linux distro or I would have already purchased another MacBook for personal use.

As I'm sure the author now realizes: truly elite skill among those working in the trades is in wildly high demand as compared to what someone might expect coming from the software industry.

If just 1% of all software developers are writing near-flawless code to spec, that's still about 287,000 people in the world. They're relatively accessible and the chances of you being able to work with one on a short timetable is actually pretty high.

By comparison: GC's, architects, builders at that level are far, far more rare by the numbers + highly localized + are usually mired in many years-long projects simultaneously. They do not need your business, are paid whatever price they ask, and are usually booked far in advance.

Even so! If you even get the hint that someone in that situation is willing to work with you it will save you far more time and money to wait for that person than to try going with someone available that you feel alright about. If they're readily available, it's because they are not in demand. Think about why that might be. If you can afford to, waiting for the person you actually want to work with is the better option every. single. time.

This comment makes me feel so sad. I lack the words to describe what critical essence this question is missing, but technology used to mean a hacker ethos of just doing things because they seemed cool and worth doing and even just the ask of this feels parasitic by comparison. Sign of the times.

Absolutely. The value proposition for me with rideshare services has ALWAYS been the conversations and experiences you get to have with a diverse cross section of humanity. I'd take the bus / train otherwise.

Wow, I've never considered this aspect of it but you're right. If you want widespread access to incoming developers that can contribute to your project, that really does mean Rust by default at this point if you want a low level language regardless of what you prefer.

The argument there is a little dishonest, given that if you only had the option of riding public transit that your schedule would indeed be well conformed to using public transit. I think everyone understands VERY well that they could get from point A to point B faster by using a dedicated vehicle which is solely concerned with getting them from point A to point B, that's not really debatable.

In the states at least if you're using public transit it's generally as an intentional time / cost tradeoff. That's not a mystery and taking a point-to-point schedule and comparing that against public transit constraints doesn't really prove much.

I might be missing something, but what does this do that an app like AnyDesk doesn't? Is there something inherently better about remoting in with dedicated hardware rather than using any of the free and widely available software solutions? I can see where this would make sense for low powered machines that can't easily encode video at high speeds / low latency, but I struggle to see the sense of this in a context where I actually want video output (a powerful workstation) rather than just SSH.