Offloading Score: Measuring AI Reliance Through Counterfactual Workflows Vishakh Padmakumar, Lujain Ibrahim, Zora Zhiruo Wang, Jennifer Wang, Q. Vera Liao, Diyi Yang https://arxiv.org/abs/2605.29392 [𝚌𝚜.𝚂𝙴 𝚌𝚜.𝙲𝙻 𝚌𝚜.𝙲𝚈 𝚌𝚜.𝙷𝙲]

Offloading Score: Measuring AI Reliance Through Counterfactual Workflows

Source: https://arxiv.org/html/2605.29392 Vishakh Padmakumar Stanford University Lujain Ibrahim University of Oxford Zora Zhiruo Wang Carnegie Mellon University Jennifer Wang Stanford University Q. Vera Liao University of Michigan Diyi Yang Stanford University

Abstract

AI tools are increasingly integrated into real-world workflows. However, existing measures of reliance on these tools focus on AI output adoption or on self-reported indicators, rather than how task effort is distributed between users and tools. Here, we introduceoffloading score, a measure of reliance that quantifies the fraction of cognitive effort offloaded to an AI tool.Offloading Scoreis simulation-based—we construct a counterfactual workflow by estimating how the user would have completed the task without the tool, and then computing the fraction of steps saved by using the tool. We validateoffloading scorethrough intrinsic evaluations of metric validity, and a controlled user study (n=40n=40) with developers performing programming tasks using AI tools. We vary time pressure to test whether reliance measures capture the known increase in reliance under time pressure. We show thatoffloading scoredetects significantly higher reliance in time-constrained settings (+43%+43\%,p=0.018p=0.018), while usage-based and self-reported baseline measures of reliance do not distinguish the conditions. We complement this with descriptive insights showing that higher reliance manifests as greater delegation of subtasks to the tool and more direct reuse of AI outputs. Finally, we demonstrate an approach of usingoffloading scorein combination with target outcomes of a task (e.g., code understanding) to identify when reliance may be (in)appropriate. Our framework offers two contributions: an instrument users can apply to measure and reflect on their own reliance, and a quantitative signal that agent designers can utilize to mitigate overreliance.

1Introduction

AI tools are increasingly integrated into everyday cognitive tasks, from writing and coding to analysis and decision-making. While these tools can improve productivity(Brynjolfssonet al.,2025)and are thus being widely adopted(Sleegerset al.,2025), they also raise concerns about risks of overreliance, including deskilling and reduced independent problem-solving ability(Shuklaet al.,2025; Zhiet al.,2026; Shen and Tamkin,2026; Ibrahimet al.,2025). These concerns extend beyond the quality of output produced, to cognitive impacts resulting from offloading of cognitive work to AI.

Existing frameworks typically measure reliance either using users’ self-assessments or AI output adoption (Section˜2). Output-based methods, developed in prior work focusing on classification settings, treat reliance as a binary measurement (accept/reject), categorizing users as overreliant when they accept incorrect outputs and underreliant when they reject correct ones(Vasconceloset al.,2023; Liuet al.,2026). These measures break down in multi-turn human-AI workflows with contemporary AI tools, where reliance may manifest in different ways users provide inputs (i.e., prompting) and interact with tool outputs. Self-reported measures are more fine-grained in capturing users’ perceived reliance, but are subjective, noisy, and expensive to collect(Kohnet al.,2021).

In this work, we instead characterize reliance by how cognitive work is distributed between the user and the AI tool, i.e. how many of the planning, execution, and verification steps that a user would otherwise perform are offloaded to the AI. Intuitively, a user who asks the tool to solve an entire coding task is more reliant than one who decomposes the task, queries the model for subcomponents, and verifies each step, even if both produce similar final outputs (Figure˜1(A)). Our goal is to measure how AI use changes people’s cognitive processes when completing tasks, and provide a starting point for identifying inappropriate reliance patterns that may lead to negative long-term consequences.

Figure 1:We proposeoffloading score, a scalar measure of cognitive effort offloaded to an AI tool, complemented by descriptive dimensions of tool use.Offloading Scoreis computed by identifyingAI-assistedworkflow steps, estimating human-only counterfactual alternatives, and computing the fraction of workflow steps saved by the tool.Offloading Scoredistinguishes user reliance patterns more effectively than baseline measures (e.g., AI Code Fraction) (Section˜4) and can be paired with outcome measures such as system recall to interpret reliance patterns (Section˜5).##### RQ1: Can we design a measure of reliance that reflects what and how much cognitive work is offloaded to AI?

We propose a multi-dimensional framework for measuring reliance (Section˜3,Figure˜2): (1) A primary scalar metric,offloading score, that estimates the fraction of cognitive effort offloaded to the tool by replacing each AI-assisted workflow step with a human-only counterfactual sequence and measuring the fraction of steps saved (Figure˜3); and (2) complementary descriptive dimensions that categorize (a) the kinds of tasks offloaded to the tool, inspired by the Flower model of cognitive processes(Flower and Hayes,1981), and (b) how users engage with model outputs, using a four-point scale inspired by Bloom’s taxonomy(Bloomet al.,1956). We first establish the validity ofoffloading scoreby evaluating whether the constructed human counterfactual workflows provide reasonable alternatives for completing the same task, as well as assessing the stability and sensitivity of the metric to controlled perturbations (Section˜3.3). We then validateoffloading scorein a controlled user study withN=40N=40experienced freelance developers completing programming tasks either undershort(11hour) orlong(44hours) time limits. To reflect the association between time pressure and increased tool reliance(Zakay,1993; Riceet al.,2009; Swaroopet al.,2024; Haduong and Smith,2024), a valid reliance measure should assign higher scores in theshortcondition. We find thatoffloading scoreassigns significantly higher reliance in theshortcondition (on average0.4510.451vs.0.3080.308,p=0.018p=0.018), while baseline measures, including output-based metrics such as fraction of AI-code retained (0.1520.152vs0.0520.052,p=0.072p=0.072) and self-reported cognitive load (3.633.63vs.3.563.56,p=0.881p=0.881), do not significantly distinguish the conditions (Section˜4.5). We also identify via the descriptive dimensions that the higher reliance is associated with a shift in usage patterns, leading to more direct reuse of AI outputs and less iterative back-and-forth with the tool.

RQ2: Can we useoffloading scoreto identify conditions for (in)appropriate reliance?

The judgment of whether a reliance level should be considered appropriate depends on the user’s normative goal, i.e., what outcome reliance is meant to support. We demonstrate an approach to useoffloading scorein combination with measures of target task outcome, using a desirable level of code understanding as an example, to identify the conditions for appropriate reliance. We observe a general negative correlation betweenoffloading scoreand task understanding, which allows setting a threshold ofoffloading scorefor overreliance—higher-than-threshold reliance leading to unacceptably poor task understanding. However, we also observe an outlier cluster of users who have moderate-to-highoffloading scoreand high task understanding. Qualitative data indicate that they exhibit a distinct pattern of using the AI tool forlearningabout unfamiliar coding tasks, suggesting higher reliance can be consideredappropriatein this particular context of AI tool use.

Concretely, we sum up our contributions as: (1)A measure of reliance grounded in user behavior.We introduceoffloading score, a scalar measure that estimates the fraction of workflow steps saved through AI assistance by replacing AI-assisted steps with human-only counterfactual alternatives.Offloading Scoreis computed directly from interaction traces (e.g., screenshots and keystrokes), making it applicable across different tools and interfaces. (2)A multi-dimensional characterization of AI usage.We complementoffloading scorewith descriptive categorization of the tasks offloaded to AI and how users engage with AI outputs. (3)Empirical validation through a user study.Offloading Scorecaptures variation in reliance under time pressure better than baseline measures, while providing descriptive behavioral insight. By jointly analyzing reliance and code understanding, we show that users exhibit distinct patterns, including overreliance and appropriate reliance.111We release thecodeassociated with this project as well as awebsitewith examples and consolidated findings.

2Background

Existing measures of reliancePrior work has measured reliance using two main approaches. The first isusage-based, usually in the form of a binary value measuring whether or not users adopt AI-provided outputs(Vasconceloset al.,2023; Buçincaet al.,2021; Zhouet al.,2025; Bansalet al.,2021). These measures are often combined with evaluations of outcome correctness to assign normative labels such as overreliance (adopt + incorrect) and underreliance (reject + correct) to an interaction. Other related usage-based metrics, such as switch fraction(Yinet al.,2019)and weight of advice(Logget al.,2019), measure whether users update their decisions with AI suggestions. The second approach involves self-reported measures of perceived reliance and its cognitive effects such as automation complacency scales(Merrittet al.,2019)and cognitive load assessments (e.g., NASA TLX(Hart and Staveland,1988)).Zhiet al.(2026)infer reliance from performance differences across AI access conditions, treating it as a latent factor. In this work, we propose a measure that bridges these different approaches by going beyondhow mucha tool is used to capturehowit is used in a workflow, providing a process-oriented view of reliance grounded in user behavior.

Impacts of (over)relianceThe public-facing deployment of LLM-based systems at scale has motivated work on the impacts of (over)reliance, characterized by reduced scrutiny of AI outputs, weaker human oversight, and difficulty maintaining appropriate control over AI-supported decisions(Passi and Vorvoreanu,2022; Buçincaet al.,2021; Yizhou Tianet al.,2026). Recent work extends this concern to longer-term effects, including cognitive surrender, disempowerment, misplaced responsibility, and reduced opportunities for skill development(Shaw and Nave,2026; Sharmaet al.,2026; Shuklaet al.,2025). In educational settings, reliance patterns are shaped by user factors such as expertise and need for cognition(Pittset al.,2025; Shen and Tamkin,2026). These concerns are salient in AI-assisted coding, one of the tasks and professions most exposed to contemporary models(Massenkoff and McCrory,2026). Coding assistants reduce effort and automate unfamiliar tasks but also raise concerns about whether users can understand and maintain the code they produce(Chenet al.,2025). AI tools may slow experienced developers in realistic open-source tasks, and AI-generated code can increase maintenance burden and technical debt when developers must later understand, review, or repair generated artifacts(Beckeret al.,2025; Xuet al.,2026). These findings motivate our focus on capturing how users delegate cognitive effort to AI systems and how well users understand the resulting code artifacts, beyond just the task outcome.

3Process-Oriented Measurement of Reliance

3.1Problem Setting

We consider the problem of characterizing the reliance of a userUUon a toolTTwhen performing computer-use activities. FollowingWanget al.(2025), we define aworkflowas a sequence of steps taken to achieve a predefined goal, where each step consists of one or more actions that accomplish a distinguishable sub-goal. Formally, letW={w1,…,wn}W=\{w_{1},\dots,w_{n}\}denote a workflow ofnnsteps undertaken byUUto achieve a goal. Each stepwiw_{i}represents a coherent unit of progress toward the goal, such as writing code to fix a feature or generating documentation files. Each step may be completed independently byUU, left entirely toTT, or involve interaction between the two for that particular sub-goal. Our goal is to characterize howTTis used at each step, as well as how the user responds to the outputs ofTT, capturing the reliance ofUUonTTby modeling both the allocation of cognitive effort and the interaction dynamics between them over the course of the workflowWW.

Figure 2:(1) We computeoffloading scoreby expanding AI-assisted steps into simulated counterfactual human-only steps and measuring the fraction saved.Figure˜3details howoffloading scoreis computed. We also characterize reliance by the (2) types ofprocessesoffloaded and (3) how users interact with tool outputs.

3.2Proposed Measure

Figure 3:Calculatingoffloading score. From raw interaction traces (e.g., keystrokes, clicks, screenshots), we induce the observed human–AI workflow using the workflow induction toolkit(Wanget al.,2025).AI-assisted stepsare expanded into equivalent human-only counterfactual sequences, representing how the same sub-goal would be achieved without the tool. We compute theoffloading scoreas the fraction of workflow steps saved through tool use.We first define a scalar measure of reliance based on how cognitive effort in the workflow is distributed between theUUandTTand introduce complementary dimensions that capture which cognitive processesUUoffloads toTTand how they engage with the tool output (Figure˜2). InSection˜4, we show how theseprocessandoutput-uselabels provide interpretable, descriptive insights into user behavior.

How would the user have done the task without AI?

We adopt a counterfactual formulation to capture not just how much the tool is used, but how it is used within the workflow. Since cognitive effort is not directly observable from the final artifacts or tool usage alone, we estimate how each AI-assisted sub-goal would have been completed without the tool. For each observed workflowW={w1,…,wn}W=\{w_{1},\dots,w_{n}\}, we identify the subset of steps that were completed with assistance fromTT. For each such stepwiw_{i}, we estimate a corresponding human-only counterfactual sequencewi′={wi,1′,…,wi,ki′}w^{\prime}_{i}=\{w^{\prime}_{i,1},\dots,w^{\prime}_{i,k_{i}}\}withki≥1k_{i}\geq 1, representing how an average user would have completed the same sub-goal without access to the tool.

We then obtain a counterfactual workflowW′={w1′,…,wm′}W^{\prime}=\{w^{\prime}_{1},\dots,w^{\prime}_{m}\}by replacing each AI-assisted stepwiw_{i}with its corresponding human-only sequencewi′w^{\prime}_{i}. Typically,m≥nm\geq n, reflecting the additional work required without the tool. SeeFigure˜3for an illustrative example. This short-horizon simulation is inspired by past work which simulates interaction trajectories to estimate the contribution of individual steps in a workflow(Wuet al.,2025). NoteW′W^{\prime}is defined with respect to an average user rather than the specific userUU, allowing this framework to be reused across different users without requiring a personalized estimate for each individual.222We note a natural extension for personalized measurement would construct user-specific counterfactuals conditioned on inferred capabilities or prior behavior(Shaikhet al.,2025).

We quantify the cognitive effort offloaded toTTby the scalar fractionm−nm\frac{m-n}{m}, which measures the proportion of counterfactual workflow steps saved through the use of the tool.333We note that our work assumes workflow induction that produces a consistent granularity across steps as part of the analysis pipeline. We acknowledge some limitations of this process inAppendixA.In general,m≥nm\geq n, so the range of this value is between0and11. This fraction, referred to asoffloading score, serves as the primary scalar measure of reliance in empirical evaluation. We evaluate how this measure correlates with reference labels of reliance inSection˜4.5and also how we can use this to distinguish different patterns of user behavior inSection˜5.

To complementoffloading score, we introduce the following dimensions that provide a structured description of how this reliance manifests.

What kind of assistance is the userUUasking of the toolTT?

For each user request, we examine the interaction in context and classify it into a set of cognitive process categories inspired byFlower and Hayes (1981). These includehigh-level planning,low-level execution,feedback seeking,coordination, and an “other” category. Each interaction is associated with a workflow stepwiw_{i}, allowing us to characterize the distribution of process types across the workflow. We compute the fraction of workflow steps that involve each type of cognitive process, capturing what kinds of work are being offloaded to the tool. These are referred to asprocesslabels.

How is the user engaging with the output of the model?

In addition to the requests made to the tool, we characterize how users engage with model outputs. Drawing onBloomet al.(1956), we define a set of interaction levels that reflect increasing degrees of user involvement:directly reuse(the user directly incorporates model-generated content with minimal modification),adapt and apply(the user applies ideas or structures from the model output but substantially adapts them),question, debug, or push back(the user evaluates or challenges the model output), andreject(the user does not use the model output and completes the step independently). We compute the fraction of workflow stepswiw_{i}associated with output interactions of each category, capturing how users allocate effort when engaging with tool-generated content. These are referred to asoutput-uselabels.

3.3Intrinsic Evaluation ofOffloading Score

We first evaluateoffloading scorethrough intrinsic tests of metric validity.

Content Validity.Content validity assesses whether a metric captures the construct it is intended to measure. For constructs that are difficult to quantify directly, we follow prior work on automatic metric design(Ryanet al.,2025)by making the metric computation transparent and supporting its components with evidence.Offloading Scoreaffords transparency by design as it is computed as a simple fraction of observed and counterfactual workflow steps, and users can review the mapping from each AI-assisted step to its human-only counterfactual. We validate the plausibility of these counterfactuals in two ways: (1) through human judgments, with over85%85\%of sampled counterfactual steps rated plausible (≥3\geq 3on a55-point Likert scale) (Section˜D.2); and (2) using a dataset of human and agent workflows fromWanget al.(2025), showing that generated counterfactual workflows align more closely with human workflows from the same task than with workflows from other related tasks in the same domain (p≈10−6p\approx 10^{-6}with a Wilcoxon test;p<10−4p<10^{-4}with a permutation test) (Section˜D.1). We also validate the descriptive annotations against human judgments, finding thatgpt-5.2achieves80%80\%agreement for cognitive process labels and81%81\%agreement for output-use labels (Section˜D.4).

Construct Validity.Construct validity asks whether a metric behaves consistently with the construct it is intended to measure. FollowingCampbell and Fiske (1959), we evaluate this through sensitivity and stability. Sensitivity tests whether a metric assigns systematically lower (or higher) scores when examples are perturbed in a manner meant to degrade (or improve) the underlying construct. InSection˜D.3, we show thatoffloading scoreexhibits sensitivity, with mean scores falling by6.9%6.9\%,9.0%9.0\%, and12.9%12.9\%when workflows are edited to remove AI-assisted steps under5%5\%,10%10\%, and20%20\%perturbations, respectively (Figure˜13). Stability checks that when perturbations are made that are not intended to affect the construct, the scores assigned remain consistent. We also find thatoffloading scoreis stable under perturbations where we do not expect reliance to change, including differentreasoning effort, different underlying models, and paraphrased workflow steps (Figure˜12).

Criterion Validity.Criterion validity measures the extent to which the proposed metric aligns with an external reference standard. In the absence of a single gold standard, we establish criterion validity foroffloading scoreusing the variation across experimental conditions in our user study (Section˜4), where prior work predicts higher reliance under time pressure.

4Validating Our Measure of Reliance

4.1Study Design

We conduct a between-subjects experiment to validate the proposed scalar measure of reliance,offloading score. Users are recruited to complete coding tasks where the goal is to build functional web-based applications using any AI tools of their choice. We select four tasks spanning different skill domains, including graphics, database management, and asynchronous event handling.444We provide each set of task specifications inSectionE.3. Participants complete the tasks by satisfying these specifications.

We introduce two experimental conditions that vary time constraints, ashortcondition (11hour) and alongcondition (44hours). Each task is completed by55participants per condition, resulting inn=20n=20participants per condition. This design is motivated by robust evidence showing that time pressure increases reliance on external tools(Zakay,1993; Riceet al.,2009; Jung and Seiter,2021; Swaroopet al.,2024; Haduong and Smith,2024; Rosbachet al.,2025; Huaet al.,2025). Therefore, foroffloading scoreto be a valid measure of reliance, it should assign higher scores on average in theshortcondition. We evaluate this by comparing our measure across conditions using two-samplett-tests, and reporting the correlation with the binary condition label as an effect size.

4.2Study Procedure and Participants

The study consists of three phases. First, participants complete a pre-task survey about their attitudes and typical usage of AI coding tools (Section˜E.2). They then complete the coding task in the time frame corresponding to their assigned condition. This involves installing theworkflow induction toolkit(Wanget al.,2025), and running the recording tool while finishing the task. The tool records all mouse and keyboard actions, while also taking screenshots when these are performed. Participants submit the recorded interaction data in addition to their final code via Google Drive or GitHub. Finally, participants complete a post-task survey consisting of: (a) a system recall component, where they answer1010questions about how task specifications were implemented in their code555We include system recall to capture how well users understand the systems they co-create, enabling us to interpret reliance in relation to task outcomes (Section5).; (b) self-reported measurements on a Likert scale of (i) cognitive load, using the NASA-TLX scale, (ii) trust of AI output, (iii) perceived ownership of the final project, (iv) perceived distribution of cognitive work between the user and the tool. (c) participants’ primary reasons for relying on the tool (Section˜E.4). The study procedure was approved by an institutional ethics board (anonymized for peer review).

Figure 4:Comparison of different reliance measures acrossshortandlongconditions inSection˜4.5.Offloading Scoreassigns significantly higher values for user reliance in the short condition (p =0.0180.018), consistent with the expected trend from prior literature. In contrast, baseline measures based on AI usage (code attribution, time, interactions) and self-reported cognitive load have higher variance.ParticipantsWe recruit U.S.-based participants through the crowdworking platform Upwork. Participants were required to have completed at least three prior coding projects on the platform and to list AI coding tools they regularly use, ensuring familiarity with modern AI-assisted coding tools. We provide more details about participant recruitment inSection˜E.1. The final study consisted of44tasks with55participants per condition across22experimental conditions (4040participants total).

4.3Summary Statistics on Collected Traces

Workflows inlongcondition are slightly longer on average thanshort(176176vs.150150,p>0.05p>0.05) with a lower proportion of AI-assisted steps (16.40%16.40\%vs9.68%9.68\%,p=0.03p=0.03) indicating more extended human involvement (Section˜B.1). Users use various tools from coding agents to chat assistants, withClaudeandChatGPTaccounting for70%70\%of workflows, followed byCursorandGemini(Figure˜8).666We calculate the primary tool in a workflow with a keyword matching process described inSectionB.2.

4.4Calculating Measures of Reliance

Workflow Induction.We run the workflow induction tool on the collected interaction traces which results in a sequence of workflow steps that describes how the user completes the task with their tools.Appendix˜Bprovides more details of this process and a representative example (Section˜B.3).

Calculating Proposed MeasuresFor each participant, we first identify the subset of workflow steps that involve interaction with the AI tool usinggpt-5.2. We then computeoffloading scorefor each participant by constructing human-only counterfactual workflows usinggpt-5.2, following the procedure described inSection˜3.2. We also usegpt-5.2to label the AI-assisted steps forprocessandoutput-uselabels according to the rubrics described inSection˜3.2. In addition to the step itself, we provide the surrounding workflow context and the overall task goal in the prompt (Section˜C.1andSection˜C.2). We report both group differences and correlations with the condition label foroffloading score, and use the distributions overprocessandoutput-uselabels for descriptive analysis.

Baseline measures.We also evaluate various baseline measures from the literature against the binary condition label. We report (a) total number of AI interactions, (b) lines of code generated by the tool(s) (Section˜E.6), and (c) the fraction of time spent using the tool. We provide details on how we compute these measures inAppendix˜B. In addition, we also include (d) first-person measurement of cognitive load using the NASA-TLX scale from the post-task survey.

4.5User Study Results

Offloading Scorereliably captures increased reliance under time pressure.FromFigure˜4, we observe thatoffloading scoreassigns higher reliance in theshortcondition (p=0.018p=0.018), as anticipated by the reference hypothesis for our user study. This provides evidence thatoffloading scorecaptures variation in reliance induced by experimental manipulation. This effect also holds within each task individually, with a higher meanoffloading scoreassigned to theshortlabel on each task (Section˜F.1).

Comparison betweenoffloading scoreand baseline measures of reliance.We also compareoffloading scoreto baseline measures of reliance based on AI usage and self-reported experience. We expect a strong measure of reliance to be able to distinguish between users in our experimental conditions. FromFigure˜4, we observe that none of the baseline metrics show significant differences between conditions at the5%5\%level, whileoffloading scoreis able to do so. We do note that the strongest usage-based baseline measure, the fraction of code attributed to the tool, approaches significance (p=0.072p=0.072). We also examine the correlation of each measure with the condition label inFigure˜15and find thatoffloading scoreexhibits the strongest association (Pearsonr=0.37r=0.37), compared to weaker correlations for baseline measures (e.g.,r=0.17r=0.17for code attribution being the second strongest). Together, these results suggest thatoffloading scoreprovides a more sensitive measure of reliance compared to existing usage-based and self-reported measures. We provide examples ofpointsof high reliance in workflows inSection˜F.7where users rely on AI outputs with minimal iteration and use their tool to entirely design and implement a feature.

Higher reliance manifests as increased delegation and more direct reuse of outputs from the tool.As shown inFigure˜5, users in theshortcondition engage in more execution-oriented interactions (38.5%38.5\%vs.29.6%29.6\%inlong) and frequently directly reuse tool outputs (25.6%25.6\%vs.11.9%11.9\%), suggesting that time pressure shifts users toward delegating task execution and incorporating outputs with minimal modification. In contrast, users in thelongcondition reject outputs more often (22.8%22.8\%vs.15.6%15.6\%inshort) and use the model more for planning-related processes (39.8%39.8\%vs.33.3%33.3\%), indicating more selective engagement and greater user agency. We provide an illustrative example inSection˜F.8.

Figure 5:Distribution ofprocessandoutput-uselabels acrossshortandlongconditions, normalized by total number of labeled interactions. Users in theshortcondition directly execute subtasks with the tool and reuse the model outputs, while users in thelongcondition more frequently reject or adapt outputs, indicating more selective engagement.

5UsingOffloading Scoreto Identify Conditions of (In)appropriate Reliance

An important utility of a reliance metric is to help identify inappropriate reliance, such as determining whether a user’s reliance score exceeds a threshold to indicate overreliance. However, such normative judgments have to be made based on the user goal, or what constitutes undesirable outcomes of inappropriate reliance. Here we analyze howoffloading score, in combination with target task outcome measures, can be used to identify when reliance may be considered (in)appropriate.

Code understanding as a desirable outcome for human-AI collaborative coding.We consider maintaining a good understanding of the task (i.e., code being produced) as a desirable outcome. This choice is motivated by findings from software engineering literature on the risks of accumulating technical debt, including increased costs of future development and maintenance(Limet al.,2012; Zazworkaet al.,2013; Martini and Bosch,2015). Since intuitively, relying on AI-assisted tools more likely creates risks instead of offering benefits for maintaining code understanding, here we only consideroverreliance(as opposed to underreliance) as the undesirable, inappropriate reliance. Note that our approach can be applied to different normative goals. In practice, it is possible that the normative standards for different goals (e.g., what is the right reliance for harnessing productivity gain versus maintaining a good understanding) will differ, and one needs to make a priority judgment.

Calculating user system recall as a proxy for code understanding.As a proxy for code understanding, we usesystem recall, measured from the post-task survey (Section˜4.2). This measure scores how well users understand the implementation details of the system they co-create with the tool. Each user answers1010questions about their system, which we evaluate using an LLM-as-judge against the reference implementation. Answers are scored on a scale asincorrect(scored zero),partially correct(0.330.33),mostly correct(0.670.67), orfully correct(1.001.00). We usegpt-5.2for performing this evaluation, and provide both additional details and the prompt used inSection˜E.5. From these, we obtain an average code understanding score of the user about the system they submit. To illustrate defining appropriate reliance, we use a threshold of0.330.33(partially correct) as an indicator of “good enough understanding”. In practice, such a threshold can be set empirically, by benchmarking the understanding level of programmers with good long-term productivity and agency.

5.1Identifying Conditions for Overreliance

A general negative correlation betweenoffloading scoreand system recall.Intuitively, reliance should predict the cognitive risk of loss of understanding. We observe that the correlation ofoffloading scoreto system recall is higher (−0.145-0.145) than other baseline reliance measures (the strongest baseline is−0.101-0.101) (Figure˜16). This offers more evidence of the validity of our metric. To dig deeper, inFigure˜6, we plot reliance, measured byoffloading score, versus system recall, measured by the average score obtained by the users on all questions. When excluding users in the outlier cluster (30%30\%of users in the green region inFigure˜6, to be discussed below), we find that the Pearson correlation ofoffloading scoreand system recall increases to−0.440-0.440. For these users, we can define overreliance as the reliance level that leads to an undesirable level of system recall of below0.330.33, setting a threshold for overreliance asoffloading score=0.33=0.33as shown inFigure˜6. Excluding the outlier clusters, points with higheroffloading scoregenerally fall below the0.330.33of system recall, correctly identified to be overreliance. This predictive power allows us to set an operational threshold of overreliance for new interactions where the outcome of system understanding is not yet measured or observed.

Analyzing the outlier cluster with highoffloading scoreand high system recall.

Figure 6:System recall (yy-axis) vs.offloading score(xx-axis) across participants. The red line shows a linear fit after excluding the moderate-to-high reliance, high-recall cluster in green, illustrating the stronger negative association betweenoffloading scoreand system recall among the remaining users. The highlighted cluster suggests effective use of the tool while maintaining understanding (Section˜5.1).Figure˜6indicates a cluster of points (green region) deviating from the linear fit, exhibiting high reliance and high recall. In their post-completion survey,55(out of1111) of them reported using the tool for coding features that they did not know how to implement by themselves. In a follow-up interview, one of these users noted “not wanting to limit themselves to one line of thinking” and hence involving the model in a back-and-forth planning loop. This distinct pattern suggests that the normative standard of appropriate reliance should be set differently for these users: when the tool is used forlearning, high reliance is often still appropriate for desirable outcomes. Our experiment does not provide enough data to identify the threshold for inappropriate reliance in this condition: the highestoffloading scorein this cluster is0.650.65, and the user still maintained a good enough understanding.

6Conclusion

In this work, we introduce a process-oriented measure of reliance consisting of a scalar metric,offloading score, that quantifies the fraction of cognitive effort offloaded to AI tools using human counterfactual workflows, combined with more interpretable dimensions categorizing observed AI tool usage. Importantly,offloading scorecan be computed directly from interaction traces without requiring reference outputs, making it easily reusable across different tools and interfaces. Through a controlled user study, we show thatoffloading scorecaptures variation in reliance aligned with known behavioral drivers, outperforming existing usage-based and self-reported measures. We further demonstrate that combining reliance with code understanding reveals distinct patterns of user behavior, showing the value in interpreting reliance in the context of task outcomes. We discuss limitations of our method inAppendix˜A. Looking forward, as user modeling improves(Shaikhet al.,2026),offloading scorecan be adapted to provide personalized estimates of reliance that account for individual differences in tool usage in the estimated counterfactuals, allowing users to reflect on their own behavior.Offloading Scorecan also serve as a signal for training agents that actively mitigate overreliance by encouraging more balanced interaction patterns.

Acknowledgments

We are thankful to Joachim Baumann, Hao Zhu, Ryan Louie, Omar Shaikh, Sunny Yu, Dora Zhao, Chenglei Si, Nishant Balepur, Nitish Joshi, Helena Vasconcelos, Judy Shen, and other members of the Stanford SALT Lab for their valuable feedback at various stages of the project. We thank the participants for the user study recruited from Upwork. This work was supported by an HAI grant, DSO lab, Open Philanthropy, Schmidt Sciences, a grant under the NSF CAREER IIS-2247357, ONR N00014-23-1-2420, and ONR N00014-24-1-2532.

References

• Does the whole exceed its parts? the effect of ai explanations on complementary team performance.InProceedings of the 2021 CHI Conference on Human Factors in Computing Systems,CHI ’21,New York, NY, USA.External Links:ISBN 9781450380966,Link,DocumentCited by:§2.
• J. Baumann, V. Padmakumar, X. Li, J. Yang, D. Yang, and S. Koyejo (2026)SWE-chat: coding agent interactions from real users in the wild.arXiv preprint arXiv:2604.20779.Cited by:§F.3.
• J. Becker, N. Rush, E. Barnes, and D. Rein (2025)Measuring the impact of early-2025 ai on experienced open-source developer productivity.Note:https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/Cited by:§2.
• B. S. Bloom, M. D. Engelhart, E. J. Furst, W. H. Hill, D. R. Krathwohl,et al.(1956)Taxonomy of educational objectives: the classification of educational goals. handbook 1: cognitive domain.Longman New York.Cited by:§1,§3.2.
• E. Brynjolfsson, D. Li, and L. Raymond (2025)Generative ai at work.The Quarterly Journal of Economics140(2),pp. 889–942.Cited by:§1.
• Z. Buçinca, M. B. Malaya, and K. Z. Gajos (2021)To trust or to think: cognitive forcing functions can reduce overreliance on ai in ai-assisted decision-making.Proceedings of the ACM on Human-computer Interaction5(CSCW1),pp. 1–21.Cited by:§2,§2.
• D. T. Campbell and D. W. Fiske (1959)Convergent and discriminant validation by the multitrait-multimethod matrix..Psychological bulletin56(2),pp. 81.Cited by:Appendix D,§3.3.
• V. Chen, A. Talwalkar, R. Brennan, and G. Neubig (2025)Code with me or for me? how increasing ai automation transforms developer workflows.External Links:2507.08149,LinkCited by:§2.
• L. Flower and J. R. Hayes (1981)A cognitive process theory of writing.College Composition & Communication32(4),pp. 365–387.Cited by:§1,§3.2.
• N. Haduong and N. A. Smith (2024)How performance pressure influences ai-assisted decision making.arXiv preprint arXiv:2410.16560.Cited by:§1,§4.1.
• S. G. Hart and L. E. Staveland (1988)Development of nasa-tlx (task load index): results of empirical and theoretical research.InAdvances in psychology,Vol.52,pp. 139–183.Cited by:§2.
• A. J. Hua, P. J. Hancock, and D. J. Carragher (2025)Time pressure increases automation reliance in a face matching task.Quarterly Journal of Experimental Psychology,pp. 17470218251389943.Cited by:§4.1.
• L. Ibrahim, K. M. Collins, S. S. Kim, A. Reuel, M. Lamparth, K. Feng, L. Ahmad, P. Soni, A. E. Kattan, M. Stein,et al.(2025)Measuring and mitigating overreliance is necessary for building human-compatible ai.arXiv preprint arXiv:2509.08010.Cited by:§1.
• M. Jung and M. Seiter (2021)Towards a better understanding on mitigating algorithm aversion in forecasting: an experimental study.Journal of Management Control32(4),pp. 495–516.Cited by:§4.1.
• S. C. Kohn, E. J. De Visser, E. Wiese, Y. Lee, and T. H. Shaw (2021)Measurement of trust in automation: a narrative review and reference guide.Frontiers in psychology12,pp. 604977.Cited by:§1.
• E. Lim, N. Taksande, and C. Seaman (2012)A balancing act: what software practitioners have to say about technical debt.IEEE Software29(6),pp. 22–27.External Links:DocumentCited by:§5.
• C. Liu, Q. Zhou, X. Shen, X. B. Liu, T. Wu, and X. Chen (2026)Behavioral indicators of overreliance during interaction with conversational language models.arXiv preprint arXiv:2602.11567.Cited by:§1.
• J. M. Logg, J. A. Minson, and D. A. Moore (2019)Algorithm appreciation: people prefer algorithmic to human judgment.Organizational Behavior and Human Decision Processes151,pp. 90–103.External Links:ISSN 0749-5978,Document,LinkCited by:§2.
• A. Martini and J. Bosch (2015)The danger of architectural technical debt: contagious debt and vicious circles.In2015 12th Working IEEE/IFIP Conference on Software Architecture,Vol.,pp. 1–10.External Links:DocumentCited by:§5.
• M. Massenkoff and P. McCrory (2026)External Links:LinkCited by:§2.
• S. M. Merritt, H. Heimbaugh, J. LaChapell, and D. Lee (2013)I trust it, but i don’t know why: effects of implicit attitudes toward automation on trust in an automated system.Human factors55(3),pp. 520–534.Cited by:§F.4.
• S. M. Merritt, A. Ako-Brew, W. J. Bryant, A. Staley, M. McKenna, A. Leone, and L. Shirase (2019)Automation-induced complacency potential: development and validation of a new scale.Frontiers in PsychologyVolume 10 - 2019.External Links:Link,Document,ISSN 1664-1078Cited by:§2.
• J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein (2023)Generative agents: interactive simulacra of human behavior.InProceedings of the 36th Annual ACM Symposium on User Interface Software and Technology,UIST ’23,New York, NY, USA.External Links:ISBN 9798400701320,Link,DocumentCited by:footnote 7.
• J. S. Park, C. Q. Zou, A. Shaw, B. M. Hill, C. Cai, M. R. Morris, R. Willer, P. Liang, and M. S. Bernstein (2024)Generative agent simulations of 1,000 people.arXiv preprint arXiv:2411.10109.Cited by:footnote 7.
• S. Passi and M. Vorvoreanu (2022)Overreliance on ai literature review.Microsoft Research339,pp. 340.Cited by:§2.
• G. Pitts, N. Rani, W. Mildort, and E. Cook (2025)Students’ reliance on ai in higher education: identifying contributing factors.InInternational Conference on Human-Computer Interaction,pp. 86–97.Cited by:§2.
• S. Rice, D. Keller, G. Hunt, and D. Trafimow (2009)Automation dependency under time pressure.In2009 International Symposium on Aviation Psychology,pp. 611.Cited by:§1,§4.1.
• E. Rosbach, J. Ganz, J. Ammeling, A. Riener, and M. Aubreville (2025)Automation bias in ai-assisted medical decision-making under time pressure in computational pathology.InBVM Workshop,pp. 129–134.Cited by:§4.1.
• M. J. Ryan, Y. Zhang, A. Salunkhe, Y. Chu, D. Xu, and D. Yang (2025)AutoMetrics: approximate human judgements with automatically generated evaluators.arXiv preprint arXiv:2512.17267.Cited by:Appendix D,§3.3.
• O. Shaikh, K. Gligorić, A. Khetan, M. Gerstgrasser, D. Yang, and D. Jurafsky (2024)Grounding gaps in language model generations.InProceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers),K. Duh, H. Gomez, and S. Bethard (Eds.),Mexico City, Mexico,pp. 6279–6296.External Links:Link,DocumentCited by:§F.6.
• O. Shaikh, S. Sapkota, S. Rizvi, E. Horvitz, J. S. Park, D. Yang, and M. S. Bernstein (2025)Creating general user models from computer use.InProceedings of the 38th Annual ACM Symposium on User Interface Software and Technology,pp. 1–23.Cited by:footnote 2,footnote 7.
• O. Shaikh, V. Teutschbein, K. Gandhi, Y. Chi, N. Haber, T. Robinson, N. Ram, B. Reeves, S. Yang, M. S. Bernstein,et al.(2026)Learning next action predictors from human-computer interaction.arXiv preprint arXiv:2603.05923.Cited by:§6,footnote 7.
• M. Sharma, M. McCain, R. Douglas, and D. Duvenaud (2026)Who’s in charge? disempowerment patterns in real-world llm usage.arXiv preprint arXiv:2601.19062.Cited by:§2.
• S. D. Shaw and G. Nave (2026)Thinking-fast, slow, and artificial: how ai is reshaping human reasoning and the rise of cognitive surrender.Available at SSRN 6097646.Cited by:§2.
• J. H. Shen and A. Tamkin (2026)How ai impacts skill formation.arXiv preprint arXiv:2601.20245.Cited by:§1,§2.
• P. Shukla, P. Bui, S. S. Levy, M. Kowalski, A. Baigelenov, and P. Parsons (2025)De-skilling, cognitive offloading, and misplaced responsibilities: potential ironies of ai-assisted design.InProceedings of the Extended Abstracts of the CHI Conference on Human Factors in Computing Systems,pp. 1–7.Cited by:§1,§2.
• W. W.A. Sleegers, J. W.B. Elsey, and D. Moss (2025)Adoption and uses of llms among u.s. tech workers.Technical ReportRethink Priorities.Note:Survey of 1,963 U.S. tech workers on LLM usage and productivity impactsExternal Links:LinkCited by:§1.
• S. Swaroop, Z. Buçinca, K. Z. Gajos, and F. Doshi-Velez (2024)Accuracy-time tradeoffs in ai-assisted decision making under time pressure.InProceedings of the 29th International Conference on Intelligent User Interfaces,pp. 138–154.Cited by:§1,§4.1.
• H. Vasconcelos, M. Jörke, M. Grunde-McLaughlin, T. Gerstenberg, M. S. Bernstein, and R. Krishna (2023)Explanations can reduce overreliance on ai systems during decision-making.Proceedings of the ACM on Human-Computer Interaction7(CSCW1),pp. 1–38.Cited by:§1,§2.
• Z. Z. Wang, Y. Shao, O. Shaikh, D. Fried, G. Neubig, and D. Yang (2025)How do ai agents do human work? comparing ai and human workflows across diverse occupations.arXiv preprint arXiv:2510.22780.Cited by:Appendix B,Appendix D,§D.1,Figure 3,Figure 3,§3.1,§3.3,§4.2.
• S. Wu, M. Galley, B. Peng, H. Cheng, G. Li, Y. Dou, W. Cai, J. Zou, J. Leskovec, and J. Gao (2025)CollabLLM: from passive responders to active collaborators.InForty-second International Conference on Machine Learning,External Links:LinkCited by:§3.2.
• F. Xu, P. K. Medappa, M. M. Tunc, M. Vroegindeweij, and J. C. Fransoo (2026)AI-assisted programming decreases the productivity of experienced developers by increasing the technical debt and maintenance burden.External Links:2510.10165,LinkCited by:§2.
• M. Yin, J. Wortman Vaughan, and H. Wallach (2019)Understanding the effect of accuracy on trust in machine learning models.InProceedings of the 2019 CHI Conference on Human Factors in Computing Systems,CHI ’19,New York, NY, USA,pp. 1–12.External Links:ISBN 9781450359702,Link,DocumentCited by:§2.
• H. Yizhou Tian, H. Amin, and M. Yin (2026)Understanding the effects of ai-assisted critical thinking on human-ai decision making.InProceedings of the 2026 CHI Conference on Human Factors in Computing Systems,pp. 1–30.Cited by:§2.
• D. Zakay (1993)The impact of time perception processes on decision making under time stress.InTime pressure and stress in human judgment and decision making,pp. 59–72.Cited by:§1,§4.1.
• N. Zazworka, R. O. Spínola, A. Vetro’, F. Shull, and C. Seaman (2013)A case study on effectively identifying technical debt.InProceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering,EASE ’13,New York, NY, USA,pp. 42–47.External Links:ISBN 9781450318488,Link,DocumentCited by:§5.
• J. Zhi, H. Kumar, and M. Lee (2026)Investigating the effects of llm use on critical thinking under time constraints: access timing and time availability.arXiv preprint arXiv:2603.08849.Cited by:§1,§2.
• K. Zhou, J. D. Hwang, X. Ren, N. Dziri, D. Jurafsky, and M. Sap (2025)Rel-ai: an interaction-centered approach to measuring human-lm reliance.InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers),pp. 11148–11167.Cited by:§2.

Appendix ALimitations

We note several limitations of our work. First, we validateoffloading scoreagainst a single reference variable, time pressure, which, while grounded in prior literature, remains only one dimension of variation in reliance. Future work should evaluate the metric against a broader set of behavioral drivers and task settings. We note that our user study is limited to4040participants on programming tasks, and, while we do perform significance testing, may not generalize to other domains or populations. The computation ofoffloading scoredepends on estimating human counterfactual workflows which may not always reflect realistic or optimal ways to achieve the same goal. Errors in this estimation directly affect the metric. The workflow induction from interaction traces is itself imperfect because the granularity of inferred steps may vary, and some steps may be misidentified or omitted which affects the results. More broadly, our formulation assumes that cognitive effort can be approximated through workflow steps, which may not capture all aspects that are not externally observable. We do note that as the research community invests more into workflow induction, user modeling and simulation, we expect the computation ofoffloading scoreto correspondingly improve as well. We also note a limitation that our formulation ofoffloading scoredoes not considerpersonalizedcounterfactual steps, instead opting for a general user counterfactual. We select this to ensure our measure is reusable and due to higher noise on estimating personalized workflows from limited interaction history. We acknowledge the large variance in user skill level and habits might mean that the general counterfactual is not equally applicable. An important line of future work is adaptingoffloading scoreto personalized workflow induction.

Appendix BWorkflow Induction Process

We broadly follow workflow induction as detailed inWanget al.[2025]. The input to the induction pipeline is the recording obtained from a participant session, including timestamped UI actions (clicks, key presses) and periodic screenshots. These raw traces are converted into a chronological action trajectory. First, these are segmented into contiguous work units using visual change between screenshots with mean squared error. These segments are then annotated with short natural-language descriptions of the visible activity using a VLM. The annotated segments are passed to an LLM, which groups consecutive segments into higher-level workflow activities. The final outputs are an induced natural language workflow and the merged activity segments, a time-aligned activity timeline with gaps/pauses inserted.

We note a few hyperparameters from the process. The first is the threshold of similarity between screenshots for grouping. We set the MSE threshold to500500, lower than the default, to ensure that no activities were lost. This resulted in a fewemptyworkflow steps, examples include “No meaningful action visible”, and “Idle or non-captured actions with no significant changes”. We manually filtered these out through a series of rule-based approaches prior to analysis. The second is the model used for induction. We usegpt-5.1for workflow induction accessed via the API, providing screenshots as images when needed. The prompts for the workflow induction remain the same as the released toolkit. We note that advances in the workflow induction pipeline should transfer to more reliable measurement foroffloading score. We share the code for our analysis atthis linked repository.

Figure 7:Average number of steps in each workflow, divided into AI-assisted and human-only steps. We observe slightly longer trajectories in thelongcondition, with slightly higher human-only steps inlongwith similar AI-assisted steps leading to slightly lower proportion of AI-assisted steps.### B.1Summary statistics of workflows

We report summary statistics of the collected workflows inFigure˜7. The total number of steps in workflows from thelongcondition is slightly longer on average thanshort(176176long vs150150short,p>0.05p>0.05on a two-sided Welch test), with increases in human-only steps (157157long vs132132short) and almost identical AI-assisted steps (1818long vs1717short), indicating more extended human involvement in the trajectories (Figure˜7). As a result, the relative proportion of AI-assisted steps is higher for the short condition (9.68%9.68\%long vs16.40%16.40\%short,p=0.03p=0.03on a two-sided Welch test).

B.2Primary tool in each workflow

Figure 8:Primary tool used in each workflow, calculated by mentions in the induction process.Given the sequence of workflow steps in natural language, we estimate the tools used in each with a simple keyword-based search. We provide the list of keywords used to map to each different tool at the end of this section. We count the frequency of each tool mentioned in each workflow, and plot the fraction of workflows in which each tool is mentioned inFigure˜9. Note that these do not sum up to100%100\%as users can use multiple tools in the same workflow. InFigure˜8, we instead report the ‘primary’ tool used in each workflow or the tool with the most mentions.

Figure 9:Fraction of workflows in which there is a keyword mention associated with different AI-coding tools.``` assistant_keywords = { “ChatGPT”: [ “chatgpt”, “gpt-4”, “gpt4”, “gpt 4”, “gpt-4o”, “gpt 4o”, “gpt-3.5”, “gpt 3.5”, “openai”, “o1”, “o3”, “codex” ], “GitHub Copilot”: [ “github copilot”, “copilot” ], “Claude”: [ “claude”, “anthropic”, “claude sonnet”, “claude opus”, “claude haiku” ], “Gemini”: [ “gemini”, “bard”, “google ai studio” ], “Cursor”: [ “cursor” ], “Codeium / Windsurf”: [ “codeium”, “windsurf” ], “Tabnine”: [ “tabnine” ], “Replit Ghostwriter”: [ “replit ghostwriter”, “ghostwriter”, “replit ai” ], “Perplexity”: [ “perplexity” ], }

### B\.3Example Workflow

Here we provide an example output of workflow induction for illustrative purposes\.

• (reading generation) Send prompt and review AI’s step-by-step UI/UX improvement plan and to-do list.
• (writing code) Modify CSS styles while following AI’s implementation order for visual improvements.

…

• (reading generation) Scroll AI chat to review “Step 1: Visual foundation” and HTML restructure.; Click “Review” to inspect proposed HTML/CSS changes for index.html.
• (test manually checking) Start timer and check localStorage in DevTools Application tab. [598-598] (reading code) Review CSS rules in index.html by clicking editor area.

…

• (reading generation) Review AI “Modern minimal CSS design” guidance while editing CSS.
• (writing prompt) Send prompt asking AI to refactor layout for improved alignment and spacing.
• (test manually checking) Start timer and observe automatic state change from Break to Work.
• (writing code) Review CSS layout changes in VS Code and then visually check in browser.
• (reading generation) Click “Review” in AI pane to inspect/apply layout modifications.

## Appendix CImplementation Details For[Section˜3](https://arxiv.org/html/2605.29392#S3)

### C\.1Rubric for tasks offloaded to AI

ANNOTATION_PROMPT = dedent( “”“ You are an expert cognitive analyst. You will analyze a sequence of actions taken by two agents in a collaborative coding setting.

Your task is to classify one target action into a cognitive process category using the theoretical framework below.

INPUT FORMAT

You are provided with:

Previous Action: Current Action: Next Action:

Broader Workflow Context:

• Previous Workflow Step: <workflow step before the matched step, if any>
• Matched Workflow Step:
• Next Workflow Step: <workflow step after the matched step, if any>

You must classify the current_action based on its function, using both the local action context and workflow context.

OUTPUT FORMAT

Return a single JSON object with the following keys:

{ “process_type”: “planning | execution | feedback | control”, “justification”: “<brief reasoning for the process type, referencing the surrounding action or workflow context when relevant>” }

THEORETICAL FRAMEWORK

This scheme adapts the Flower & Hayes (1981) Cognitive Process Model for programming workflows. Cognitive processes are recursive and context-dependent — planning, executing, and evaluating occur repeatedly throughout a coding session.

1. Process Categories

PLANNING Formulating or revising goals, structuring code, or selecting solution strategies. → Examples: outlining function design, deciding on data structures, sketching pseudocode, reading task description before coding.

EXECUTION Translating plans into concrete code or commands. → Examples: typing new functions, editing syntax, refactoring code, implementing logic, running code snippets.

FEEDBACK / MONITORING Evaluating outputs, debugging, interpreting logs or test results, comparing alternatives. → Examples: reading error messages, analyzing stack traces, inspecting model output, consulting docs to validate reasoning.

CONTROL / COORDINATION Meta-level actions that regulate task flow or transitions between phases. → Examples: pausing to reprioritize subtasks, switching from exploration to implementation, deferring a fix, or prompting the model for clarification.

DECISION RULES

1. Use previous and next action context to interpret what cognitive function the current action serves.
2. Use the workflow context to disambiguate broad or underspecified actions.
3. Label actions by the function they perform, not by vague intention.
   • E.g., suggesting code = planning, executing code = execution, showing errors = feedback.

Previous Action: {previous_step_text} Current Action: {current_step_text} Next Action: {next_step_text} Previous Workflow Step: {previous_workflow_step} Matched Workflow Step: {matched_workflow_step} Next Workflow Step: {next_workflow_step} “”“ )

### C\.2Rubric for engaging with AI output

OUTPUT_USE_NEXT_STEPS_PROMPT = dedent( “”“ You are an expert analyst studying how users integrate AI-generated content into their workflow.

Your task is to classify how the AI-assisted step at a specific moment is used in the subsequent workflow.

================================================== INPUT DESCRIPTION

You will receive the following inputs:

TASK_DESCRIPTION

• The overall task the user is trying to accomplish.
• This provides global context for understanding how the AI-assisted step might contribute.

PREVIOUS_HUMAN_STEP

• The nearest preceding human-authored step before the AI-assisted step being analyzed.
• This approximates what the user was doing or asking for around this moment.

CURRENT_AI_ASSISTED_STEP

• The current AI-assisted step being analyzed.
• This is the content whose downstream use you must evaluate.

WORKFLOW_CONTEXT

• The matched workflow step for the AI-assisted step, plus one workflow step before and one after.
• This is only secondary context and may be imperfect.
• Use it only as light background framing, not as primary evidence.

NEXT_STEPS

• A sequence of subsequent actions (from the user and/or tool) that occur after the AI output.
• These steps provide the primary behavioral evidence of how (or whether) the AI output was used.

Your classification must be based ONLY on observable evidence in NEXT_STEPS, while using TASK_DESCRIPTION and WORKFLOW_CONTEXT as contextual framing. If NEXT_STEPS and WORKFLOW_CONTEXT seem to point in different directions, trust NEXT_STEPS.

================================================== INPUT

TASK_DESCRIPTION: <<< {task_description}

PREVIOUS_HUMAN_STEP: <<< {previous_human_step}

CURRENT_AI_ASSISTED_STEP: <<< {current_ai_assisted_step}

WORKFLOW_CONTEXT: <<< Previous Workflow Step: {previous_workflow_step} Matched Workflow Step: {matched_workflow_step} Next Workflow Step: {next_workflow_step}

NEXT_STEPS: <<< {next_steps_sequence}

==================================================

Your goal is to determine how the CURRENT_AI_ASSISTED_STEP is integrated into the workflow based on evidence in NEXT_STEPS.

CLASSIFICATION LABELS

Choose exactly ONE label.

• Reuse The user directly reuses the AI-assisted content with minimal or trivial changes. Examples:

• copying or pasting AI-generated text, code, or commands

• executing a command clearly provided by the AI

• accepting or applying an AI suggestion with only minor visible modification

• incorporating AI-generated wording or code into docs/files with little transformation

• Apply The user takes an idea, method, structure, or recommendation from the AI-assisted content and adapts it to their own context in a visible way. Examples:

• making a concrete edit, configuration change, test, or revision that clearly follows the AI’s recommendation

• reimplementing an AI-suggested idea in a different form

• using AI recommendations as a basis for edits, tests, prompts, or plan changes that are clearly connected to that specific guidance but not direct copy-paste

• following the AI’s suggested approach, but with noticeable adaptation rather than direct reuse

• Pushback The user tests, questions, challenges, corrects, or follows up on the AI-assisted content because it appears insufficient, problematic, incomplete, or still unresolved. Examples:

• identifying that the AI suggestion is wrong, incomplete, mismatched, or does not fully solve the problem

• asking follow-up questions, debugging, or testing because the AI output appears flawed or insufficient

• revising direction or seeking correction because the AI content was evaluated and found wanting

• Reject There is no clear observable evidence that the AI-assisted content was meaningfully used in subsequent steps. Examples:

• later steps are unrelated or only loosely related

• the user continues the task, but there is no visible trace that this specific AI-assisted step influenced those actions

• the connection is only thematic or speculative

DECISION GUIDANCE

Use a balanced standard:

• Do not require perfect proof for Apply. But Apply should only be used when NEXT_STEPS show a concrete downstream action that is specifically responsive to the AI-assisted content.
• Do not assign Reuse unless the connection is fairly direct.
• Prefer Reuse over Apply when the later steps show direct uptake of the AI content with little transformation, even if the user also verifies or lightly adjusts it afterward.
• Do not assign Reject merely because the later steps are not copy-paste explicit.
• Prefer Reject over Apply when the later steps are only generic continuation of the same task, such as browsing nearby files, generic testing, or continuing implementation without a clear visible trace of this specific AI-assisted step.
• Prefer Apply over Reject only when there is a specific visible connection between the AI-assisted content and what the user does next, such as implementing the recommended change, testing the suggested fix, or revising a file or plan in a way that clearly matches the guidance.
• Prefer Pushback when the user visibly responds to the AI output by probing, challenging, debugging, or seeking correction because the output seems wrong, incomplete, mismatched, or unresolved.
• Do not use Pushback for ordinary implementation or generic verification. Use it only when the later behavior indicates friction with the AI output itself.
• Prefer Reject when the relationship is only thematic, vague, or speculative.
• Prefer NEXT_STEPS over WORKFLOW_CONTEXT if they conflict.
• Similar topic alone is not enough; there should be some visible downstream trace.

IMPORTANT RULES

1. Base your decision ONLY on observable evidence in NEXT_STEPS.
2. Do NOT infer hidden learning unless behaviorally reflected.
3. Do NOT use a staged or linear interpretation. Choose the single best-fitting label from the set above.
4. WORKFLOW_CONTEXT is secondary and may be imperfect.
5. Running tests, editing files, reading docs, or continuing the task support Apply only when they clearly instantiate or verify the AI’s specific recommendation, not when they are merely generic continuation.
6. Return exactly one classification.

OUTPUT FORMAT

Return a JSON object in this exact format:

{ “label”: “<Reuse | Apply | Pushback | Reject>”, “justification”: “” }

Return ONLY the JSON object. No additional commentary. “”“ )

### C\.3Rubric for creating human\-only counterfactual

You are rewriting a single step in a human-AI collaborative coding action with a realistic user-only steps. Essentially, you are estimating how a human would have accomplished the same step without any AI assistance, while matching the granularity of surrounding user actions. You can introduce any additional tools the user might have used to accomplish the task in the absence of AI. Your goal is to replace the single human-AI step with an appropriate number of user-only steps that accomplish the same code changes or actions.

GOAL: Replace all AI actions that occur in the current TOOL turn with an appropriate number of USER ONLY turns that:

• Accomplish the same code changes or actions performed that the human-AI step did
• Match the granularity of surrounding workflow steps
• Are realistic human workflow actions
• Do NOT include any AI actions or references to AI assistance
• Introduce any additional tools they might have used to accomplish the task in the absence of AI
• Are NOT too small (no single keystrokes)
• Are NOT too large (no “wrote entire file”)

CONTEXT — PREVIOUS TURNS: {context_block}

TOOL TURN TO REWRITE: {tool_block}

NEXT TURN (for alignment): {next_block}

OUTPUT FORMAT:

• Return ONLY the reconstructed steps, a list of strings which are the steps that would replace the single human-AI step if the user did not have access to any AI tools.
• Do NOT include explanations.
• Do NOT include markdown. “”“

## Appendix DMetric Validity\.

##### Criterion Validity

Criterion validity measures the extent to which the proposed metric aligns with an external reference standard\. In the absence of a single gold standard, we establish criterion validity for*offloading score*using the variation across experimental conditions in our user study \([Section˜4](https://arxiv.org/html/2605.29392#S4)\), where prior work predicts higher reliance under time pressure\.

##### Content Validity

Content validity assesses whether a metric captures the construct it is intended to measure\. For constructs that are difficult to quantify directly, we follow prior work on automatic metric design\[Ryanet al\.,[2025](https://arxiv.org/html/2605.29392#bib.bib27)\]by providing transparency into the metric computation and supporting evidence about the different components of our measurement\.*offloading score*naturally affords transparency as the score is computed via a simple fraction of observed and counterfactual workflow steps\. Users can inspect their workflow and the mapping of each AI\-assisted step to corresponding human\-only counterfactual steps to check whether the measurement reflects their behavior\. In our user study, we validate the plausibility of these counterfactuals through participant responses \([Section˜4\.5](https://arxiv.org/html/2605.29392#S4.SS5)\)\. We further support this by showing that the generated counterfactuals align with human workflows on the same tasks with significance at the5%5\\%level on a permutation test using a dataset of human and agent workflows fromWanget al\.\[[2025](https://arxiv.org/html/2605.29392#bib.bib1)\]\. We also verify the LLM\-as\-judge annotations of descriptive dimensions with human judgments \([Section˜D\.4](https://arxiv.org/html/2605.29392#A4.SS4)\)\.

##### Construct Validity

Construct validity asks whether a metric behaves consistently with the underlying construct it is intended to measure\. FollowingCampbell and Fiske \[[1959](https://arxiv.org/html/2605.29392#bib.bib28)\], we operationalize construct validity as robustness, evaluated through sensitivity and stability\. Sensitivity tests whether a metric assigns systematically lower \(or higher\) scores when examples are perturbed in a manner meant to degrade \(or improve\) the underlying construct\. Stability checks that when perturbations are made which are not intended to affect the construct, the scores assigned remain consistent\. In[Section˜D\.3](https://arxiv.org/html/2605.29392#A4.SS3), we verify that*offloading score*exhibits \(a\) sensitivity by showing that manually editing workflows to remove AI\-assisted steps reduces metric scores \([Figure˜13](https://arxiv.org/html/2605.29392#A4.F13)\); and \(b\) stability by showing that metric scores remain consistent to perturbations where the human counterfactual is generated in ways where we do not expect the reliance to change \(e\.g\., different*reasoning effort*, different underlying model, paraphrasing steps\) \([Figure˜12](https://arxiv.org/html/2605.29392#A4.F12)\)\.

### D\.1Validation of human\-only counterfactual on prior dataset

##### Dataset and our usage

To provide a data\-driven validation of the procedure for creating human\-only counterfactual workflows \([Section˜3\.2](https://arxiv.org/html/2605.29392#S3.SS2)\), we use the dataset collected as part ofWanget al\.\[[2025](https://arxiv.org/html/2605.29392#bib.bib1)\]that contains recorded workflows for four short\-horizon software engineering tasks\. These short\-horizon tasks are useful for our setting because they resemble the kinds of steps that users offload to tools within longer coding workflows, including those in our user study\. For each task, the dataset includes multiple human workflow traces, as well as AI\-agent trajectories\. In this validation, we use only the task instructions, or the request to the tools, and our prompting procedure from[Section˜3\.2](https://arxiv.org/html/2605.29392#S3.SS2)to generate synthetic human\-only counterfactual workflows, and we compare these against the recorded human workflows for the same tasks\. For each task, we create55synthetic counterfactual workflows\. We then embed each of these human and counterfactual workflows using a SentenceTransformer model \(sentence\-transformers/all\-MiniLM\-L6\-v2\)\. We hypothesize that workflows from the same task should cluster together, so for each synthetic workflow, we compute a statistic equal to its average similarity to human workflows from the same task minus the average similarity to human workflows from the other tasks\.

##### Significance testing for median in\-cluster similarity

We first perform a one\-sided Wilcoxon signed\-rank test on these per\-workflow statistics against the null hypothesis that their median is not greater than zero\. We find strong evidence that the statistics are positive \(p≈1​e−6p\\approx 1e^\{\-6\}\), indicating that synthetic workflows are substantially more similar to human workflows from the same task than to those from other tasks\.

##### Permutation test for cluster assignment

We also perform a one\-sided permutation test on the same statistic\. For each synthetic workflow, we first compute the difference between its average similarity to human workflows from the same task and its average similarity to human workflows from other tasks\. We then take the mean of these differences across all synthetic workflows\. To form a null distribution, we repeatedly flip the sign of each workflow\-level difference at random and recompute the mean, using10,00010\{,\}000random sign assignments\. This null distribution represents the values of the test statistic that would be expected if counterfactual workflows were no more similar to human workflows from the same task than to those from other tasks\. The p\-value is the fraction of permuted means that are at least as large as the observed statistic\. This test also yields a highly significant result \(p<10−4p<10^\{\-4\}\)\.

##### Takeaway\.

These results show that the synthetic counterfactual workflows are semantically closer to the corresponding human workflows than to workflows from other tasks\. While this does not establish that the synthetic workflows are exact reconstructions of true human\-only behavior, it provides evidence that our procedure produces reasonable task\-aligned approximations\. We also verify our approximations with participants in our user study in[Section˜4\.5](https://arxiv.org/html/2605.29392#S4.SS5)\.

##### Visualization of clusters in 2D\.

We also visualize the human and synthetic workflows in two dimensions using t\-SNE applied to the workflow embeddings \([Figure˜10](https://arxiv.org/html/2605.29392#A4.F10)\)\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/cluster_visualization_synthetic_original_workflows.png)Figure 10:t\-SNE visualization of workflow embeddings for recorded human workflows and synthetic counterfactual workflows across the four software engineering tasks \([Section˜D\.1](https://arxiv.org/html/2605.29392#A4.SS1)\)\. Colors indicate different tasks, and the marker shape indicates human versus synthetic workflows\.

### D\.2Verifying the quality of human counterfactuals with human annotations

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/likert_ratings_counterfactuals.png)Figure 11:Distribution of Likert\-scale ratings for generated human counterfactual steps, showing that most are perceived as plausible alternatives \([Section˜4\.5](https://arxiv.org/html/2605.29392#S4.SS5)\)\.The computation of*offloading score*relies on estimating human counterfactual workflows \([Section˜3\.3](https://arxiv.org/html/2605.29392#S3.SS3)\)\. We additionally validate the reliability of the counterfactuals with human annotations\. We ask2020randomly sampled users to evaluate55counterfactual steps from*their own*workflows\. For each step, users rate whether the proposed human\-only alternative is a reasonable way to achieve the same sub\-goal on a Likert scale from11\(Strongly Disagree\) to55\(Strongly Agree\)\. From[Figure˜11](https://arxiv.org/html/2605.29392#A4.F11), over60%60\\%of steps receive ratings of44or55, while only15%15\\%are rated in disagreement \(11or22\), indicating that the generated counterfactuals are generally perceived as plausible by participants\.777We note that as the research community increasingly invests in user modeling\[Shaikhet al\.,[2025](https://arxiv.org/html/2605.29392#bib.bib19),[2026](https://arxiv.org/html/2605.29392#bib.bib38)\]and simulation\[Parket al\.,[2023](https://arxiv.org/html/2605.29392#bib.bib39),[2024](https://arxiv.org/html/2605.29392#bib.bib40)\], the computation of*offloading score*will continue to improve\. We discuss this further in[Section6](https://arxiv.org/html/2605.29392#S6)\.

### D\.3Establishing construct validity through sensitivity and stability of*offloading score*

##### Stability

Stability measures the ability of a metric to assign consistent scores under perturbations for which the quantity being measured, here*offloading score*, is not truly affected\.[Figure˜12](https://arxiv.org/html/2605.29392#A4.F12)shows the distribution of scores assigned on55runs where, \(a\) Runs11and22are identical inputs where we re\-run the counterfactual estimation with two different reasoning effort settings with thegpt\-5\.2; \(b\) Run33varies the underlying model togpt\-5\-mini; \(c\) Runs44and55was where we paraphrase a random sample of20%20\\%steps in the workflow withgpt\-5\-minibefore rerunning the*offloading score*calculation withgpt\-5\.2\-mini\. We observe minimal differences across the runs, both in the spread of scores as well as aggregate measures \(mean, median, quartiles\)\. This confirms that the pipeline for calculating*offloading score*is stable\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/stability_multiple_runs_wide.png)Figure 12:Variation in the distribution of*offloading score*scores across55runs described in[Section˜D\.3](https://arxiv.org/html/2605.29392#A4.SS3)\. We find that*offloading score*remains stable under these perturbations\.
##### Sensitivity

Sensitivity measures the ability of a metric to assign lower scores under perturbations that are intended to produce lower reliance\. To obtain targeted perturbations where users are less reliant, we randomly select5%5\\%,10%10\\%, and20%20\\%of AI\-assisted steps from the collected workflows and replace these with the steps where the user did not use the tool, i\.e\., the human counterfactuals\. From[Figure˜13](https://arxiv.org/html/2605.29392#A4.F13), we see that perturbing workflows to reduce AI usage led to a systematic decrease in*offloading score*\. Mean values fell in the5%5\\%,10%10\\%, and20%20\\%replacement conditions by6\.9%6\.9\\%,9\.0%9\.0\\%, and12\.9%12\.9\\%\. These decreases were significant at the5%5\\%level under both pairedtt\-tests and Wilcoxon signed\-rank tests for all three levels, indicating that the metric is sensitive to true reductions in AI usage\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/sensitivity_perturbations_wide.png)Figure 13:Variation in the distribution of*offloading score*values when perturbing5%5\\%,10%10\\%, and20%20\\%of AI\-assisted steps in a manner designed to reduce reliance as described in[Section˜D\.3](https://arxiv.org/html/2605.29392#A4.SS3)\. We find that*offloading score*is sensitive to each of these perturbations with significance, and larger perturbations lead to more decrease in*offloading score*scores\.![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/correlation_baseline_measure.png)Figure 14:Pearson correlation scores between different baseline measures of reliance and*offloading score*\.*offloading score*is strongly correlated with usage\-based baseline measures\.![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/correlation_condition.png)Figure 15:Pearson correlation scores between various measures of reliance and the experimental condition label\.*Offloading Score*correlates most strongly with the label\.![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/correlations_to_system_recall.png)Figure 16:Pearson correlation between different measures of reliance, and task outcome, measured as a binary\{0,1\}\\\{0,1\\\}value based on whether the user’s system recall score is≥0\.33\\geq 0\.33\([Section˜5](https://arxiv.org/html/2605.29392#S5)\)\.

### D\.4Validating LLM\-as\-judge with human annotations

To validate the use of LLM\-as\-judge for labeling workflow steps, we collect human annotations for the cognitive process and output\-use labels introduced in[Section˜3](https://arxiv.org/html/2605.29392#S3)\. We recruit66professional programmers from Upwork as annotators\. Each example is annotated independently by two different annotators\. For each labeling task, we sample100100workflow steps from different users and provide annotators with local context \(the preceding and following three steps\) to support consistent labeling\. We first evaluate inter\-annotator agreement to assess the reliability of the labeling scheme\. For cognitive process labels, we observe78%78\\%agreement with Cohen’sκ=0\.803\\kappa=0\.803\. For output\-use labels, agreement is84%84\\%withκ=0\.854\\kappa=0\.854, indicating substantial agreement for both tasks\. We then evaluate LLM\-as\-judge performance by comparing model predictions against the majority human label\. We consider three models:gpt\-5\-mini,gpt\-5\.2, andgpt\-5\. As shown in[Table˜1](https://arxiv.org/html/2605.29392#A4.T1),gpt\-5\.2achieves the highest agreement with human annotations across both tasks \(80% for cognitive process and 81% for output use\), and we use it for all subsequent analyses\.

TaskCategoriesHuman AgreementCohen’sκ\\kappagpt\-5\-minigpt\-5\.2gpt\-5Cognitive process4478%78\\%0\.8030\.80363%63\\%80%80\\%74%74\\%Output use4484%84\\%0\.8540\.85475%75\\%81%81\\%76%76\\%Table 1:Human inter\-annotator agreement and LLM\-as\-judge accuracy \(against majority human labels\) for cognitive process and output\-use annotations\. Metrics for each task are reported on100100randomly sampled examples, and22human annotators scored each example\.

## Appendix EUser Study Details

### E\.1Participant Recruitment

We recruit U\.S\.\-based participants through the crowdworking platform Upwork\.888[Upwork](https://www.upwork.com/)is an online platform where freelancers sign up to complete various tasks\.When evaluating respondents to the job posting, we filtered for participants who had completed at least three prior coding projects on the platform and were able to list coding tools they regularly use, ensuring familiarity with contemporary AI\-assisted coding tools\. Participants were compensated at a rate of$​20\\mathdollar 20to$​30\\mathdollar 30per hour according to their self\-proposed hourly rate\. In total, we recruited4444participants and randomly assigned them to one of the tasks and to one of the experimental conditions\. We excluded44participants due to anomalous completion behavior \(e\.g\., finishing in under 10 minutes, taking more than 6 hours, or not using any AI tools\), and replaced them to maintain balance\. The final study consisted of44tasks with55participants per condition across22experimental conditions \(4040participants total\)

### E\.2Pre\-Task Survey

##### Overview

We collect information about participants’ prior experience with AI\-assisted coding tools, including which tools they use, their level of access, typical use cases within their workflow, and the extent to which AI contributes to code generation\.

##### Survey Questions

1. 1\.What is your Upwork Username\(required\)
2. 2\.AI coding tools that you have used in the last 30 days\(check all that apply\) - •Github Copilot - •Cursor - •Claude Code - •Codex - •Manus - •CodeWhisperer - •Tabnine - •Autocomplete from your IDE - •Custom or in\-house AI tools - •Other
3. 3\.What tier of access do you use for these services\(select one\) - •Free versions only - •Paid subscription
4. 4\.Typically what do you use AI for in your workflow?\(check all that apply\) - •Writing new modules with AI agents - •Autocomplete / inline suggestions - •Debugging errors - •Explaining unfamiliar code - •Refactoring / cleanup - •Writing tests - •Documentation / comments - •Code review assistance - •Searching APIs / libraries - •Other
5. 5\.Lines of code written by AI in a typical coding project\(select one\) - •\>75%\>75\\% - •Between25%25\\%and75%75\\% - •Less than25%25\\% - •I don’t use AI to write lines of code, only for other things

### E\.3Task Details

Participants complete one of four simple web development tasks designed to capture realistic programming workflows\. The goal of each task is to build a self\-contained local web application while satisfying a list of mandatory requirements provided\. Here we list the four tasks\.

#### E\.3\.1Task 1: Mindful Break Timer

Build a simple local web app that lets users run focused work timers and receive mindful break prompts between sessions\. The goal is a clean, usable timer that encourages healthier breaks without distractions\. You are free to/encouraged to use any AI tools typical to your workflow\.

##### What to build

- •A single\-page web app with: - –A configurable work timer \(e\.g\., 25 minutes by default\) - –A break timer that starts automatically after work ends - –Start / pause / reset controls
- •When a break starts, show one mindful activity suggestion \(e\.g\., stretch, breathe, look away from screen\)
- •Persist completed sessions locally in the browser \(e\.g\., localStorage\)
- •Display a simple session history \(count or list of completed work sessions\)

##### Technical constraints

- •Runs fully locally in the browser \(open index\.html or npm run dev \)
- •Plain JavaScript, or a lightweight framework of choice
- •Use browser timing APIs \( setInterval , setTimeout \)
- •Local persistence only \(e\.g\., localStorage \)

##### Mandatory Requirements

- •User can start a work timer and see it count down correctly
- •When the work timer ends, a break timer begins automatically
- •A mindful activity suggestion is shown at break start
- •Refreshing the page does not erase completed session history
- •The app is usable and testable via localhost or a local HTML file
- •README to set up and run your code

#### E\.3\.2Task 2: Personalized Recipe Explorer

Build a local web app that helps users discover recipes based on ingredients they already have and simple preferences\. The app queries a public recipe API or LLM and presents a small, usable recipe exploration flow\. You are free to/encouraged to use any AI tools typical to your workflow\.

##### What to build

- •A web app with: - –An input for available ingredients \(free text or comma\-separated\) - –Optional filters \(e\.g\., diet type, max cooking time, calories\)
- •Fetch matching recipes from an LLM or public recipe API
- •Display a list of results with: - –Recipe title - –Key metadata \(time, diet tags, calories if available\)
- •Clicking a recipe shows a detail view \(ingredients \+ basic instructions\)
- •Allow users to save favorite recipes locally in the browser

##### Technical constraints

- •Runs locally \(npm run dev or similar\)
- •Frontend\-only UI; API calls may be proxied through a lightweight local server
- •API key provided via environment variable
- •Local persistence via localStorage
- •Responsive layout, but minimal styling is sufficient

#### E\.3\.3Task 3: Digital Vision Board

Build a local web app where users upload images and arrange them freely on a visual board\. The app should support direct manipulation and persistent layout across sessions\. You are free to/encouraged to use any AI tools typical to your workflow\.

##### What to build

- •A board\-style UI where users can: - –Upload images from their computer - –Drag, reposition, and resize images on a canvas or grid
- •Support only image tiles \(uploaded images\)
- •Persist board layout and tiles across refreshes
- •Simple controls to add, move, and delete tiles

##### Technical constraints

- •Runs locally \(npm run dev or similar\)
- •Images stored locally \(e\.g\., FileReader, Blob, or browser storage\)
- •Live data may be mocked or fetched from a single external API
- •Persistence via browser storage \(e\.g\., localStorage, IndexedDB\)

##### Mandatory Requirements

- •User can upload at least one image and see it on the board
- •Images can be dragged and repositioned
- •Board state persists after page refresh
- •At least one non\-image tile shows dynamic \(changing\) data
- •User can remove a tile from the board
- •README to set up and run your code

#### E\.3\.4Task 4: Project Planner

Build a local web app that helps users turn a vague project idea into a concrete plan by breaking it into tasks and visualizing structure over time or hierarchy\. You are free to/encouraged to use any AI tools typical to your workflow\.

##### What to build

- •A web app where users can: - –Enter a project title and short description - –Break the project into tasks and subtasks
- •Visualize tasks in one structured view: - –Either a task tree \(parent / child\), or - –A timeline\-style ordered list
- •Allow users to: - –Add, edit, and delete tasks - –Mark tasks with basic metadata \(e\.g\., status or priority\)
- •Persist the project plan locally in the browser

##### Technical constraints

- •Runs locally \(npm run dev or similar\)
- •Frontend\-only implementation
- •State and plans persisted via browser storage \(e\.g\., localStorage\)
- •Minimal styling is sufficient; clarity over polish

##### Mandatory Requirements

- •User can create a project and add multiple tasks
- •Tasks can be structured \(ordered or hierarchical\)
- •Changes persist after page refresh
- •User can visually understand task breakdown at a glance
- •App supports editing and deleting tasks
- •README to set up and run your code

##### Mandatory Requirements

- •User can enter ingredients and retrieve recipe results
- •Filters affect the returned results correctly
- •At least one recipe detail page is viewable
- •Favorite recipes persist across page refreshes
- •App is usable on a small screen width \(basic mobile friendliness\)
- •README to set up and run your code

### E\.4Post\-Task survey

##### Overview

After completing the programming task, participants filled out a post\-completion survey consisting of \(a\) a system recall component and \(b\) self reported measurements on a Likert\-scale on various dimensions\. We provide questions from the survey here\.

##### System Recall \(Representative Questions\)

The system recall section consists of task\-specific questions about design and engineering choices which are to be answered in the form of free form text\. The full list of questions for each task can be found at[this linked repository](https://github.com/vishakhpk/offloading-score)\. Below we provide22representative examples per task\.

Task 1 \(Mindful Break Timer\)\.

- •How did you represent the timer state internally? Did you use separate states for work vs\. break, or a single timer with mode flags?
- •How did you persist session history locally? Simple counters, timestamped entries, or structured objects in localStorage?

Task 3 \(Digital Vision Board\)\.

- •How did you handle drag\-and\-drop interactions? Native HTML drag events, pointer/mouse listeners, or a library?
- •How did you manage image uploads? Base64 encoding, object URLs, or IndexedDB\-backed storage?

Task 4 \(Project Planner\)\.

- •How did you handle deleting tasks with subtasks? Cascade delete, prevent deletion, or prompt the user?
- •How did you persist project state locally? A single serialized object or multiple keyed entries in storage?

##### Self\-reported Measurements

The remaining questions are shared across all post\-task surveys and capture subjective perceptions of the task and AI usage\.

- •Mental demand:“How mentally demanding was this task?” \(7\-point scale from not demanding to very demanding, based on cognitive load on the NASA\-TLX scale\)
- •Trust in AI:“How much did you trust the output of your AI tools?” \(5\-point scale\)
- •Perceived ownership:“How much does the final project feel like your output vs\. the tool?” \(5\-point scale\)
- •Cognitive contribution:“What percentage of the thinking did you do yourself vs\. the model?” \(5\-point scale\)
- •Reasons for tool use:What factors result in coding tool use, such as lack of knowledge, speed, habit, curiosity about model outputs, or any other reason \(please specify\.

### E\.5System Recall Eval

To evaluate system recall, we compared each participant’s answers from the post\-task survey about their implementation against the contents of their submitted codebase\. For each participant and task, the pipeline evaluates each question individually against the participant’s repository\. First, the repository is segmented into text snippets, and for each question\-answer pair the system retrieved a small set of candidate snippets using lexical matching over both code content and file\-path information\. These retrieved snippets, along with the original question and participant answer, were then passed to agpt\-5\-miniwith a prompt evaluating factual accuracy and completeness relative to the available repository evidence\. The judge assigned one of four labels—incorrect, partially correct, mostly correct, or fully correct along with a short evidence\-based justification in natural language\. We then calculate the average system recall score for each user for the evaluation in[Section˜5](https://arxiv.org/html/2605.29392#S5)\.

##### Prompt for system recall eval\.

You are grading whether a candidate answer about a code repository is supported by the provided repository evidence.

• Use ONLY the provided snippets as evidence.
• Do not speculate beyond the snippets.
• Do not give credit for claims that are plausible but not supported by the evidence.
• Evaluate the answer using both:
  • 1. factual accuracy
  • 2. completeness relative to the question
• Use this 4-level rubric:
  • fully correct: The answer is fully supported by the snippets, materially complete for the question and contains no meaningful false, exaggerated, or unsupported claims.
  • mostly correct: The core answer is supported and most important details are correct, but the answer has minor omissions, slight overstatement, or a small unsupported detail that does not change the main substance.
  • partially correct: The answer is mixed. Some meaningful parts are supported, but important parts are missing, overgeneralized, unsupported, or incorrect.
  • incorrect: The answer is mostly unsupported by the snippets, contradicted by the snippets, or wrong on the main point.
• Decision rules:
  • Use fully correct only when essentially all substantive claims are supported by the snippets.
  • If the main answer is right but there are only minor issues, use mostly correct.
  • If support is genuinely mixed on important points, use partially correct.
  • If the main takeaway is unsupported or contradicted, use incorrect.
  • A minor unsupported detail should usually prevent fully correct, but may still allow mostly correct.
  • If an unsupported or incorrect detail changes the main meaning of the answer, prefer partially correct or incorrect.
  • When in doubt, prefer the lower label unless the evidence clearly supports the higher one. -In your explanation:
  • cite concrete file paths and line numbers from the snippets
  • explicitly identify which parts of the answer are supported
  • explicitly identify which parts are unsupported or contradicted
  • briefly explain why the chosen label fits better than the neighboring labels
• Return ONLY valid JSON with exactly two keys:
  • “answer”
  • “reason”
• The “answer” value must be exactly one of: ’“incorrect”, “partially correct”, “mostly correct”, “fully correct”

### E\.6Code Attribution Evaluation

We estimate the code attributed to the AI tool using a rule\-based pipeline that consumes each participant’s final project codebase with their recorded interaction logs\. The primary inputs are the final source files, the raw action trace, and segmented workflow annotations\. We first exclude non\-informative system artifacts such as lockfiles, dependency trees, and build outputs, from the code base\. Then, we extract interaction evidence from the action trace, including recoverable typed text, paste operations, and higher\-level annotated episodes such as manual editing, prompt writing, and AI\-response review\. Attribution is performed at the file level and then refined at the line level\. Human\-side evidence comes from direct matches between recovered typed fragments and final code, as well as episodes consistent with manual editing\. Tool\-side evidence comes from stronger indicators of externally introduced code, such as paste\-heavy edits, and annotated episodes from workflow induction suggesting AI\-generated changes were applied\. The pipeline outputs line\- and file\-level provenance labels, along with coverage and confidence diagnostics that indicate how much of the codebase could be attributed and how strongly supported those attributions are\. The code for this pipeline is made available at[this linked repository](https://github.com/vishakhpk/offloading-score)\. In addition to strict labels, we also calculate a softened attribution view that captures weaker but directional evidence\. This version includes code that cannot be assigned with high confidence but is more consistent with being from the tool\. Primarily in[Section˜4\.5](https://arxiv.org/html/2605.29392#S4.SS5), we report the stricter version of code attribution\. In[Appendix˜F](https://arxiv.org/html/2605.29392#A6), we confirm that the softened version of code attribution does not change any of the conclusions\.

## Appendix FAdditional Results

### F\.1Split of*offloading score*across experiment conditions by task

[Figure˜17](https://arxiv.org/html/2605.29392#A6.F17)provides the boxplot of*offloading score*values for*long*and*short*from[Section˜4](https://arxiv.org/html/2605.29392#S4)when divided into scores by individual task\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/offloading_by_task.png)Figure 17:*Offloading Score*values for*short*and*long*conditions for each task\.*Offloading Score*assigns lower mean values for each task to varying degrees\.
### F\.2What fraction of the workflow is associated with*process*and*output\-use*interactions?

[Figure˜18](https://arxiv.org/html/2605.29392#A6.F18)is the same interactions as labeled in[Figure˜5](https://arxiv.org/html/2605.29392#S4.F5), but the denominator to calculate the proportion is the total number of workflow steps\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/process-output-use-workflow.png)Figure 18:Fraction of workflow steps associated with*process*and*output\-use*labels across*short*and*long*conditions\. Users in the*short*condition directly execute subtasks with the tool and reuse the model outputs, while users in the*long*condition more frequently reject or adapt outputs, indicating more selective engagement\.
### F\.3Do some tools lead to more reliance than others?

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/reliance_scores_by_tool.png)Figure 19:Variation of*offloading score*values by AI tool\.We plot the*offloading score*scores obtained by users using various tools in[Figure˜19](https://arxiv.org/html/2605.29392#A6.F19)\. In general, we don’t find a clear pattern of a single tool leading to higher or lower reliance\. Most notably, among the most common tools, Claude and ChatGPT, users display a wide range of reliance behavior patterns, indicating that, at this sample size, the human user is the driving factor in the differing reliance patterns, echoing findings fromBaumannet al\.\[[2026](https://arxiv.org/html/2605.29392#bib.bib48)\]\.

### F\.4*Offloading Score*is correlated with first\-person perceptions of cognitive offloading and negatively correlated with perceived ownership\.

From the post\-completion questionnaire, we calculate the Pearson correlation of*offloading score*with various dimensions\. We find that*offloading score*is positively correlated with the perceived distribution of cognitive work between the user and tool \(\+0\.23\+0\.23\) and negatively correlated with perceived ownership of the project \(−0\.37\-0\.37\), providing corroborating evidence for validating the metric\. Contrary to prior work\[Merrittet al\.,[2013](https://arxiv.org/html/2605.29392#bib.bib46)\], we find that trust is only weakly negatively correlated with*offloading score*\(−0\.07\-0\.07\) which may be explained by the observation that users have high trust in coding agents \(3535out of4040participants scored their trust between44and55\) due to their strong capabilities\.

### F\.5Relationship between*process*and*output\-use*labels and counterfactual steps\.

[Figure˜20](https://arxiv.org/html/2605.29392#A6.F20)shows overlap in counterfactual workflow length across*process*labels, with planning slightly higher than execution and feedback, and control associated with shorter counterfactual workflows\.[Figure˜21](https://arxiv.org/html/2605.29392#A6.F21)shows a similar plot across*output\-use*labels—debug\-or\-pushback cases are associated with the longest counterfactual workflows, while directly reuse, adapt\-and\-apply, and reject have similar, lower medians\.

![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/counterfactual_length_by_process.png)Figure 20:Counterfactual workflow length by*process*label\. Planning has a slightly higher median counterfactual length than execution and feedback, while control steps tend to map to shorter counterfactual workflows\.![Refer to caption](https://arxiv.org/html/2605.29392v1/figures/counterfactual_length_by_output_use.png)Figure 21:Counterfactual workflow length by*output\-use*label\. Debug\-or\-pushback cases have the highest median counterfactual length, suggesting that these interactions correspond to more involved workflow segments\.
### F\.6Qualitative Interviews for Interpreting User Behavior

To better understand these behavioral patterns, we conduct follow\-up interviews with two users from each of the three clusters \(six total\) in[Figure˜6](https://arxiv.org/html/2605.29392#S5.F6)\. We first investigate the potentially*overreliant*group, with high reliance and low system recall\.44out of77post\-task survey responses from this group indicated that they knew how to complete the task independently but chose to use the tool out of habit or to complete the task faster\. In follow\-up interviews, when reflecting on incorrect answers, users reported that in some cases they were unaware that features had been included in the implementation\. In other cases, they had requested a “typical” implementation of a feature and did not verify whether this underspecified intention was followed, reflecting an unresolved grounding gap\[Shaikhet al\.,[2024](https://arxiv.org/html/2605.29392#bib.bib47)\]\. The second group of users tends to have moderate\-to\-high reliance and high system recall\. In this group,55users reported using their tool for tasks or features for which they did not know how to implement by themselves\. In a follow\-up interview, one of these users described their process as “not wanting to limit themselves to one line of thinking” and hence involving the model in a back\-and\-forth planning loop\. This form of interaction, using their tool to augment their capabilities, is consistent with more*appropriate*reliance in a workflow\. Finally, both users interviewed from the lower reliance group reported that a key blocker for them was limited awareness of how the tool could be used effectively\. When shown examples of alternative workflows, they indicated that they would have used the tool more if they had known these capabilities, suggesting that lower reliance may reflect a lack of familiarity rather than deliberate avoidance\.999We provide these interview findings as anecdotal qualitative context for the quantitative patterns observed across users, and are not necessarily representative of the full participant pool\.

### F\.7Examples of points of high reliance

We provide two example moments of high reliance below\.

##### Example 1

The original workflow step:

• (editing generation) Accept AI-suggested CSS/Controls/Board changes for responsive design via multiple “Accept all”/inline Accepts.

And the corresponding counterfactual human\-only steps:

• Open the Implementation Plan / notes that summarize the mobile-responsiveness fixes and keep that window visible for reference.
• Use VS Code (or editor) search to find UI/layout sources referenced in the notes—open index.css plus component files that contain the controls and board layout (e.g., Controls.tsx / Controls.module.css, Board.tsx / Board.css, App.css).
• Edit index.css to add mobile-targeted rules: add a @media (max-width: 600px) block that adjusts root spacing variables, sets the main container to column flow, reduces paddings/margins and font-sizes, and ensures full-width for top-level containers.
• Update controls component styles (Controls.module.css or inline styles in Controls.tsx) so the control group stacks vertically on small screens (use flex-direction: column or display: grid with one column) and make buttons/inputs expand to 100% width within that breakpoint.
• Adjust board/container styles to preserve aspect and spacing on narrow viewports (set max-width: 100%, use responsive heights, and ensure overflow behavior is handled), and add any utility classes needed to support the new layout.
• Run the dev server (npm start / yarn start) and open the app in a browser; use DevTools Device Toolbar (responsive mode) at common mobile widths (e.g., 375x667, 414x896) to inspect the layout.
• Interact with the board and controls in the responsive DevTools view, noting layout/spacing issues; iterate on the CSS edits (tweak media query breakpoints, padding, gaps) until controls and board behave as expected on small screens.
• Run linting and tests (npm run lint, npm test) and fix any style or test failures introduced by the changes (update test snapshots if the visual/layout changes require it).
• Create a descriptive commit capturing the changes (e.g., “responsive: stack controls and add mobile media queries in index.css and component styles”) and push the branch.

##### Example 2

The original workflow step:

• (reading generation) Ask VS Code AI how to add a generate button and recipe list using the API key; read its implementation plan.

And the corresponding counterfactual human\-only steps:

• Open the Spoonacular API docs in a browser and locate the recipe search endpoint (e.g., GET https://api.spoonacular.com/recipes/complexSearch). Note required query parameters, response format (where results live), and how the API key is passed (query param key or header).
• In VS Code open App.jsx and decide where to add UI and state: plan to add a ’Generate’ button, a search input (or reuse existing input value), and a recipe list below the input.
• Add React state hooks at the top of the component: recipes (array), loading (boolean), error (string), and query (string) if not present.
• Implement a searchRecipes function in App.jsx: set loading true and error null; build the request URL using import.meta.env.VITE_SPOONACULAR_KEY and the query (and number=5 or similar); call fetch(url), await response.json(), setRecipes(data.results || data) based on the docs, set loading false; catch errors and setError with a readable message and set loading false.
• Wire the UI: add an onChange to the input to update query, add a Generate with onClick={searchRecipes} (disable it when loading), and below add conditional rendering for loading, error, ’no results’ message, and a mapped list of recipes showing title and image (use recipe.title and recipe.image from the API response).
• Save App.jsx and restart the dev server if necessary (in the terminal run npm run dev or stop/start the server) so environment changes (.env.local) are picked up.’, ’Open the app in the browser and test: enter a query, click Generate, watch the network tab and console for the request/response, confirm recipes render correctly; if there are issues (401/403), verify the VITE_SPOONACULAR_KEY in .env.local and restart the dev server.
• If the API returns only ids for results, add an extra fetch to the recipe information endpoint for each id or adjust to call the endpoint that returns full recipe data; update mapping code to show the additional fields.

### F\.8Example of selective engagement from users in*long*

In one*long*workflow shown below, a participant building a mindful break timer repeatedly used the assistant for design guidance, asking how to redesign timer buttons and session\-history cards\. Rather than directly accepting the generated changes, the participant reviewed the suggestions, manually edited the prompt and asked for more edits\. In a later step, the participant reviewed the AI\-proposed UI refactor but did not apply it, instead continuing with manual testing and edits\. This illustrates selective engagement: the model is used for planning and guidance, while the user retains control over whether and how outputs enter the implementation\.

• (test manually checking) Run 1-minute work -> 15-second break and verify suggestions/history updates.
• (reading generation) Review AI notes about card styling improvements before applying changes.
• (writing prompt) Send detailed prompt for redesigning the session history section.
• (writing code) Scroll and update session history CSS while referencing AI design notes. …
• (reading generation) Scroll AI/chat panel to review textual description of UI refactor.
• (test manually checking) Run work session through transition into break while checking history.
• (writing code) Double-click near bottom of editor to position cursor for further HTML edits.
• (reading generation) Clear/collapse AI panel to reset context while staying on index.html.
• (writing prompt) Submit multi-line prompt requesting updated HTML/CSS layout changes.
• (writing code) Scroll/edit CSS, focusing on session-history rules while reading AI layout changes.
• (test manually checking) Reload/focus the app, click around controls/history, and observe one-minute cycles.
• (writing prompt) Trigger built-in AI chat and request redesign of break suggestion component.
• (writing code) Position cursor in index.html to review/edit CSS for session history/components.
• (test manually checking) Toggle History, clear history, start work and break sessions, and test Session History modal interactions.