CHI 2026 research found AI coding assistance cuts task time by 22%. The same paper found a measurement called "verification load" that statistically predicts how fatigued you'll be across subsequent sessions. Every AI productivity dashboard you have captures the first number. None of them capture the second.
The paper is "When Help Hurts: Verification Load and Fatigue with AI Coding Assistants," published in the ACM CHI 2026 proceedings and awarded an honorable mention. Sixty developers, three Python tasks, three interaction modes (Inline, Chat, Structured), plus a matched no-AI control cohort. Methodologically clean: the same LLM backend across all AI conditions, with only the interaction interface varying. The 22% time reduction held up. So did something else.
What Verification Load Actually Is
The researchers built a composite metric they called the verification-load index. It combines five signals that reflect how hard you work to confirm that AI output is correct:
- Compile and test failures: how many times the code didn't run
- Time-to-first-compile: how long from session start until you had something that could run at all
- Churn: how much of the AI-generated code you modified or discarded
- Pauses: periods where you stopped coding to read and evaluate output
- Mode switches: times you moved between writing, testing, and correcting
Each of those signals is individually observable. Taken together, they form a composite that captures the cognitive work of auditing AI output — work that doesn't look like coding but consumes working memory in the same way.
The key finding is what this composite predicts. Higher verification load in an AI-assisted session statistically mediates increased stress and fatigue across the task sequence. Not just fatigue by the end of a single session — the trajectory. You carry it forward.
Why the Cross-Session Effect Matters
Most AI productivity research measures within the session. Did the developer complete the task faster? Did the code pass tests? What was their subjective workload score at the end? These are reasonable questions. They're also incomplete.
Software development is not a series of isolated sessions. Each session begins where the last one ended — not just in terms of code state, but in terms of mental state. If a session high in verification load leaves you more fatigued and stressed, your starting conditions for the next session are worse than they would have been. The session that looked productive by its own metrics imposed a cost on everything that came after.
This is the part the CHI paper makes explicit that most AI productivity discourse skips entirely. The 22% time savings is real. It's repeatable across sessions. But so is the verification load that follows from it, and that load doesn't dissipate at end-of-day the way task completion does. It compounds across sessions in a way the aggregate numbers don't show.
The existing research on AI productivity mostly asks "was this session faster?" The CHI paper is asking "what is this session costing the next one?" Those are different questions, and the answer to the second one isn't as clean.
Interaction Mode Changes the Cost, Not the Outcome
The study varied three AI interaction modes while holding the model constant. Inline suggestions — autocomplete, Copilot-style completions — were fastest and lowest-load for simple tasks. Chat — explicit prompting and response integration — produced higher correctness on complex tasks without a meaningful time cost at that complexity level. Structured prompting — predefined templates for task specification — most benefited novice developers at intermediate complexity.
None of these differences are about raw output quality in isolation. They're about which mode creates how much verification load for which kind of work. Inline suggestions on a complex, multi-file task generate more verification load than Chat, because the inline output is shorter and more contextually ambiguous — you're repeatedly accepting small suggestions and then discovering that their combined effect doesn't do what you expected. Chat output is longer and more self-explanatory, which makes auditing it a single larger cognitive event rather than many small ones.
The practical implication: the "right" interaction mode isn't the fastest one or the one that generates the most code. It's the one that minimizes the verification load that accrues for the specific task type you're doing. Those two are not always the same.
What This Looks Like in Session Data
In theory, verification load is invisible. In practice, it has a distinct signature in how a developer's session actually unfolds.
An AI-assisted session with high verification load looks like this at the application level: a block of work in the IDE, a switch to the terminal for a compile or test run, back to the IDE for a correction, terminal again, IDE again, browser tab for documentation check, IDE, terminal. The switching pattern is faster and more fragmented than a flow session, and it keeps returning to the same verification steps — run, read result, modify, run again.
A session with low verification load — typically one where the AI output was accurate enough that auditing it was fast — looks more like a human-authored flow session. The IDE stays primary. Terminal visits are confirmatory rather than investigative. The browser doesn't appear much.
Both sessions might produce the same final output. Both might show the same session length. One carries a measurably different cost into the next day's work.
This distinction is trackable. It shows up in application switching frequency within a session, in the ratio of IDE time to terminal time, in how often you return to a browser tab mid-session. These signals exist in system-level working data — the kind that records what you actually had open, not just what the IDE thinks you were doing.
At xeve, we track exactly this: the full session pattern, not just the editor activity. When we look at working sessions for developers using AI tools, the ones that correlate with better subsequent performance (longer uninterrupted blocks the next morning, higher commit-to-session ratios) tend to show tighter in-session switching patterns. The high-churn, many-correction sessions show up as a leading indicator for fragmented mornings after.
The Measurement You're Missing
Every AI coding tool in 2026 gives you some version of the same dashboard: suggestions accepted, tokens used, time in the tool, maybe cycle time from open to merge. These numbers tell you how engaged you were with the AI. They say nothing about the verification load you were absorbing while engaged.
The CHI paper's verification-load index isn't a score you can get from your current tooling. But you can approximate its component signals. How many times did tests fail before you had something that compiled? How much of the generated code did you end up modifying? How often did you switch between the editor and terminal in a focused session, compared to your non-AI sessions?
Those questions have answers in your session data if anything is measuring it. If your time tracking stops at the IDE, you're missing the terminal visits, the browser documentation tabs, the switching pattern that actually tells you what the session cost. The compile-test-fix loop is where verification load accumulates. It happens outside the editor.
The Takeaway
AI assistance makes individual sessions faster. That's the 22% number, and it's real. The verification work it introduces — the auditing, the compile-test-fix cycling, the mental overhead of holding the AI's decisions alongside your own understanding — creates a load that predicts how much harder your next session starts.
You can't optimize what you don't measure. The AI dashboard measures how much you used the tool. The verification load is a measure of what using the tool cost your cognitive state over time. They're different numbers, and only one of them tells you whether the tradeoff is working in your favor.
Track your switching patterns within sessions. Watch the ratio of terminal time to editor time in AI-heavy versus non-AI sessions. Notice whether your most AI-intensive days are followed by fragmented or focused mornings. The signal is in the sequence, not the aggregate.
The paper is free to read in the ACM Digital Library. The data it points you toward is in your own working sessions — if something is actually measuring them.