JetBrains’ HAX team tracked 800 developers and 151,904,543 IDE events over two years and presented findings at ICSE 2026 in Rio de Janeiro. The headline: AI doesn’t just speed up development — it redistributes and reshapes how developers work in ways their own perceptions consistently miss. 74% of AI-assisted developers didn’t notice increased window switching, yet telemetry confirmed it was happening the entire time.
What JetBrains’ April 2026 Research Actually Found (And Why It Matters)
JetBrains’ April 2026 research is significant not because it reports new productivity statistics — the ecosystem has plenty of those — but because it is one of the first large-scale longitudinal studies to compare what developers believe about their AI-augmented workflows against what objective behavioral telemetry actually shows. The study, conducted by JetBrains’ Human-AI Experience (HAX) team and presented at ICSE 2026, analyzed 151,904,543 logged IDE events from 800 developers over two years (October 2022 to October 2024). Sixty-two developers completed follow-up surveys and interviews. The core finding challenges the dominant narrative: AI tools do not primarily speed up the same work. They redistribute it. Tasks that previously required focused writing time shift toward validation, review, orchestration, and context-switching. The net effect is a fundamentally different developer rhythm — more output, more deletion, more cognitive overhead — that developers themselves systematically underestimate. For engineering teams planning AI tool adoption or evaluating current tooling, this data is more actionable than headline productivity percentages. It names the actual mechanism of change so teams can measure and manage it.
The Study Behind the Data: 800 Developers, 151 Million Events, 2 Years
The JetBrains HAX study is methodologically unusual because it combines three data sources that most productivity studies treat as alternatives: passive IDE telemetry (151M+ logged events), developer self-report surveys, and semi-structured interviews. Most AI productivity research relies on task-completion experiments or self-reported surveys alone — both have well-known limitations. Controlled tasks don’t reflect real workday complexity, and self-reported data is subject to perception bias, recall error, and social desirability effects. The JetBrains study bypasses these limitations by treating telemetry as the ground truth and using surveys to measure the gap between perception and reality. The dataset spans two years across all devices — not a single session or week-long sprint — making longitudinal trend detection possible. Crucially, the study design separated AI-assisted developers from non-AI-assisted developers in the same environment, enabling causal attribution rather than correlation. This is the study design that makes the findings credible. When telemetry and self-report diverge, the telemetry wins — and the divergences in this dataset are consistent and directional, not random noise. The study was published as an academic paper on arXiv (arXiv:2601.10258) and presented at the International Conference on Software Engineering (ICSE) 2026 in Rio de Janeiro, giving it peer-reviewed credibility unusual for vendor-sponsored research.
The Perception Gap: Why 74% of Developers Missed How AI Changed Their Habits
The most striking finding from JetBrains’ research is the magnitude of the perception-reality gap. Seventy-four percent of AI-assisted developers reported no increase in window switching — yet telemetry on 151 million IDE events confirmed that AI users’ window switching trended upward month-over-month over the two-year study, while non-AI users remained flat. This is not a small discrepancy. It is a consistent, directional, multi-year behavioral change that three-quarters of participants were completely unaware of. The explanation is likely cognitive: when AI handles the mechanical code-writing step, developers shift attention to managing AI output — switching to browser tabs for context, verification, documentation lookups, and the AI interface itself. These micro-switches accumulate but don’t feel like “switching” because each individual switch seems purposeful. The aggregate behavioral pattern, however, looks exactly like increased fragmentation. This perception gap has practical implications. Developer self-assessment is the dominant mechanism for evaluating AI tool ROI in most organizations. Surveys asking “does AI make you more productive?” yield highly positive responses — 74% report increased productivity in JetBrains’ ecosystem survey — that don’t capture hidden workflow costs. Teams relying solely on sentiment data are flying with an incomplete instrument panel. Objective telemetry provides the missing dimension.
How AI Actually Redistributes Your Workflow (Not Just Speeds It Up)
The dominant mental model of AI coding assistance is additive: AI writes code faster, so you ship more, faster. JetBrains’ two-year behavioral data tells a more complex story. AI assistance redistributes developer workflow time across different activity types rather than uniformly compressing all of them. Time spent generating code decreases, while time spent on validation, code review, deletion, integration testing, and orchestrating AI outputs increases. The net productivity effect depends entirely on which activities were the bottleneck in a given developer’s workflow. For developers whose bottleneck was writing boilerplate, API client code, or mechanical transformations, AI provides clear time compression — GitHub Copilot users complete tasks 55% faster in controlled research involving 4,800 developers. For developers whose bottleneck was system design, debugging complex interactions, or understanding unfamiliar codebases, AI’s impact is more ambiguous. The METR study found developers actually take 19% longer to complete issues with AI versus the expected 24% faster — and still perceive themselves as 20% faster. The JetBrains longitudinal data contextualizes why: developers are doing more total work (more code generated, more code validated) in the same perceived time, with the additional validation overhead invisible to their introspection.
| Activity | Time Without AI | Time With AI | Net Effect |
|---|---|---|---|
| Code generation (boilerplate) | High | Low | Significant savings |
| Code review / validation | Low | High | Significant overhead |
| Context switching | Moderate | High (per telemetry) | Hidden cost |
| Debugging AI output | Minimal | New activity | New overhead category |
| System design | Unchanged | Mostly unchanged | Neutral |
The New Developer Rhythm: More Code Produced, More Code Deleted
JetBrains’ telemetry revealed a consistent behavioral signature for AI-assisted developers: higher throughput accompanied by higher deletion rates. AI-assisted developers produce more lines of code than non-AI-assisted peers — and delete significantly more. This is not a defect in AI tooling; it reflects the fundamental nature of AI-assisted coding. AI generates candidate code that developers then accept, modify, or reject. The acceptance decision requires reading, understanding, and often running the AI suggestion before deciding whether it fits. When it doesn’t fit — wrong API, wrong abstraction level, wrong context — it gets deleted. The cycle is: generate, evaluate, accept or delete, integrate, re-evaluate. This rhythm is faster than writing from scratch for many task types, but it is not the same as “writing code, only faster.” Code acceptance rates for GitHub Copilot average 27–30%, meaning roughly 70% of generated code is rejected or substantially modified. The 46% of code written by Copilot users that originates from AI suggestions reflects the accepted portion — but understanding what happens to the other 54% requires behavioral data, not acceptance rate statistics. The deletion pattern in the JetBrains data makes this visible at scale. For engineering managers, the implication is that lines-of-code metrics become even less meaningful as an output measure in AI-assisted workflows. Throughput needs to be measured at the feature or story level, not the line level.
AI Adoption in 2026: Usage Numbers vs. Daily Workflow Reality
The gap between AI tool adoption statistics and daily workflow reality is as wide as the perception gap in JetBrains’ behavioral study. Headline numbers: 85% of developers regularly use AI tools for coding in 2026 (JetBrains Developer Ecosystem Survey), 73% of engineering teams use AI coding tools daily (Pragmatic Engineer, up from 41% in 2025), and 51% of all code committed to GitHub in early 2026 was either generated or substantially AI-assisted. These numbers suggest near-universal adoption. Daily workflow reality is more nuanced. JetBrains’ research blog reports that only 18% of developers regularly use AI coding tools in their daily work despite 76% awareness of GitHub Copilot — a measurement that captures sustained habitual use rather than occasional experimentation. The discrepancy between 85% “regular use” and 18% “daily work use” reflects how survey framing shapes results. Developers who use AI tools once a week for specific tasks count as “regular users” in broad surveys but are not experiencing the workflow redistribution effects JetBrains documented. The developers whose telemetry showed behavioral changes — increased window switching, higher code throughput and deletion rates, shifted time allocation — are those using AI as a primary workflow tool, not a supplementary one. This distinction matters for teams evaluating AI ROI. Providing access is not equivalent to achieving workflow integration. The behavioral signal is the reliable indicator of actual integration depth.
From Code Writer to Code Orchestrator — Your Role Is Changing
The framing that best captures what JetBrains’ data describes is the shift from code writer to code orchestrator. A code writer’s primary value-add is producing correct implementation from a specification. A code orchestrator’s primary value-add is directing AI to produce implementation, evaluating its output, integrating it into a larger system, and maintaining correctness across a codebase where significant portions were generated rather than handwritten. This role shift has skill implications that are only beginning to register in hiring and team design. Multi-agent workflow inquiries surged 1,445% in early 2026, and coding agent sessions grew from an average of 4 to 23 minutes — indicating that developers are increasingly managing AI agents through extended, complex tasks rather than single-shot completions. Seventy-eight percent of agent coding sessions now involve multi-file edits. The skill set for effective code orchestration overlaps with but differs from effective code writing. Code orchestrators need strong systems thinking (to direct AI at the right level of abstraction), rigorous code review skills (to catch AI errors before they compound), deep domain knowledge (to evaluate whether AI output is contextually correct), and explicit context management (to keep AI agents oriented across multi-turn sessions). These are skills that senior developers have always needed — but they’re now the primary value-add for the median developer, not secondary to writing speed.
The Hidden Costs: Code Review Overhead, Bug Density, and Downstream Bottlenecks
JetBrains’ behavioral findings align with downstream quality data organizations are reporting in 2026. When developers don’t adequately verify AI-generated code, time spent on code review increases 12% and bug density in unreviewed AI-generated code runs 23% higher than human-written equivalents — per McKinsey’s survey of 4,500+ developers across 150 enterprises. Forty-five percent of developers say debugging AI-generated code is more time-consuming than writing it manually. These costs are invisible to productivity measurements that capture code generation speed but miss the review, debugging, and rework that follow. The JetBrains telemetry adds behavioral texture to these statistics. If AI-assisted developers are context-switching more, producing more code, and deleting more — all of which the telemetry confirms — the downstream validation burden scales with that throughput. A team generating 40% more code throughput without proportionally increasing code review capacity creates a quality deficit that surfaces in later sprint cycles or in production. Ninety percent of developers using AI save at least one hour per week, and 20% save eight or more hours — but those productivity gains are captured at the individual level, while downstream quality costs are absorbed by the team. This asymmetry explains why aggregate team velocity doesn’t always reflect individual AI productivity gains as cleanly as expected. The hidden cost is real, measurable with telemetry, and manageable with process adjustment — but only visible if you’re looking for it.
How to Audit Your Own AI-Augmented Workflow Using Objective Metrics
The actionable lesson from JetBrains’ methodology is that you can apply the same separation of behavioral signals and self-report to your own team. You don’t need 151 million events — you need a small set of consistent, objective workflow metrics tracked over time alongside the AI tools you’re adopting. The most valuable metrics to track: active coding time (time with a file open and keystrokes happening) versus total session time — a widening gap indicates increased context-switching or review overhead. Code churn (lines written then deleted within the same sprint) — elevated churn signals that generated code isn’t fitting on first attempt. Build frequency — AI-assisted developers often run builds more frequently as a validation step after accepting suggestions. PR review cycle time — if AI increases code throughput without corresponding review capacity, this metric degrades. Track these weekly, baseline them before AI tool adoption or during a controlled rollout period, then compare after 4–8 weeks. The JetBrains study’s core insight — that self-report and behavior diverge systematically — applies at the team level too. A developer survey asking “is AI helping you?” returns positive results almost regardless of actual workflow impact. IDE telemetry, git commit patterns, and build frequency tell a different story. Use both, weight the behavioral data, and treat the divergence as signal rather than noise.
What Teams and Developers Should Do With These Findings
JetBrains’ research doesn’t argue against AI adoption — 90% of developers using AI save at least one hour per week, and the 55% task completion speed improvement from Copilot research is real under controlled conditions. The findings argue for clear-eyed adoption that accounts for the full workflow impact, not just the code generation upside. For individual developers: accept that your introspective report of how AI affects your workflow is likely incomplete. Spend two weeks tracking context switches, active coding time, and code churn before concluding that AI is unambiguously accelerating you. The developers in the JetBrains study who were most effective with AI tools treated AI output as a first draft requiring active review, not as finished code. For engineering teams: measure AI impact at the story or feature completion level, not the line-of-code level. Increase code review capacity in parallel with AI tool adoption — the throughput increase is real, and the review overhead is real. Build structured onboarding around the code orchestrator skill set: prompt engineering, AI output evaluation, context management for multi-turn sessions, and knowing when to reject AI suggestions rather than fix them. For engineering managers: resist measuring AI ROI purely through self-reported developer satisfaction. Establish behavioral baselines before broad rollout and track objective workflow metrics through adoption. The perception-reality gap documented by JetBrains is not a flaw in developer self-awareness — it’s a predictable feature of how humans process familiar task environments. Design for it rather than assume it away.
Frequently Asked Questions
These questions address the most common implementation concerns arising from a careful reading of the JetBrains HAX findings and how they fit within the broader landscape of AI developer productivity research in 2026. The perception-reality gap the study documents — where 74% of developers missed a consistent two-year behavioral change in their own work patterns — challenges assumptions that underpin most AI ROI evaluations in organizations today. JetBrains’ methodology, combining 151 million logged IDE events with surveys and interviews, is more rigorous than the single-session controlled experiments or self-report surveys that dominate the AI productivity literature. Understanding what the study actually claims, what it doesn’t claim, and how to apply its findings to real team contexts requires more nuance than the headline statistics provide. The questions below ground the discussion in behavioral data rather than vendor productivity claims, addressing how to measure workflow change, interpret conflicting studies, and structure adoption decisions for engineering teams of different sizes and maturity levels.
Does the JetBrains study prove AI tools reduce overall developer productivity?
No. The study does not make a net productivity claim in either direction. It demonstrates that self-reported perceptions of AI tool impact are systematically incomplete. The longitudinal behavioral data shows redistribution of workflow time, not a net decrease. Other data points — 55% faster task completion with Copilot, 90% of AI users saving at least one hour per week — remain valid for the specific task types they measure. The study’s contribution is methodological: it reveals what existing productivity research misses by relying on self-report alone.
What types of AI tools were included in the JetBrains research?
The study analyzed developer behavior in JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, etc.) with AI assistant plugins enabled. The primary AI coding tool was JetBrains AI Assistant, integrated with various LLM backends. The behavioral patterns are likely generalizable to other AI coding assistants (GitHub Copilot, Claude Code, Cursor) because they share the same fundamental interaction model — suggestion generation and accept/reject evaluation — which drives the context-switching and code churn patterns the study documents.
How does the METR finding (19% slower with AI) fit with the JetBrains data?
METR’s research — which found developers take 19% longer to complete issues with AI despite perceiving themselves as 20% faster — reflects the same perception-reality gap mechanism the JetBrains data documents. METR used a different methodology (controlled task completion on real GitHub issues) but found the same directional result: AI-assisted developers feel more productive than objective measurement confirms, and behavioral measurement contradicts self-report. The two studies reinforce each other’s core finding rather than contradict.
Should teams mandate objective workflow telemetry to evaluate AI tool ROI?
Teams should instrument workflow metrics as a baseline before broad AI tool adoption — not as surveillance, but as a calibration mechanism. The JetBrains study’s key methodological contribution is demonstrating that self-report is insufficient for capturing AI’s full workflow impact. Simple, aggregate metrics (team-level code churn, build frequency, PR cycle time) are low-overhead and sufficient for tracking the most significant redistribution effects. Individual-level surveillance creates perverse incentives and doesn’t add proportional signal value.
What’s the most important behavioral change to watch for when adopting AI tools?
Context switching is the highest-priority behavioral change to monitor, based on the JetBrains data. It’s the change that was most invisible to developers (74% missed it) and most consistently confirmed by telemetry over two years. Elevated context switching during AI-assisted work indicates that the validation and orchestration overhead is fragmenting focus time. Developers who structure AI interactions in batches — submitting larger prompts, reviewing output in dedicated sessions, protecting focused coding windows — report better sustainable productivity outcomes than those who use AI in a constant back-and-forth interrupt model.