Zed's Anant Goel on evals, agent context, and the limits of git

At the AI Engineer World's Fair 2026, Garrett Galow talked with Anant Goel, an AI engineer at Zed who works mostly on the agent side of the product. Two problems ran through the conversation: keeping a daily-driver code editor stable while the models underneath it change every few weeks, and the fact that most of the work of writing code now happens somewhere git never sees.

The editor can't change under you overnight

Zed's constraint is that its core product is an editor people open every morning.

at Zed our core product is a code editor and that's something you rely on daily. So we don't want the behavior of that code editor to change from under you just because you came the next day and there's a new model release.

So Zed runs evals on every new model release. What they check is narrower than a leaderboard: whether the tools and system prompts Zed hands the model through its agent interface still behave similarly enough to agents that have been around for a while. They keep internal data sets for that, and keep expanding them.

The awkward part is that Zed doesn't control the timing. Users can bring whatever model they want, their own provider, locally hosted models, anything. Goel put the release-day window like this:

Model could drop at like 10 a.m. 10:01 someone's using it in Z[ed].

Zed's own updates don't ship the moment a model does, and often nothing needs to change on Zed's side at all. What anchors the decision is usage data: Zed publishes a page on zed.dev showing the mix of models running in the editor, and Goel treats it as the baseline of what not to break while supporting whatever launched that morning. That page, Agent Metrics, is anonymized, aggregated data from developers using AI agents through Zed, refreshed weekly so new models have time to accumulate a meaningful sample. As of its August 3rd, 2026 update it showed 846.4K sessions and 7.1M turns across the selected agents over the previous 30 days. It also states its own blind spot: model-level breakdowns only exist for Zed's own agent, because external agents don't reliably report which model they're running.

Most eval numbers are vanity metrics

Asked what makes a good eval, Goel went after the scores first.

a lot of the metrics that come with eval are sort of vanity metrics in the sense that like if you move them by a couple of points in either direction, they don't really meaningfully tell you much about how differently your actual agent is going to behave

What Zed takes from an eval run is the granular observation: the team reads the complete rollout. Goel is blunt that nobody has this solved, Zed included. There isn't good tooling for reading rollouts, so today it amounts to throwing a lot of logs at an LLM, plus Goel manually reading through them to see what changed in behavior between one Sonnet version and the next. The bar isn't a score. It's whether the behavior change would be disruptive to somebody using the editor.

That's a harder bar to automate than a benchmark score, and it's the one that matters when the product is something people never stop using.

The work happens before the commit

Goel isn't declaring git obsolete. You still need to track how a file changed over time, and you still need a place to say this is the version I'm shipping. The problem is what happens upstream of that.

a lot of work now happens before that final commit happens

His own loop: talk to the agent, get something back, decide the first attempt is bad, and do it three or four more times. None of those iterations survive into the commit. What he wants to recover later is the conversation around a piece of code: why the design landed where it did, and what the agent should learn for next time, including what not to do the next time it touches that file.

What Delta DB records

Zed's answer is Delta DB, still in beta, which tracks operations at the file system level along with keystrokes and other events, stored in a CRDT. The goal is to capture the context around code, since that's where the work now happens when people aren't typing the code themselves.

The obvious objection is volume. Nobody wants to open the six-month-old equivalent of an 80-message Slack thread to answer one question. Goel's answer is that a human isn't the one doing the digging:

the idea is to expose all of the context in a way that the agent can go fetch the pieces that it needs and leave behind the pieces that it doesn't for whatever problem you throw at it while maintaining the richest possible history that we can

Review is turning into process review

The most concrete change Goel described is what he now looks for in someone else's PR.

my mental checklist for reviewing someone else's code now is not does this code look good. It is did you run like the code review skill on this piece of code? Did you rewrite this like multiple times or was this like a first pass?

Every one of those questions is about the process that produced the diff, and none of that information travels. If you want the person reviewing your code to see the conversation you had with your agent, there's no good collaborative way to do it. Capturing the history and being able to hand it to a reviewer are two different problems, and only the first one has a system behind it today.

What would let him stop reading the diff

Galow asked the question worth asking: how much of the agent's code do you actually read, and what would have to change for you to read less?

Goel reviews everything that reaches PR stage, though not every intermediate thing the agent writes.

once I am sending it in as something that needs to go into production or just merge into main I want to make sure that I understand most of the lines of code that is written

Which means keeping PRs small, the same discipline teams already had for human PRs. What would change his mind is better verification. Zed has started investing in tools for whether a change performs well after merge, whether it's correct, and whether it's causing regressions; unit tests cover part of that surface area and performance tests cover part, but not all of it. Underneath sits the slower cost: if you never build a mental model of your codebase, you pay for it the next time you need to change something. As long as you still have to point agents at what to build and how, he wants to read the code.

The artifact worth capturing changed

The trail that explains a piece of software used to be the commit history, and reading it was a human activity. Both halves of that are coming apart: the explanation now lives in a sequence of prompts and rejected attempts, and the thing best equipped to read it back is another agent. Zed is building infrastructure to capture that trail. What it hasn't built yet, and what Goel says nobody has, is a way to hand the trail to the person reviewing your PR.

This interview was recorded at the AI Engineer World's Fair 2026.