I like the idea of using LLMs to transform code into something more readable, and vice versa. I am not sure if meandering paragraphs and linear lists are the best targets.
It's when that text gets copied and pasted into a blog, or a PR, etc. that it really galls.
What I don't care for is the pretty-yet-verbose HTML outputs that I see from some teams. They can be way too long and it's often the case that the engineer who made it didn't read the whole thing.
As someone who likes a nicely designed report document, slapping a coat of paint on slop output isn’t helpful
Ask for a rewriting pass! Get it to edit for word count, remove redundancies, remove run-on sentences, and change sentence structure to use active voice.
You wouldn't ship your first draft - why let AI do it?
Worst case you lose 10 seconds of your life. Not too bad!
First attempt: mountains of meta conversation and not answering the original question.
Second attempt: shorter and more concise, cuts out some of the nonsense, but terribly written.
Third attempt: goes off the rails, misunderstands what you are asking and tries pushing the work onto you.
Fourth attempt: finally something that's concise, reasonably well written, to the point and passable.
Sorry, my brain just fried trying to read the post.
Aside from the H1 and H2 headers, nearly everything on the page is ultra-low contrast.
Darkish gray text combined with the faded gray background, along with the (nearly) undetectable highlight makes for a terrible reading experience. I'm sorry, but somebody has to say it.
Surely it can't just be my own eyes that are squinting to see the images and the small text therein? The page design as such is fairly minimal with bold blue theme; would it hurt to add a bit more contrast to the typography?
Thanks
/offtopic
For (1), the main value I'd see is in mentoring junior engineers or less technical contributors on a team. If someone puts up a PR with sloppy results, you could actually jump into the thread that produced that PR and see how the results came about, or even coach that contributor on how to do better next time. Also might make it easier to hand off work from one person to another - right now most coding agent sessions are user-local.
On (2), I frequently find myself consuming agents' gigantic text responses and tediously writing 8-bullet-point responses to guide them. It's pretty exhausting. I could see inline comments providing much better ergonomics.
All that being said, Zed has largely fallen out of the conversation for "agentic coding tools", and so this feels like their attempt at creating something like the Cursor Agents Window, Codex, or Claude Code. These two features seem compelling, and I understand they're even compatible with other coding harnesses. But I don't know if there's enough there to have a defensible product; if these features are excellent, others will clone them eventually.
Regardless, would love to give this a shot!
For your 2 plannotator [1] has a nice way to annotate agent messages or documents and its integrated into the agent chat (codex app also adopted the pattern)
But a lot has changed in those 12 months.
Frontier models and coding agents have advanced so much that I don't really see much value in this anymore.
Not sure the DeltaDB based features really add anything significant compared to the alternatives.
I reckon the game here has to be adding a service that stores the data and runs agent sessions?
Here they've moved the AI chat to the center and code editor has been pushed to the side.
This feels like engaging with a prog lang community for the first time, and answer to a basic question is "this has been covered before, read the IRC chat history"
It's not like Pull Requests are perfect, and with discipline they do the job well - but this looks like a step in the wrong direction.
No but you will want all of the transcripts anyway.
> AI will summarize it for me?
Not exactly. You will have some question later that you would never have entertained during your thousands of conversations about code.
You’ll ask your AI something fairly abstract but it will be deep in the context of some other idea.
And the AI will find among all your conversations those turns that are relevant to solving your problem or explaining why.
I know this is the case because I’ve built this and use it every day.
Here are some examples:
1. Resume unfinished work → "where did we leave off on that?"
2. Recover the intent/scope → "what was the actual goal of this whole effort?"
3. Verify it got done → "did we ever finish that, and which session proves it?"
4. Recall a fix → "how did we fix this the last time it broke?"
You would be amazed how good the agent can be at assembling queries against a corpus of transcripts and assembling the results.
My product is called Contextify: https://contextify.sh
I'm working on a legacy system right now - I'd commit several felonies just to have well documented code, I don't really care about all the conversations that the original team had to decide what they eventually did.
Maybe I'm just too old and don't get it.
theres a lot of context and decision making that is useful but not documented in the code. The code tells you how the system works, not how its supposed to work.
I tend to agree that at a certain point if you need to constantly think "gee, I wish I was in the meeting when they came up with this" the code you are looking at might just suck.
In such contexts it is also often the case that being in the meeting may not have helped. As they say, garbage in, garbage out.
A similar thing happens in agentic conversations, where a model may point out something but it is not recognized as important by the operator.
A few directives later and the model is being pushed another direction.
It can be very useful to have perfect recall of moments like these.
Unrelatedly, I have been looking at Zed to centralize my agentic work at $job, where we use different API keys per project to better attribute spend and control model availability based on per-project data protection controls. All of the standard UIs I've tried for this don't really work, but the CLIs mostly do. Using ACP in Zed I was able to bridge that into the UI world and I'm quite happy with it.
I signed up for the beta and I look forward to trying it.
The interesting bit is this type of UI doesn't fit very well in any of the existing terminal TUIs, I have only seen it enabled working well in GUIs.
I want to like the app, but I'm not sure if it actually fits well to my use case. With my current setup I need to fully quit and restart it if I want to work on a different project (to get it to use a different API key) and I cannot work in two threads belonging to different projects at the same time.
Also I generally prefer to handle sandbox the entire agent and disable its internal safeguards. Beside any doubts regarding the quality of the relevant sandbox implementations, I have just gotten my projects to work better this way.
The following demo is a version of a text editor - a chat window and a diff. How would building a new limited text editor be the best possible experience? Like you've setup your Zed schemes/keybinds to your liking, why would jumping to a totally different app improve your experience?
Good thing I can just fork the editor. This is how you lose the trust and goodwill of your users.
The conversation may have been long and meandering, for legitimate reasons, but what matters is the decision you reached at the end and the reasons for the choice.
If your project cares about those things, they should be captured in your specifications / docs / ADRs, in a concise form that respects the reader's time.
If you don't care about why the choices were made, then why save the discussion in a fancy database at all?
I guess everyone's just too cool to actually write good docs now?
(I've had some runins with the auto-generate specs based on LLM chats tools lately, like OpenSpec and an internal equivalent, and boy do I have some choice words about them. So much verbosity for so little clarity...)
Nevertheless another Zed post, another plea to focus on basics https://github.com/zed-industries/zed/discussions/54150 [how can developers work with agents in zed when developers cannot see files agents create] best luck to Delta but please do not neglect the text editor!
https://podcasts.apple.com/us/podcast/syntax-tasty-web-devel...
(i worked on this)
After all, we already have safe conccurent edits, etc via regular git tooling
To me it this seems a bit backwards looking. Increasingly code review is more on verifying the functional requirements, and less about reading every line an agent has written (or watching it write those lines live)
It will cause the community to fail because VC dev tooling is unsustainable as the community needs will never take priority over what their VC benefactors want. So if you want the slop that helps you pump out slop they got you covered.
It sounds counter intuitive but you have to remember nearly every business of the planet operates as a centrally planned economy with either a monarch at the helm or an aristocracy. These are some of the least efficient ways to collaborate as humans, at least if history is anything to go by.
I suggest you focus on real open source solutions like neovim, emacs, or helix.
I kind of like the Hunk workflow for reviews (of both AI and human-generated code), you basically tell the agent "walk me through the diff by annotating and controlling this diff viewer". If it could control Zed diff views it would be even better.
This can be improved though - I think that simply a separate collaborative doc and a chat linked to that doc would work way better.
This thing is fairly new in software years and has already stagnated. Bugs, glitches and rough edges all around. Almost feels like abandonware.
I first heard of Zed back when it was “the code editor that respected your choices”, you could turn off AI entirely with a single switch and all that… guess it was too much of a pipe dream to hope it would continue down that road.
This thing is now just a white-label version of Visual Code. Nothing more. Nothing less. Same software, different case.
What a shame.
> This thing is now just a white-label version of Visual Code.
That's a wild hot take, and pretty ignorant to the people working on that for years.
Hot take or not, it’s accurate. There’s little to nothing that differentiates Zed from VSCode now.
Edit: grammar
Plus a substantial percentage of people in the industry probably never used git blame ffs.
Does Zed even remember it is a code editor? Or are these guys just interested in building more AI slop to add to the never-ending pile? What even is Zed supposed to be at this point?
What happened to using "adversarial LLM"? Too expensive for plebs? So this is the middle ground?
I think zed has lost the plot.
When will this ai slop era end? Hopefully soon because I am tired of reviewing junk PRs
So, this seems like a lot of work on really cool tech for no useful purpose at all?
Are there people crying out for a multi-user code editor? I mean, we have to have code reviews, sure. That involves other people or other agents. But, I don't need to stand over someone's shoulder while they work. That seems like the worst thing in the world for everyone involved. I don't want an audience for my dumb looking experiments because I forgot how to do something.
I've definitely used the live sharing session with VS Code in the past to help coworkers debug or give them some suggestions for how to structure things (usually giving Rust pointers to people newer to the language). I haven't done it in a while though, probably because nowadays people will just ask their agent rather than me.
I've never desired to have two people working on the same file at the same time during a debugging/teaching session.
I could see it being useful if you're helping someone debug something, but chances are it's easier just to screenshare.
My personal experience is, of course, not representative of an entire industry, but I just have a hard time imagining it being a common thing. I like working with other people and helping juniors sort out their problems, but I'd quit my job if I had to take turns writing code while someone else watched and just sitting and watching someone else writing code. Both of those things seem horrible, to me.