alt Hacker News>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.
Replies
> 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.
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.