Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

59% Positive

Analyzed from 3365 words in the discussion.

Trending Topics

#code#don#more#zed#git#commits#agent#every#something#around

Discussion (73 Comments)Read Original on HackerNews

tomjakubowski•about 2 hours ago
I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process.

I don't want my thoughts to be serialized, version controlled and publicly accessible.

https://www.nature.com/articles/s44222-025-00323-4

hinkley•about 1 hour ago
This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. If you squash them I have 400 lines of code you 'wrote' all at the same time and only have the feature request it was assigned to as context. Thanks for nothing.

The worst actor would write a new module and check nothing in until it kinda worked. I think it went along with the fragile ego that had people sneaking around fixing bugs in his code without talking to him about it first. He wrote convoluted code that exhibited Kernighan's law and he was about 10 years too senior to still be doing that shit. He bragged about how 'powerful' his code was as if that was a compliment instead of a harbinger. Many times I found bugs in code from the initial commit. Just... give me something man. Anything. Fuck.

Just because you tried random shit until you found the problem doesn't mean you have to fess up to it. You can tell any story you want that gets us from point A to point B now that you know point B is attainable. You can rearrange the commits the way you would have written it if you knew exactly what needed to be done. Drop 90% of the code you wrote and immediately deleted again, anything that doesn't support that narrative.

In law enforcement you have something called Parallel Construction. You can know a suspect is guilty by knowing facts that are not admissible in court. So you need to rediscover those same facts by the book. Grab his trash on trash day. Interview neighbors. Get enough circumstantial evidence to get a search warrant, then go find that evidence again.

sharts•26 minutes ago
Squash smaller commits?
giraffe_lady•about 1 hour ago
Probably coulda used an example that isn't itself a fourth amendment violation that essentially requires perjury to accomplish. Also less euphemistically called evidence laundering. Not really a neutral example.
bonzini•30 minutes ago
A more charitable case is that the source cannot be disclosed because it's an undercover agent or informant. What the parent describes is indeed evidence laundering.
gmueckl•about 1 hour ago
Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.
InfinityByTen•about 1 hour ago
One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me.

In my life, I've never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.

ablob•1 minute ago
I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.
ozim•8 minutes ago
Ugh, let's take a step back and make a distinction:

I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.

If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.

jcgrillo•2 minutes ago
OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?
fridder•about 2 hours ago
The collaboration part I’m skeptical of but I get it, as it sounds like a feature made for business consumers
sdesol•about 1 hour ago
This sounds like it is more aligned with what I have created which is "We need to capture your conversations with AI". If you look at

https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...

you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about.

What they are working on will be more useful for AI code provenance. It is only a matter of time before you are expected to show your chats with AI as part of the code review and for performance reviews.

So I don't see human collaboration being the main use case. I see tracking, studying and improving the Human-AI relationship...and seeing if somebody should be promoted or not.

An interesting take I've heard is, we will have a token/impact stat where if you spent a shitload of tokens to produce the same impact as somebody else who spent a lot less, you will be the prime candidate for layoffs and/or less pay. This is why I think AI code provenance will become a serious thing in the future.

jorl17•about 1 hour ago
FYI your link 404s.

Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r

jcgrillo•about 1 hour ago
Fully agree, very icky surveillance vibes. In particular:

> DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity.

I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues reviewing every single intermediate edit, down to the keystroke, that went into the commits I publish for review.

Before I put a PR up for review, I'll sometimes edit my commit history a little bit in magit to make it more linear and digestible--maybe update descriptions, squash some adjacent commits together, etc. This just throws that whole aspect of the job out the window and says "hey, colleague, hoover up this firehose of deltas and enjoy it".

And what the hell does this even mean?

> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.

Lmao. No. Wrong.

fridder•about 1 hour ago
The more I think about it and your comment the more I wish it was local only. It could be useful to analyze your editing habits and interactions with AI but I want that for my own benefit not random coworkers
slackpad•9 minutes ago
Yeah I really would not want all my convos synced up like this. I've been working on a personal version of something like this but it keeps all your conversations and notes in a separate Git repo that you control that's totally separate from the project repo - it's entirely designed for personal use:

https://github.com/modulecollective/moe

0xb0565e486•about 2 hours ago
Aren't you paid to think?
pdimitar•4 minutes ago
No, you are paid to deliver. Whether you do that by thinking + hand-coding or just vibe-coding, or handing the task description to Cthulhu and waiting for him to materialize the solution on your disk, is immaterial.

Unless of course you also have to explain your thinking and problem-solving process in meetings, which happens quite a lot the more senior you get.

NewJazz•about 1 hour ago
A woodworker is paid to work with wood. But the finished product is the worked wood, not a detailed summary of how the wood was worked with.
bauldursdev•about 2 hours ago
No I'm paid to write code.
malyk•about 1 hour ago
No, you are paid to provide solutions for your customers.
NewJazz•about 1 hour ago
Does that... Not imply thinking avout what you are writing???
muadddib•about 1 hour ago
and you can do that without thinking?
WorldMaker•about 1 hour ago
This just sounds to me like "frequent auto-commits" with less trust in git. git can handle frequent auto-commits just fine. If you want to "rollup" frequent auto-commits into "cleaner" top-level commits but also keep all the point-in-time "conversation" of your auto-commits, then `git merge --no-ff` from time to time and use tools like `--first-parent` to focus in on "top-level" commits over "conversation" commits.

The git backend already has a ton of "delta DB optimizations" (in git packs and other tools) and it's really just the git frontend that needs a little massaging (`--first-parent`, primarily) and the vast world of "subway-diagram-first/only" Git UIs that should have more "drill down" `--first-parent` counterparts simply because so many people find the subway diagrams ugly/confusing/distasteful.

tengbretson•3 minutes ago
This is going to have so many api keys stored in it.
mplanchard•about 2 hours ago
There are so many early-stage startups also competing in this space right now. I’ve been on the interview circuit the past few weeks and talked to at least two. It’s going to be stiff competition for any of these tools to get well-established enough to be successful at a large scale.

I can’t help but feel like it is all enabling a level of developer surveillance with which I am deeply uncomfortable, though.

prodigycorp•about 2 hours ago
I have an uneasy feeling in my stomach because i know anthropic or openai acquiring zed is inevitable. They have too many good ideas and their software is too good.
clickety_clack•about 2 hours ago
Ya, their coding harness is way better than Claude code, but because it’s directly using the clause api it’s way more expensive. Rolling it into the family would make it product-class-defining.
darepublic•about 2 hours ago
They drove up to my house with a dump truck full of money... Im not made of stone!
elevation•about 2 hours ago
> I have an uneasy feeling in my stomach because i know anthropic or openai acquiring zed is inevitable. They have too many good ideas and their software is too good.

Why stop at zed? The trillion dollar investment AI companies have amassed was nominally for datacenters, but as those costs rise and completion timelines extend past the typical business planning horizon, it becomes more efficient to put the money to work elsewhere. You can buy whatever you want with a trillion dollars.

whazor•about 2 hours ago
Seems like where anthropic or openai want to go, there are no editors anymore.

I personally want better read-only code tools, or maybe the return of UML?

prodigycorp•about 2 hours ago
I think it's the other way around. OpenAI is definitely recreating the IDE from scratch with codex app.
Xotic007•about 2 hours ago
A commit is useful because you cleaned it up first. The messing around in between is where you try things and delete the dead ends and most of it is meant to be thrown away. Saving every change and every agent message keeps all that junk around instead.
jmole•about 1 hour ago
Google has been doing this for maybe a decade now with citc [0]. I don't know when Gemini is actually going to be taking advantage of this, but I do know that google has essentially a full history at "Ctrl-S" granularity, from ~every developer that works there, for at least 10 years now.

If Gemini seems stupid nowadays, it's only because they're being stingy with compute allocation.

0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

OtherShrezzing•about 1 hour ago
I don’t see the value proposition here. I’ve seen roughly this feature proposed by multiple companies, and absolutely none of the have given a convincing reason for the technology to exist.
chrishill89•about 1 hour ago
Many years ago I helped a friend with some draft that had to do with him finishing his doctorate. It ended up being maybe 50-60 between three of us and as fine grained as possible.

That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.

softwareseko•about 1 hour ago
The interesting question is whether agents actually benefit from finer-grained history or whether they're better served by semantic checkpoints – "this works, this doesn't" rather than line-by-line diffs. Git wasn't designed for that, but neither is anything else yet.
jerf•about 1 hour ago
I would be interested in a clear statement about how this scales. I've not used this workflow myself, but I've seen teams that did it. Whether they got huge benefits out of it I don't know, but I do know that watching them, I was not jealous of what I saw. If I make a change, and I run some tests that were passing a moment ago, and they fail, and the reason why they failed is that Bob hit "save" on his editor (or his editor autosaves) and he made a syntax error in a shared library, and this happened often... I would go insane. I cause enough problems for myself without other people's problems actively intruding at uncontrolled times into my tests.

AI's code writing velocity makes this even worse, there's no way I can be simultaneously working on a code base while an AI agent is running around it doing something else.

It feels like maybe there's a ghost of an idea here about how to get the best of both worlds, but I'm not sure I follow the throughline on it.

localhoster•about 2 hours ago
Sad to see zed going the same route everybody is screaming them not to. Altough, I never expected otherwise.
dkdbejwi383•about 2 hours ago
What route is that, and why is everyone screaming at them, for someone out of the loop?
Advertisement
pjm331•about 3 hours ago
so i think the thing that everyone building these git alternatives is missing is a multi-repo story - unless the expectation is that everyone is going to start operating out of monorepos

i've settled on all of this context attached to issues in a project management system and referenced from commits

it works just fine - its not like your agent cannot read your issue tracker

jackxlau•about 2 hours ago
I came across the conclusion here since a change sometimes spans several repos, per-repo history optimizes the wrong target.
QuercusMax•about 2 hours ago
I've built some skills to help work with multiple repos, but it's really annoying how e.g. repo-specific .claude/ configs are only read when you start the agent in the repo folder. There's a ton of low hanging fruit to improve dev experience.
seanclayton•about 1 hour ago
> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.

This benefits those who make the machines you have conversations with and those that invest in them.

abahgat•about 1 hour ago
I can see how this is a great building block for what Zed is doing around collaboration.

One thing I would really love to see, however, is a way to better attach code review comments to the specific version of code they were left on. I find it quite difficult to do with git and github, considering that commit hashes change every time one is forced to rebase (say, for example, to handle a merge conflict).

Do you expect DeltaDB to help address this problem?

shibel•about 1 hour ago
A bit O/T but:

> I have never been a big fan of pull requests.

I guess this partly explains why Zed (still) lacks a PR review flow, let alone a coherent one, despite some interest [1]. Pretty much the only reason I’m still with JetBrains.

[1]: https://github.com/zed-industries/zed/discussions/34759

fridder•about 2 hours ago
Well shoot, they beat me to the punch. I’d been circling around something like this, just not collaborative and obviously more thought out than my random experiments. Minus the collab portions I’m interested to see how it compares to jujutsu
timuthang•about 3 hours ago
Music is the silence between notes
_pdp_•about 1 hour ago
What is apparent to me is that we are moving towards dark factories if the promise of LLMs writing most of the code is fulfilled. So this means that it is less about conversations and it is more about iteration.
these•about 2 hours ago
This seems like a great way to facilitate data gathering for improving LLMs coding performance.

If previously you needed to take action 1, 2, 3 to go from state A to B, all you saw was the change from A, B. Now you see intermediates 1, 2, 3 and can train the models to skip straight to B with the added context of the intermediate states.

ivanjermakov•about 2 hours ago
Just a stream of thoughts: if git commits were a list of sequential primitive changes instead of diff snapshots, conflict resolution would be trivial in most cases.

Not without cons of course: commit byte size, public WIP work and leaked secrets/unwanted edits.

wxw•about 1 hour ago
Agents can certainly use a new substrate as they can eat dense information quickly.

Not convinced DeltaDB is useful for humans directly but assume new and interesting interfaces can arise from the abstractions it provides.

Agree that PRs/snapshots is an antiquated way of sharing information.

Advertisement
thesurlydev•about 2 hours ago
I'm glad to see this feature and looking forward to see how it evolves.

Many of the product decisions that Zed's made caused me to switch to Zed for my daily driver IDE (previously JetBrains). The recent AI agent threads and improvements around diffs really solidified the move.

b33j0r•about 2 hours ago
JetBrains’ AI offering peaked last year when Junie was briefly better than Codex. Now it’s a wash.

Honestly all of this drives me back towards nvim or notepad sometimes.

I have had a jetbrains subscription since pycharm came out, and the killer feature was always the visual debugger. Seems nearly quaint now.

What specific things do you like about zed?

gnunicorn•about 1 hour ago
I totally see where they are coming from, jitsu, too is making every change its own artifact. And it plays hard to the "faster shipping" that especially AI-driven teams are pushing hard, and find the review process to be the next big bottleneck now (as I just saw with my last client as well).

There has also been a lot of discussion about the value of the peer review process recently, in in general. But I wonder if this isn't all going into the wrong direction. Quite honestly, even with the previous review and discussion system of (squashed) commits how often did you really use git blame and opened up the original PR discussion of that changed line that caused the bug? And how often did it help you beyond learning it was done by that rockstar developer who has left long ago? And that the discussion on that PR was a point in time and the code around it has evolves beyond that and it would need looking at another 10 PR discussion to get the entire context.

What I am saying is that git (and before that Subversion and CVS) has a full history is so that it can resolve the latest state. Period. We made that commit ritual somewhat of a hallmark in putting more supposed meaning into recording ever more in that history. But we rarely stopped to check if that is all that useful. Recording even more, all the time, reminds me of these work group meetings that have minute records of every bike shedding meeting word said by everyone, that, honestly, no one ever looks at after the next meeting ever again. I don't think there is value in minute record keeping, it becomes too much noise that just makes it harder to parse. Now also adding all AI conversation and agent thinking to that tree? What's the value of that in like 3 months down the line? I don't see it.

lijok•about 1 hour ago
I swear a lot in my chats with Claude..
hyperhello•about 3 hours ago
I hate software tools now. I really do. A hammer would never ask you to think about it constantly. If you think about your hammer it’s because something is wrong with it.
ChrisMarshallNY•about 2 hours ago
It's not just tools. Pretty much all software is like that.

The problem is, is that it works, if you assume "working" means the software sellers get wealthy.

There's a reason that most waitstaff wear black. They should blend into the background, and not be what the folks at the table are talking about. In rare instances, restaurants exist, where the waitstaff is the service.

In software, though, you're being served by a waiter wearing a clown suit, screaming slogans at you, and serving you lukewarm, pre-chewed goo.

hyperhello•about 2 hours ago
Ah, McDonald’s isn’t that bad.
skydhash•about 2 hours ago
I use OpenBSD as a daily driver (but could use Alpine or VoidLinux too) and my setup is pretty much silent. No notifications, no rainbows of colors, no glitz. Let’s take mail. I use a combination of mutt hto directly connect via imap) and fdm/mu4e (to have them locally). I”m not interested in having counters or notifications for any of those.

The “calm technology” book has an handful of advices, but one of the best example is the xbiff program. It switches picture when you have new mail on your local spool.

darepublic•about 2 hours ago
From a Casey m podcast I think of agentic driven software dev as code extrusion. I guide and massage the steady output of content
bronlund•about 2 hours ago
Just what we need, a new kind of version control %]
csours•about 2 hours ago
The work product is not the work.
skydhash•about 2 hours ago
> Before agents, it was easier to believe that the ceremony of trading comments on snapshots was an effective way to collaborate on software,

I’m highly skeptical of this claim. For any complicated feature, there’s always a design doc (or an RFC, or a wireframe) and that’s what people used for discussion. Discussion in a PR are mostly about whether to accept the code, reject the feature, or provide feedback about alternate implementations. It’s not for pair programming or directing design.

Collaborating together in a research lab (brainstorm session) is not the same as asking feedback for a journal article (PR). What is described in the article is pair programming with extra steps.

axegon_•about 3 hours ago
I'll probably get more hate for saying this but fine: I use Zed 50% of the time (the other 50% dedicated to vim) for two reasons:

1. It is fast and snappy. Nothing comes even close besides vim (and I don't mind going full time to it if I have to)

2. The ability to completely shut off and block any slop machine features from interfering with my workflow or leak code back to sloppenai, sloppus or any other self-installed-worst-security-practice-backdoor garbage.

Having said that, I hope they don't remove that ability in the future and enforce the "slop is so good man, you should try it" philosophy.

dematz•about 2 hours ago
there is a fork of zed against ai: https://gram-editor.com/

I am happy about even though I've never tried gram, because if zed goes to shit there will be an alternative, which hopefully pressures zed to stay sane

Aerolfos•about 1 hour ago
From their mission statement:

> I also object to making myself and my work depend on paying a subscription fee to anyone. I don't want an outage at Anthropic to affect my ability to do my work. I think it is a grave mistake to build anything on such shaky foundations as the sustainability and profit margins of the AI industry.

Someone actually sensible, excellent.

axegon_•about 2 hours ago
Oh, that's a breath of fresh air. And they are on codeberg. Nice! Thank you!

Edit: After further inspection, I think I'm jumping ship before it's too late. And I'll look, see if there's a way to lend a hand or two when I have time!

bigstrat2003•about 1 hour ago
Thank you for that link! Looks like it fixes all of my annoyances with Zed; I'll have to try it out.
slopinthebag•about 2 hours ago
I really like Zed. It's customisable enough for me to make it look how I want, it's faster than every other editor I've tried (scrolling is silk, zero lag anywhere), it has enough features that I don't need an IDE (debugger, refactoring tools), and it generally gets out of my way.

I also like the AI tools, the inline assistant is good and the agent is also pretty nice and well integrated into the editor without it being the focus point. I'm not against using AI but I certainly don't use it as much as a lot of people do.

That being said, I really dislike this recent push towards becoming more like a cursor wannabe. They have a new (for now) opt-in default layout that almost hides the editor panel in favour of the agent threads and agent panels. And now this. I don't want to switch editors, but if they keep pushing a different workflow from what I use it might send me back to Jetbrains...

ukprogrammer•about 1 hour ago
With LLMs now being responsible for the physical typing of code and mundane plumbing tasks, this is a wise direction to go into

Our human ability is not defined by our _absolute_ output, but, by the quality of the _delta_ applied to an engineering artefact

Great engineers obsess over every keystroke

With LLMs, a much smaller number of keystrokes can create a much larger and more positively impactful delta

Every delta to the codebase can tell us some informational property about the behaviour of the system and storing that information WILL prove to be useful in the future

Advertisement