[ammmir]

I was using Zed up until a few months ago. I got fed up with the entire AI panel being an editable area, so sometimes I ended up clobbering it. I switched to Cursor, but now I don't "trust" the the editor and its undo stack, I've lost code as a result of it, particularly when you're in mid-review of an agentic edit, but decide to edit the edit. The undo/redo gets difficult to track, I wish there was some heirarchical tree view of history.

The restore checkpoint/redo is too linear for my lizard brain. Am I wrong to want a tree-based agentic IDE? Why has nobody built it?

[senko]

> I got fed up with the entire AI panel being an editable area, so sometimes I ended up clobbering it.

They fixed that with the new agent panel, which now works more like the other AI sidebars.

I was (mildly) annoyed by that too. The new UI still has rough edges but I like the change.

[freehorse]

Interesting. I actually like the editable format of the chat interface because it allows fixing small stuff on the fly (instead of having to talk about it with the model) and de-cluttering the chat after a few back and forths make it a mess (instead of having to start anew), which makes the context window smaller and less confusing to the model, esp for local ones. Also, the editable form makes more sense to me, and it feels more natural and simple to interact with an LLM assistant with it.

[dtkav]

Yes! Editing the whole buffer is a major feature because the more you keep around failed attempts and trash the dumber the model gets (and more expensive).

If you're working on stuff like marketing websites that are well represented in the model dataset then things will just fly, but if you're building something that is more niche it can be super important to tune the context -- in some cases this is the differentiating feature between being able to use AI assistance at all (otherwise the failure rate just goes to 100%).

[koito17]

> I actually like the editable format of the chat interface because it allows fixing small stuff on the fly

Fully agreed. This was the killer feature of Zed (and locally-hosted LLMs). Delete all tokens after the first mistake spotted in generated code. Then correct the mistake and re-run the model. This greatly improved code generation in my experience. I am not sure if cloud-based LLMs even allow modifying assistant output (I would assume not since it becomes a trivial way to bypass safety mechanisms).

[freehorse]

The only issue I would imagine is not being able to use prompt caching, which can increase the cost of API calls, but I am not sure if prompt caching is used in general in such a context in the first place. Otherwise you just send the "history" in a json file, there is nothing mystical about llm chats really. If you use an API you can just send to autocomplete whatever you want.

[senko]

> I am not sure if cloud-based LLMs even allow modifying assistant output.

In general they do. For each request, you include the complete context as JSON, including previous assistant output. You can change that as you wish.

[ntonozzi]

The old panel still exists, they call it a text thread.

[dtkav]

Yeah, but text threads cannot be used as context in the inline assist right now so there's no way to apply the code.

[freehorse]

Ah that's a bummer. You can still add threads as context, but that you cannot use slash commands there, so the only way to add them or other stuff in the context is to click buttons with the mouse. It would be nice if at least slash commands were working there.

edit: actually it is still possible to include text threads in there

[dtkav]

You can add agent threads as context, but right now adding text threads as context doesn't work.

[senko]

What, that was a thing? I was copypasteing manually, which was annoying and error prone, that's why I like the new agent panel more.

Oops, I guess.

[dtkav]

Yeah, It was great because you were in control of where and when the edits happened.

So you could manage the context with great care, then go over to the editor and select specific regions and then "pull in" the changes that were discussed.

I guess it was silly that I was always typing "use the new code" in every inline assist message. A hotkey to "pull new code" into a selected region would have been sweet.

I don't really want to "set it and forget it" and then come back to some mega diff that is like 30% wrong. Especially right now where it keeps getting stuck and doing nothing for 30m.

[cedws]

I’m on the opposite end, I hate the new panel. It’s less space efficient, slash commands are gone, and I can’t figure out how to clear the chat.

[cies]

All vims and emacses can have undo-tree (as a plugin iirc). Many devs use it.

Vote/read-up here for the feature on Zed: https://github.com/zed-industries/zed/issues/17455

And here on VSCode: https://github.com/microsoft/vscode/issues/20889

[tgtweak]

Been using cline and their snapshot/rewind/remove context (even out-of-order) features are really shining especially with larger projects and larger features+changes becoming more commonplace with stronger LLMs.

I would recommend you check it out if you've been frustrated by the other options out there - I've been very happy with it. I'm fairly sure you can't have git-like dag trees, nor do I think that would be particularly useful for AI based workflow - you'd have to delegate rebasing and merge conflict resolution to the agent itself... lots of potential for disaster there, at least for now.

[mrorigo]

omg. "the entire AI panel being an editable area" is the KILLER feature for me! I have complete control, use my vim keys, switch models at will and life is awesome.

What I don't like in the last update is that they removed the multi-tabs in the assistant. Previously I could have multiple conversations going and switch easily, but now I can only do one thing at a time :(

Haven't tried the assistant2 much, mostly because I'm so comfy with my current setup

[conartist6]

Worry not, for it is being built.

You will not catch me using the words "agentic IDE" to describe what I'm doing because its primary purpose isn't to be used by AI any more than the primary purpose of a car is to drive itself.

But yes, what I am doing is creating an IDE where the primary integration surface for humans, scripts, and AIs is not the 2D text buffer, but the embedded tree structure of the code. Zed almost gets there and it's maddening to me that they don't embrace it fully. I think once I show them what the stakes of the game are they have the engineering talent to catch up.

The main reason it hasn't been done is that we're still all basically writing code on paper. All of the most modern tools that people are using, they're still basically just digitizations of punchcard programming. If you dig down through all the layers of abstractions at the very bottom is line and column, that telltale hint of paper's two-dimensionality. And because line and column get baked into every integration surface, the limitations of IDEs are the limitations of paper. When you frame the task of programming as "write a huge amount of text out on paper" it's no wonder that people turn to LLMs to do it.

For the integration layer using the tree as the primary means you get to stop worrying about a valid tree layer blinking into and out of existence constantly, which is conceptually what happens when someone types code syntax in left to right. They put an opening brace in, then later a closing brace. In between a valid tree representation has ceased to exist.

[pierrec]

Representing undo/redo history as a tree is quite different from representing the code structure as a tree. On the one hand I'm surprised no one seems to care that a response has nothing to do with the question... on the other hand, these AI tooling threads are always full of people talking right past each other and being very excited about it, so I guess it fits.

[conartist6]

They certainly can be quite different things and in all current systems I know of the two are unrelated, but in my system they are one and the same.

That's possible because the source of truth for the IDE's state is an immutable concrete syntax tree. It can be immutable without ruining our costs because it has btree amortization built into it. So basically you can always construct a new tree with some changes by reusing most of the nodes from an old tree. A version history would simply be a stack of these tree references.

[gnrlst]

I've very interested in this, and completely agree we are still trying to evolve the horse carriage without realizing we can move away from it.

How can I follow up on what you're building? Would you be open to having a chat? I've found your github, but let me know how if there's a better way to contact you.

[conartist6]

The BABLR Discord is the spot, though I'm also happy to take emails: https://discord.gg/NfMNyYN6cX (and yes I'm happy to chat!)