Tried it again few days ago. I kinda get that currently you can only use AI on Helix through LSP, but on top of that it does not have auto-refreshing files when changed outside - makes it really hard to work with external AIs, as I'm just constantly worrying if I'm editing a stale file.

I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commands

I have reload-all bound to Ctrl-r

Same!

GitHub Copilot, Claude Code and Codex provide fairly good IDE integrations. They don't just edit files behind your back. They actually edit the files you have in the IDEs using editor APIs and even show you a nice diff view. This way you never have content that is out of sync. I find this approach very usable and appealing.

On the other hand, many of the AI tools and their companies think that you should completely ditch IDEs for CLIs only, because "nobody needs to write code anymore". Some of them even stopped maintaining IDE extensions and go all-in in CLIs.

(I call that complete BS)

I've noticed that Codex usually uses the native editing tools and shows me a diff, but sometimes it just sidesteps that and does a cat > file << EOF, so I need to rely on Git diffs to tell what it did.

> This way you never have content that is out of sync.

They can definitely go out of sync, particularly if something that isn't the editor or the AI changes the code (e.g. running shell commands or opening the file in a different editor and making changes there). I've had a whole load of issues with VSCode where there's been spurious edits all over the place that show up again even if I try and revert them, because every time the AI makes an unrelated edit, VSCode tries to reset the file to the version it thinks exists and then play the AI's edits on top.

That problem already existed long before the age of LLMs?

I don’t even open a text editor anymore 90% of the time. Seems clear to me that IDEs, in the traditional sense, don’t really have a place in the future of software creation. They might morph into something that does, but definitely not in their current form, imo.

If you actually want to engineer properly and review the code rather than pushing out vibe coded slop PRs, then IDEs absolutely do have a future.

> If you actually want to engineer properly.

I think this statement is misguided, and potentially comes from a lack of experience in getting AI coders to produce quality.

Proper engineering does not come about from the tools you use or how you use them. Proper engineering has always come from thought, and reasoning, it never was about the act of coding. It always was about the systems thinking and expressing the goals and desires that matched the requirements.

IDEs were never needed to properly engineer and in the days of AI will become increasingly less important.

Tools for planning, reviewing, and commenting on code are the future. The necessity to edit actual code is coming to an end.

Yes, that's what I said, I'm contrasting properly engineered AI code to vibe coded slop AI code, not that human written code is inherently better engineered.

I was feeling this pain also; so I switched my workflow to watching file changes with lazygit, and then switching to helix to make small tweaks.

Another option you may want to try is mux (github.com/coder/mux). It wraps the LLM in a nice interface which has the ability to do line/block comments on changes by the LLM that then goes goes into your next prompt. It’s very early stage though: v0.19.0.

With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.

The latter is pretty easy to vibe-patch in:

https://github.com/burke/helix/pull/1

> you can only use AI on Helix through LSP

How do other editors do this, if they don't use LSPs? Helix specifically choses LSP as the integration mechanism (in combination with TreeSitter) for supporting different programming languages, because it is a language-agnostic protocol and therefore only needs to be implemented once. Is there some established AI-agnostic protocol/interface? I don't think MCP would work here?

ACP Agent Client Protocol https://agentclientprotocol.com/get-started/registry

This is a distinctly Zed solution - trying to move the agent experience into the editor, rather than just giving the agent an interface with which to control and read from the editor.

Not only do the most popular editors have little-to-no incentive to implement it (they’re more interested in pushing their own first-class implementations, rather than integrating those of others), it’s much more work to integrate the evolving agent experience into the IDE than it would be to provide IDE integration points for the agents themselves.

So, I think this project would have been much more successful if it had been more focussed on keeping the agent and IDE experiences separated but united by the protocol, instead of trying to deeply marry them. But that’s not in line with Zed’s vision and monetization strategy.

It won’t be long before the big players start to release their own cloud-based editors. They’ll be cloud-based because the moat is wider, and they’ll try to move coding to the cloud in the way that Google Workspaces moved docs to the cloud. Probably with huge token discounts to capture people. If you squint, you can already see this starting to happen with Claude Desktop, which runs its agent loop on the cloud (you can tell because skills appear to need to be uploaded).

Notably, Microsoft, with VSCode and GitHub have a web-based editor advantage in this space, but no models.

It's not just Zed, Emacs has has a thriving ACP implementation in agent-shell[0], and allows for some very cool integrations[1]. There are a fair number of other clients[2] as well.

[0]: https://github.com/xenodium/agent-shell

[1]: https://www.youtube.com/watch?v=HJQ86HuSIJI

[2]: https://agentclientprotocol.com/get-started/clients

The second half of this is spot on. The now is making IDEs that can integrate with agents, not the other way around. Soon the Claude and Codex will do that for us on their hosts and the argument is it will save sending the context up.

Just watching filesystem for file changes and updating the in-memory view of the file on any change? This isn’t really relevant to MCP, though one option is to provide a different tool to the AI agent for file modifications, which would make modifications through the file editor itself.

> Just watching filesystem for file changes

This is non-trivial, if you want to do it efficiently. On Linux you can set up an inotify listener for individual files, but not for entire directories. This also breaks down if you are working with data on non-local drives.

> Is there some established AI-agnostic protocol/interface?

AFAIK no