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.
There’s two arguments in competition:
1. LLMs make it cheap (in the time sense) and easy to build
2. Rewrites and/or writing something in a native app or program is harder and more time consuming
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.
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.
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 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".
0 - https://finance.yahoo.com/news/anthropic-ceo-predicts-ai-mod...
Now whether they can do it -- that's a separate, and a much more interesting, discussion.
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.
You might get more maintainable code for $168k by hiring humans, but if its something bespoke it isn't going to get you far (or far quickly).
Vibing is straight out gambling right now, the thing is, I don't know who the house is any more.
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.
The major open harnesses are in the ~800k lines of code size ( https://simonwillison.net/2026/Jul/15/grok-build/ ) and CC is the oldest and quite-likely largest judging by features.
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.
The argument I responded to argued that cost might be the prohibiting factor. I'm saying that for them, the costs mentioned are negligible.
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.
If I misunderstood -- my apologies.
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?
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.
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.
they rewrite themselves, Bun team is under Antrophic umbrella
Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?
Jarred used many agents and they worked 24/7. It tracks for me.
So yes, I do believe it. What makes you skeptical?
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).
In 2 years? A well-engineered TUI could be the difference between the Blackberry and the iPhone for all we know.
This can be true, while "nullifies such "business" concerns" can be false. Both are not dependent on each other.
Automation doesn't "nullify business concerns", it just changes them.
Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.
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!"
Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
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).
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.
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.
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.
Tabs vs spaces makes no tradeoffs. Tech choices do
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.
They couldn't even fix flickering in their TUI and their new renderer is complete garbage.
They succeeded despite their tech.
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.
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).
Sorry, I'm bad at analogies.
This is just blatantly ignoring all of the glaring issues Claude Code has had over its lifespan.
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.
Oh, that's buggy too. I just tried Claude Code on win10 powershell, and the first typed character goes in the wrong spot and can't be backspaced.
It is by far the the least reliable program on my machine, and every time I have to interact with it I feel like walking in eggshells.
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...
Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.
Nobody but a JS dev would choose react-on-terminal shenanigans over it
I could see CC getting a ratatui port eventually actually
the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.
And the question of “if AI is so amazing, shouldn’t it enable easy development of a native TUI even if JS is easier at first?”
Don’t get me wrong I find great value in coding agents daily. Just finding the hype cycle tiring.
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.
The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.
If you have unlimited access to the magical development tool, then why would you not?
But they haven't.
A ringing endorsement!
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.
I'd argue these tech companies got popular because they have good models, nothing else.
Even OpenAI took two years to fix basic chat scrolling.
Could it be that they aren't being entirely honest?
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.
Much less fragmented compared to "write the app 3 times in 3 different languages".
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."