Ditto. I've started to wonder if the real problem with many of these complaints about LLM writing is actually reading comprehension.
8,767 karma · joined July 12, 2010
I sporadically rant at http://masonmark.com and usually see email sent to mason at that domain.
The reason LLMs tend to use a lot of em dashes is that the human-authored texts they were trained on used a lot of em dashes.
The "watermark" can be trivially defeated, but may be enough to satisfy the letter of the law, and like many people here, I would argue that if you are letting Claude write for you, you've already accepted getting the literary equivalent of turd soup, so the harm is — or at least could be — fairly minuscule.
[1]: https://digital-strategy.ec.europa.eu/en/policies/code-pract...
(FWIW I have a more favorable view than most people seem to of the EU's efforts to at least try tackle problems like this — but predictably, the bureaucratic "solutions" they come up with don't work, but do make things objectively worse)
For years, that was the only context in which I read Twitter, and that still holds true today for the various things that replaced Twitter for me.
The toilet is a fine place to peruse this website, too. It's pretty hard to do anything to excess if you only do it there.
Instead of trying to be present and think valuable thoughts while shitting, I recommend doing that while not shitting.
Make a habit of taking walks. Maybe learn to do mindfulness meditation. Clean the kitchen in silence.
There are really a lot of better options than locking yourself in a small room with only your thoughts and your feces.
Did you mean dogs don't have values and judgements? I suspect they do, and those might be much more different than dog consciousness vs human. And one judgement might be "human gone; i do wtf i WANT bro" or, you know, something vaguely like that.
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. :)
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.
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.
So, you might also be repped writ large in their their training data...
(;^_^)also, your last-line worldview... i mean i get it, but...
just basically sounds like the twitter origin story (T_T)
that stopped after twitter
and went asymptotically downhill from there
approaching, but never quite literally getting to the point of eating a dog shit sandwich
(despite the same nauseous feeling and bad taste in your mouth)
(still reserving judgement on Bun, though — I mean, we'll soon see, one way or the other!)
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).
¹: https://www.reddit.com/r/Deno/comments/1rwjaeb/whats_going_o...
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.
But I got it backwards. While A Deepness in the Sky is set earlier than A Fire Upon the Deep, it was actually published later, as a prequel.
So I agree. Read the first-published one, and if you like it, read the other.
Surely we can agree that one of those positions is relatively less ambitious?
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.
but sure anthropic might not agree
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." ¯\_(ಠ_ಠ)_/¯
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
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.
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.
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.
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.