AI coding saved time. Where did your attention go?

Picture a platform team shipping a routine change: a new field on an internal API, propagated through two services and a client. The team is hypothetical and the numbers are illustrative. Before assistants, the work took a developer most of a day. Now the implementation lands in ninety minutes. The pull request opens Tuesday morning and merges Friday afternoon.

Nothing in that week went wrong. The reviewer was in a discovery workshop Tuesday and Wednesday. The security question about the new field's persistence needed someone from the platform group, who answered Thursday. The client team wanted to confirm a naming decision before the contract froze. Every one of those steps was necessary, and none of them got faster.

The gap between implementation speed and delivery speed is easy to miss when an adoption dashboard stops at acceptance rates, generated lines, or developer satisfaction. Those measures describe the first ninety minutes. The remaining three days are where the delivery system actually lives, and they depend on the attention of the people who verify, decide, integrate, and coordinate.

What the research actually shows

The published evidence is narrower than the marketing claims, and more useful for planning.

Barke et al. (2023) observed programmers working with a code-generating assistant and found that use splits into two distinct modes. In acceleration mode, the programmer already knows what comes next and treats suggestions as fast completion; interaction is quick and low-friction. In exploration mode, the programmer is unsure of the approach and uses the model to survey options, so the work becomes comparison, prompting, and validation. Tool and developer stay the same across both modes. What changes is the attention profile, and it changes with whether the next step is already known.

Vaithilingam et al. (2022) provide a useful check on enthusiasm. In their study, participants frequently preferred working with the assistant and valued having a starting point rather than a blank file. Task completion time and success rates did not clearly improve. Understanding, editing, and debugging generated code absorbed the effort that generation had saved. Preference and outcome came apart, which matters if your adoption metric is a satisfaction survey.

Perry et al. (2023) tested whether verification attention can be assumed. In controlled security-relevant tasks, participants with AI assistance produced less secure solutions on most tasks, while rating their own work as secure more often than the unassisted group. Confidence moved in the opposite direction from correctness. That result should shape how review is designed, because confidence in an AI-assisted result cannot stand in for evidence that someone checked it.

Lee et al. (2025) widen the frame beyond software. Surveying knowledge workers about generative AI use, they report that critical-thinking activity shifts rather than disappears: away from producing a first draft, toward verifying outputs, integrating responses into a larger body of work, and stewarding the result. The thinking survives; what changes is where in the workflow it happens.

Read together, these give a defensible claim:

AI coding tools do not remove human attention from delivery. They move it: less effort may go into writing familiar code, while more attention is needed for exploration, verification, integration, and coordination.

What this evidence cannot tell you

Be clear about the limits before building policy on any of this.

All four studies are small, controlled, or self-reported. Barke et al. worked with a modest, academia-heavy sample on researcher-designed tasks, and their acceleration/exploration distinction describes behaviour rather than estimating an effect. Vaithilingam et al. ran a within-subject study of similar scale. Perry et al. used mostly student participants, a custom interface, time-boxed tasks, and a model generation that is now several years old. Lee et al. surveyed knowledge work in general; software delivery was outside their frame.

More importantly, none of these studies measures the thing an engineering organisation is actually managing. Not one tracks review age, coordination wait, integration lead time, defect escape, or delivery predictability under production conditions. The step from "attention reallocates in a controlled task" to "queues form in your delivery system" is a mechanism-based inference. It belongs in your own measurement before it belongs in your policy.

The tooling has also moved. Agentic workflows, larger context windows, and repository-aware assistants change the interaction pattern these studies captured. Treat the direction of the finding as informative and the magnitude as unknown in your context.

The flow argument, stated as a hypothesis

Here is the reasoning worth testing locally. If implementation becomes cheaper, the arrival rate of proposed changes rises. Verification capacity, product decision capacity, security judgment, and cross-team coordination capacity do not rise automatically, because each is attached to specific people whose calendars did not change. When arrival rate increases against fixed downstream capacity, queues form downstream. That is ordinary flow economics, and it is the most plausible reason a team can feel faster while its cycle time stays flat.

This remains a hypothesis rather than a finding of the studies above. In some teams the effect will be small, because review was never the constraint. In others the largest queue will sit somewhere unexpected, such as a product decision or a dependent team's release window.

Notice also what the research does not support: a blanket claim that AI creates more work. Barke et al. document genuine low-friction acceleration when the developer knows the next step. Redistribution becomes a problem under specific conditions, when work is unfamiliar, when generated output is hard to inspect, or when review and decision capacity stay fixed while volume grows.

A diagnostic you can run this month

Take the last 20 AI-assisted work items that reached production or were abandoned. For each one, record six timestamps: implementation start, first meaningful human review, each major revision loop, any decision wait, integration or release wait, and post-merge rework.

Then separate touch time from waiting time. Touch time is when a person was actively working the item; waiting time is everything else. Do not predict what the ratio should be. The exercise earns its keep only if it reveals where waiting concentrates in this delivery system.

Two patterns deserve attention. First, items where implementation was fast and first review was slow, which suggests review capacity has become the constraint. Second, items that came back after merge, which suggests verification attention arrived too late to be cheap.

Once the largest queue is visible, change one operating condition and hold it for four weeks. If review is the constraint, the change worth testing is a reviewer capacity commitment: name two people per team whose calendars protect a fixed daily block for review, and measure whether review age drops. If the constraint is decision wait, the equivalent move is a standing decision slot rather than more reviewers. Change one thing, because two changes teach you nothing about either.

Four weeks is long enough to see whether the queue moved and short enough that reversing the change costs little.

References

Barke, S., James, M. B., & Polikarpova, N. (2023). Grounded Copilot: How Programmers Interact with Code-Generating Models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), 85-111. https://doi.org/10.1145/3586030

Lee, H. P. H., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., & Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, 1-22. https://doi.org/10.1145/3706598.3713778

Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants?. Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2785-2799. https://doi.org/10.1145/3576915.3623157

Vaithilingam, P., Zhang, T., & Glassman, E. L. (2022). Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. CHI Conference on Human Factors in Computing Systems Extended Abstracts, 1-7. https://doi.org/10.1145/3491101.3519665