On Speed: It still matters
It’s 2026, and a dev tool leader might reasonably ask: does speed still matter if agents, not humans, are waiting? Here’s my take.
I worked at Antithesis for four years; at one point I oversaw a team that built a time-library. We’d often describe one of the internal variables for a time object ‘r’ as the ‘rate’, often set to ‘1’ to represent one second per second. We thought “one second per second” was funny to say, I think, because it pokes at a cosmic rule that seconds march on, somehow both fungible and non-fungible, like clockwork.
Probably that same week, I remember arguing that, in a build, more net-good comes from optimizing a 5-minute build down to 30s than the net-good that comes from optimizing a 10-minute build down to 4 minutes. I wonder if this will feel intuitively true to you, but I believe that these seconds are non-fungible.
My argument largely rests on a 30s build-task being different-in-kind from a 4-minute task, whereas 4-minute, 5-minute, and 10-minute build-steps are all of the same kind. If I interrogate why I feel this way, I think it’s because the number of iterations, the number of at-bats I have, is time-spent ÷ build-time. With build-time as a denominator, this shakes out as a hyperbola with respect to build-time, what an ugly asymptote.
Humans add a few funny perturbations to this equation that are worth reasoning about. As a fellow non-lizard human, I feel differently about setting aside a day to hit multiple iterations vs setting aside an afternoon vs setting aside an hour. How caffeinated will I be in the first hour of the day? Will there be a post-lunch crash? Will I be exhausted due to meetings? There’s a scheduling and planning overhead that’s innately human.
Second, I feel differently about ‘juggling’ a few different contexts. If I have to sit for 5 minutes staring into a void of build logs, maybe the task is complex enough that I can benefit from thinking during that time, maybe it’s not. I may be tempted to juggle a second task, to do a dreaded context switch. But at or below ~30s something magical happens: I get to focus. In my mental model of the world this makes the task-time hyperbola a chunky, human hyperbola.
O(task)
At a low enough iteration-cycle something dangerous happens. You have the ability to artificially increase the asymptotic complexity of the task. Here’s what I mean exactly. We’ve all seen a senior engineer glance at the screen of a struggling coworker, instantly know the problem and solution and intervene. That’s an O(1), constant-time, debugging approach if you can pull it off.
Unfortunately, you can’t always pull it off and sometimes the constant in O(1) is so high or unknown that it’s smarter to take an O(n) approach. In the linear approach, you do something like add log lines or attach a debugger, run through your program, improve your mental model of the program, and repeat. You trade good asymptotics for more certainty.
Disturbingly, becoming extremely skilled at using a debugger can lead you into a better-is-worse trap. Emboldened by your fast iteration loop, you can end up always applying this O(n) approach where the constant-time one would make sense. I know I’ve caught myself throwing debuggers or log lines at problems that were better suited for a “let me just read and grok this code” O(1) approach.
I call this out because it’s an effect in the back of my mind and the minds of others when discussing build-times. Medium-to-long builds give us the opportunity to mess up context-juggling while short builds give us the opportunity to mess up approach selection. It’s another perturbation on the underlying hyperbola, but with an effect size inversely correlated with experience.
Agents
Agents noise the analysis. Adam Frankl, who literally wrote the GTM book on developer tools, had this to say:
For a generation, everyone in developer tools assumed developer time was the constrained resource. Right? And now with the move to agentic coding, that may no longer be the case.
…
[The constrained resource] is time, but it’s in a different dimension, because how developers spend their day after the adoption of AI tools is changing rapidly.
And the idea is [sic], I know what it’ll be twelve months from now? No. I don’t.
I know it’ll be different from today, but it’s so different today from what it was twelve months ago.
src: Adam Frankl answers my Technical Advisory Board questions
You also have strategists like Ben Thompson saying that agentic-inference is currently latency sensitive, but that’s a temporary phenomenon that will last until humans get out of the loop of agentic engineering. Ben speculates that in the steady-state, “if anything it will be the speed of CPUs for things like tool use that will matter more than the speed of GPUs.”
src: Ben Thompson, The Inference Shift
From my perspective agents do a couple things. First they remove the human chunkiness from the hyperbola, which makes for a more extreme slope than we’re used to at some time-scales and a less extreme slope at others. Second, they scramble the likelihood that an asymptotically-correct approach is applied while altering the boundaries of such approaches. I.e., an agent can often unexpectedly ‘just look’ at a codebase and know what’s wrong in constant time. But by the same token, they’ll endlessly bisect git blame when there’s nothing to be found in a way no human ever would. I think this is where some of the “right-context right-time” conversation comes into play. Having specific-to-your-project debugging guidance in AGENTS.md can increase the success rate of asymptotic selection or at least offer some control.
In aggregate though, the rules are the same. The 1/x-hyperbola is the same curve as it was before, despite the new plinko-board of asymptotic selection above it. So for the leader wondering if it’s finally OK for a dev tool to be slow: I’m not sure it is.