There is the same divide starting to form that NFTs had back in the day. Tech bros instantly like if something has claw in the name, the rest of us will dismiss anything with that naming and philosophy as toxic slop culture. will be interesting to see how far this one will go.
Its just another example and just a detail in the broader story: We cannot trust any model provider with any tooling or other non model layer on our machines or our servers. No browsers, no cli, no apps no whatever. There may not be alternatives to frontier models yet, but everything else we need to own as true open source trustable layer that works in our interest. This is the battle we can win.
Why don't people form cooperatives, contribute to buy serious hardware and colocate them in local data centers, and run good local models like GLM on them to share?
We are starting to! TBH it will take some time until this is feasible at larger scale but we are running a test for this model in one of my community groups.
This take is so incredibly short sighted. Sure mcp is not perfect and needs better tooling and a bit updated standards, but clis are >maybe< just the future for agents that are clis themselves but i would argue these agents will be not the mainstream future but a niche i call "low level system agents" or things for coding bros. An agent of the future needs to be way more secure, auditable, reasonable and controllable none of which is possible by slapping a cli with execution rights into a container even with a bubblewrap profile. An agent of the future will run in a sandbox similar to cloudflare workers/workerd isolate with capabilities. The default will be connecting one central MCP endpoint to an agent that runs in its own sandbox without direct access to the systems it works on. The MCP gateway handles all the things that matter, connecting LLM providers, tokens for APIs, enforcing policies, permission requests, logging, auditing, threat detection and also tools. Tools execute on the container level, so there is not even a need to change anything about any existing containerised workloads, its all transparently happening in the container realm. I am not saying system level agents have no use but any company running anything like kubernetes or docker compose will have zero need or tolerance for an agent like that.
Can we please not change the meaning of chat to mean agent interface? It was painful to see crypto suddenly meaning token instead if cryptography. Plus i really dont want to “chat” with ai. its a textual interface
Fair point, although I think we have OpenAI to blame for that - for buying chat.com and pointing it to the most popular textual AI interface of them all :)
Its an interesting direction if you see it under the umbrella of diminishing costs: You build a product once with vibe coding and a design/ product hat. Once you know what works you rebuild it 100% in a framework like this. You do this every time from scratch when the tech debt or the mismatch between architecture and needs are too big.
You could also use the same framework always - that's what I'm doing anyway. But you gotta remember that no matter how well you spec it, first iteration of the specs is going to suck anyway.
But you vibe-code it anyway and see what happens. You'll start noticing obvious issues that you can track back to something in spec.
Then you throw away the entire thing (the entire project!) and start from scratch. Repeat until you have something you like.
Incremental specing doesn't work though. You need a clean room approach with only important learnings from previous iterations. Otherwise agent will never pick a hard but correct path.
I keep reading these unfair comparisons mixing many different problems into a naive story in favour of clis.
First of all no one should still consider connecting mcps directly to agents, this is completely outdated, you connect mcps and tools to a single gateway that has an api, handles federation, auditing, prolicies and much more. A good gateway exposes a tiny minimal context with just instructions how to query what is available and has a configurable "eager" flag for the things that should be put eagerly into the context for certain agent profiles.
Secondly many many mcp servers are outdated as they were build for way dumber models than what we have today and will have overly heavy context and descriptions that slow down and degrade the current frontier models. If you compare a cli to a state of the art agent gateway setup with adjustments for the current models, you will find that the only advantage for clis is operational complexity.
Its funny how many variations of meaning people assign to agent related terms. Conflating agent with cli and as opposite spectrum of ide is a new one i did not encounter before. I run agents with vscode-server also in a vm and would not give up the ability to have a proper gui anytime i feel like and also being able to switch seamless between more autonomous operation and more interactive seems useful at any level.
The same could be said for color, just to then go into detail that using color codes on too many columns and with unclear associations are the problem. This is just a weird way to frame an article. Colors and icons are indeed essential to quickly parse and use big amounts of tabular data. All the criticisms the author brings forward are specific problems of some implementations or just poor choices. All this is solved by putting a few key icons in their own column next to the text field they belong to, so users can hide and show them as needed depending on the task. I have eg. a basic indicator that is a red exclamation mark or yellow question mark or green checkmark and another one with a colored icon representation of a category field. Its 100 times easier to get a quick impression and find something than without those. if someone has a problem its 2 clicks to hide the columns, thats the universality of a table ui! Don’t let absolutist click bait articles fool you.
As nice as zulips aspirations may be, every time i have to use it for a community i effectively stop interacting with them after a short while just because everything is janky, ugly and feels like a drag to interact with, just tried opening it on my phone to see if it improved but the header ui is just plain broken.
Are you using iOS? Safari 26 has several changes that break the mobile web app layout, and it's proven quite difficult to fix. I'd suggest using the actual mobile app on iOS if you've upgraded to Safari 26.
(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).
I don’t use native apps as general principle, while i happened to be on ios safari when i tried and i am the first to criticize that browser, the bugs i am seeing do not happen in other apps and should be easily fixable in a proper build webapp. Also keep in mind that this was just a coincidence, every other browser and platform i had to use zulip in had a bad experience.
For what it's worth, essentially every main view surface was visually redesigned over the course of the last 2 years. So while I can't promise you'll like the new design, it certainly isn't the same as it was 2 years ago.
One of the other nice features of the new design implementation is there are handy settings for font size and line spacing. It turns out that different people have very different desires for how dense content is in chat apps, and empirically there's a significant portion of users with just about every combination.
I've spent a bit of time last year trying to convey my product instincts to the Zulip team and mostly stopped because I felt like they didn't care enough / weren't moving very fast. The basic problem is that the mobile app is, like it or not, the way most people will use the product, and it needs to be designed by an opinionated person who actually will say no to things.
In my view, the home page should be just like a proper messaging app: show every recent thread ("topic" in Zulip nomenclature) that I'm involved in, across all my channels, with unread ones indicated using a 'dot'. Or, if you really want to be like Slack, just copy Slack more directly. In either case, the other views (Inbox, Combined Feed, DMs, etc) should be under menus, not primary actions.
The other thing is that it's often hard to figure out how to reply to a topic. In the Combined Feed, which is my preferred view for consuming updates, the UX for replying sucks -- first you have to figure out to tap the headers; and even then, you can accidentally tap into a channel instead of a topic. It's extremely non obvious when you've done this and constantly causes people to reply in the wrong topic.
I vibecoded some improved Inbox UX using Claude Code and I think it would be a big step up, but it's hard to know what the steps would be to get it shipped, since I don't have time to spin up properly on the codebase and I doubt my changes are acceptable as-is. If Zulip team wants them I'd happily share though.
there are just so many issues, where do i start? its just apparent no designer or usability person ever used it or was involved in anything for this project. there is a weird search button with uncentered icon, scrolling makes some tooltip flicker and partially scroll on top of the header, the content of the page reappears on the top of the header when scrolling past it. everything just feels like one giant glitch. and when you scroll, there is a focus outline around whatever item you happened to drag the scroll area with. This is what i encountered in 5 seconds testing just opening and scrolling up and down.
I have looked at the rust Zulip forums, which are bulky. But with moderation and rules and having people on the autistic spectrum [citation needed], it perhaps is usable for large organizations. Just kidding.
We are using Zulip for 300+ members in a makerspace, and at 40 members, we were not happy. Scaling to 300 never broke not being happy, since we all hate the UI ever since.
I cannot re-open Zulip threads, which are also issues with an atomic "solved/unresolved" state, unless I have elevated access. It is not a true forum like PHP forums, where we ask people to name threads, and you might just skip reading more than the title, or locate interesting threads by activity and find stickies about important announcements in a pull, not push, way of doing things.
It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
If they wanted to re-invent forums, they should have cloned the "discourse" web app/forum. Still looks like shit on every platform, mobile or desktop, but at least does not break down on mobile.
It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
I really wanted to like Zulip and use it as a personal chat service for a small group and it was exactly that feature that made it basically unsuitable. Forcing everything into titled threads did not make any sense for lots of user to user interactions that are ad-hoc in nature.
I didn't think it was terrible software by any stretch of the imagination - just not really suitable for informal communication.
> It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
Do you mean people are happy to post on a thousand different threads, but no one reads posts from anyone else?
Why do you even have so many different active threads? Why not just let "resolved" threads be, and funnel conversations into fewer threads? (esp if you want ephemerality i.e. conversations to expire with time)
> 300+ members in a makerspace
If you have 300+ people discussing a wide variety of things, how do you ever expect to maintain your sanity with only channels and without threads? Won't every channel be quickly flooded and really hard to resurface anything useful from past discussions?
> I cannot [...] unless I have elevated access
Is your complaint that your Zulip space is not moderated well and that it would be helpful to ad-hoc decentralize some of the maintenance work across more participants?
reply