Can faster AI inference give developers their flow back?

OpenAI says GPT-5.3-Codex-Spark can stream at more than 1,000 tokens a second. My first question was the obvious developer one: does that kind of speed change the feeling of working with an AI?

I had also seen developers on social media describe a stranger trade. I did not read those posts as nostalgia for typing every line. The tension was that AI could put more code on the screen while the work felt less like solving a problem and more like waiting, checking, reviewing, and managing models and agent harnesses. I wanted to know whether lower latency or higher token throughput could tighten that loop again. Those posts gave me the question, not evidence of how common the experience was.

The February 2026 announcement for GPT-5.3-Codex-Spark describes a research-preview model served on Cerebras WSE-3 hardware, with a 128,000-token text-only context window and work across the stack to reduce time to first token, per-token latency, and client-server overhead. OpenAI presents it as a model for targeted, interactive coding. It also says Spark does not automatically run tests unless asked.¹

That final detail changed the question for me. A model can finish talking before the code has been compiled, tested, reviewed, or even understood.

I use two kinds of work throughout this piece. In interactive work, the developer stays in the loop: ask, read, edit, test, and ask again. In delegated work, the developer hands an agent a bounded task, lets it inspect files and run tools and tests, then returns when there is something ready to review. The human waits in different places.

Token speed belongs to the machine.Flow belongs to the person using it.

I wanted to know whether reducing latency could help preserve the conditions for flow. Before I could answer that, I had to be clear about what flow meant here. The obvious story is that less waiting means less friction. In a tight interactive loop, where the next move is blocked on a useful response, that may be true. But it is only one kind of work.

Flow is not a waiting-time metric. The response still has to belong to the task, and the resulting code has to survive tests, review, and the developer's own understanding. With delegated work, generation may not even be the wait that holds the human up.

So I started following the wait through the whole job: what it interrupts, and what the developer has in hand when it ends.

Flow is not the same as speed

Flow is doing too much work in this conversation. So I needed to separate it from a few neighboring terms.

Flow

An absorbing activity state associated with fluency, concentration, a workable balance between challenge and skill, clear goals, feedback, and perceived control. Researchers measure it with multi-item instruments such as the Flow Short Scale. It is not inferred from a stopwatch or from the absence of a browser-window switch.²

Focus

Continuity of attention. It may be necessary for flow, but a developer can focus intensely on a frustrating incident without experiencing flow.

Engagement

Continued use, return behavior, or interaction with a product. A faster tool may increase engagement without improving the code.

Productivity

An output divided by some resource, usually time. The answer changes depending on whether the output is a correct task, lines, commits, pull requests, deployed features, or maintained software.

Trusted change

A term I use in this essay for a change that has passed the checks appropriate to its risk, and that the responsible developer has reviewed, understands well enough to own, and accepts. This is an operational proposal, not a validated psychological scale. Tests are necessary in many workflows, but passing them does not prove comprehension or trust.

These outcomes are not interchangeable. A product team may count a return visit as engagement, while a repository study calls more commits productivity. Serving benchmarks report machine time. On its own, none of those numbers tells me whether a developer experienced flow.

One latency number hides several clocks

Tokens per second describes what happens after generation begins. In day-to-day work, the developer experiences a much longer chain:

1. request, queue, routing, and context preparation;
2. time to the first useful output, not merely the first token;
3. generation of the remaining answer or patch;
4. tool calls, builds, tests, retries, and external services; and
5. human review, comprehension, correction, and acceptance.

The chain behaves differently in two kinds of work. During a small interactive edit, the developer may be blocked until the first useful response. A delegated migration changes the picture: the agent can generate and run tools while the developer does something else. Attention returns when the work is ready for review. Faster generation has a very different value in those two situations.

Agent traces make the machine side of that chain visible. TraceLab's open workload contains 4,265 sessions from 43 users, 357,161 model steps, and 432,510 tool calls across Claude Code and Codex. Only about 4% of tool calls lasted more than one minute, but those calls accounted for 85% of tool time.³

In a separate systems paper, PASTE reports that tools consumed 45% to 57% of end-to-end time in selected agent workloads. Its speculative execution design reduced average latency by as much as 43.5% and p99 by as much as 55.4%, while an audit blocked 602 potentially side-effecting actions among more than 20,000.⁴

Those traces describe infrastructure, not attention.

They cannot tell us whether a developer stared at the screen, read documentation, reviewed another patch, or went for coffee. For this question, a trace gives us elapsed machine time, not what the developer did with it.

What changes when the wait changes

A warning before we go further: what follows is a detailed literature review, and there are a lot of studies in it. I kept them because no single paper measures model latency, the developer's experience of flow, and the path to a tested, understood change together. Each catches a different part of the question.

The cleanest latency experiment was not about code

At CHI 2026, Tan and colleagues published the cleanest isolated response-time study I found. It was preregistered and randomized, and it held the model and output rate constant. It came close to the experiment this question needs, except that nobody was programming.⁵

The final analysis assigned 240 US participants to knowledge-creation or advice tasks. The model was GPT-4o. By the time I read the paper, that already felt old. It began responding after 2, 9, or 20 seconds and then generated at a fixed 25 tokens per second. That design separates the wait for a response from the speed of the response itself.

The researchers had 309 otherwise valid interaction logs before excluding 69 cases, including 63 whose delivered delay missed the assigned latency band. Because most exclusions concern the treatment itself, the result needs to be generalized carefully.

The fastest condition did not improve logged interaction behavior or NASA-TLX workload. Participants rated the 2-second response as less thoughtful than the 9-second response, 5.76 versus 6.09, and less thoughtful than the 20-second response, 5.76 versus 6.11. They rated the 9-second response more useful than the 2-second response, 6.44 versus 6.19. There was no monotonic pattern, much less evidence that nine seconds is an ideal delay.

Response time communicates something too. An immediate answer can feel insufficiently considered, while a pause can set an expectation of effort. That is a UX effect, not evidence that the model thought harder. Coding assistants should not fake deliberation, but task type, expectation, and the experience of waiting can change how a response is received.

The coding A/B measured engagement

The closest real-product evidence comes from Microsoft's Visual Studio Code team. In June 2026, it reported moving GitHub Copilot requests from HTTP to WebSockets while keeping the same product-model combinations. Median time to first token fell 19.46% for GPT-5.3-Codex and 16.37% for GPT-5.4. Median completion time fell 13.55% and 11.74%, respectively.⁶

Microsoft also reported statistically significant increases in active users of 1.27% and 2.17%, and increases in two-day engagement of 1.90% and 3.14%. Those are modest changes, but they moved in the direction a latency argument would predict.

The experiment stops at product behavior. The post does not disclose sample size, absolute latency baselines, allocation details, a complete analysis plan, or output-quality checks. More active use could mean lower frustration, novelty, more attempts, or greater utility. Flow, productivity, and software quality were not measured, so the post cannot tell us what happened to them.

Copilot Arena offers another large field signal. Its platform served 4.5 million paired code suggestions and recorded 11,604 votes from 1,642 users. Latency-aware sampling reduced median experienced latency from 1.61 to 1.07 seconds. In a preference model, the latency coefficient was -0.17 with a 95% interval from -0.33 to 0.00.⁷

That result is likely compatible with a small preference cost for waiting, but the interval touches zero, models and outputs varied, and the platform waited for the slower member of each pair. Flow and trusted completion were outside the study.

So the evidence gave me an estimate compatible with a small preference cost for waiting and a modest engagement signal, not the threshold I thought I was looking for.

An instant interruption can still break the work

Feedback supports flow when it belongs to the task. In a controlled computer task, relevant feedback produced higher flow ratings than either no feedback or randomized feedback.⁸

Nadj and colleagues found a similar complication in office work in their study. Across 166 self-report observations and 129 ECG observations, relevance changed the relationship between interruption frequency, self-reported flow, and heart-rate variability. Frequent interruptions were not uniformly harmful. The physiological measure also failed to correlate with performance or self-reported flow, so one sensor cannot act as ground truth.⁹

That sent me to the programming studies, where timing and relevance arrive bundled together.

Kuo and colleagues studied proactive assistance over five days with 15 professional developers. They recorded 229 interventions and 5,732 interaction points. Post-commit interventions drew 52% engagement, while suggestions after a declined edit were dismissed 62% of the time. In sampled episodes, proactive interpretation averaged 45.4 seconds and reactive episodes 101.4 seconds.¹⁰ Timing was not randomized, so the duration difference is associative. The moment of intervention belongs beside its speed.

The same tension showed up again when the assistant did not wait to be asked. Chen and colleagues compared reactive and proactive assistants with 65 students completing short Python tasks. Some proactive conditions improved completed test cases by 11.6 to 18 percentage points. Yet 90% preferred the user-invoked "Suggest" design and only 47% preferred the persistent design, which participants often described as distracting or annoying.¹¹ The persistent condition changed delay, suggestion frequency, and guidance together, so no latency-only conclusion is possible.

EditFlow's name is a trap in this discussion. Its "developer flow" is an inferred edit sequence composed of Keep, Jump, Revert, and Break states. It is not psychological flow. In separate benchmark resource measurements, the sequence-aware recommender added an average of about 1.71 seconds and 6,580 tokens per query. A 32-student task study then reported faster completion on some tasks, while several task-level contrasts were null.¹²

Extra inference work can be worth the wait when it produces a more relevant next edit. That is very different from saying slower is better.

Two routine data-entry experiments run against the instinct to remove every pause. Brumby and colleagues found that a 10-second post-interruption lockout reduced resumption errors.¹³ These were not programming tasks, and a lockout is not model latency. Still, the result is a useful counterexample: zero delay does not automatically produce the best overall performance, and the delay is not the useful ingredient here.

Relevance, control, and cognitive preparation change what the delay means. An irrelevant suggestion delivered instantly remains irrelevant, except that a faster system may now interrupt more often.

Most of the coding evidence here concerns code completion or short suggested snippets. Long-horizon agent work changes the interaction again, and the evidence has not caught up.

What developers actually report about flow

The same visible work pattern can accompany very different internal experiences. And that's exactly the thing that makes telemetry both tempting and dangerous.

Brown and colleagues first ran an 18-engineer diary study, then validated their log-based method with 51 developers over 97 days. Related-action telemetry could help estimate focused work, but nearly identical logs were sometimes described retrospectively as flow and sometimes as non-flow.¹⁴ This is why the tempting metric "no context switch" cannot stand in for flow. Telemetry still needs human report, and human report has its own recall and reactivity limits.

This is where I wanted the quantitative and qualitative evidence next to each other. The logs can show patterns across the work, while the interviews bring in how developers describe the conditions around flow. Ritonummi and colleagues identified low challenge, interruptions, time pressure, constrained exploration, and poor tool experience as perceived barriers in software work. In interviews with 12 IT professionals, Lange, Cajander, and Normark found that generative AI could support exploration and rapid feedback, while unclear goals, complex tasks, and inaccurate output disrupted flow.¹⁵ Neither study manipulated assistant latency.

Then the newest longitudinal study produced the most mixed picture. Vella and Blincoe surveyed 158 professional developers, followed up with 101, and matched 95 continuing users. Perceived feedback loops improved by 0.21 after correction for multiple comparisons. Flow declined by 0.18 and cognitive load by 0.15, but neither adjusted result was statistically significant. Among individuals, 27% reported improved flow and 35% reported decline.¹⁶

The sample had roughly 40% attrition and relied on self-report. Because the adjusted flow change was nonsignificant and individuals moved in both directions, the average decline does not establish that AI reduces flow. A separate feedback-loop item improved. Latency was never isolated.

Faster output can push the wait into review

So, let's consider the speed of the output.

Fan and colleagues compared 36 AI-assisted participants with 24 controls across three Python tasks. The AI group reported 18.2 fewer NASA-TLX points, finished about 22% faster, and had modeled odds of correctness 1.71 times as high. At the same time, a verification-load composite tracked increasing stress and fatigue and partially mediated those outcomes.¹⁷ Latency was not manipulated. The study shows that assistance can improve task outcomes while checking and reviewing can still carry a psychological cost. This is study evidence of the same tension, but it still does not tell us how common the experience is or whether latency caused it.

A within-participant study of 20 regular Copilot users shows how quickly the clocks can split. Correctness was 25% with interactive Copilot assistance and 60% with OpenHands. Among correct tasks, hands-on effort was 25.1 minutes versus 12.5 minutes. Yet the agent's total elapsed time averaged 27.9 minutes, and the comparative flow item was null.¹⁸ Automation reduced touch time more clearly than wall-clock time. The study did not establish a corresponding flow benefit.

The understanding studies worry me more.

I started this piece thinking about seconds spent waiting. But a developer can save those seconds and still arrive at a change they cannot explain or safely own. At that point, the tool has moved work, and perhaps risk, beyond the place where a throughput chart usually stops.

In the preprint (Im)Paired Programming, 54 students were assigned to a repository-acting agent or a chatbot for an initial web task. Agent users were faster and more accurate on that task but performed worse on recall comprehension. Reasoning comprehension and a later unaided extension did not differ significantly.¹⁹ The condition changed agency, interface, repository access, and required writing together, so latency cannot explain the result.

Shen and Tamkin randomized 52 junior Python programmers using an unfamiliar library. The AI group finished roughly two minutes sooner, a nonsignificant difference, and scored 50 versus 67 on an immediate comprehension quiz, with a reported standardized effect of 0.738 and p=.01.²⁰ This is a small, immediate study from a model vendor, so durable skill loss remains unproven. Completion time and understanding belong in separate columns.

Then there is the three-week workplace trial Dear Diary. It began with 228 eligible participants and ended with 106 protocol-adherent cases: 29 controls, 35 first-time Copilot users, and 42 continuing users. Liking and perceived usefulness rose in the treatment group. Trust did not. Every reported telemetry difference-in-differences estimate for lines, pull requests, and coding time was null.²¹

Attrition and noncompliance were substantial, the product was a 2023-era autocomplete tool, and a null estimate is not proof of no effect. But those nulls still belong in the main argument here rather than hidden in a limitations section.

Wrong code creates review work. Correct code can still leave an ownership problem if the responsible developer does not understand it. So I do not want to manufacture delay. I want the measurement to continue after the code appears.

By this point I could see three different ways lower latency might enter the work.

Why the productivity studies seem to disagree

The apparent conflict starts with one early controlled study, where 95 professional programmers using GitHub Copilot completed a bounded JavaScript HTTP-server task 55.8% faster.²² Three later workplace randomized trials covering 4,867 developers estimated a pooled 26.08% increase in completed weekly tasks or pull requests among developers induced to adopt Copilot, with a standard error of 10.3%. The same analysis estimated 13.55% more commits and 38.38% more compiles.²³ The 26.08% is a complier estimate for older autocomplete tools at participating firms, not a generic productivity constant.

METR then studied a very different setting: 16 experienced open-source developers completing 246 real tasks in mature repositories they knew well. With early-2025 AI tools, the developers took an estimated 19% longer, even though they had predicted a 20% speedup.²⁴ In February 2026, METR reported more than 800 tasks from 57 developers. Raw estimates suggested an 18% speedup for returning participants and around 4% for new participants, but the researchers judged the population signal unreliable because participation, task withholding, concurrent-agent use, and time reporting had become selective. It would be misleading to present that update as a clean reversal.²⁵

Now, looking at the evidence at repository scale, I think the outcome becomes more indirect. An NBER matched event study of more than 100,000 GitHub developers found cumulative commit increases of 40%, 140%, and 180% following adoption of autocomplete, interactive, and autonomous tools. The autonomous estimate shrank to 50% for projects and 30% for releases.²⁶

Now, this is observational evidence, and adoption can travel with developer ability, project selection, organizational change, and other unmeasured factors. The smaller project and release estimates show why writing code and shipping code cannot be treated as the same outcome.

A matched difference-in-differences study compared 806 open-source projects with detectable Cursor adoption against 1,380 matched controls. Its preferred estimator reported a 28.6% average increase in lines added, concentrated early, but no significant average increase in commits. Point estimates for static-analysis warnings, duplication, and complexity were positive in that specification. Duplication was not significant across estimators, however, and alternative estimators materially disagreed about warnings and complexity.²⁷ The adoption proxy, estimator sensitivity, and residual confounding prevent a claim that Cursor caused technical debt. The study raises a quality hypothesis that later work should test.

I would not average these findings.

A productivity measure that stops at generated code also stops too early.

Interactive and delegated work are different problems

I think very fast inference has its strongest case in a tightly coupled loop: completing the next expression, explaining a failing test, transforming a small function, or comparing two local options. If the answer remains relevant and correct, every avoidable pause sits between the developer and the next move.

But delegated work is different. An agent can inspect a repository, edit several files, run tools, and retry while the developer works elsewhere. In that setting, I may want less streaming rather than more. Give me a clear contract at the start, quiet execution, and a well-timed review-ready notification with tests and provenance. The clock I care about ends when responsible review can begin. Chances are, I will ignore the verbose output in between.

No effect size sits behind this table. In a one-company survey with a 14.86% response rate, task demand, accountability, experience, identity, and desired control were associated with differences in developers' openness to AI support. A companion analysis found requests for bounded delegation, earlier quality signals, provenance, uncertainty, and explicit authority limits.²⁸ These are self-reported preferences, not demonstrated effects.

What I would optimize now

If I were designing an assistant or evaluating one for a team, I would keep throughput on the dashboard. The first number I would stop leading with is time to first token. A typing indicator or preamble can improve it without giving the developer anything actionable, so I would measure first useful output instead.

Then I would keep queue, generation, tool, test, retry, review, and acceptance time visible. Medians need their tails; a p99 tool stall can matter more than another hundred tokens per second. Five seconds that freezes an interactive debugging loop should not be added to five minutes of background execution as though the two feel the same.

Then, the output needs its own evidence. A fast patch should arrive as the smallest relevant diff, with the checks actually run, any failures, uncertainty, and links to the material it relied on. More frequent suggestions are not automatically more helpful. The developer should be able to invoke, dismiss, mute, or defer them without negotiation. For unfamiliar or consequential code, acceptance may also require explaining the change, predicting a behavior, or identifying a failure mode.

Then I would follow the work into delivery: rework, defects, review cycles, and release lead time alongside suggestions, commits, and pull requests. More activity can be useful, neutral, or expensive.

The measure I keep coming back to is time to a tested, understood, trusted change. I would keep its components visible rather than collapse them into one score, because teams may reasonably weight them differently. A toy function, a payment migration, and an authentication review should not share one trust threshold.

The experiment I still want to see

The study that would answer the narrow question still does not exist in the evidence I found.

There is a small irony here: the design is conceptually simple and operationally difficult. Randomize coding-assistant latency while holding the model, output, interface, and task stable, then use real programming work. A validated participant-report instrument would measure self-reported flow. Behavioral instrumentation could capture switching and resumption, but it would not stand in for the inner state. That is the part the current evidence keeps missing.

The endpoint should also include correctness, review effort, later comprehension, and a tested, understood, accepted change. I would preregister the delay bands and analysis before observing outcomes. Interactive and delegated tasks need separate estimates because averaging them could erase the difference we care about.

Null results, adverse quality effects, and disagreement between participants would all stay in the report. They are findings too. So would the exclusions, latency fidelity, model stochasticity, task sampling, and any sign that the instrumentation changed the work.

With that design frozen, an N-of-1 pilot could tell me whether the protocol and instrumentation work. It could not establish "the" latency threshold for developers. A population claim would need professional participants, enough matched work to estimate how people differ, and independent replication.

Where that leaves me

I came out of this with more questions than answers, but not with no answer.

If I were choosing a coding assistant tomorrow, I would pay for low latency in the interactive loop and look for a separate review-ready metric for delegated work.

If the developer cannot make the next move until a useful answer arrives, speed has its clearest case. I would measure time to first useful output and then time to a tested, understood, accepted change. When the work is delegated, I care less about the stream of tokens and more about what comes back: a bounded result with tests, provenance, uncertainty, and enough explanation to review and own the change.

That is a workflow conclusion, not proof that lower latency restores psychological flow. Speed can help preserve one condition for flow by removing dead time. It cannot supply relevance, control, correctness, or understanding.

I still want to know whether a faster answer keeps the developer inside the problem, or merely gets code onto the screen sooner.