Yeah, this is what I’m trying to get at.

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.

> 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.

> 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).

How much extra money do you think they would make if Claude Code wasn’t JavaScript?

>making it cheap and fast to build whatever you like automatically

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.

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.

Or those choices just don't matter, it's fundamentally just "tabs vs spaces".

>> They succeeded in spite of their tech choices.

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.

> basically anything that isn’t typing characters has had/still has unaddressed bugs.

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.

> I loathe their bug-ridden UI.

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...

Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.

The vim mode in that text box was a mess for sure

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.

Correct

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.

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.

...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?

But they haven't.