Source-linked AI summary
When to Show a Suggestion? Integrating Human Feedback in AI-Assisted Programming
Hussein Mozannar, Gagan Bansal, Adam Fourney, Eric Horvitz
TL;DR
AI code-recommendation systems need a principled way to decide when suggestions are worth showing, using programmer feedback without adding unnecessary verification or latency. The paper introduces CDHF, a utility-theoretic cascade that predicts acceptance from Copilot telemetry and selectively hides suggestions. Retrospective data show substantial reductions in displayed and generated suggestions, while latent programmer state matters and acceptance optimization can favor lower-quality short suggestions.
Problem
The paper asks when AI-generated code suggestions should be displayed by balancing their likely acceptance and usefulness against verification and generation costs.
Method
CDHF uses a utility-theoretic framework and cascade of models over Copilot telemetry to decide whether to generate and display suggestions.
Results
Retrospectively, CDHF could hide 25% of shown suggestions while guaranteeing that 95% would have been rejected, avoid generating 13%, and increase acceptance by 7.2%.
Takeaways & Limitations
Acceptance feedback can guide suggestion-display decisions that reduce programmer verification and system latency, but optimizing acceptance can produce lower-quality short suggestions.
Takeaways & Limitations
The evaluation is retrospective, so a prospective study is needed for conclusive assessment of Copilot with and without CDHF.
Abstract
from arXiv · showhide
AI powered code-recommendation systems, such as Copilot and CodeWhisperer, provide code suggestions inside a programmer's environment (e.g., an IDE) with the aim of improving productivity. We pursue mechanisms for leveraging signals about programmers' acceptance and rejection of code suggestions to guide recommendations. We harness data drawn from interactions with GitHub Copilot, a system used by millions of programmers, to develop interventions that can save time for programmers. We introduce a utility-theoretic framework to drive decisions about suggestions to display versus withhold. The approach, conditional suggestion display from human feedback (CDHF), relies on a cascade of models that provide the likelihood that recommended code will be accepted. These likelihoods are used to selectively hide suggestions, reducing both latency and programmer verification time. Using data from 535 programmers, we perform a retrospective evaluation of CDHF and show that we can avoid displaying a significant fraction of suggestions that would have been rejected. We further demonstrate the importance of incorporating the programmer's latent unobserved state in decisions about when to display suggestions through an ablation study. Finally, we showcase how using suggestion acceptance as a reward signal for guiding the display of suggestions can lead to suggestions of reduced quality, indicating an unexpected pitfall.
1 Introduction
AI code-recommendation systems aim to improve programmer productivity, but this work asks when suggestions should be shown or withheld using acceptance feedback and latency-aware utility. CDHF uses predictive models to hide likely-rejected suggestions, with retrospective results showing fewer displays, less generation, and higher acceptance.
- Approach: CDHF uses a utility-theoretic display rule and a cascade of acceptance models to decide whether generating and showing a suggestion is worthwhile.The procedure weighs expected acceptance against generation latency and can withhold suggestions under a selected rejection-probability threshold.
- Evaluation: 25% of shown suggestions could be hidden while guaranteeing that 95% would have been rejected, and 13% of these suggestions could avoid generation.The retrospective evaluation used sessions from 535 programmers and feedback on 168k suggestions.
- Evaluation: CDHF would increase the acceptance rate by 7.2% while balancing displayed suggestions against latency through a parameter that halts generations.This trade-off lets the system control how aggressively it avoids generating or displaying suggestions.
- Implications: The authors frame CDHF as a roadmap for better suggestion display and note that a minimal version was implemented in a newer GitHub Copilot release.They also state that their insights may extend beyond Copilot and code-based tasks.
- Extensions: The work also examines acceptance as a reward for choosing suggestions and finds that partial completions can be prioritized over complete code segments.The introduction presents this as a separate direction beyond deciding when to display recommendations.
2 Related Work
Prior work selectively hides code suggestions using learned quality estimates, while this paper uses organically collected programmer acceptance feedback from Copilot telemetry. CDHF emphasizes fast inference and display decisions rather than updating the underlying language model.
- Selective display: CDHF differs from QEBC [SDS+22] by estimating suggestion acceptance from real programmer behavior rather than code-completion quality datasets.The comparison also distinguishes Copilot telemetry from custom-trained models used in [SDS+22].
- System design: The approach prioritizes fast inference to reduce latency and hides suggestions rather than updating the language model.This operational focus differentiates the display intervention from model-training approaches.
- Foundations: The paper builds its theoretical formulation on earlier work using machine learning and utility to guide human-AI contributions.Its contribution is to apply that framing to AI-assisted code suggestion display.
3 Problem Setting
The problem setting models Copilot as a time-indexed interaction that generates suggestions after pauses and records prompts, suggestions, and programmer actions in telemetry. Because telemetry omits activities between events, programmer latent state is an important but unobserved factor in acceptance prediction.
- Interaction design: The central design question is when Copilot should inject a suggestion into the IDE, with the existing system triggering suggestions when it detects a brief pause.Alternative designs could require explicit programmer requests or mix human and machine initiative.
- AI-Assisted Programming: Copilot generates a suggestion from code context at time t and presents it at t + τ, where τ represents language-model latency.The programmer can accept or reject the suggestion, with rejection triggered implicitly by continuing to type.
- Telemetry: Telemetry records within-session event times, actions, prompts, and suggestions, forming a discretized representation of each coding session.Figure 2 depicts these events as a timeline, and the resulting data provides human-feedback signals.
- Programmer State: Programmer latent state captures whether the programmer is verifying a suggestion or engaged in activities such as thinking or consulting documentation.This state affects recommendation value but is not captured between consecutive telemetry timestamps.
4 Theoretical Formulation of Suggestion Utility
The paper formulates suggestion utility as the change in programmers’ total coding time from showing rather than withholding a suggestion. A suggestion should be shown when its expected benefit exceeds verification, latency, editing, and rejection-related costs, but estimating utility directly is difficult.
- Programmer Model: Showing a suggestion combines verification and latency costs with acceptance-weighted editing time and rejection-weighted writing time, whereas withholding it requires writing the code directly.The model also allows later suggestions to affect editing and writing times.
- Suggestion Utility: Suggestion utility δ measures the change in programmers’ coding time caused by showing a suggestion, with δ > 0 indicating that showing it reduces task time.The optimal policy is to display suggestions only when their utility is positive.
- Feasibility of Estimating Utility: Directly estimating δ requires four quantities, but verification-time prediction achieves only R2 = 0.13 because of high variance and unobserved confounders.The paper therefore restricts its practical methodology to estimating acceptance probability.
- Latent Programmer State: Because telemetry omits the programmer’s latent state ϕ, the practical model estimates P(A = accept|X, S) rather than P(A = accept|X, S, ϕ).In the reported ablation, accuracy rises from 61.9 ± 1.9 without latent state to 83.6 ± 2.4 with it, with p = 6.9e −7 and t = 7.11.
- Acceptance Threshold: At P*, showing and withholding have equal time cost when latency is zero, so the figure compares total time against the programmer’s conditional acceptance probability.The plotted acceptance probability is P(A = accept|X, S, ϕ).
- Acceptance Threshold: The acceptance threshold P* decreases as rejection-related writing becomes more costly relative to editing after acceptance, while verification and latency increase the threshold.When acceptance probability falls below P*, the proposition says the suggestion should not be shown.
5 Conditional Suggestion Display From Human Feedback
CDHF uses a cascade of predictors to decide whether to display a suggestion, sometimes before generating it. The design trades off hiding likely-rejected suggestions against making accurate decisions without incurring suggestion-generation latency, while constraining hidden suggestions’ rejection rate.
- Display Decision: CDHF first uses code-only information to decide whether a display decision can be made without generating the suggestion, then uses suggestion-aware information when needed.This two-stage design reduces unnecessary LLM calls while retaining access to the suggestion for harder decisions.
- Model Parameterization: The cascade combines a code-only routing function r(X) with stage-one and stage-two acceptance predictors, m1(X) and m2(X, S), to produce the display decision m(X, S).When r(X) = 1, the system decides before generating S; otherwise it generates S and applies the second-stage model.
- Objective and Guarantees: The method optimizes hiding suggestions that would have been rejected and increasing decisions made before generation, subject to a constraint that hidden suggestions have at least probability p of being rejected.The two objectives trade off because suggestion-aware decisions are more accurate.
- Parameterization: CDHF fits calibrated acceptance predictors and tunes thresholds t1, t2, and tr, with entropy-based routing controlling when the code-only prediction is sufficiently decisive.The thresholds are optimized jointly over [0, 1]3, and the procedure saves latency by reducing LLM calls.
- Implementation: The system retains a keyboard shortcut so programmers can override display decisions, and the paper evaluates CDHF retrospectively.This override preserves user access to suggestions hidden by the automated policy.
6 Experiments
The experiments evaluate CDHF using Copilot telemetry, measuring acceptance prediction, selective hiding, latency-aware generation, and counterfactual outcomes. Results show useful display-versus-generation trade-offs, while the retrospective design and acceptance-based objective impose important limitations.
- 6 Experiments: The telemetry evaluation used 535 Python programmers across 4,749 coding sessions, totaling almost 1,675 hours and 168,807 shown events.The observed acceptance rate was 21.4%, and the authors state that it should not be interpreted as Copilot’s average acceptance rate.
- 6.2 Model Evaluation: The acceptance model achieved 0.780 AUC when splitting across users, while removing suggestion features reduced AUC to 0.631.The personalized model achieved 81.1% accuracy, with 95% confidence intervals reported in the evaluation.
- 6.3 Retrospective Evaluation of CDHF: CDHF varies hiding and generation decisions through operating points that trade off the fraction of suggestions hidden against the guaranteed accuracy when suggestions are hidden.Figure 5 varies the desired FNR/TNR constraint and the frequency R of decisions made before or after generating suggestions.
- 6.3 Retrospective Evaluation of CDHF: 25.3% of shown suggestions could be hidden while guaranteeing that 94.7% would have been rejected, while avoiding generation of 12.9% of suggestions.With no latency concern, CDHF could hide 52.9% while guaranteeing that 91.3% would have been rejected.
- Discussion and Limitations: The evaluation is retrospective, so a user study is required to verify whether CDHF makes programmers more productive.The paper also warns that insufficiently representative training data could cause CDHF to hide useful suggestions, and rejected suggestions may still be useful.
7 Which Suggestion to Show?
The paper examines whether ranking candidate code by predicted acceptance can determine which suggestion to show. The experiment finds that this objective can favor very short suggestions, motivating caution about acceptance as a reward.
- Results: When k > 0, the highest-scored suggestion lies in the [0, 0.2] length percentile for over 60 of 164 problems and is the first token for at least 40.For k = 0, normalized lengths are almost uniform, with a Kolmogorov–Smirnov test p-value of 0.53 and KS=0.06.
- Potential Bias Towards Short Suggestions: Acceptance-based ranking can favor short suggestions, because the highest-scored candidate often falls within the first few lines of the solution.The authors hypothesize that this ranking scheme may produce poor short suggestions.
- Limitations: The short-suggestion finding is limited because the model was trained only on Copilot suggestions, which may themselves reflect a short-suggestion bias.The paper also reports that the embedding-based reward model predicted accepts with AUC=0.701, while noting possible bias relative to fine-tuning the language model.
8 Conclusion
The paper proposes CDHF, a utility-theoretic strategy for deciding when to display code suggestions, and retrospectively finds that it can reduce suggestions and programmers’ time without sacrificing Copilot’s utility.
- 8 Conclusion: CDHF uses a two-stage predictive procedure grounded in utility theory to decide when to display code suggestions.The models predict suggestion acceptance and guide whether suggestions should be shown or hidden.
- 8 Conclusion: The retrospective evaluation showed that CDHF can reduce the number of suggestions and programmers’ time without sacrificing Copilot’s utility.
- 8 Conclusion: A prospective study comparing Copilot with and without CDHF is needed for conclusive evaluation.
- 8 Conclusion: The authors state that CDHF functions as a filtering mechanism for unhelpful suggestions and is not expected to introduce negative consequences beyond Copilot.
- 8 Conclusion: Future work will incorporate the programmer’s latent state into predictive models and investigate ranking suggestions with CDHF models.
- 8 Conclusion: The paper does not validate CDHF’s efficacy in user studies.
A Extended Related Work
Related work situates CDHF among code-recommendation evaluation, human-feedback learning, collaborative filtering, interactive interfaces, and algorithmic deferral. CDHF differs by using implicit telemetry feedback from real Copilot behavior without updating the language model.
- A Extended Related Work: Prior work reports mixed evidence about Copilot’s effects, including perceived productivity gains, reduced coding iteration time, and no significant task-completion-time improvement.
- A Extended Related Work: Unlike offline code-completion evaluations, CDHF uses real programmer behavior from a code-recommendation system currently in use.Its acceptance estimator is based on Copilot telemetry rather than custom-trained completion datasets.
- A Extended Related Work: Reinforcement learning from human feedback gathers preferences, trains a reward model, and updates the language model, whereas CDHF only guides suggestion display.
- A Extended Related Work: CDHF uses implicitly collected acceptance or rejection telemetry instead of explicit preferences, and avoids updating the underlying language model.
- A Extended Related Work: Collaborative filtering re-ranks content, while CDHF must address both generating and ranking code suggestions.
- A Extended Related Work: Algorithmic deferral estimates error for deciding whether humans or AI should act, whereas CDHF estimates time costs for deciding when support should be shown.
B Derivation of P∗
The derivation defines a threshold P* for displaying suggestions by equating their expected time impact with verification, writing, editing, and latency costs. Suggestions should be hidden when predicted acceptance falls below this threshold.
- B Derivation of P∗: If predicted acceptance P(A = accept|X, S, ϕ) is below P*, the suggestion should not be shown; if it is above P*, the suggestion should be shown.
- B Derivation of P∗: The derivation assumes that accepted suggestions require less editing time than rejected suggestions require writing time.
- B Derivation of P∗: P* combines expected verification time, latency, rejected-suggestion writing time, and accepted-suggestion editing time into a display threshold.
- B Derivation of P∗: Under an additional assumption that rejected suggestions provide no later writing benefit, P* simplifies by replacing rejected-case writing time with ordinary writing time.
- B Derivation of P∗: P* is not necessarily a valid probability in [0, 1], so it functions as a decision threshold rather than a probability estimate.
- B Derivation of P∗: The model assumes programmers either accept or reject suggestions, with rejection implicitly triggered by continuing to type.
C Model Evaluation and Analysis
The evaluation analyzes acceptance-prediction models, calibration, sample complexity, feature importance, and transfer to a user study. Stage 2 reaches 0.69 AU-ROC with 1% of training data and 0.75 AU-ROC with 25%, while its predictors correlate with programmer behavior rather than establish causation.
- Calibration: The stage 2 XGBoost model is reported as well calibrated.
- Sample Complexity: 25% of training data yields 0.75 AU-ROC for the stage 2 acceptance model, compared with 0.69 AU-ROC using 1% or 1688 samples.
- Factors Influencing Programming Actions: The two most important features are Copilot’s suggestion confidence and suggestion length; together they produce a model with 0.71 AUROC.
- Factors Influencing Programming Actions: Recent coding-session context and textual properties also correlate with acceptance behavior, including whether the suggestion contains the character '#'.The '#' feature was split eight times in the tree ensemble.
- Factors Influencing Programming Actions: Feature-importance findings describe correlations with programmer behavior and should not be interpreted causally.
- Analysis of Suggestions: Evaluated on 1029 accepted and rejected events from a 21-participant user study, the model achieves 0.73 AU-ROC.
- Analysis of Suggestions: Suggestions most likely to be rejected cluster around tiny non-alphabetic completions and midword completions that may distract programmers already typing.
D Which Suggestion to Show: Plots
The experiments examine where the model’s highest-acceptance-probability suggestion falls in the length distribution and how acceptance probability changes with suggestion length across k=0, 1, 2, and 3. The same trend appears with and without probability normalization.
- D Which Suggestion to Show: Plots: The plots measure both the length-percentile location of the highest-probability suggestion and normalized acceptance probability as suggestion length increases.For each example, raw acceptance probabilities are normalized by that example’s maximum across lengths.
- D Which Suggestion to Show: Plots: The observed trend persists without normalization, indicating that the plotted pattern is not produced solely by rescaling probabilities within each example.The text states that the same trend is observed when raw probabilities are left unnormalized.
- D Which Suggestion to Show: Plots: The analysis covers k=0, k=1, k=2, and k=3, corresponding to docstring-only context through the docstring plus the first three solution lines.Figures 10–13 report the plots separately for each k value.