Comment by trymas
3 hours ago
If I would get a dollar each time a developer (or CTO!) told me "this is (relatively) simple, it will take 2 days/weeks", but then it actually took 2 years+ to fully build and release a product that has more useful features than bugs...
I am not protecting anthropic[0], but how come in this forum every day I still see these "it's simple" takes from experienced people - I have no idea. There are who knows how many terminal emulators out there, with who knows how many different configurations. There are plugins for VSCode and various other editors (so it's not only TUI).
Looking at issue tracker ~1/3 of issues are seemingly feature requests[1].
Do not forget we are dealing with LLMs and it's a tool, which purpose and selling point that it codes on ANY computer in ANY language for ANY system. It's very popular tool run each day by who knows how many people - I could easily see, how such "relatively simple" tool would rack up thousands of issues, because "CC won't do weird thing X, for programming language Y, while I run from my terminal Z". And because it's LLM - theres whole can of non deterministic worms.
Have you created an LLM agent, especially with moderately complex tool usage? If yes and it worked flawlessly - tell your secrets (and get hired by Anthropic/ChatGPT/etc). Probably 80% of my evergrowing code was trying to just deal with unknown unknowns - what if LLM invokes tool wrong? How to guide LLM back on track? How to protect ourselves and keep LLM on track if prompts are getting out of hand or user tries to do something weird? The problems were endless...
Yes the core is "simple", but it's extremely deep can of worms, for such successful tool - I easily could see how there are many issues.
Also super funny, that first issue for me at the moment is how user cannot paste images when it has Korean language input (also issue description is in Korean) and second issue is about input problems in Windows Powershell and CMD, which is obviously total different world compared to POSIX (???) terminal emulators.
[0] I have very adverse feelings for mega ultra wealthy VC moneys...
[1] https://github.com/anthropics/claude-code/issues?q=is%3Aissu...
Although I understand your frustration (and have certainly been at the other side of this as well!), I think its very valuable to always verbalize your intuition of scope of work and be critical if your intuition is in conflict with reality.
Its the best way to find out if there's a mismatch between value and effort, and its the best way to learn and discuss the fundamental nature of complexity.
Similar to your argument, I can name countless of situations where developers absolutely adamantly insisted that something was very hard to do, only for another developer to say "no you can actually do that like this* and fix it in hours instead of weeks.
Yes, making a TUI from scratch is hard, no that should not affect Claude code because they aren't actually making the TUI library (I hope). It should be the case that most complexity is in the model, and the client is just using a text-based interface.
There seems to be a mismatch of what you're describing would be issues (for instance about the quality of the agent) and what people are describing as the actual issues (terminal commands don't work, or input is lost arbitrarily).
That's why verbalizing is important, because you are thinking about other complexities than the people you reply to.
As another example `opencode`[0] has number issues on the same order of magnitude, with similar problems.
> There seems to be a mismatch of what you're describing would be issues (for instance about the quality of the agent) and what people are describing as the actual issues (terminal commands don't work, or input is lost arbitrarily).
I just named couple examples I've seen in issue tracker and `opencode` on quick skim has many similar issues about inputs and rendering issues in terminals too.
> Similar to your argument, I can name countless of situations where developers absolutely adamantly insisted that something was very hard to do, only for another developer to say "no you can actually do that like this* and fix it in hours instead of weeks.
Good example, as I have seen this too, but for this case, let's first see `opencode`/`claude` equivalent written in "two weeks" and that has no issues (or issues are fixed so fast, they don't accumulate into thousands) and supports any user on any platform. People building stuff for only themselves (N=1) and claiming the problem is simple do not count.
---------
Like the guy two days ago claiming that "the most basic feature"[1] in an IDE is a _terminal_. But then we see threads in HN popping up about Ghostty or Kitty or whatever and how those terminals are god-send, everything else is crap. They may be right, but that software took years (and probably tens of man-years) to write.
What I am saying is that just throwing out phrases that something is "simple" or "basic" needs proof, but at the time of writing I don't see examples.
[0] https://news.ycombinator.com/item?id=46877204