Been really enjoying the X3 lately. This is a great piece and ideally how a good blog post written about an experience with AI should go – authentically written, and not AI generated. I had fun reading it.
4.6 was the last model that didn’t over-cook its writing in circular loops. I use it as a daily driver and drop into fable when I’m doing higher level architectural work. 4.6 is so much more efficient in its effort.
It became obvious to me very quickly that 4.7 and on were broken. I’m a little puzzled how others didn’t realize it, but maybe they don’t actually review model output (code) or have a strong process/workflow.
It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.
Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.
>It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack.
But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
That they wont, or worse, couldn't, speaks against that.
>2. Rewrites and/or writing something in a native app or program is harder and more time consuming
Why would it be harder and/or more time consuming rather than the opposite? It's like having full specs and a full test-suite to match against the result you want.
> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.
I don't know how you can't see it, to me it's blindingly obvious: risk aversion.
Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.
I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.
You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?
And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).
> I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.
How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.
Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".
Going to give a short reply to one point because I’m about to go to sleep (I try to make an effort to be honest as to why I’m not fully engaging with the entire comment) but re: strawman, I don’t think so. When Dario Amodei is saying SWEs will be replaced soon [0], I think it follows that then he believes Claude can write a native app as well as a native app dev.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
This is a spectrum, it's not just 0% vs 100%. Even Fable frakked up a few things really badly in my professional work (though to its credit after a very detailed 2h chat it self-corrected and fixed all the blunders).
I would also challenge "fast" -- Fable (and I assume Mythos) are wicked fast and efficient and even they can't compensate for f.ex. slow recompilations or test suite reruns or security scans, linters etc.
Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
Billions of dollars of annual revenue go through Claude Code, and the people who work on it must be a lot of millions in headcount.
The time matters a fair bit, it's probably time someone can't spend breaking things in the name of new features, but if rewriting the stack had even a tiny impact on retention or driving higher usage, it would pay back that $168k.
It's going to take an order of magnitude longer though, delaying any of that revenue significantly. I'm sorry, but we're talking 11 days here. What does "maintainable" even mean with impossible time-scales like this now!?
True on the premise, remains to be seen if that's what's going to happen in practice.
In my work I have Fable/Opus add bespoke linters and tie them to verify/precommit tasks (including in CI) so nothing of the reworks and 15+ initiatives we have in flight ever regresses.
Some discipline will remove that worry of yours. It's not nice to immediately assume that the rewrite's orchestrator (Jarred) did not use discipline. He even outlined a few false starts.
You might be surprised. Runtimes can be easier to test than UI for AI, and the bun rewrite was almost line-for-line translation, whereas CC likely uses many more libraries that cannot be ported directly.
>Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
For an entity like Anthropic that's not even the cost of a single developer for a year. It's closer to what they pay a chef on premises.
That the showstopper for a better Claude agent is that they'd need to pay $168k or event $1M or even $10M in costs, can't be used as an excuse.
Lets see what happens in the future. From my experience cost of maintaining this amount of shitty code explodes pretty quickly. We will see in a few years if SW development in all phases using agents is that much automated and easy as people now predict.
I didn't claim that the cost is the prohibiting factor at all. Obviously they gave Jarred free Fable access and to do as his pleases. The cost was an FYI tidbit and nothing more.
What I argued was that you seemed to have been arguing an extreme point i.e. LLMs can one-shot stuff in any PL and that it does not matter in what PL they'd rewrite Bun.
Well, I never said anything about one-shotting it.
What I said is, those AI companies push LLMs as the replacement of programmers, that can do everything code-wise, say their programmers "don't write code anymore" etc.
So how come they can't have the LLM write something better than "react for cli" for their flagship agent product?
My only half-decent guess: they deem it too big and risky and believe they'll lose revenue while working on it and ironing out remaining kinks.
Claude Code is likely not well-specified and it's a product of rapid iteration and now nobody really knows how the whole thing works. LLMs don't do well when requirements are muddy.
It has to have been purely a marketing move. There's no other way that acquiring a software product for millions and then completely rewriting it makes any sense.
Maybe it's one of the cases when techies call the shots?
I can understand people being more sold on Rust compared to Zig -- there are legitimate differences on the memory safety front and I can see how people will prefer one or the other.
Plus I believe Jarred (Bun's main dev) went out of his way to explain why he chose Rust over Zig in his blog post.
Of course the marketing angle might indeed be the explanation; not arguing against that, I simply followed with interest and Jarred seemed very reasonable to me.
The rewrite makes sense, it's all their dog food at that point. It's the acquisition that doesn't make sense. Why didn't Anthropic just rewrite it themselves?
> Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?
> by making it cheap and fast to build whatever you like automatically.
Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount.
At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished.
If you do that and don't spend enough effort on making it be something polished --> your competitors have a better product and you lose.
If you pause feature development to give enough effort to the initiative, you don't get to add new features quickly enough --> your competitors have a better product and you lose.
Maybe their priorities lay elsewhere, like how I've noticed that the desktop app version of Claude Code has gotten both faster (no 2-4 second lag when switching conversations), more stable and usable over time, to where I enjoy using the models because of it, not in spite of it (though not that they haven't had bumps along the way, like that one cache invalidation issue, or how people didn't like the auto accept timeout thing). I don't doubt that you can get pretty far with gradual patches and improvements, instead of only big rewrites.
Honestly it's really cool for me to see Kimi having their own CLI too, same with OpenCode, Pi, Hermes (well more of an agent than just a coding harness but you get the idea) - there's so many competing solutions out there, each good or bad in unique ways.
Just wish we'd see similarly many GUI solutions, for now OpenCode GUI seems like the one I've settled on (cross platform and supports most models), though it's not exactly ideal either (feels a bit barebones, especially in regards to sub-tasks and progress/plan tracking, even ZCode seems a bit better in that regard, it was actually surprisingly good after they pushed out some updates).
I don't think they bought them just for the claude-code gui harness as it is now. it's to have strategic control over some software runtime they can use to do other things related to verification, deployment, and end to end value delivery. Same reason other companies are buying up dev tools.
Yeah it was a little tongue-in-cheek--I think the estimate I saw was over $100M for bun, which would have been enough to pay Donald Knuth to rewrite Claude Code, let alone AI.
I suspect it's at least partly akin to OpenAI buying uv where they did not want a startup with questionable profitability horizons that serves as a critical piece for their business to get suffocated when VCs come for their money back.
By the same argument, why does it matter from the technology stack side? It doesn't just nullify the business concerns - it largely nullifies the tech stack concerns. Your preference doesn't matter if you aren't touching the code and the product works for your user base.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.
They succeeded in spite of their tech choices. Their model outshone it, which is an extremely rare thing to happen and not something they could've counted on. In any other timeline they could've/would've been hurt by their choices.
It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"
As much as an enthusiast dev like myself hates it -- this is innately true, way too often.
I am 46 y/o and still excited to code and solve problems with code and I still have trouble to admit to myself sometimes that people make dozens of millions with PHP and the tech hardly matters when you can throw bodies at the problem (and when that throwing of bodies at the problem actually solves it, of course).
> I still have trouble to admit to myself sometimes that people make dozens of millions with PHP
Or many billions. eg. Facebook was originally written in PHP.
As a 52 y/o who cares deeply about software development as an art I don't have trouble admitting that the tech hardly matters relative to the economics, that was obvious to me very early in my career.
I have just never really cared because there has always been a path where you can have a decent career being paid to work on and with good technology in spite of the fact that the technology wasn't important to the economics.
I do fear that the rapid adoption of LLMs will probably cause the path I took to narrow considerably. There will likely be less companies willing to pay people to work on elegant technology when they are all competing against endless code generation machines (and this is assuming software companies can exist at all in this future). But at my age that's more of a concern for younger people than me.
I hear you on the worry, I have the same (and probably so do most devs even).
But IMO the endless churning of code will slow down, if it has not already. Quantity does not equal quality as we know, it even erodes it. There are already consulting companies that are "vibe-code fixers".
I am also not sure it's about "elegant" code. What we might call elegant has multiple measurable axii f.ex. well-isolated effectful code layer so you can easily static-code-check it, domains and enforcement of boundaries between them, bespoke linting to enforce business processes and standing code discipline, and many others.
Apply this reasoning to any other industry. Yes the average person is not the judge of the quality of a doctor or engineer. That doesn’t invalidate it. You want a doctor who cares about medicine , not whatever will accomplish a business goal.
Eh, the rendering of Claude Code is genuinely such a mess. I have quit claude code over it because when used as a terminal in PHPStorm it sometimes gets so bad that it becomes hard to use.
This isn't a minor nitpick, it's a pretty major UX issue.
Not saying it's like a massive business downside because I'm just one of a few users, maybe this affects their bottom line a little bit, but probably not by much.
Regardless, switching to pi has been a nice breath of fresh air. It just renders well and smoothly and handles terminal resizes well, which is especially important when used in a terminal window in PHPStorm.
Truthfully, the terminal in Jetbrains IDEs just isn't that great. It's gotten a lot better with their rewrites (yes, plural) of the last years, especially on Windows, but it can still be pretty dodgy.
The choices were clearly (far) less important than having the best model and a good product that was way ahead of the competition.
However, that's not the same as the technology choices not mattering at all. As others have mentioned the product is buggy, and it appears Anthropic are struggling to continue to release new features within the existing architecture.
That's also not to say that Anthropic made bad choices - there's always going to be a tension between building quickly to capture the market now vs moving slower and building something more maintainable in the long-term.
It is rarely the case that technology choice is the make-or-break when it comes to whether a product is successful and achieves widespread adoption. Some choices are less ideal than others, but at the end of the day if you manage to make something that people want, the rest won't matter much.
What do you mean in spite of their tech choices? When have the tech choices ever been an issue in the lifespan of Claude Code? From where I sit, it seems like their tech choices enabled them to create an industry-defining product.
I mean people are using Claude Code because of their underlying LLM - they'll put up with Claude Code. There's no other real option to get Opus at a reasonably affordable price without CC.
Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).
I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not.
Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs.
OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug.
If you’re holding the SOTA crown, people will put up with your buggy mess. As soon as that crown slips your pile of trash becomes a huge liability.
So weird that the same exact people telling you that programming careers are now obsolete are the same group who haven't been able to fix screen flickering bugs for like a year...
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
That does seem to be the way many use it. I'd be very surprised if they didn't have to insert a rule to prevent opus from constantly asking why they didn't just use ncurses. I just asked sonnet for design options for a tui to onteract with llms to perform sw dev tasks. After describing the tui it immediately suggested ratatui and crossterm as the tech stack. I feel like they must have ignored even the advice of their own llm to come up with this solution.
Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.
This reply makes no sense in this context, though. Sure, it exploded in popularity based on whatever random tech choices were made. But now, when apparently they're deciding there's a problem there, why unleash $150k of tokens to rewrite a JS runtime wrapper from Zig to a million lines of rust, rather than simply rewrite Claude Code itself to rust?
They probably should rewrite it in Rust, but also, I think the Bun guy wanted to rewrite it in Rust because he thinks Rust is a better choice for Bun, independent of Bun being used by Claude Code.
This speaks for the benefits of JavaScript runtimes like Bun and Node.js. JavaScript is a dynamically typed language which makes it a good choice for explorative programming. It is a Lisp in sheeps' clothing.
Programs which need more stability and performance than exploration are better done in statically typed languages like Rust. Therefore Bun is a platform for JavaScript programming, but itself is written in Zig or Rust.
This is the “eating yogurt with a hammer” argument. Yes, of course you can do that. Yes, the yogurt gets eaten. It’s just… you see someone eating yogurt with a hammer and it’s hard not to wonder wtf is going on.
...while proving their technology has finally reduced these questions down to what's best, instead of "how much effort will it take to be good enough".
If you have unlimited access to the magical development tool, then why would you not?
This is a useless post-hoc rationalization. "It worked out, so it doesn't matter". You're trying to galaxy brain yourself into ignoring the obvious conclusion.
The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.
> It largely works and it's a massive business success.
You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.
One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.
For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?
Could it be that they aren't being entirely honest?
Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.
This is far less so in this case because this is thier hot path. Everything runs through it and tens of billions in revenue depends on it. It needs to be as fast and solid as possible
This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.
As an industry we are responsible for making our part good. So yes a business can succeed in spite of bad tech choices, but that doesn’t make it good tech.
No, it's because they wanted a unified pipeline in claude code, claude app, and their website. All of them use more or less the same claude features (claude code has artifacts, claude website has "Ask User a Question" tool, etc.).
Much less fragmented compared to "write the app 3 times in 3 different languages".
I think it makes sense that when you've outlawed competition for many/most users of your product's matching service that you would cheap out on it if you were maximally extractive and took no pride in your work, sure.
But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.
"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."
I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld
But the people usually just nod along.
The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
> The only awkward thing is when I am in person or on the phone and have to explain that my customer email address
I had one small business aggressively threaten me that they fully owned their business name and I wasn't allowed to use it in my email address.
My solution was to keep my wonderful aliases and dump them. If a business is concerned but nice about it I'll offer an alternative such as plumber@
> The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
If you have your own domain most mail providers don't care what username@ you use on your sent mail so you shouldn't need any additional mailboxes (especially if they already offer inbound catch all)
I also use the ReplayAsOriginalRecipientUp [1] extension in Thunderbird which takes the recipient address and puts it as the sender for ongoing communication.
> I had one small business aggressively threaten me that they fully owned their business name and I wasn't allowed to use it in my email address.
I haven't had that, but before I switched to Hide My Email I've had many businesses ask if I was an employee of the business - many people don't intuit the difference between john@bank.com and bank@john.com.
So I guess I'll take a moment and plug my email provider, Fastmail. Their integration with 1Password to enable creation of Masked Email at account creation time is really fantastic! I have several hundred of these at this point, it's made my digital life appreciably better.
But to the point of forward-in-only -- I use the fastmail web client and iOS client. Both of these respond using the Masked Email address if you choose to respond to an email. In fact I can choose any of my masked email addressed as I am composing mail to initial communication from that address.
In short, "it just works". I really can't say enough good things about Fastmail!
Just happened to me today! I was at the Verizon store and my address was verizon@... Sometimes it leads to confusion, but sometimes it leads to getting extra special treatment actually! They think I'm someone important.
Not really, this only works for other emails hosted by Gmail (including Workspaces) or if you supply SMPT that will send those emails. If you use simple email forwarding from your DNS provider, you don't have SMPT server to give to gmail:/
Google will happily send from smtp.gmail.com, after verifying that you own that email. You won’t get DKIM, but Google’s reputation is enough to make the mail land in people’s inboxes.
Can someone explain to me if EU card transactions are capped, why Stripe charges me (US) the full ride on my EU customer's cards? In fact, I get charged even more for EU cards – perhaps as much as 2.5% extra.
I just checked and I get charged ~8% in fees on a 10 euro transaction on Stripe. Of course some of that is the low transaction amount (flat 0.30), but it's brutal for a small business like myself.
The EU only capped interchange fees, which is the amount that goes to the bank that issued the card. It did not cap the fees that go the your PSP. Which makes sense, since you can pick the PSP you do business with, but you can't pick the bank that issues your customers' cards.
(And I don't think it applies to US merchants like you anyways)
perhaps they are capped only for EU merchants, because EU government works to protect their own companies and citizens from foreign artificial unregulated monopolies.
in US, the government is more protective of private monopolies due to lobbying
How are you defining monopolies? Companies that are successful? Because you seem to be defining most US companies that do business in Europe as monopolies. It seems that this is the kind of mindset that has kept Europe behind. Too bad. Regulation that keeps out competition or needlessly puts obstacles in place is bad for the consumer, bad for employment, and bad for the general standard of living. And If you think US companies are unregulated then you haven't seen the 20 ft of federal CFR regulations together with the regulations of 50 different states that US companies have to deal with everyday.
Interestingly, the EU did manage to cap interchange on US cards paid by EU merchants to pretty much the same rate as that paid for domestic/intra-EU cards, at least at the POS. Many things are possible with a regulator with teeth.
I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.
It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.
Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.
It's also always worth noting that RSCs don't require a server, and still bring value without one.
It's a shame that VCs have corrupted a $200MM/year business into the perception as a failure. Who cares if the VCs didn't get a large return, or if the outsized impact of the software didn't quite fully capture the value created. $200MM/yr without aggressive R&D or operational costs could be an incredibly healthy business.
Maybe we should stop trying to build so many billion dollar/year businesses and work on more sustainable models.
I haven’t followed Docker’s case in particular, but how much investment was required to get it to that point? If it’s a case of “How do you become a millionaire? Start as a billionaire and invest in Docker”, then the perception may have some basis.
Yes but that is just a tiny part of the whole CF worker ecosystem. The other services are not open source and so the lock-in is very very real. There are no API compatible alternatives that cover a good chunk of the services. If you build your application around workers and make use of the integrated services and APIs there is no way for you to switch to another provider because well, there is none.
reply