[j45]

Claude Code could absolutely build a chat client in the hands of someone who could also build the rest around it.

Slack itself originally ran on irc servers as the back end, and I consider it a modern IRC implementation.

[troupo]

> Claude Code could absolutely build a chat client in the hands of someone who could also build the rest around it.

So why can't Anthropic build a CLI client that doesn't flickr and doesn't consume 68 GB to run a CLI wrapper on top of their API? https://x.com/jarredsumner/status/2026497606575398987

[senko]

That's still light years better than Slack.

The thing lags a few seconds while typing a message on a 20 core 128g ram machine. That's with their desktop (electron) app. Mercifully, the web app works better.

Still, CC blows it out of water. Slack is that bad.

[quesera]

Something important must be different about our Slack environments. Maybe it's the number of users, or possibly the OS?

We're a small company (about 150 Slack users), and I've run the Slack (Electron) app on a 16GB M2 (macOS) and a 4GB Chromebook (running a non-ChromeOS Linux), and it has never had any noteworthy performance issues.

It still sucks, but not because of performance.

[troupo]

How is it "light years better than Slack"?

It's a terminal wrapper for Anthropic API. It somehow baloons to 68 gigabytes when all it needs to do is call an APi and slowly draw a few hundred characters on screen. And they can't even do that without flickering. Oh yes, and until very recently it would also consume a significant percentage of CPU just waiting for input to a slash command.

Yes, on that same 20 core 128g RAM machine.

You surely must be kidding. Slack is an amazing cutting edge high performance tech in comparison as it has about two orders of magnitude more features that a TUI API wrapper.

[theshackleford]

your instance does that. Mine does no such thing and I don’t know anyone for whom it does.

Not to say it doesn’t, but it’s clearly not a universal issue.

[paradox460]

They are using react for that

Not even joking

[brookst]

Can’t != not prioritizing

[troupo]

No. They literally can't.

E.g. they claim it's a difficult task to render a few hundred characters on screen, and that their CLI wrapper is a tiny game engine: https://x.com/trq212/status/2014051501786931427

They literally had to buy bun to have someone who understands how things work to fix this

[bdangubic]

that is 1/8 of Slack so it’d be progress :)

[troupo]

Slack doesn't require nearly as much to run. And Slack has about two orders of magnitude more functionality

[bensyverson]

Yeah, I have so much less patience for "this should exist" posts. In 2026, you could argue that this blog post should have come with a link to the repo.

[monsieurbanana]

I don't want everybody with an idea making a repo. It's already hard enough to filter out the slop in github that I'm reluctant about using anything built in the past year.

[bensyverson]

I hear you, but it's not like the quality bar on Github was super high before AI

[monsieurbanana]

It might not have been. But it's not hard to see that whatever productivity coefficient multiplier llms brings, it's being dwarfed by how much easier it is to publish projects that only look good on the surface.

While it's a great tool in the hands of capable and well intentioned people, there's not a world out there where the average quality of software goes up.

[j45]

Underrated comment.

Even if AI with autonomous agentic development made something that worked at the average of code quality, I wonder if the code might be a little more sturdy, predictable, and the compromise is a little more verbose for the level that works for the AI to manage it.

Humans would then help oversee the input, insight, and extension and improvement above and below that.

AI could be a baseline.