This seems like a cool augment to current PR processes but fundamentally I don’t see anyway around still reading the code? Review should optimize for that. Agents make it very easy to create human digestible logical chunks of work that are easily understood and testable. Your job as a dev is to make it easy for your teammates (and your future self) to understand what your change is doing - cause we all know Claude will use 1000 words when 10 will do.
Other end of this is all the high performing teams I’ve worked on don’t really need PR review. Work is discussed prior to it happening so by the time PR review comes up it’s a rubber stamp. Agents changed none of that - again, unless you’re not reading the code. PR review is mostly for new devs to get brought up to speed. Trust lets you move really fast.
> but the decisions behind the code still need review. Smaller diffs don't supply that context
Maybe this is the bit that just seems wrong? Yes they do. You write out what the small change is working towards as part of optimizing your PR for your reviewers time. Might be just text, a link to a doc, link to a prototype etc.
It reminds me a bit of jujutsu in that there is a database with your code changes that is automatically kept in sync with your working directory. The agent edits the database copy directly. I guess the sync must be two-way?
Looks interesting for a small team that's working on a single project. I am curious to understand how this would work out for a large org that has multiple projects under the belt.
PRs may look old fashioned, but they're a very clear way of tracking an issue that may need multiple reviews. With Delta, things can get confusing after more than two reviews + RBAC is another challenge if the agent has similar context for every category.
I have not gone so far as to allow agents to operate my version control, so excuse my ignorance, but by abandoning PRs for thread deltas, are we also abandoning human-written code entirely? Will every micro-change, fix, or refactor have to be prompted to be tracked in this paradigm?
Oh, yeah. I gave Claude sudo on my AI dev machine: it commits, pushes, checks the results of pre-push tests, sudos to another user, deploys, checks the results of smoke tests, and then checks the end result.
It also has MCP access to Cloudflare. Front-end deploys on every push to main but Claude can adjust the pipeline, add environmental variables, etc.
This stuff reminds me of people who are full into XP and pair programming, where you end up agreeing to pull in more or less any work done by two people together. Not the worst model in the world.
I am disappointed by the "agent chat"-centric design for the future. There is important value in highlighting what's important, and jettisoning the unimportant. Written artifacts are good when they're nice and cut down. And it's not really about the sequence of events (well, most of the time)
Instead of "agent chat", I feel like a written page (that could be interacted with through agents) is a much more interesting way of working through a problem. Capture the final idea, and minimize the fluff around it.
And if nobody is going to read it anyways, why have the chat in the first place?
And of course the glib comment that I can't help but make:
> Teammates can ask the same agent why you chose a Mutex instead of an RwLock.
you know in this hypothetical neither human involved has much of any idea what is going on. Skill atrophy is real, folks! Be careful.
Seems interesting! I have found my main bottleneck right now is having too primitive tools for code review. A tighter loop around that might be a solution.
I never liked it myself, but this looks like an extension of Zed's own systems of collaborative coding (remotely), which in turn is built on top of the ideas of Extreme Programming, and / or intensive pair or mob programming.
It's interesting enough and I'd like to try it sometime, but probably only for hackathons - my main line of work is more planning than actual coding.
I find pair programming very productive with agentic coding.
Two people (plus one or more agents) have the full context of the plan, execution, written code, automated and manual testing. Both can help drive to the point where it feels safe to sign off on the change right then and there and merge it.
Compare that to traditional PR / code review, where so much of that context is lost. At best the coder needs to spend a lot more time rewriting up a great PR description to bring the reviewer up to speed. At worst the reviewer needs to read lots of AI slop PRs, docs, transcripts, and code to try to make sense of things.
Doing it together then merging the thread and moving on can be efficient.
It sounds like it's not conceptually different from a MR, the main difference is preserving the rationale for all the changes by bolting the "threads" (a log of agent interactions) on top. I can see how the discussion logs are quite useful if you have an agent that is there to parse them.
Other end of this is all the high performing teams I’ve worked on don’t really need PR review. Work is discussed prior to it happening so by the time PR review comes up it’s a rubber stamp. Agents changed none of that - again, unless you’re not reading the code. PR review is mostly for new devs to get brought up to speed. Trust lets you move really fast.
> but the decisions behind the code still need review. Smaller diffs don't supply that context
Maybe this is the bit that just seems wrong? Yes they do. You write out what the small change is working towards as part of optimizing your PR for your reviewers time. Might be just text, a link to a doc, link to a prototype etc.
https://delta.dev/docs/concepts/core-concepts
It reminds me a bit of jujutsu in that there is a database with your code changes that is automatically kept in sync with your working directory. The agent edits the database copy directly. I guess the sync must be two-way?
PRs may look old fashioned, but they're a very clear way of tracking an issue that may need multiple reviews. With Delta, things can get confusing after more than two reviews + RBAC is another challenge if the agent has similar context for every category.
It also has MCP access to Cloudflare. Front-end deploys on every push to main but Claude can adjust the pipeline, add environmental variables, etc.
I am disappointed by the "agent chat"-centric design for the future. There is important value in highlighting what's important, and jettisoning the unimportant. Written artifacts are good when they're nice and cut down. And it's not really about the sequence of events (well, most of the time)
Instead of "agent chat", I feel like a written page (that could be interacted with through agents) is a much more interesting way of working through a problem. Capture the final idea, and minimize the fluff around it.
And if nobody is going to read it anyways, why have the chat in the first place?
And of course the glib comment that I can't help but make:
> Teammates can ask the same agent why you chose a Mutex instead of an RwLock.
you know in this hypothetical neither human involved has much of any idea what is going on. Skill atrophy is real, folks! Be careful.
It's interesting enough and I'd like to try it sometime, but probably only for hackathons - my main line of work is more planning than actual coding.
I find pair programming very productive with agentic coding.
Two people (plus one or more agents) have the full context of the plan, execution, written code, automated and manual testing. Both can help drive to the point where it feels safe to sign off on the change right then and there and merge it.
Compare that to traditional PR / code review, where so much of that context is lost. At best the coder needs to spend a lot more time rewriting up a great PR description to bring the reviewer up to speed. At worst the reviewer needs to read lots of AI slop PRs, docs, transcripts, and code to try to make sense of things.
Doing it together then merging the thread and moving on can be efficient.