Meh, bring on the ARM devices! Get native binaries on heterogeneous SoCs, and then maybe someday OSes will allow x86 SoCs to live up to their potential instead of forcing them to pretend to be a PCI peripheral and turn into a hot plate just keeping up with serial instructions.
I wouldn’t say Kagi has “moved to become an AI company”.
They host some open weight models, which you can use with your subscription (which hasn’t increased in price or dropped features since they added AI access), but you’re not forced to use AI ever, and they’re not collecting your searches or prompts to feed into training.
They’ve taken a pretty skeptical stance on AI from the start. You can disable AI features completely, so you don’t even accidentally use them. But even if you leave them enabled, you have to opt into invoking AI by ending your query with a question mark.
Edit: Also, they downrank content that has been flagged as AI generated: https://help.kagi.com/kagi/features/slopstop.html
Well, “should you”? Only you can decide that. You only get the one life, you know. It would suck to spend it only doing things because they’re “prudent”.
It seems like you’re asking for market predictions here, based on the AI and outsourcing aspects. Nobody knows what the future holds. But we can look at the past and present.
Historically, companies — both individually, and the industry as a whole — tend to oscillate between:
For all the AI corpos’ talk about a revolutionary change in the way we think about work and employment, it all looks very familiar right now.
Historically, these moments, where everyone seems to agree that they want more hands on keyboards rather than more brains on call… tend to be the worst time to freelance.
It’s a race to the bottom, and you’ll probably be so busy spinning plates that you won’t be able to make any long-term strategic decisions about what you wanna learn and do next.
If you can, I’d look for a stable corpo job that you can firewall to 9-5, and keep your options open. Watch the market, and — more importantly — find something that you like, so you don’t have to ask internet strangers what to do with your life again.
The “it’s just a tool” (with optional add-on “what matters is how you use it”) thought-terminating cliche makes me put my face in my hands a little bit deeper every time I see it.
Daily life in 2026 would be completely unrecognizable to a person from 5,000 years ago, and the difference is not just how we use our tools. The production, existence, and proliferation of the tools shape what is easy or hard, or even what is possible or impossible.
To think that you can reshape the contours of the decision-making terrain and that has no effect on what people do, or how they think of who they are… you’d have to accept that someone in the bronze age could just wake up one day and decide to be a telecommuting web developer on HRT and Ozempic.
To be fair to the original commenter: They did bring up copyright in the context of “what makes this a different kind of tool”, which is an empirical claim and not a normative one.
I can say a little bit on tooling: We’ve experimented with Chromatic. We’re on a mobile app though, so the idea with Chromatic is to render via react-native-web, which has its own issues, so the ROI is such that we haven’t taken it beyond POC. Seems nice though, and probably more in line with your domain.
But for org strategy, I take it you’re on a much bigger team than I ever have been. (10 people max for me) So I can’t speak to personal experience there, but what I will say is that being able to control your entire env top to bottom is crucial for pretty much anything where you want high fidelity testing.
Like, being able to set up an env that allows you to play with stuff like externally-sourced ads and CDN caches in a space that’s private and temporary. No small feat, but that’s pretty much what you have to do if you want to catch those Rube Goldberg style failures before prod.
It depends how much it’s worth it to you, to have a test env that’s 99.999% realistic. As with anything, the first two 9s are the cheapest.
Meanwhile at work we just had a training course that specifically said doing “opt out” instead of “opt in” violates the principle of informed consent.
I did it to invite collaboration and connect with other developers with similar interests. FOSS is more about building communities than building software, after all.
I did not anticipate that it could be (legally) used to dismantle the kinds of communities I wanted to build. (I did anticipate that it could be illegally used to that end, but historically that has tended to cause a Streisand Effect, so that risk seemed worth it.)
Oh hey, I just watched something that was full of good info about this! https://youtube.com/watch?v=-Lv7jmdqTUU
ADHD context, but most of it is universal. I hope there’s something useful in there for you!
That’s exactly how full my luggage is.
I don’t think there’s anything wrong with the author sticking to the level at which he’s an expert. If everyone had to chase down the lowest possible level, we’d all be physicists (or maybe philosophers, depending on your take there).
Besides, isn’t the “materialism” portion of “dialectical materialism” about interrogating the implications of present world you find yourself in, rather than evaluating what-ifs of alternate histories?
However generative AI might have emerged differently under a different regime, this is the version that we have access to inspect and, crucially, the version we must contend with if we want to influence its future trajectory under any regime.
Edit: But I do have to agree that he is much better at diagnosing the problem than he is at prescribing the solution. That seems to be the way of things. People tend to be good at either analyzing problems in detail, or rallying people around a tractible plan of action. It’s very very very rare to see someone who is good at both. So I don’t mind it too much.
Ehhh, probably the most pragmatic option for someone in his position, but I’m not gonna take that as an even-handed analysis of AI in open source, the software industry, the economy, or civilization writ large.
There was a post earlier today that directly counters the “just a tool” trope. (And if you’re thinking “but this is Linus! What credentials could this rando possibly have?”, allow me to preface their essay+video with a note that this guy has experience at high levels in the industry and then quit the industry to get a PhD with a focus on the social impacts of software development tools.)
And Cory Doctorow has a book (and many blog posts and speaking engagements covering the same content) about the precise harms (and non-harms) of AI.
Dr. Fatima (on Youtube) also has a pretty well-rounded take.
And Baldur Bjarnason makes some good points from a cognitive science perspective, though I think he’s ultimately out over his skis quite a bit.
Can’t answer for them, but I can explain a similar situation I ran into:
Large external RAID I was using for telescoping backups with a restic cron job. Didn’t want to have it on all the time cuz it was noisy, so I put it on a smart plug and had it turn on and off as part of the job.
I really wanted a set of backup rules that worked like… “always a full snapshot of current state, plus as much of the following as will fit into the destination: daily for the past 7 days, weekly for the past 4 weeks, monthly for the rest until full” …but restic doesn’t (or didn’t) support that kind of dynamic rule set.
I tried to estimate it programmatically, but it never worked 100% and I frequently ran into out of space errors.
But of course, I never saw the actual disk usage in my day-to-day, because the RAID was only on at like 4 AM.
Agreed.
I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.
i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.
This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.
(Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)
I’ve seen that before. It’s a self-destructive policy.
We’re embarking on the information/communication equivalent to Kessler Syndrome.
It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.
Can you stop releasing breaking changes on minor releases? It’s absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.
By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.
I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.
But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.
And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.
The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.
There’s Armada OS for now, but I’m looking forward to first party support (eventually) or retooling of Steam Frame support (more likely).