I spent the last few months pretty much living in Claude Code.
It became a regular part of how I worked: give it a task, let it work through the codebase, review what it changed, and keep iterating.
Today I ran the same multi-step agentic task through Google Antigravity, and the difference surprised me.
Antigravity, running Gemini Flash 3.8, finished the task in about half the time Claude Code took with Sonnet 5.
The speed was nice, but that's not actually what stood out to me.
It was the waiting.
The hidden cost of waiting
When an AI coding agent is working through several tool calls, there are moments where you can be staring at the screen for a minute or two waiting for the next step.
At first, I didn't think much of it.
But I've noticed what I do during those waits.
I check Slack.
I look at another tab.
I start thinking about something else.
And when the agent finally finishes, I have to spend a few seconds — sometimes longer — figuring out where I was in the problem.
That's a surprisingly expensive interruption.
It's not just the two minutes spent waiting. It's the context switch that happens during those two minutes.
When the feedback loop gets tight
With a faster agent, the interaction feels different.
You make a change.
The agent runs a tool.
It comes back.
You review the result and give it the next instruction.
Repeat.
When those cycles happen in seconds rather than minutes, it's much easier to stay focused on the problem.
You still have the architecture in your head. You remember why you made the previous change. You know what you want to try next.
You don't have to reconstruct the mental model every time the agent finishes a long operation.
That was the part I didn't expect to notice as much as I did.
Speed isn't just about tokens per second
When we compare coding agents, we tend to focus on things like:
- Which model writes better code?
- How good is the reasoning?
- How well does it understand a large codebase?
- How accurate are its tool calls?
- How fast does it generate tokens?
Those things obviously matter.
But there's another metric that is harder to measure:
How long does it take to get back into the interaction?
A coding agent isn't operating in isolation. There's a human sitting in the loop.
If the agent takes two minutes to complete a step, the human doesn't necessarily remain in the loop for those two minutes.
That's where latency starts affecting productivity in a way that raw benchmark numbers don't really capture.
I'm not abandoning Claude Code
Claude Code is still very good, and I wouldn't make a broader conclusion from one task or one comparison.
The point isn't that one tool is universally better than another.
What surprised me was how much low latency changed the way I interacted with the agent.
After experiencing an agent that keeps the feedback loop moving quickly, long waits feel much more noticeable.
Maybe that's one of the next things we'll start paying more attention to with agentic development:
Not just how capable is the model?
But also:
How well does the system keep the developer in the loop?
Because sometimes the biggest productivity improvement isn't getting the agent to do more.
It's simply not giving the developer enough time to get distracted.
Top comments (1)
The “time to get back into the interaction” is a much better metric than raw token speed. For agentic coding, I’d measure the full human feedback loop: tool latency + model latency + time for the developer to understand the result and issue the next instruction. A faster model can still feel slow if it produces a huge result that takes longer to review. The real optimization target is keeping the developer’s mental state warm, not simply minimizing inference time.