Does Developer Delight Matter in a CLI? The Case of Charm’s Crush

Crush shows the CLI can be AI-Native and Glamorous

Released in July, and now amassing 12k stars, Crush is a new open-source command-line AI coding assistant developed by CharmBracelet (the team behind tools like Glow).

It provides a terminal-based interface for devs to interact with a coding agent (npm install -g @charmland/crush). Crush works with a wide range of models (via OpenAI, Anthropic, and other APIs) and lets you switch models mid-session while preserving context.

You can maintain multiple sessions per project, meaning Crush remembers conversation history and file context across runs. This helps when working on larger tasks or hopping between different projects without losing context.

Crush ties into Language Server Protocol (LSP) servers to inject code-aware context into the AI’s prompts. If you’re unfamiliar with the term, LSP lets editors talk to language servers for code intelligence: a simple example is that when you type math.sq in Python, the LSP automatically suggests math.sq,[object Object],.

This means Crush can understand type signatures, function dependencies, and project structure. It also supports MCPs for plugging in external tools and context sources.

True to Charm’s ethos of making the command line “glamorous”, with successful OS projects like bubbletea, gum, and lipgloss, Crush has a modern and playful text-based UI. It features a split-pane view (with things like a dedicated diff view for code changes) and intuitive keyboard navigation, aiming to feel friendly and futuristic.

Community: Crush sparks joy, comparisons, and cost questions

The consensus so far: Crush offers a refreshing UX and solid foundation, but it’s one player in a bigger trend. As one observer quipped, the “terminal-based AI coding agents” trend is hot, and everyone is experimenting to see which tool will stick.

The word “playful” came up frequently in our research - CharmBracelet’s TUI framework pedigree (Bubble Tea, etc.) is well respected, so seeing those slick visuals applied to an AI assistant delighted people.

Shifting gear, a Hacker News user requested a detailed “comparison between all these new tools” – listing Crush, Claude Code, OpenCode, Aider, and Cortex – because “I just can’t get an easy overview of how each tool works and is different”.

This captures a common reaction: excitement about the tool, paired with the question “How does it stack up against X?”. This sentiment shows both the interest in these AI dev agents and the fragmentation of the ecosystem. It’s not often we see multiple similar tools gain popularity almost simultaneously, so community members are trying to map the space, often through first-hand trials and discussions.

Some devs also lamented that they feel “in golden handcuffs” with proprietary tools like Claude’s official app, because those offer unlimited usage for a flat rate, whereas using something like Crush with pay-as-you-go APIs could rack up costs. We might see future updates focus on easier integration with subscription-based models or better support for local LLMs to alleviate cost issues.

Will AI dev tools win on delight? Thoughts on DevX vs Model Capability

OpenAI’s CFO recently described a vision of an “agentic software engineer” – essentially an AI that could take a high-level project description and autonomously build and iteratively improve software.

AI is becoming a first-class citizen in dev workflows. Just as version control or stack overflow search became ingrained in a dev’s day-to-day, AI assistants (be it in the terminal, editor, or IDE) are heading in the same direction, helping with brainstorming, coding, debugging, and documentation. But, who will win devs’ hearts?

Many of these AI coding assistants rely on the same or similar underlying models. If every tool can hook up to GPT-5, Claude Opus, or the next open-source model, then what sets them apart? I believe there is merit in thinking that it would be how effectively they let devs harness those models and how much delight they bring to the experience.

I’ve come to a similar conclusion upon writing a comparison of Windsurf, Cursor, Copilot with GPT-5. Building with these tools brought me to the finish line in all cases. But how I got there, and the feelings I had as a dev varied. The real differences showed up in workflow ergonomics, UI polish, and how much hand-holding each agent needed.

History offers instructive analogies: Betamax vs. VHS is often cited – Betamax was arguably the superior video tape technology, but it lost the format war due to practical UX factors (shorter recording time, higher costs, less industry support) . Similarly, HD DVD vs. Blu-ray ended with Blu-ray victorious not purely for technical reasons but due to strategic partnerships and consumer perception.

Conversely, a pleasant, well-integrated tool can win even if under the hood it’s not radically different. Crush’s playful interface and thoughtful touches (like preserving scrollback, offering diff views, etc.) might seem cosmetic, but they significantly impact adoption.

As one HN user pointed out, even something as simple as syntax highlighting or colorful text can change how we feel about a tool - decades ago, some old school devs scoffed at such features as unnecessary, yet today we take them for granted as usability must-haves.

Looking ahead, AI dev tools will increasingly compete on the design choices that shape how enjoyable and intuitive they feel to use. Delight matters. Still, real hurdles remain: accuracy, reliability, and trust in code generation. Developers will need guardrails - tests, reviews, and structured practices- to confidently fold AI into their workflows.

At AI Native Dev, we believe one promising path is spec-driven development: anchoring AI contributions in clear, testable specifications that keep humans in the loop and guardrails agents. If you’re curious about how this concept, you can explore more about it here.