Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If Claude Code LLMs are reportedly so good, then why is the Claude Code CLI such a buggy, messy, featureless disaster? Are they dogfooding?




Eesh, a disaster? I use it daily to do some pretty impressive things. Wouldn’t call it a disaster.

Some of the user interaction borders on "disaster" IMO. One puts up with it because it's not a show-stopper for the core value proposition of the software (an LLM agent completing tasks for you), and the core value proposition of the software is really valuable.

The noticeable issues are (1) unpredictable scrolling of the terminal window and (2) a super-buggy text box for inputting the prompt.

In particular if I mash the arrow key too fast while moving around and editing the prompt CC and my terminal's idea of where the cursor is get out of sync somehow and it's tricky to get them re-aligned, and I can't actually input text until I do. The vim mode lets me bypass this but it has its own bugs and is missing a ton of features that I expect. Visual selection in particular seems to be missing? Not entirely certain what things I'm used to are stock vim features vs Spacemacs features but I'm pretty sure visual mode is the former. Regardless, only the very basics seem to actually work. "w", "b", "e", "cw/b/e", "dw/b/e", "esc/i".

So for the most part I actually just edit CC prompts in emacs and paste them.

I resort to this workaround because I am very motivated to use Claude Code. For a less-useful piece of software I would probably just give up.


I've built terminal applications and when not using a dedicated alternate buffer, things like multiline text input and navigation are so easy to screw up. Not to mention when you have to do all the tricks to properly detect key strokes, pastes, etc. It's a mess of printing special codes and carriage returns.

I'm guessing they're using abstraction of some sort, but imo they've done a lot of great features and definitely usable.

That being said- they could just build / use something more like a jupyter notebook and have a wildly more stable and rich experience. Or a classic tui app, but pros and cons.


> That being said- they could just build / use something more like a jupyter notebook and have a wildly more stable and rich experience.

Right, part of the reason it stands out is that we're conditioned to much more functional text input in claude.ai (or competing web apps like ChatGPT).

I assume part of the motivation for the terminal app concept is that all the tool calls run in a deterministic environment (whatever was the environment of the shell where you launched "claude"). A Jupyter-type approach would really muddle up that whole picture (at least from a user perspective).


I really love Claude Code but it's wild to me if others aren't seeing this.

Is Ctrl+R usable at all? I've given up on it, the whole screen just starts scrolling madly most of the time. Not that I have to press Ctrl+R to get that bug to happen, it's just the most reliable way to do so.

And I've had the input box stuck not accepting input or not allowing me to delete past a certain point a hundred times. By now I know how to get it unstuck (although I couldn't tell you - my fingers figured it out but my brain doesn't know).


This is a funny comment because it's just made up

While disaster is strong language, Claude Code isn't really a well engineered product, they're just kinda trying shit, they don't have a clear long term vision. The core prompts and agent loop are good though, it's too bad it's not open source so someone could implement them in a client with good UX/engineering (at least without disassembling claude code and being legally questionable).

> not opensource

You can extract prompts with mitmproxy/netcat, and AFAIK there isn't much more to it (bash and todo list are all you need in terms of tools), there's already a lot of simpler tools with better ux:

- sst/opencode and charmbracelet/crush -- related "cc clones" with top tier UX; opencode has near feature parity with cc, crush is more barebones

- block/goose -- a lot of multi-model features and extensions (it's practically a framework), but UI is pretty basic

- antinomyhq/forge -- similar to goose, but last week they merged some PRs with agent-agent communication, yet to see how it works out

- openai/codex, gemini-cli -- both somehow don't even have a way to resume a conversation

- avante.nvim with mcphub.nvim -- neovim plugin that emulates cursor to a degree; has a crazy good hack that makes even older models like gpt4.1 "more agentic" -- it keeps reprompting the model with "STFU and write code" until the model calls a "task_completed" tool; gets diagnostics, formatting and anything else neovim can do "for free"

For the sake of completeness, closed-source:

- amp-cli -- absolutely barebones, zero configuration (they even decide what model you're using for you); one problem -- closed source, no BYOK or subscription, pay per token only

- cursor-cli -- atm unusable, can't even set a global context file

- codebuff -- yet to try it myself, but they have some sort of an overengineered setup with 5+ different models (resoner/coder/file picker (!)/fast apply/...), curious to see how it works in practice (I'm assuming this setup is strictly worse than a single sonnet4/gpt5, but much cheaper)

Claude does have a lot of unique/rare (for now) features -- hooks, sub-agents, background jobs, planning mode, per-prompt reasoning effort controls, executable bash in slash commands.

Only half of them are really useful IMHO, but I wouldn't know that if they didn't have them.


Most of those features aren't executed well though. Hooks aren't ubiquitous and have very little transformational ability, subagents are routed poorly and lack intelligent context inheritance, etc. It is a good playground to get work done for a great price while building intuition though.

What exactly are your gripes with hooks, wdym by "transformational"? Regarding ubiquity, there's already quite a few repos with collections of hooks; I've only tried notifications and format-on-write so far, the only problem I noticed is that the provided formatting hook is confusing for the model (maybe cc could backtrack and prefill the tool call with the formatter output?)

Subagents are indeed kinda useless, but in any case, I don't see anything better right now


There are events that you can't hook, and for events that you can hook, in many cases you can't do anything other than go/no go. Being able to rewrite prompts and tweak the internal state of the agent.

By which metric is it a disaster? Seems quite solid and impressive to me as it is.

I replied to a sibling comment with my observations - the upshot is the actual user interaction is quite buggy in my experience.

If you typically compose prompts in a separate editor and paste them in you aren't likely to even notice. But it's the kind of thing that would drive me up the wall in a piece of software whose primary function was less impressive.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: