2025 xmas day, was at my wife's parents' house in rural Japan, my kids were all playing with their cousins, I was posted up with my laptop just listening to some podcast about the benefits of making time for long walks in middle age (as if! ~lol) while running another "agentic team" experiment — 12 agents in parallel.
I'd been feeding these bots a few projects, over and over — the hard part was the feeding them — that is, giving them enough well-defined work to do. They weren't yet good enough to write real software you could keep — at least I'd never seen that — and my experiments were just about finding the edges, building my intuition, and playing with processes that might be useful someday.
These things had built my kids' weird magical-dominoes games a few times by that point — but the experiment had been repeated so many times that you could argue we had "written" that software in English, with a spec that had been built, reworked, and rebuilt many times.
But this time, the bots were building me a bespoke git client, unlike any other, and unlike anything I would take the time to write — waaaay to complicated, with too little benefit. I wanted it, but only for this one niche use case.
It was a GUI client to manage a collection of repos, about 200 of them in a monorepo where every subproject was a git submodule , which are the universal counterpart to node_modules — while the latter is notorious for being "the heaviest object in the universe", git submodules are widely acknowledged to be the most annoying objects in the universe.
Nevertheless, I had this weird monorepo, and I wanted to visualize and do stuff to this list of independent repos that were also git submodules of the parent monorepo: sort by outstanding commits, divergence from upstream, recency of activity, etc. Visualize them differently based on these things. Search across them, including the source code on branches other than the current one. Show the branch counts and number of branches and commits that existed locally but not pushed upstream. A bunch more boring stuff like that, but done across the full set of repos.
That project itself wasn't even interesting to me; that software would be marginally useful to me if it existed and worked, but the main point it was just a large enough chunk of work to keep a team of bots busy all day without a human in the loop.
In December 2025, AI coding agents were already useful with a human in the loop. Opinions varied a lot about how useful they were, but to me it was obvious we were going to use them for the rest of our careers as software engineers.
It was not yet obvious that we were going to let them write huge swaths of code, or entire programs, without any humans in the loop. I had never seen that produce something that worked well enough to be worth keeping.
And then, that day, I did. I had structured the workflow so that the git client was on the screen and auto-refreshing. I was listening to the podcast, drinking coffee, reading the news. The git client was a crude window with a table in the background, a single column showing the full path to each repo, and nothing else.
Then the table expanded. It got color coded numbers representing the commit/branch counts. It suddenly gained styles, and looked nice. A contextual menu started popping up, repeatedly, and grew to include several more menu items over the next few minutes. New confirmation dialogs popped up as the bots implemented and exercised the various features from my spec.
I remember my field of vision narrowing as I started to focus on what the bots were doing. They were just executing my loop — one bot would implement one bullet from my spec, another bot would review the code while another bot manually tested it, and tried to break it, run a code review gauntlet in a loop until there were no more findings, repeat.
I could see the progress play out on my screen as they worked. I had watched bot teams work before, but it had always been pretty janky, and something like a bad game that nobody would play, or a stupid to-do-list app, or — more often — something that didn't actually work.
This was the first time I had ever seen it work. This was the grail we'd been looking for, not sure if it really existed: a fleet of bots successfully building a piece of complex, useful software without human assistance. I could tell it was working, because the adversarial testing and usability checks were all happening right before my eyes.
So it _is_ possible, I thought to myself.
They did it all morning. The app worked. I used it every day after that, for several weeks, until I finally got that entire monorepo converted to a more sensible git subtree-based arrangement.
In the half year since then I've been in a kind of manic state some of my friends call cyberpsychosis, chasing that dream. I've now seen agentic fleets successfully build many things. I've also seen a bunch of failures, some subtle, some catastrophic and hilarious. I'm still building my intuition, and the laws of physics in this universe are mutating every few weeks. It's wild.
I am fortunate enough to work at a place that doesn't pressure engineers to climb a token leaderboard, or to use AI beyond what we deem prudent. This kind of agentic no-humans-in-the-loop coding is prohibited. The policy is that in this era where we all generate more code than ever, even by hand, it's the quality bar that must go up, not the speed of production.
That's awesome because it keeps me grounded in the old ways, and confines my cyberpsychosis to my weekends and evenings. I usually spend the weekend building up a couple software plans, honing them as best I can, and then unleashing the clankers Sunday night.
I'll let them run all week, sometimes giving them a poke or flipping them over a couple time in the evening, and then the next Saturday morning, I see what I've got. What I'm mainly interested in is: How can agentic fleet-coding processes evolve to produce better software and require less human interaction and inspection? And the corollary: How can software architectures evolve to safely consume more of this fundamentally untrustable code?
It's thrilling. Exhilarating. The near-infinite subsidized tokens are about to finally run out this month, alas. But for the past 6 months it's easily the best $400/month I have ever spent. :)
I like to think I'm part of the reason the bots use em dashes so much, since I've been using them — or the ASCII "--" that we used to have to type to represent them in the pre UTF-8 times — since you could write stuff and post it on the internet.
This fixes a dozens-of-times-per-day annoyance for me.
The grid is good, but even better is the instant virtual display switching.
Nowhere is the death-by-a-thousand-paper-cuts annoyance of modern macOS worse than having to hit Ctrl→→→→→→→ and suffer those repeated animations, over and over.
It's every action on Mac and iOS that does this, and it has been increasing in intrusiveness for a decade. I can't be sure why they do it, but it comes off as though their visual designers are immature, thinking we want to see their impressive animations not just in a demo, not just in a tutorial that we go through once, where we are meant to grasp the relationships between the things, but over and over again, all day long, for decades.
I freaking don't. One time was plenty. I don't want any animation. And the "reduce animation" feature's implementation is a slap in the face: all the delay -- that part is non-negotiable apparently -- but with blurry crossfades instead.
I'm using cwm (x11) without a compositor (never noticed tearing). And it's so nice when everything is not trying to be cute with shadows, animations and round corners. Animation only makes sense when there's a direct action that controls it (like when swapping spaces or hovering) or the system wanting to inform us (notifications). And it's better be fast. Otherwise it's just visual effects that quickly become tiring after a few days.
It is absolutely, positively mind boggling that you have to sit through those animations. And key presses don’t even take effect if your new desktop until the animation is done. It’s just lunacy.
How does a company with infinite resources and talented designers come up with shit like that??
I've also switched to Instant Space Switcher, it is soo good! Previously I used BetterMouse for only this feature but they made the space switching worse in later versions (slower, on-par with the default macOS speed).
You can also do Ctrl-UpArrow then click the space you want. This isn't instant, but it might be a little better than repeatedly cycling through each desktop, especially if you have a lot of them. Turning off "Automatically rearrange Spaces based on most recent use" is also a must IMO.
Personally, I only open one app per desktop and just use Command-Tab. If you hold Command after Command-Tab, you can select an app with having to cycle through all of them.
But AFAICT he's never suggested they reviewed all the code, and that they didn't seems like a pretty safe assumption given the volume, and timeline.
I personally think the test suite passing counts for something, and I would bet they also set up some pretty intense LLM-powered verification loops and quality gates (which I hope the forthcoming blog post will detail). I've seen mechanical LLM ports that went extremely well (though nowhere near this scale, so we could review the code (which is how I know they went well)).
I think the most hysterical reactions that we are seeing from some people are premature, knee-jerk responses. We're gonna _find out_ if the Rust version really is better than Zig version, and soon.
And even if it is better overall, I think if there is an AI-slop-induced major bug we are definitely gonna know that, too, because we have a highly motivated community of folks ready to tweet the shit out of it the instant it is found.
So even as a pretty heavy daily user of Bun, I'm actually really glad they did this. The value of the public experiment is high, and if new Bun sucks, well, I still have Deno.
I frequently joke with people that the reason I have influence in the AI world is that I'm blogging like it's the early 2000s, when everyone else gave up on blogging as a medium.
Substack is thriving, btw. Curiously I simply have less desire to read the thoughts of "smart" people than ever. Either write a proper book or distract me from the horrors of the world.
> but substack is mostly just another twitter low-engagement farm
That, plus it's also full to the brim with LinkedIn-esque AI slop. There are still some decent writers there, for sure, but Substack is going downhill fast as more grifters join the platform in the hopes of making a quick, easy buck.
Via Substack's own recommendation algorithm, Substack Notes, and by perusing the leaderboards, both of which have been a thing on the platform for a while now. Substack's social media side is very Twitter-esque. Writers you follow "restack" publications (some of which are full of AI slop, unbeknownst to the restacker) and the algorithm also inserts "writers" you haven't encountered into your feed. ("Writers" is in scare quotes for a reason.)
I had this gaming PC — and once a year doing excel and dropbox exchanges with my accountant, but other than that, gaming PC — and it never had an issue, from 2020 or 2021 to last month.
So I decided to move it to the living room, and connect it to our big TV, instead of the small TV — same LG manufacturer, same 4K res, mind you — and now it just freezes every 3-4 days. And freeze means just, the screen still shows whatever it was showing when it froze, no USB mouse or keyboard does anything, cannot be RDP'd to cannot be pinged... hold-down-power-button only answer.
(I have swapped all the cabels, just to be sure.)
The only differences: moved it 20 meters physically, connected it to a slightly newer TV. ¯\_(ಠ_ಠ)_/¯
macOS and Linux also do suck, but both are AFAICT way more predictable, and less random
TBH your problem sounds like a hardware issue. Maybe the PC's new location is warmer due to a more enclosed space, triggering more unrecoverable hardware faults.
I agree it sounds like that, but (having that same thought) I kept the temp in the living room 20℃ or less for a week but nah
My best guess at this point is the 2025 LG TVs have some different HDMI ARC something something compared to the 2019 it was plugged into before.
But also my point is that there's no way a human with 3 kids and job could ever know... it either starts working or I get a PlayStation or a different PC or whatever.
Or just tell my kids, "Hey, Death Stranding works on your Mac now, so shut the fuck up until you finish that whole game." ¯\_(ಠ_ಠ)_/¯
> macOS and Linux also do suck, but both are AFAICT way more predictable, and less random
macOS maybe as long as you're only using Apple hardware. As soon as you use 3rd party peripherals, you're in for very interesting bugs that are not getting confirmed by Apple and suddenly disappear again with a macOS update (if you're lucky).
yeah — i have my kids on Macs, bc I'm lazy, but just the ones with only two USB ports and nothing else — otherwise never-ending, unresolvable nightmare unless it's just some Apple thing you're plugging in
Vernor Vinge has some hits and some misses, but A Deepness in the Sky (best to just take the plunge and read it without googling — it's good either way, but better if you don't even read the back of the paperback).
Then, a bit further afield but for me, at least, exercised what I liked in The Culture series, even though stylistically different: Spin by Robert Charles Wilson.
I think A Fire Upon the Deep would be a more enjoyable starting place for someone that likes the Culture series, even though A Deepness in the Sky is generally considered the better novel.
I can understand where you are coming from, but I myself am coming from a quite different place. I'm a long-time Deno fan, and to me Bun was less interesting because a.) it seemed like a much-less-ambitious Deno, and b.) I don't want to learn Zig, so I wasn't likely to try to hack on Bun itself, even just recreationally.
But, I warmed up to Bun over the last couple years almost against my own will — trying to maintain a pretty large body of TypeScript code in a runtime-agnostic way (including even Node, since 24.2). I don't want to make any specific TypeScript runtime a requirement for my TypeScript code, unless there are really good reasons to do so.
But Bun (like Deno) kept providing those reasons. Postgres, SQLite, S3, websockets, local secrets (Keychain/wallet), bundling, compilation, killer speed. So I (somewhat grudgingly) started using Bun more, and even made it a requirement for some of my projects (albeit, in ways I could walk back later if needed).
Today, I have a bunch of API servers and frontend app servers which are bun build --compile --bytecode single executables ,that can run and be deployed virtually anywhere.
I've been very happy with it so far. But also, I don’t think that the way I am doing it is super-common, and now that they are doing this, uh... extremely ambitious LLM port, I am perfectly positioned to regret all of my decisions around Bun if this port ends up sucking.
So I'm a little nervous, but... what if it doesn't suck? That would be cool, because a.) they will have shown something interesting about what is possible with LLMs (albeit if you are rounds-to-a-trillion-dollars valuation frontier AI lab, lol, but still). And b.) going forward, Bun will be developed in Rust. We all have our own preferences, obviously, but to me, that's a win.
And if it does suck, though — that's super interesting too! Will be annoying to me to re-architect my Bun-specific shit to Deno, but for the world at large (and me, too) that's still interesting information!
Because Bun is perfectly positioned to do a huge LLM-powered port. They are one of the premier TS/JS runtimes, it's obviously and insane marketing pillar for the AI lab that bought them, they have unfathomable resources and access to the cutting-edge models that all of us don't get to play with yet, and for all intents and purposes, they have unlimited money to do this.
So if they can't do it — which will be really obvious, I think, if true — then it really just isn't possible yet, and all the naysayers were right.
lol — what you're saying doesn't make sense to me, but I'm sure it makes sense to somebody
What I was specifically referring to is Deno (originally) trying to fix the (glaring, fundamental) problems that Node imposes on the world, vs just do them faster.
I guess it depends on how you define ambition. If you are talking about in an absolute sense, yeah of course, the Dart project had to build a whole language, VM, and ecosystem. That's way more ambitious than Deno.
Though if you look relative to the team size and resources going into it, a project like Deno can still be considered ambitious. Creating an alternative ecosystem to nodejs is a large undertaking.
OK. But without changing programming laguages, "fix some fundamental Node problems" vs "don't fix those problems, just run them faster, and maybe inline the most popular dependencies"...
Surely we can agree that one of those positions is relatively less ambitious?
I think the Anthropic acquisition means that Bun isn't in that business anymore. Bun is still fixing fundamental Node problems, but that's no longer the business.
The business value the Bun team needed to deliver (to make the acquisition pay out) might very well be this controversial, but nevertheless spectacular, 6-day Zig→Rust port.
But beyond that, now Bun is just tooling used internally at Anthropic, which also happens to be open-source.
Oh. Well, then, yes I agree. It certainly does remain to be proven if anybody can make "Node, but better" a business.
Certainly the recent layoffs¹ of ~half-or-so of the Deno team doesn't bode well for it, as AFAIK Bun was the only other significant player trying (to make it a business).
Well "slop" is doing a lot of work there. If it's all incomprehensible garbage-code that no human can understand? Then... yeah very marginal value to me, in terms of hacking on it.
However, I think if it turns out that that's the case, then their port will fail in two ways (to paraphrase Hemingway): gradually, and then suddenly.
I don't think this port can be a success unless they end up — on the other side of it, not necessarily immediately — with maintainable Rust code.
If they succeed the software will be more reliable with less memory issues that are very likely significant security issues at least some of the time.
When we've seen linux having a new significant exploit every other day now thanks to LLMs being better at weaponizing memory bugs this seems significant.
No, and there's been a lot of confusion about that on this website.
They did cite Rust's safety as a motivating factor for the port. That doesn't imply trying to achieve that simultaneously with the language change — which is good, because that would be insane. (Or, if you prefer, even more insane.)
You cannot faithfully port a codebase to a new language while also radically re-architecting it. You have to choose.
They want the safety benefits of Rust going forward; i.e., after it's finished, when they then write new code in Rust.
Yeah, exactly. The typical approach is to do a mechanical translation such as with rust2c, that is full of unsafe, and then gradually refactor safety in.
And the first post is about the team working on the project, with about two and a half sentences on c2rust, and making it very clear they just started.
The newer posts go into detail about the rearchitecting that follows.
reply