You’re elbow-deep in a function, half-watching ghost-text suggest the next few lines, when you flip to a chat panel to ask why a different file keeps throwing an error. It feels like getting more done at once. Two independent, non-vendor studies published days apart in July 2026 — both examining GitHub Copilot’s two ways of working, in-code suggestions and chat-based prompting — describe that exact habit and reach a narrower verdict. A mixed-methods field study of professional developers in their actual work environment, by Brandebusemeyer, Zunic, Zimmermann, Schimmer and Arnrich (revised 9 July 2026), finds that in-code suggestions and chat prompting each independently improve efficiency and reduce workload — but combining both within a single task diminishes the benefit. Set beside that is a bigger number: a study of Microsoft’s early-2026 rollout of command-line coding agents, by Murphy-Hill, Butler and Savelieva , found adopters merged roughly 24% more pull requests than they otherwise would have, a lift that held for four months across tens of thousands of engineers. Together the papers move the debate off “does AI coding help” — clearly, in aggregate, it does — and onto a question almost nobody building these tools asks: combining two interaction modes inside one task might quietly tax the people they’re meant to speed up.
Autocomplete and chat each work; stacked, they fight
The Brandebusemeyer team didn’t run a lab task; they combined controlled data-collection sessions with developers’ ordinary work periods, capturing real tasks as they happened. Both channels earned their keep alone: ghost-text completion for quick extensions of code already open in front of you, chat for questions needing explanation or a detour to a file you haven’t touched yet. Developers reported satisfaction “particularly for monotonous, repetitive, and structured tasks” — precisely the work autocomplete was built for. But when a single task pulled in both modes — glancing at a chat explanation of an error while also accepting inline fixes for it — the combined result wasn’t the sum of the two benefits; it was smaller than either delivered alone. The researchers propose a rule of thumb for choosing one interaction type over the other by task type.
In-code suggestions and chat prompting each make a task lighter alone; put both on the same task and the ease cancels out.
The tax is the switching, not the answer’s quality
What makes this more than an ergonomics footnote is where the researchers locate the cost. During development-heavy tasks, perceived cognitive load arises from the AI interaction itself, the study reports, while perceived productivity depends on AI output quality — two variables moving independently. A bad suggestion is a quality problem you diagnose and route around. Reorienting between a ghost-text stream and a chat thread mid-task is a different cost: attention management, deciding which channel to trust for which sub-problem, paid regardless of whether either answer was any good. That points at interaction design, not the underlying model, as the thing worth fixing — echoing a familiar split in this literature, self-reported friction sitting oddly next to measured output, the same asymmetry that surfaced when METR’s follow-up productivity study couldn’t even recruit developers willing to work without AI .
A 24% lift complicates the tax story, it doesn’t erase it
Microsoft’s study is the strongest available complication to a pure friction narrative. Tracking the company’s early-2026 rollout of Claude Code and GitHub Copilot CLI across tens of thousands of engineers, Murphy-Hill and colleagues found the merged-PR lift persisted across their full four-month window — explicitly not a novelty effect. Adoption spread mostly through social networks, and retention tracked engineers’ coding activity more than demographics, suggesting the tools kept earning their place.
“Adopters merged roughly 24% more pull requests than they would have otherwise… the lift persists across our four-month window.”
The authors caution that a merged pull request is a proxy, not the value it delivers, and that the token spend behind these gains “can run into millions of dollars annually.” Still, a number this large and stable is hard to square with mode-switching quietly canceling out the benefit. The likelier reading is that the two findings sit at different altitudes: the cognitive-load result is perceptual, self-reported from a comparatively small sample describing how a task felt, while Microsoft’s is a large, output-based measure of what shipped. Mixing modes may genuinely tax the person doing the work without denting the aggregate — a company can post a 24% lift while developers producing it quietly pay a switching cost neither team measured.
Interaction discipline is the lever nobody is pulling
Put the two papers side by side and the industry’s blind spot comes into focus. Vendors keep adding interaction surfaces to the same session — inline completions, chat, agentic multi-file edits — on the assumption that more channels can only help, and leaders roll them out together because a durable 24% lift is worth chasing regardless of how one developer experiences a Tuesday afternoon. The field study offers a cheap fix needing no new tooling: pick one interaction mode per task, matched to what the task needs, rather than reaching for both because both are open in the same editor. It won’t show up in a rollout deck the way a quarterly PR-merge chart does. But for the developer choosing, mid-bug, whether to trust the ghost text or the chat window, it might be the difference between a tool that lightens the load and one that just relocates it.
