47 ms·

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

by switz 2mo ago

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.

deleted 2mo ago
[deleted]
galangalalgol 2mo ago
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.
- weakfish 2mo ago
  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.
- bwfan123 2mo ago
  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.
  - jubilanti 2mo ago
    > for sw that is intended to be built to last, I dont see this working out. the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
    - zdragnar 2mo ago
      Did it really exist? I remember buying games on discs as a kid that had bugs in them that prevented you from actually finishing the game at all. I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.
    - nozzlegear 2mo ago
      The era in which the [VC-backed, SV area] tech industry built software to last was over long before LLMs.
  - galangalalgol 2mo ago
    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.
    - simonw 2mo ago
      They decided on the tech stack for Claude Code over a year and a half ago.
      - tough 2mo ago
        ratatui was still an excellent choice over a year and a half ago. Nobody but a JS dev would choose react-on-terminal shenanigans over it I could see CC getting a ratatui port eventually actually
tripleee 2mo ago
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!"
- benoau 2mo ago
  > They succeeded in spite of their tech choices. Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
  - azeirah 2mo ago
    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.
    - lucumo 2mo ago
      > when used as a terminal 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.
      - jamienicol 2mo ago
        That may be so but Claude code certainly has rendering glitches in other terminals too.
    - vips7L 2mo ago
burner54828182 2mo ago
> “It largely works” A ringing endorsement!
coldtea 2mo ago
>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.
- weakfish 2mo ago
  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.
  - pdimitar 2mo ago
    > 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".
pjmlp 2mo ago
So Claude isn't great for everything?!?
adastra22 2mo ago
Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.
yojo 2mo ago
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.
- yojo 2mo ago
  Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.
- BoppreH 2mo ago
  > 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.
- neutronicus 2mo ago
  The vim mode in that text box was a mess for sure
- cvadict 2mo ago
  > 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...
nullsanity 2mo ago
[dead]
groundzeros2015 2mo ago
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.
reinitctxoffset 2mo ago
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."
femiagbabiaka 2mo ago
It doesn’t work, it performs horribly and is full of bugs. Serious people use open harnesses.
realusername 2mo ago
> It largely works and it's a massive business success. 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.
geraneum 2mo ago
> It largely works and it's a massive business success. The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.
- dd8601fn 2mo ago
  ...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.
losvedir 2mo ago
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?
- jolux 2mo ago
  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.
- galaxyLogic 2mo ago
  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.
solid_fuel 2mo ago
> 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.
- complianceowll 2mo ago
  I disagree, Solid Fuel.
  - solid_fuel 2mo ago
    Nobody cares what a bot account thinks.
    - complianceowll 2mo ago
      [flagged]
wonnage 2mo ago
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.
tacitusarc 2mo ago
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.
vips7L 2mo ago
Any choice would have made obscene money in this market. It doesn’t make it a good choice.
DoesntMatter22 2mo ago
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
behnamoh 2mo ago
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".
ozozozd 2mo ago
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.
LtWorf 2mo ago
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?
overgard 2mo ago
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.

by switz 2mo ago

deleted 2mo ago

[deleted]

galangalalgol 2mo ago

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.

weakfish 2mo ago
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.
bwfan123 2mo ago
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.
- jubilanti 2mo ago
  > for sw that is intended to be built to last, I dont see this working out. the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
  - zdragnar 2mo ago
    Did it really exist? I remember buying games on discs as a kid that had bugs in them that prevented you from actually finishing the game at all. I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.
  - nozzlegear 2mo ago
    The era in which the [VC-backed, SV area] tech industry built software to last was over long before LLMs.
- galangalalgol 2mo ago
  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.
  - simonw 2mo ago
    They decided on the tech stack for Claude Code over a year and a half ago.
    - tough 2mo ago
      ratatui was still an excellent choice over a year and a half ago. Nobody but a JS dev would choose react-on-terminal shenanigans over it I could see CC getting a ratatui port eventually actually

tripleee 2mo ago

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!"

benoau 2mo ago
> They succeeded in spite of their tech choices. Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
- azeirah 2mo ago
  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.
  - lucumo 2mo ago
    > when used as a terminal 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.
    - jamienicol 2mo ago
      That may be so but Claude code certainly has rendering glitches in other terminals too.
  - vips7L 2mo ago

burner54828182 2mo ago

> “It largely works” A ringing endorsement!

coldtea 2mo ago

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

weakfish 2mo ago
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.
- pdimitar 2mo ago
  > 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".

pjmlp 2mo ago

So Claude isn't great for everything?!?

adastra22 2mo ago

Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.

yojo 2mo ago

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.

yojo 2mo ago
Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.
BoppreH 2mo ago
> 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.
neutronicus 2mo ago
The vim mode in that text box was a mess for sure
cvadict 2mo ago
> 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...

nullsanity 2mo ago

[dead]

groundzeros2015 2mo ago

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.

reinitctxoffset 2mo ago

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

femiagbabiaka 2mo ago

It doesn’t work, it performs horribly and is full of bugs. Serious people use open harnesses.

realusername 2mo ago

> It largely works and it's a massive business success. 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.

geraneum 2mo ago

> It largely works and it's a massive business success. The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.

dd8601fn 2mo ago
...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.

losvedir 2mo ago

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?

jolux 2mo ago
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.
galaxyLogic 2mo ago
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.

solid_fuel 2mo ago

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

complianceowll 2mo ago
I disagree, Solid Fuel.
- solid_fuel 2mo ago
  Nobody cares what a bot account thinks.
  - complianceowll 2mo ago
    [flagged]

wonnage 2mo ago

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.

tacitusarc 2mo ago

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.

vips7L 2mo ago

Any choice would have made obscene money in this market. It doesn’t make it a good choice.

DoesntMatter22 2mo ago

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

behnamoh 2mo ago

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

ozozozd 2mo ago

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.

LtWorf 2mo ago

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?

overgard 2mo ago

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.