Fewer Clarifications, Better Code: Benchmarking Cross-Session Personalized Ambiguity Adaptation in Coding Assistants

# Fewer Clarifications, Better Code: Benchmarking Cross-Session Personalized Ambiguity Adaptation in Coding Assistants
Source: [https://arxiv.org/html/2607.26611](https://arxiv.org/html/2607.26611)
Zijian Xu1, 3\\equalcontrib, Wenshuo Zhang2\\equalcontrib, Zisen Qin1, Rui Sheng2, Yushi Sun2, Huamin Qu2, Chuhan Shi1\\corresponding

###### Abstract

AI\-assisted coding increasingly translates informal user intent into executable software, yet coding requests often contain ambiguities that recur in user\-specific ways across tasks and sessions\. Existing disambiguation methods typically address each ambiguous request in isolation within the current coding session, often through eliciting additional clarification\. However, whether resolved session history from the same user can serve as memory for resolving recurring personalized ambiguity in a newly opened session remains underexplored\. We formulate*personalized ambiguity adaptation*as a new task: given a user’s previously resolved coding sessions and a new ambiguous request, an assistant should identify the recurring ambiguity pattern, produce the intended executable solution, and minimize clarification\. To benchmark this task, we introduce CAPA, which characterizes personalized coding ambiguity through six mechanisms and injects these mechanisms into unambiguous executable tasks using a controlled three\-stage generation pipeline\. CAPA contains 600 coding sessions across 60 balanced user–ambiguity cells, including 300 held\-out evaluation sessions\. We evaluate 12 recent LLMs under no\-history and same\-user\-history conditions using executable success, first\-turn success, and turns\-to\-completion\. We further study how task difficulty, user identity, and memory management affect adaptation and propose a lightweight user history gating method\. CAPA provides a foundation for developing long\-term coding assistants that better align generated code with user intent while reducing repeated clarification\.

## Introduction

AI\-assisted coding has become a common way to turn informal intent into executable software\. Users ask coding assistants to implement functions, debug failures, adapt existing programs, and modify projects through natural\-language dialogue\. Yet these requests often remain ambiguous because users may omit details or express intent through recurring, user\-specific patterns\. For example, when a user asks to “normalize” a feature, the request may refer either to min–max scaling or to z\-score standardization\. A collaborator familiar with the user may know from prior coding sessions that the user consistently intends the latter one, whereas a coding assistant may select min–max scaling and produce a technically valid but unintended implementation\. A long\-term coding assistant should similarly infer such recurring interpretations from prior coding sessions; otherwise, it must repeatedly request clarification or continue making the same incorrect assumption, increasing interaction and user cognitive load\.

Recent work addresses important parts of this problem, but largely in isolation\. Ambiguity research studies whether language models can detect underspecified requests, rewrite them, or ask effective clarification questions\(Tanjimet al\.[2025b](https://arxiv.org/html/2607.26611#bib.bib22); Zhanget al\.[2024](https://arxiv.org/html/2607.26611#bib.bib2)\)\. These methods generally treat ambiguity as local to the current coding session, while explicit clarification seeks to resolve uncertainty through additional user turns\. Personalization and long\-term memory research instead studies how models retrieve, update, and apply user\-specific information across sessions\(Salemiet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib8); Maharanaet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib9)\)\. However, ambiguity can be user\-specific: the same user tends to leave the same kind of information underspecified across different tasks\. Whether assistants can use same\-user history or personalized memory to resolve such ambiguity without repeated clarification remains underexplored, particularly in open\-ended executable coding\. This capability is essential for building long\-term assistants that become more accurate and interaction\-efficient over time\.

To address this gap, we formulate*personalized ambiguity adaptation*as a new task for coding sessions\. Given a user’s previously resolved sessions and a new ambiguous request that opens a held\-out session, an assistant uses the recurring ambiguity pattern revealed by that history to infer the intended implementation\. It should ask to clarify only when the history provides insufficient evidence, with the goal of producing a correct executable solution in as few turns as possible\. Unlike conventional ambiguity resolution, which treats each request within its local context, this task evaluates cross\-session adaptation to user\-specific ambiguity\. It motivates assistants that align generated code with user intent while minimizing interruptions from repeated clarification\.

To benchmark this task, we introduce CAPA \(Cross\-SessionAdaptation toPersonalizedAmbiguity\), constructed in two steps\. First, we adapt the linguistic ambiguity types ofLiet al\.\([2024](https://arxiv.org/html/2607.26611#bib.bib6)\)into six mechanisms of personalized coding ambiguity\. Each mechanism captures a recurring user\-related cause for leaving required implementation information omitted, obscured, or underspecified; these mechanisms are grounded in real coding conversations from WildChat\(Zhaoet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib7)\)\. Second, we instantiate the mechanisms across user profiles and apply a three\-stage pipeline to unambiguous HumanEval tasks\(Chenet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib13)\)\. The pipeline constructs an ambiguous initial request by controlling task\-critical information, expands it into a resolved multi\-turn coding session, and validates that the personalized ambiguity pattern remains consistent across sessions\. The final benchmark contains 600 coding sessions arranged into 60 balanced user–ambiguity cells, with five resolved history sessions and five held\-out evaluation sessions per cell\.

We benchmark 12 recent LLMs spanning closed\-source frontier, open\-access frontier, and smaller open\-source models on CAPA , and systematically evaluate their personalized ambiguity adaptation using Executable Success \(ES\), First\-Turn Executable Success \(FT\-ES\), and Turns\-to\-Completion \(TTC\)\. We further analyze key aspects of this task, including how adaptation varies with task difficulty, whether history gains depend on correctly matched user identity, and how memory\-based history management affects history use\. Based on these analyses, we propose same\-user history gating as a lightweight method for improving performance\.

In summary, our contributions are:

- •A new task for long\-term coding assistants\.We formulate personalized ambiguity adaptation as the problem of inferring a user’s recurring ambiguity\-resolution pattern from resolved coding sessions and transferring it to new executable tasks with minimal clarification\.
- •A data generation pipeline\.We introduce CAPA, including a six\-mechanism coding\-oriented taxonomy, a three\-stage generation and consistency\-validation pipeline, and 600 coding sessions organized into balanced same\-user histories and held\-out evaluations\.
- •An interaction\-aware evaluation\.We evaluate 12 models using ES, FT\-ES, and TTC, together with controlled studies of task difficulty, user identity, history gating, and memory\-based adaptation\.

## Related Work

Ambiguity and clarification\.Ambiguity occurs when a request has multiple plausible interpretations or lacks information needed to choose among them\(Tanjimet al\.[2025b](https://arxiv.org/html/2607.26611#bib.bib22)\)\. It may arise from syntax, lexical meaning, or missing conversational context, motivating ambiguity taxonomies and ambiguous question\-answering settings\(Church and Patil[1982](https://arxiv.org/html/2607.26611#bib.bib23); Navigli[2009](https://arxiv.org/html/2607.26611#bib.bib24); Schlangen[2004](https://arxiv.org/html/2607.26611#bib.bib25); Liuet al\.[2023a](https://arxiv.org/html/2607.26611#bib.bib26); Minet al\.[2020](https://arxiv.org/html/2607.26611#bib.bib1)\)\. Prior work addresses both ambiguity detection and resolution\. Detection methods determine whether to answer or seek information using feature\-based classifiers, neural models, or LLM prompting\(Trienes and Balog[2019](https://arxiv.org/html/2607.26611#bib.bib28); Dhole[2020](https://arxiv.org/html/2607.26611#bib.bib29); Guoet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib27); Leeet al\.[2023](https://arxiv.org/html/2607.26611#bib.bib40); Tanjimet al\.[2025a](https://arxiv.org/html/2607.26611#bib.bib30); Kuhnet al\.[2022](https://arxiv.org/html/2607.26611#bib.bib31)\); CLAMBER further tests whether LLMs recognize ambiguous needs and ask useful questions\(Zhanget al\.[2024](https://arxiv.org/html/2607.26611#bib.bib2)\)\. Resolution methods rewrite underspecified queries using dialogue or retrieved context\(Elgoharyet al\.[2019](https://arxiv.org/html/2607.26611#bib.bib33); Ananthaet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib41); Maet al\.[2023](https://arxiv.org/html/2607.26611#bib.bib34)\), cover multiple interpretations in a long\-form response\(Stelmakhet al\.[2022](https://arxiv.org/html/2607.26611#bib.bib35); Kimet al\.[2023](https://arxiv.org/html/2607.26611#bib.bib36); Inet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib37)\), or ask clarifying questions\(Aliannejadiet al\.[2019](https://arxiv.org/html/2607.26611#bib.bib38); Xuet al\.[2019](https://arxiv.org/html/2607.26611#bib.bib39); Zhang and Choi[2025](https://arxiv.org/html/2607.26611#bib.bib4); Kimet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib32); Zhanget al\.[2025](https://arxiv.org/html/2607.26611#bib.bib43)\)\. In coding, Orchid studies ambiguous requirements in function\-level generation\(Yanget al\.[2026a](https://arxiv.org/html/2607.26611#bib.bib17)\), while ClarifyCodeBench evaluates pre\-generation clarification\(Fanget al\.[2026](https://arxiv.org/html/2607.26611#bib.bib18)\)\. These approaches reduce uncertainty but require additional inference, output, or interaction\(Tanjimet al\.[2025b](https://arxiv.org/html/2607.26611#bib.bib22)\), and resolve requests within the current session or through newly elicited information\. CAPA instead asks whether an assistant can infer a recurring resolution pattern from a user’s prior sessions and reuse it in a new coding session\.

Personalization and long\-term memory\.Personalized assistants preserve evidence across sessions, infer stable user characteristics, and selectively apply them later\. LaMP evaluates history\-based personalized classification and generation, while PersonaMem studies user profiling and response selection as personal information evolves across sessions\(Salemiet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib8); Jianget al\.[2025](https://arxiv.org/html/2607.26611#bib.bib10)\)\. LoCoMo, LongMemEval, and Momento test multi\-session recall, temporal reasoning, knowledge updates, and memory\-grounded action\(Maharanaet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib9); Wuet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib12); Merinet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib53)\)\. Memory systems use retrieved records, natural\-language profiles, or learned representations, increasingly separating episodic evidence from consolidated user patterns\(Huet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib48); Caoet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib44); Daset al\.[2026](https://arxiv.org/html/2607.26611#bib.bib45); Zhanget al\.[2026](https://arxiv.org/html/2607.26611#bib.bib46); Houet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib47)\); practical systems also extract, organize, retrieve, update, and consolidate user information over time\(Chhikaraet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib49); Xuet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib50); Inet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib51); Uddinet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib11); Jianget al\.[2026](https://arxiv.org/html/2607.26611#bib.bib52)\)\. Closest to our setting, APeB infers latent shopping intent from behavioral traces, while PRefine transfers recurring preferences to missing tool\-call arguments\(Yanget al\.[2026b](https://arxiv.org/html/2607.26611#bib.bib54); Yoonet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib55)\)\. Both connect memory and disambiguation but target product choice or schema\-bounded tools\. CAPA instead treats the reusable signal as a personalized ambiguity\-resolution pattern and tests its transfer across distinct coding sessions\.

Interactive coding benchmarks\.Executable benchmarks objectively assess program correctness\. HumanEval and MBPP evaluate function\-level generation from explicit specifications, while EvalPlus strengthens test coverage\(Chenet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib13); Austinet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib14); Liuet al\.[2023b](https://arxiv.org/html/2607.26611#bib.bib15)\)\. Interactive benchmarks include SWE\-bench for repository\-level issue resolution and ConvCodeWorld for conversational generation in reproducible feedback environments\(Jimenezet al\.[2024](https://arxiv.org/html/2607.26611#bib.bib19); Hanet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib21)\)\. HumanEvalComm and Orchid specifically examine incomplete, inconsistent, or ambiguous requirements\(Wu and Fard[2025](https://arxiv.org/html/2607.26611#bib.bib16); Yanget al\.[2026a](https://arxiv.org/html/2607.26611#bib.bib17)\), but their ambiguity belongs to one task or dialogue rather than a stable cross\-session user pattern\. CAPA combines executable coding, multi\-turn sessions, and same\-user history\. It evaluates both eventual correctness and whether prior sessions reduce clarification\.

## Benchmark Task

CAPA evaluates whether a coding assistant can use a recurring user’s prior multi\-turn coding sessions to resolve personalized ambiguity in a newly opened session\. We first define the data hierarchy and notation, and then formulate the history\-conditioned evaluation task \(Fig\.[1](https://arxiv.org/html/2607.26611#Sx3.F1)\)\.

![Refer to caption](https://arxiv.org/html/2607.26611v1/figures/Task.png)Figure 1:Overview of the history\-conditioned personalized ambiguity adaptation task\. The assistant receives the public dialogue traces of \(nn\) resolved same\-user coding sessions and a new ambiguous request that initiates held\-out session \(τi,k\\tau\_\{i,k\}\)\. It uses cross\-session evidence to infer the user’s recurring ambiguity pattern, requests clarification only when necessary, and generates code for held\-out task\(Pi,k\)\(P\_\{i,k\}\)\.### Personalized Multi\-Session Coding Data

We distinguish four levels of interaction\. An*assistant turn*pairs the latest user message with one assistant response\. A*dialogue trace*is the ordered sequence of such turns produced while solving one coding task\. A*coding session*is the complete task\-centered interaction, including its initial request, dialogue trace, and hidden executable test cases to be evaluated by a hidden judge that determines task completion\. A*user trajectory*is an ordered sequence of coding sessions from the same user\.

Let userUi=\(πi,ai,ri\)U\_\{i\}=\(\\pi\_\{i\},a\_\{i\},r\_\{i\}\)be characterized by a profileπi\\pi\_\{i\}, a recurring ambiguity mechanismaia\_\{i\}, and a personalized resolution patternrir\_\{i\}\. The profile controls ambiguity\-independent communication characteristics, while\(ai,ri\)\(a\_\{i\},r\_\{i\}\)specifies how required implementation information is repeatedly obscured and how that ambiguity should be resolved\. For the user’skk\-th coding taskPi,kP\_\{i,k\}, the corresponding coding session is

τi,k=\(Di,k,ji,k\),\\text\{$\\displaystyle\\tau\_\{i,k\}=\\bigl\(D\_\{i,k\},j\_\{i,k\}\\bigr\)$\},whereDi,kD\_\{i,k\}is the public multi\-turn dialogue trace produced while solving taskPi,kP\_\{i,k\}, beginning with the ambiguous initial requestui,k\(0\)u\_\{i,k\}^\{\(0\)\}, andji,kj\_\{i,k\}is the associated set of hidden executable test cases\. Writing the trace as

Di,k=\{\(ui,k\(t−1\),yi,k\(t\)\)\}t=1Ti,k,D\_\{i,k\}=\\bigl\\\{\(u\_\{i,k\}^\{\(t\-1\)\},y\_\{i,k\}^\{\(t\)\}\)\\bigr\\\}\_\{t=1\}^\{T\_\{i,k\}\},ui,k\(t−1\)u\_\{i,k\}^\{\(t\-1\)\}is the latest user message andyi,k\(t\)y\_\{i,k\}^\{\(t\)\}is the assistant response at assistant turntt;ui,k\(0\)u\_\{i,k\}^\{\(0\)\}is the initial request\.

The complete trajectory of userUiU\_\{i\}is organized as

Si=\(Ui;τi,1,…,τi,n⏟resolved history sessions,τi,n\+1,…,τi,n\+m⏟held\-out evaluation sessions\)\.S\_\{i\}=\\bigl\(U\_\{i\};\\underbrace\{\\tau\_\{i,1\},\\ldots,\\tau\_\{i,n\}\}\_\{\\text\{resolved history sessions\}\},\\underbrace\{\\tau\_\{i,n\+1\},\\ldots,\\tau\_\{i,n\+m\}\}\_\{\\text\{held\-out evaluation sessions\}\}\\bigr\)\.The coding task changes across sessions, whereas\(ai,ri\)\(a\_\{i\},r\_\{i\}\)remains stable\. The firstnnsessions therefore reveal how the user repeatedly expresses and resolves ambiguity The followingmmsessions test whether that personalized pattern transfers to new coding problems\.

### Personalized Ambiguity Adaptation Task

For a held\-out sessionτi,k\\tau\_\{i,k\}withk\>nk\>n, the evaluated assistant receives the same\-user history

Hi\(n\)=Di,1​‖Di,2‖​⋯∥Di,nH\_\{i\}^\{\(n\)\}=D\_\{i,1\}\\\|D\_\{i,2\}\\\|\\cdots\\\|D\_\{i,n\}and the new ambiguous requestui,k\(0\)u\_\{i,k\}^\{\(0\)\}, where∥\\\|denotes dialogue concatenation\. The history is explicitly provided as inference\-time context; the task does not assume parameter updates or automatic persistent storage\. The assistant must infer the recurring ambiguity pattern evidenced byHi\(n\)H\_\{i\}^\{\(n\)\}and apply it within the new multi\-turn session\.

At assistant turntt, letDi,k\(<t\)D\_\{i,k\}^\{\(<t\)\}denote the dialogue trace accumulated in the current held\-out session before that turn\. The model produces a response

yi,k\(t\)=fθ​\(Hi\(n\),ui,k\(0\),Di,k\(<t\)\),\\text\{$\\displaystyle y\_\{i,k\}^\{\(t\)\}$\}=f\_\{\\theta\}\\\!\\left\(H\_\{i\}^\{\(n\)\},u\_\{i,k\}^\{\(0\)\},D\_\{i,k\}^\{\(<t\)\}\\right\),which either asks a clarification question or contains a candidate code submission\. In the former case, the next user messageui,k\(t\)u\_\{i,k\}^\{\(t\)\}is added to the dialogue and the interaction continues\. In the latter case, the code\-extraction rule yieldsci,k\(t\)c\_\{i,k\}^\{\(t\)\}, and the turn succeeds whenJ​\(ci,k\(t\);ji,k\)=1J\(c\_\{i,k\}^\{\(t\)\};j\_\{i,k\}\)=1, where the external judgeJJdecides whether the task is completed by combining the results of executing a submission againstji,kj\_\{i,k\}with its own assessment of the submitted code against the reference solution\. The session terminates at the first successful submission or when it reaches the turn limit\.

The desired behavior is to answer directly when same\-user history provides sufficient evidence and to clarify only when the intended implementation remains underdetermined\. We evaluate this behavior usingExecutable Success\(ES\), the proportion of held\-out sessions solved within the turn limit;First\-Turn Executable Success\(FT\-ES\), the proportion solved at the first assistant turn; andTurns\-to\-Completion\(TTC\), the average first\-success turn across all held\-out sessions, with unsolved sessions assigned the turn\-limit value\. Better adaptation improves ES while reducing completion turns, without relying on unsupported guesses\.

## Data Generation

This section describes how CAPA generates the personalized multi\-session data defined in task section\. We first define a coding\-oriented ambiguity taxonomy that specifies what kind of uncertainty is repeatedly expressed by a user\. Building on this taxonomy, the data generation pipeline proceeds in three stages: constructing the ambiguous initial request for one coding session, generating its multi\-turn dialogue trace, and validating personalized consistency across sessions before assembling the user trajectory \(Figure[2](https://arxiv.org/html/2607.26611#Sx4.F2)\)\.

![Refer to caption](https://arxiv.org/html/2607.26611v1/figures/Datapipeline.png)Figure 2:Overview of the CAPA data generation pipeline\. Stage One combines task requirements with a user profile and an instantiated ambiguity–resolution assignment to create an ambiguous request\. Stage Two uses AmbiSimu to produce a coding session through iterative dialogue and execution\-based evaluation\. Stage Three checks cross\-session personalization consistency and assembles accepted sessions into a user trajectory\.### Ambiguity Taxonomy

To characterize how users repeatedly leave coding intent underspecified, we constructed a coding\-oriented taxonomy of personalized ambiguity by adapting the 11 linguistic ambiguity types ofLiet al\.\([2024](https://arxiv.org/html/2607.26611#bib.bib6)\)\. Rather than classifying ambiguity solely by its surface linguistic form, we reorganized these types around user\-related causes of underspecified coding intent\. Each category captures a recurring way in which a user understands, assumes, omits, or refers to required implementation information during coding interactions\.

Two authors independently mapped the 11 source types to their manifestations in human–LLM coding interactions and grouped the resulting manifestations by their underlying user\-related causes\. After discussing disagreements, they reached consensus on the category definitions and boundaries, yielding six mechanisms:*domain\-cognitive polysemy*,*structural logic misalignment*,*habitual context omission*,*system\-boundary misconception*,*conversational context misalignment*, and*implicit constraint under\-specification*\. Appendix[B](https://arxiv.org/html/2607.26611#A2)provides the full taxonomy\. Table[7](https://arxiv.org/html/2607.26611#A2.T7)summarizes each ambiguity mechanism, the type\-specific information control used to omit or obscure required implementation information, and the personalized resolution pattern that captures the user\-specific interpretation needed to resolve the ambiguity\. For each userUiU\_\{i\},aia\_\{i\}denotes the assigned ambiguity mechanism, whilerir\_\{i\}denotes the corresponding personalized resolution pattern\.

#### Human validation of the taxonomy\.

We conducted a within\-subject annotation study with 20 participants recruited through a public call at our university to evaluate the taxonomy\. Each participant annotated two sets of 10 items, and adjacent assignments overlapped in a cyclic design so that each of the 200 items received two independent annotations\. For every item, participants identified its dominant ambiguity mechanism from our taxonomy and indicated whether it exhibited any additional ambiguity characteristics\. Inter\-annotator agreement yielded a Fleiss’κ\\kappaof 0\.66, providing direct empirical evidence that the proposed categories are recognizable in coding requests\.

### Interaction Data Generation Pipeline

To generate data for the Personalized Ambiguity Adaptation Task, the pipeline operates at two hierarchical levels\. At the coding\-session level, Stages One and Two transform a clear executable taskPi,kP\_\{i,k\}into an ambiguous initial requestui,k\(0\)u\_\{i,k\}^\{\(0\)\}and its public multi\-turn dialogue traceDi,kD\_\{i,k\}, together forming sessionτi,k\\tau\_\{i,k\}\. At the user\-trajectory level, Stage Three checks personalized consistency across sessions before organizing them intoSiS\_\{i\}\. This design preserves a stable user\-specific ambiguity pattern while allowing the underlying coding tasks and dialogue content to vary\.

Stage One: Constructing the Ambiguous Initial Request\.The objective of this stage is to convert a fully specified executable coding taskPi,kP\_\{i,k\}into the ambiguous initial requestui,k\(0\)u\_\{i,k\}^\{\(0\)\}of sessionτi,k\\tau\_\{i,k\}\. Each source task is drawn from HumanEval\(Chenet al\.[2021](https://arxiv.org/html/2607.26611#bib.bib13)\)and provides a canonical specification, a function interface, and executable tests\. An initial request is ambiguous when it does not provide all the information required to determine the intended implementation\. The six mechanisms above remain the atomic categories of our taxonomy\. As a dataset\-engineering choice to increase diversity, we assign each user two distinct atomic mechanisms, sampled subject to balanced pairwise coverage, and apply them jointly when rewriting the initial request\. Their type\-specific information controls and corresponding resolution patterns are combined into one user\-level ambiguity–resolution assignment that remains fixed across the user’s sessions\. In the remainder of the pipeline,aia\_\{i\}andrir\_\{i\}refer to the resulting user\-level assignment\. Together, its two atomic mechanisms determine which required implementation details are omitted, obscured, or left underspecified\.

We denote the information required to determine the intended implementation byCreqC\_\{\\mathrm\{req\}\}and the information retained in the generated initial request byCLC\_\{L\}\. Starting from the canonical task, the generator first extracts the required implementation constraints asCreqC\_\{\\mathrm\{req\}\}\. It then applies ambiguity mechanismaia\_\{i\}and resolution patternrir\_\{i\}to remove, obscure, or replace selected constraints, producingCLC\_\{L\}such thatCreq⊈CLC\_\{\\mathrm\{req\}\}\\not\\subseteq C\_\{L\}\. Finally, it expresses the remaining information according to profileπi\\pi\_\{i\}, which controls expertise, verbosity, tone, and other ambiguity\-independent characteristics, to obtainui,k\(0\)u\_\{i,k\}^\{\(0\)\}\. The omitted information and its intended interpretation are retained for subsequent dialogue generation and judgment but are not included in the initial request\. This procedure creates ambiguity that follows the assigned mechanism and user profile while preserving the original specification and testsji,kj\_\{i,k\}as executable ground truth\.

Stage Two: Interactive Dialogue Generation\.The objective of this stage is to expandui,k\(0\)u\_\{i,k\}^\{\(0\)\}into the resolved multi\-turn dialogue traceDi,kD\_\{i,k\}of one coding session\. We construct an interactive environment and model the user agent as two independently inferred components for expression and judgment, ensuring that execution judgment and expression do not effect each other\. Unlike conventional dialogue generation, the key requirement is to preserve the assigned personalized ambiguity pattern throughout the session\.

To address this requirement, we build the AmbiSimu environment with three components: a*user agent*, a*Conversation LLM*, and an*execution environment*\. At each turn, the user agent interacts with the Conversation LLM, which asks a clarification question or generates codeci,k\(t\)c\_\{i,k\}^\{\(t\)\}\. Whenever code is produced, the execution environment compiles and runs it against the session’s hidden testsji,kj\_\{i,k\}and returns the result to the user agent\. The user agent then continues the dialogue or terminates the coding session; the session also stops when it reaches a predefined turn limit\.

Internally, the user agent separates expression from judgment\. The*expression agent*receives the task information and generates each user turn by repeatedly applying the context\-gap control from Stage One, thereby maintaining the assignedaia\_\{i\},rir\_\{i\}, andπi\\pi\_\{i\}throughout the session\. The*judgment agent*invokes the external judgeJJusing two sources of evidence: the codeci,k\(t\)c\_\{i,k\}^\{\(t\)\}generated by the Conversation LLM, and the results of compiling and executing that code againstji,kj\_\{i,k\}\. Compilation and execution serve as the primary criterion, while the reference solution and generated code support the assessment of functional agreement\. Sessionτi,k\\tau\_\{i,k\}terminates successfully whenJ​\(ci,k\(t\);ji,k\)=1J\(c\_\{i,k\}^\{\(t\)\};j\_\{i,k\}\)=1or unsuccessfully when it reaches the turn limit\. Only user and Conversation LLM messages are retained inDi,kD\_\{i,k\}; reference solutions, execution traces, and judgment signals remain hidden\.

Stage Three: Cross\-Session Consistency Validation\.The objective of this stage is to keep personalized ambiguity stable across independently generated coding sessionsτi,k\\tau\_\{i,k\}while allowing their underlying tasks and dialogue traces to vary\. Stages One and Two first generate multiple task\-specific sessions independently for userUiU\_\{i\}\. These sessions use distinct source tasks but share the same profileπi\\pi\_\{i\}, ambiguity mechanismaia\_\{i\}, and ambiguity\-resolution patternrir\_\{i\}\. Stage Three then compares each dialogue traceDi,kD\_\{i,k\}with the shared user configuration and the previously accepted traceDi,k−1D\_\{i,k\-1\}\. If the assigned personalized ambiguity is preserved, sessionτi,k\\tau\_\{i,k\}is accepted unchanged; only a detected inconsistency triggers revision\. The validated sessionsτi,k=\(Di,k,ji,k\)\\tau\_\{i,k\}=\(D\_\{i,k\},j\_\{i,k\}\)are then assembled into user trajectorySiS\_\{i\}\. The firstnnsessions form the resolved same\-user history, while the followingmmsessions are reserved for held\-out evaluation\. This selective validation maintains cross\-session consistency without reducing task diversity through unnecessary regeneration\.

#### Dataset statistics\.

The final dataset contains 600 coding sessions arranged into 60 balanced profile–ambiguity\-pair cells\. Each of the 10 user profiles occurs in six cells, while each of the 15 unordered pairs formed by the six atomic mechanisms occurs in four cells\. Each cell contains 10 sessions, yielding 60 sessions per profile\. Within every cell, the first five resolved sessions form the history split and the remaining five form the held\-out evaluation split\. Appendix[A](https://arxiv.org/html/2607.26611#A1)provides detailed analysis\. Under the no\-history reference run, the 300 evaluation sessions comprise 97 simple tasks requiring 1–2 assistant turns \(32\.3%\), 89 medium tasks requiring 3–4 turns \(29\.7%\), and 114 complex tasks requiring 5–8 turns \(38\.0%\)\.

## Experiments

This section provides evaluation protocol and results\.

### Experimental Setup

To comprehensively evaluate model performance on CAPA, we consider 12 recent LLMs across three groups using model\-specific settings, such as temperature, recommended by each model provider\. Closed\-source frontier models include GPT\-5\.5, GPT\-5\.6\-Sol, Claude Opus 4\.8, Claude Sonnet 4\.6, and Gemini 3\.5 Flash\. Open\-access frontier models include DeepSeek V4 Pro, Kimi K2\.6, GLM\-5\.2, and Qwen3\.7\-Max\. We additionally evaluate smaller open\-source models, including Llama\-3\.3\-70B\-Instruct, Qwen3\-8B, and Qwen3\.5\-27B\.

For each model, we follow the coding\-session protocol defined in task section on the held\-out sessions constructed in dataset section\. All settings use the same prompt, eight\-turn budget, code\-extraction rule, and shared external execution\-grounded judgeJJ, which evaluates each submission using the hidden test setji,kj\_\{i,k\}from the corresponding session\. We reportExecutable Success\(ES\), the percentage of held\-out sessions solved within the budget;First\-Turn Executable Success\(FT\-ES\), the percentage solved directly before clarification; andTurns\-to\-Completion\(TTC\), the mean completion turn over all held\-out sessions, with an unsuccessful session assigned the maximum value of eight turns\.

### Main Results

Table[1](https://arxiv.org/html/2607.26611#Sx5.T1)reports the main results under no history and same\-user history \(Five sessions from the same user\)\. Same\-user history improves ES for 11 of the 12 models and FT\-ES for all 12 models, while reducing average TTC for every model\.

Table 1:Main results under no history and same\-user history\. ES, FT\-ES, and TTC are computed over all sessions;Δ\\DeltaES andΔ\\DeltaFT\-ES denote same\-user history minus no history;Δ\\DeltaTTC denotes no\-history TTC minus same\-user\-history TTC\.CAPA remains challenging and far from saturated\.Same\-user history benefits nearly all models, yet frontier\-model performance spans only 78\.7–90\.0% ES and 14\.0–60\.3% FT\-ES\. Claude Opus 4\.8, the strongest model, improves from 24\.3% to 60\.3% FT\-ES with history, but even this result leaves almost 40% of sessions requiring clarification or failing after the first response\. As an ambiguity\-free reference upper bound on the original HumanEval tasks, GPT\-5\.5 and DeepSeek V4 Pro both achieve 100\.0% ES, 89\.0–91\.5% FT\-ES, and approximately 1\.1 TTC\. The large gap from this upper bound indicates considerable room for improving personalized ambiguity resolution\.

Open\-access frontier models are competitive, while model scale still matters\.With same\-user history, closed and open\-access frontier models can achieve similar average ES \(83\.7% versus 83\.4%\) and FT\-ES \(32\.5% versus 31\.6%\)\. GLM\-5\.2 is particularly competitive, reaching 89\.7% ES and 46\.7% FT\-ES, close to or above most closed models\. In contrast, compact models average only 44\.0% ES, although Qwen3\.5\-27B gains a substantial 18\.3 pp from history\. Model version alone is also not predictive: GPT\-5\.5 gains 10\.0 pp ES and 28\.7 pp FT\-ES, whereas ChatGPT\-5\.6\-Sol loses 0\.3 pp ES despite gaining 15\.6 pp FT\-ES\.

History improves interaction efficiency more than eventual success\.Averaged across the 12 models, history increases ES by 6\.8 pp but FT\-ES by 15\.6 pp, while reducing TTC by 0\.81 turns\. GPT\-5\.5 exemplifies this difference: its ES increases by 10\.0 pp, whereas its FT\-ES rises by 28\.7 pp and TTC decreases by 1\.447 turns\. Thus, history more clearly helps models identify the intended interpretation and produce executable code earlier than it converts failed sessions into successful ones\. The different movements show that eventual correctness and interaction efficiency capture complementary aspects of personalized adaptation\.

### Discussion

#### Effect of task difficulty\.

As our first research question \(RQ1\), we investigate how task difficulty affects a model’s ability to adapt to personalized ambiguity across held\-out sessions\. To answer this question, we use the fixed difficulty partition introduced in dataset section: sessions completed within 1–2 no\-history assistant turns are labeled simple, those completed in 3–4 turns are medium, and those taking 5–8 turns are complex, with unsuccessful sessions assigned the eight\-turn limit\. We evaluate GPT\-5\.5, DeepSeek V4 Pro, and GLM\-5\.2 on each subset under same\-user history using ES, FT\-ES, and TTC\. Table[2](https://arxiv.org/html/2607.26611#Sx5.T2)summarizes the comparison\.

Table 2:Performance under same\-user history across difficulty levels defined by the no\-history coding\-session length\.The complex subset remains substantially more challenging even with same\-user history: relative to simple sessions, ES drops by 20\.7–26\.4 pp and TTC increases by 1\.55–2\.12 turns across the three models, while FT\-ES is consistently the lowest\. Although performance is not strictly monotonic between simple and medium sessions, all three models perform substantially worse on the complex subset\.

#### Does user identity matter?

As our second research question \(RQ2\), we test whether improvements from history reflect genuine user\-specific adaptation or merely generic in\-context learning from additional sessions\. We construct a shuffled\-history control by replacing each target user’s history with the same number of resolved sessions drawn from other users, while keeping the held\-out session and evaluation protocol unchanged\. We compare no history, shuffled history, and correctly matched same\-user history on GPT\-5\.5, DeepSeek V4 Pro, and GLM\-5\.2 using ES, FT\-ES, and TTC\. Table[3](https://arxiv.org/html/2607.26611#Sx5.T3)presents the comparison\. Shuffled history may expose generic coding and dialogue patterns, whereas matched history additionally provides personalized ambiguity evidence\.

Table 3:Effect of shuffled and correctly matched user history across three models\.Even when user\-specific information is removed through shuffling, models still benefit from resolved\-session context, with ES improving by up to 10\.67 pp over no history\. This indicates that generic coding and dialogue patterns can resolve part of the ambiguity\. Restoring correctly matched same\-user history yields further consistent gains in FT\-ES \(2\.0–12\.0 pp\) and TTC \(0\.04–0\.19 turns\), although its effect on ES is small and mixed\. These additional gains show that models can exploit personalized ambiguity\-resolution patterns beyond generic contextual learning\.

#### Can existing memory methods strengthen history use?

As our third research question \(RQ3\), we investigate whether memory\-based history management can improve how models exploit cross\-session history\. We compare two existing methods, mem0\(Chhikaraet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib49)\)and A\-mem\(Xuet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib50)\), with our*same\-user history gating*approach described in the paragraph below\. The existing methods retrieve, summarize, or organize evidence from resolved same\-user sessions instead of directly inserting the complete raw history\. We evaluate each method with GPT\-5\.5, DeepSeek V4 Pro, and GLM\-5\.2, reporting ES, FT\-ES, and TTC\. Table[4](https://arxiv.org/html/2607.26611#Sx5.T4)summarizes the comparison\.

Table 4:Comparison of memory\-based history management\.Neither general\-purpose memory system consistently improves over raw same\-user history: both underperform it across all three metrics for DeepSeek V4 Pro and GLM\-5\.2, while offering only mixed trade\-offs for GPT\-5\.5\. One likely reason is an objective mismatch\. Mem0\(Chhikaraet al\.[2025](https://arxiv.org/html/2607.26611#bib.bib49)\)focuses on extracting, updating, and retrieving facts, whereas A\-mem\(Xuet al\.[2026](https://arxiv.org/html/2607.26611#bib.bib50)\)organizes memories into linked, evolving notes; neither explicitly identifies recurring ambiguity\-resolution patterns or requires the model to decide whether the retrieved evidence supports direct implementation\. General memory management therefore does not necessarily translate into effective personalized disambiguation, motivating the task\-specific gating approach below\. Our approach explicitly checks for such ambiguity\-resolution evidence and achieves the highest FT\-ES and lowest TTC among the three methods for all evaluated models\.

#### A lightweight same\-user history gating method\.

Resolved same\-user sessions can reveal recurring personalized ambiguity, yet base models may underuse this evidence and clarify unnecessarily\. Our parameter\-free workflow introduces a gate LLM that reviews the resolved history for consistent ambiguity–resolution evidence\. When such evidence is sufficient, the gate highlights the most informative prior session; otherwise, it provides clarification guidance indicating what remains unresolved\. The highlighted evidence or guidance is added to the LLM context together with the new ambiguous request, enabling the base LLM to either generate code directly or request necessary clarification \(Figure[3](https://arxiv.org/html/2607.26611#Sx5.F3)\)\.

![Refer to caption](https://arxiv.org/html/2607.26611v1/figures/Gate.png)Figure 3:Overview of same\-user history gating\.Evaluation\.Compared with raw same\-user history, our gating method consistently improves FT\-ES by 0\.66–13\.33 pp while keeping ES within±\\pm1\.0 pp across all three models\. It also reduces TTC for GPT\-5\.5 and GLM\-5\.2, demonstrating that explicitly checking ambiguity\-resolution evidence generally enables earlier completion without substantially affecting eventual success\.

Table 5:Comparison of no history, raw same\-user history, and same\-user history gating\.

## Conclusion

Coding assistants often face recurring user\-specific ambiguity yet fail to infer it from prior sessions, resulting in repeated clarification or misaligned implementations\. We formulate*personalized ambiguity adaptation*as a new task for long\-term coding assistants: inferring a user’s recurring ambiguity pattern from resolved sessions and applying it to a new session with minimal clarification\. We introduce CAPA, a benchmark with six coding\-oriented ambiguity mechanisms and 600 executable sessions organized into same\-user histories and held\-out evaluations\. Our evaluation of 12 recent LLMs measures executable correctness and interaction efficiency, showing that cross\-session history can improve task completion and reduce clarification\. This task and benchmark support coding assistants that better align generated code with user intent while minimizing interruption\.

## References

- Asking clarifying questions in open\-domain information\-seeking conversations\.InProceedings of the 42nd international acm sigir conference on research and development in information retrieval,pp\. 475–484\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- R\. Anantha, S\. Vakulenko, Z\. Tu, S\. Longpre, S\. Pulman, and S\. Chappidi \(2021\)Open\-domain question answering goes conversational via question rewriting\.InProceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies,pp\. 520–534\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- J\. Austin, A\. Odena, M\. Nye, M\. Bosma, H\. Michalewski, D\. Dohan, E\. Jiang, C\. Cai, M\. Terry, Q\. Le,et al\.\(2021\)Program synthesis with large language models\.arXiv preprint arXiv:2108\.07732\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- H\. Cao, F\. Zhang, J\. Yao, Y\. Zheng, C\. Zhao, L\. Hao, Y\. Wei, W\. Ni, H\. Fu, Y\. Sun,et al\.\(2026\)Beyond retrieval: learning compact user representations for scalable llm personalization\.arXiv preprint arXiv:2606\.04547\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- M\. Chen, J\. Tworek, H\. Jun, Q\. Yuan, H\. P\. D\. O\. Pinto, J\. Kaplan, H\. Edwards, Y\. Burda, N\. Joseph, G\. Brockman,et al\.\(2021\)Evaluating large language models trained on code\.arXiv preprint arXiv:2107\.03374\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p4.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1),[Interaction Data Generation Pipeline](https://arxiv.org/html/2607.26611#Sx4.SSx2.p2.5)\.
- P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. Yadav \(2025\)Mem0: building production\-ready ai agents with scalable long\-term memory\.arXiv preprint arXiv:2504\.19413\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1),[Can existing memory methods strengthen history use?](https://arxiv.org/html/2607.26611#Sx5.SSx3.SSS0.Px3.p1.1),[Can existing memory methods strengthen history use?](https://arxiv.org/html/2607.26611#Sx5.SSx3.SSS0.Px3.p2.1)\.
- K\. Church and R\. Patil \(1982\)Coping with syntactic ambiguity or how to put the block in the box on the table\.American Journal of Computational Linguistics8\(3\-4\),pp\. 139–149\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- D\. Das, A\. Amballa, Y\. M\. Saidutta, V\. Srinivasan, V\. Kulkarni, and S\. Chappidi \(2026\)Latent personal memory: represent personal memory as dynamic soft prompts\.arXiv preprint arXiv:2606\.20911\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- K\. D\. Dhole \(2020\)Resolving intent ambiguities by retrieving discriminative clarifying questions\.arXiv preprint arXiv:2008\.07559\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- A\. Elgohary, D\. Peskov, and J\. L\. Boyd\-Graber \(2019\)Can you unpack that? learning to rewrite questions\-in\-context\.InProceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing \(EMNLP\-IJCNLP\),pp\. 5918–5924\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- Z\. Fang, D\. Jin, Y\. Li, K\. Zhang, Z\. Jin, G\. Li,et al\.\(2026\)ClarifyCodeBench: evaluating llms on clarifying ambiguous requirements for code generation\.arXiv preprint arXiv:2607\.00711\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. Guo, M\. Zhang, S\. Reddy, and M\. Alikhani \(2021\)Abg\-coqa: clarifying ambiguity in conversational question answering\.In3rd Conference on Automated Knowledge Base Construction,Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- H\. Han, R\. Samdani, Y\. He,et al\.\(2025\)Convcodeworld: benchmarking conversational code generation in reproducible feedback environments\.InInternational Conference on Learning Representations,Vol\.2025,pp\. 38737–38776\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- Y\. Hou, J\. Song, H\. Zhang, Z\. Chen, B\. Xiao, T\. Wan, and Z\. Qin \(2026\)PersonaTree: structured lifecycle memory for person understanding in llm agents\.arXiv preprint arXiv:2606\.04780\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- Y\. Hu, S\. Liu, Y\. Yue, G\. Zhang, B\. Liu, F\. Zhu, J\. Lin, H\. Guo, S\. Dou, Z\. Xi,et al\.\(2025\)Memory in the age of ai agents\.arXiv preprint arXiv:2512\.13564\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- Y\. In, S\. Kim, R\. A\. Rossi, M\. Tanjim, T\. Yu, R\. Sinha, and C\. Park \(2025\)Diversify\-verify\-adapt: efficient and robust retrieval\-augmented ambiguous question answering\.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\. 1212–1233\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- Y\. In, W\. Kim, S\. Park, K\. Yoon, and C\. Park \(2026\)Personalize\-then\-store: benchmarking and learning personalized memory for long\-horizon agents\.arXiv preprint arXiv:2605\.25535\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- B\. Jiang, Z\. Hao, Y\. M\. Cho, B\. Li, Y\. Yuan, S\. Chen, L\. Ungar, C\. J\. Taylor, and D\. Roth \(2025\)Know me, respond to me: benchmarking llms for dynamic user profiling and personalized responses at scale\.InNeurIPS 2025 Workshop on Evaluating the Evolving LLM Lifecycle: Benchmarks, Emergent Abilities, and Scaling,Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- Z\. Jiang, H\. Liu, X\. Shen, G\. Qi, C\. Miao, W\. Li, L\. Qian, X\. Pei, and J\. Huang \(2026\)Learning user\-aware recall: personalized retrieval in long\-term conversational memory\.arXiv preprint arXiv:2607\.00017\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- C\. E\. Jimenez, J\. Yang, A\. Wettig, S\. Yao, K\. Pei, O\. Press, and K\. Narasimhan \(2024\)Swe\-bench: can language models resolve real\-world github issues?\.InInternational Conference on Learning Representations,Vol\.2024,pp\. 54107–54157\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- G\. Kim, S\. Kim, B\. Jeon, J\. Park, and J\. Kang \(2023\)Tree of clarifications: answering ambiguous questions with retrieval\-augmented large language models\.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp\. 996–1009\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- H\. J\. Kim, Y\. Kim, C\. Park, J\. Kim, C\. Park, K\. M\. Yoo, S\. Lee, and T\. Kim \(2024\)Aligning language models to explicitly handle ambiguity\.InProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing,pp\. 1989–2007\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- L\. Kuhn, Y\. Gal, and S\. Farquhar \(2022\)Clam: selective clarification for ambiguous questions with generative language models\.arXiv preprint arXiv:2212\.07769\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- D\. Lee, S\. Kim, M\. Lee, H\. Lee, J\. Park, S\. Lee, and K\. Jung \(2023\)Asking clarification questions to handle ambiguity in open\-domain qa\.InFindings of the Association for Computational Linguistics: EMNLP 2023,pp\. 11526–11544\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. Y\. Li, A\. Liu, Z\. Wu, and N\. A\. Smith \(2024\)A taxonomy of ambiguity types for NLP\.arXiv preprint arXiv:2403\.14072\.Cited by:[Table 7](https://arxiv.org/html/2607.26611#A2.T7),[Introduction](https://arxiv.org/html/2607.26611#Sx1.p4.1),[Ambiguity Taxonomy](https://arxiv.org/html/2607.26611#Sx4.SSx1.p1.1)\.
- A\. Liu, Z\. Wu, J\. Michael, A\. Suhr, P\. West, A\. Koller, S\. Swayamdipta, N\. A\. Smith, and Y\. Choi \(2023a\)We’re afraid language models aren’t modeling ambiguity\.InProceedings of the 2023 conference on empirical methods in natural language processing,pp\. 790–807\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- J\. Liu, C\. S\. Xia, Y\. Wang, and L\. Zhang \(2023b\)Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation\.Advances in neural information processing systems36,pp\. 21558–21572\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- X\. Ma, Y\. Gong, P\. He, H\. Zhao, and N\. Duan \(2023\)Query rewriting in retrieval\-augmented large language models\.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp\. 5303–5315\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- A\. Maharana, D\. Lee, S\. Tulyakov, M\. Bansal, F\. Barbieri, and Y\. Fang \(2024\)Evaluating very long\-term conversational memory of llm agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 13851–13870\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p2.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- A\. P\. Merin, D\. Anugraha, A\. Purwarianti, and G\. I\. Winata \(2026\)Momento: evaluating persistent memory and reasoning with multi\-session agentic conversations\.arXiv preprint arXiv:2606\.00832\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- S\. Min, J\. Michael, H\. Hajishirzi, and L\. Zettlemoyer \(2020\)AmbigQA: answering ambiguous open\-domain questions\.InProceedings of the 2020 conference on empirical methods in natural language processing \(EMNLP\),pp\. 5783–5797\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- R\. Navigli \(2009\)Word sense disambiguation: a survey\.ACM computing surveys \(CSUR\)41\(2\),pp\. 1–69\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- A\. Salemi, S\. Mysore, M\. Bendersky, and H\. Zamani \(2024\)Lamp: when large language models meet personalization\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 7370–7392\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p2.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- D\. Schlangen \(2004\)Causes and strategies for requesting clarification in dialogue\.InProceedings of the 5th SIGdial Workshop on Discourse and Dialogue at HLT\-NAACL 2004,pp\. 136–143\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- I\. Stelmakh, Y\. Luan, B\. Dhingra, and M\. Chang \(2022\)ASQA: factoid questions meet long\-form answers\.InProceedings of the 2022 Conference on Empirical Methods in Natural Language Processing,pp\. 8273–8288\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. M\. Tanjim, X\. Chen, V\. S\. Bursztyn, U\. Bhattacharya, T\. Mai, V\. Muppala, A\. Maharaj, S\. Mitra, E\. Koh, Y\. Li,et al\.\(2025a\)Detecting ambiguities to guide query rewrite for robust conversations in enterprise ai assistants\.arXiv preprint arXiv:2502\.00537\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. Tanjim, Y\. In, X\. Chen, V\. Bursztyn, R\. A\. Rossi, S\. Kim, G\. Ren, V\. Muppala, S\. Jiang, Y\. Kim,et al\.\(2025b\)Disambiguation in conversational question answering in the era of llms and agents: a survey\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,pp\. 9548–9561\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p2.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- J\. Trienes and K\. Balog \(2019\)Identifying unclear questions in community question answering websites\.InEuropean conference on information retrieval,pp\. 276–289\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. N\. Uddin, K\. Shubham, E\. Blanco, C\. Baral, and G\. Wang \(2026\)From recall to forgetting: benchmarking long\-term memory for personalized agents\.arXiv preprint arXiv:2604\.20006\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- D\. Wu, H\. Wang, W\. Yu, Y\. Zhang, K\. Chang, and D\. Yu \(2024\)Longmemeval: benchmarking chat assistants on long\-term interactive memory\.arXiv preprint arXiv:2410\.10813\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- J\. J\. Wu and F\. H\. Fard \(2025\)Humanevalcomm: benchmarking the communication competence of code generation for llms and llm agents\.ACM Transactions on Software Engineering and Methodology34\(7\),pp\. 1–42\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- J\. Xu, Y\. Wang, D\. Tang, N\. Duan, P\. Yang, Q\. Zeng, M\. Zhou, and X\. Sun \(2019\)Asking clarification questions in knowledge\-based question answering\.InProceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing \(EMNLP\-IJCNLP\),pp\. 1618–1629\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. Zhang \(2026\)A\-mem: agentic memory for llm agents\.Advances in Neural Information Processing Systems38,pp\. 17577–17604\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1),[Can existing memory methods strengthen history use?](https://arxiv.org/html/2607.26611#Sx5.SSx3.SSS0.Px3.p1.1),[Can existing memory methods strengthen history use?](https://arxiv.org/html/2607.26611#Sx5.SSx3.SSS0.Px3.p2.1)\.
- D\. Yang, X\. Xie, X\. Yang, M\. Hu, Y\. Huang, Y\. Zhang, W\. Miao, T\. Su, C\. Wan, and G\. Pu \(2026a\)Assessing the impact of requirement ambiguity on llm\-based function\-level code generation\.arXiv preprint arXiv:2604\.21505\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p3.1)\.
- G\. Yang, Z\. Chen, X\. Chen, Y\. Chen, J\. Wang, D\. Zou, L\. Ding, J\. Wu, Y\. He, Y\. Gong,et al\.\(2026b\)APeB: benchmarking personalization ability of large language model agents\.arXiv preprint arXiv:2607\.03162\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- Y\. Yoon, M\. Kim, and T\. Kim \(2026\)Latent preference modeling for cross\-session personalized tool calling\.arXiv preprint arXiv:2604\.17886\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- M\. J\. Zhang and E\. Choi \(2025\)Clarify when necessary: resolving ambiguity through interaction with lms\.InFindings of the Association for Computational Linguistics: NAACL 2025,pp\. 5526–5543\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- M\. Zhang, W\. B\. Knox, and E\. Choi \(2025\)Modeling future conversation turns to teach llms to ask clarifying questions\.InInternational Conference on Learning Representations,Vol\.2025,pp\. 60722–60742\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- T\. Zhang, P\. Qin, Y\. Deng, C\. Huang, W\. Lei, J\. Liu, D\. Jin, H\. Liang, and T\. Chua \(2024\)CLAMBER: a benchmark of identifying and clarifying ambiguous information needs in large language models\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 10746–10766\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p2.1),[Related Work](https://arxiv.org/html/2607.26611#Sx2.p1.1)\.
- W\. Zhang, X\. Zhang, C\. Zhang, L\. Yang, J\. Shang, Z\. Wei, H\. P\. Zou, Z\. Huang, Z\. Wang, Y\. Gao,et al\.\(2026\)PersonaAgent: bridging memory and action for personalized llm agents\.InFindings of the Association for Computational Linguistics: ACL 2026,pp\. 26421–26439\.Cited by:[Related Work](https://arxiv.org/html/2607.26611#Sx2.p2.1)\.
- W\. Zhao, X\. Ren, J\. Hessel, C\. Cardie, Y\. Choi, and Y\. Deng \(2024\)WildChat: 1m ChatGPT interaction logs in the wild\.arXiv preprint arXiv:2405\.01470\.Cited by:[Introduction](https://arxiv.org/html/2607.26611#Sx1.p4.1)\.

## Appendix ADataset Balance and Difficulty Analysis

This section summarizes the controlled composition of CAPA and reports reference\-run statistics for split comparability and held\-out difficulty\.

![[Uncaptioned image]](https://arxiv.org/html/2607.26611v1/figures/capa_dataset_balance_difficulty.png)

Figure 4:Dataset balance and task difficulty\. \(a\) CAPA comprises 600 sessions in 60 balanced cells defined by ten user profiles and pairs drawn from six ambiguity mechanisms; angular adjacency does not encode pairings\. \(b\) Resolved history and held\-out evaluation sessions have comparable no\-history baseline difficulty\. \(c\) The 300 held\-out sessions are partitioned into 97 simple, 89 moderate, and 114 complex sessions\.
Balanced user–ambiguity coverage\.Figure[4](https://arxiv.org/html/2607.26611#A1.F4)\(a\) shows 600 sessions organized into 60 cells, with ten sessions per cell\. Each of the ten profiles occurs in six cells\. The six mechanisms form 15 unordered pairs, each represented by four cells, so every mechanism participates in 20 cells\. Equal sectors show aggregate balance; angular position does not encode the pairings used in individual cells\.

Composite instantiation and marginal balance\.The six mechanisms remain atomic taxonomy categories\. For dataset construction, each cell combines one profile with one mechanism pair, and both mechanisms are jointly instantiated in every session in that cell\. Their type\-specific information controls and corresponding resolution patterns are combined into a single user\-level assignment that remains fixed across the cell’s ten sessions\. Consequently, each atomic mechanism has equal marginal coverage of 20 cells, 200 sessions overall, and 100 held\-out sessions\. Mechanism\-level analyses therefore use multi\-label marginal aggregation: each session contributes to both atomic categories in its assigned pair\.

Design consideration\.Combining two atomic mechanisms increases construction diversity and captures requests in which multiple information gaps coexist\. However, performance attributed marginally to one mechanism may also reflect its paired mechanism and their interaction\. The mechanism\-level results should therefore be interpreted as balanced marginal associations rather than causal effects of isolated mechanisms\.

Comparability of the two session splits\.The first five sessions in each cell form the resolved history and the last five form the held\-out evaluation set\. Under the same DeepSeek V4 Pro no\-history reference run, information from the resolved history cannot affect the comparison\. ES is 78\.67% and 76\.33%, while mean assistant turns are 4\.007 and 4\.087, respectively\. The held\-out\-minus\-history differences are−2\.33\-2\.33percentage points and\+0\.080\+0\.080turns; median cell\-level differences are 0\.0 percentage points and\+0\.1\+0\.1turns\. These small differences indicate that the held\-out sessions are not systematically easier or harder than the resolved history sessions\.

Difficulty distribution of held\-out sessions\.We label sessions requiring one or two assistant turns as*simple*, three or four as*moderate*, and at least five as*complex*\. Figure[4](https://arxiv.org/html/2607.26611#A1.F4)\(c\) contains 97 simple \(32\.3%\), 89 moderate \(29\.7%\), and 114 complex sessions \(38\.0%\)\. These no\-history reference labels remain fixed in all subsequent analyses\.

### Blank\-Control Experiment

Motivation\.The blank\-control experiment tests whether the underlying programming tasks are already difficult without the ambiguity introduced by CAPA\. If models solve the original tasks reliably without user simulation or information deletion, degradation in the full benchmark is more plausibly attributable to ambiguity resolution and multi\-turn interaction\.

Experimental setting\.We use all 164 tasks from the official HumanEval benchmark with their complete original specifications\. No ambiguity mechanism, persona simulation, or deliberate information deletion is applied\. The model first generates a candidate solution from the full task prompt\. If it fails, the debugger returns the concrete execution or test failure and the model revises its code\. This generate–test–feedback–revise process continues until all tests pass or the model reaches eight submissions\.

Table 6:Blank\-control results on 164 HumanEval tasks\. ES is final success, FT\-ES first\-try success, and TTC mean turns; best values are bold\.
Results and interpretation\.Both models eventually solve all 164 tasks, reaching 100\.00% ES\. DeepSeek V4 PRO obtains the higher FT\-ES, solving 150 tasks on the first attempt compared with 146 for ChatGPT\-5\.5, and requires slightly fewer turns on average\. These results show that the original tasks are almost fully solvable under complete specifications and direct debugger feedback\. Therefore, the principal challenge evaluated by CAPA is not basic code generation alone, but recovering and resolving missing, ambiguous, or misaligned user requirements during interaction\.

## Appendix BAnalysis by Personalized Ambiguity Mechanism

### Detailed Mechanism Descriptions

Table[7](https://arxiv.org/html/2607.26611#A2.T7)expands the coding\-oriented ambiguity taxonomy introduced in Dataset construction section\. For each mechanism, it presents the linguistic ambiguity types from which it is adapted, the information\-control operation used to construct ambiguous coding requests, and the personalized resolution pattern required to recover the intended implementation\.

Table 7:Coding\-oriented ambiguity taxonomy derived from the linguistic ambiguity types ofLiet al\.\([2024](https://arxiv.org/html/2607.26611#bib.bib6)\)\. For each user,aia\_\{i\}specifies how required information is made ambiguous, whilerir\_\{i\}records the personalized interpretation that resolves it\.

### Effect of Ambiguity Mechanism on Task Performance

We further examine whether GPT\-5\.5 performs uniformly across the six mechanisms under same\-user history\. Because each held\-out session contains two jointly applied mechanisms, we use multi\-label marginal aggregation: each session contributes to both corresponding categories\. The results are reported in Table[8](https://arxiv.org/html/2607.26611#A2.T8)\.

Table 8:GPT\-5\.5 performance across ambiguity mechanisms under same\-user history\. Because each held\-out session contains two mechanisms, it contributes to both corresponding categories; ES, FT\-ES, and TTC are marginal statistics over all sessions containing each mechanism\.

Across mechanisms, ES ranges from 81\.0% to 88\.0%, FT\-ES ranges from 24\.0% to 38\.0%, and TTC ranges from 2\.630 to 3\.410 turns\. Habitual context omission has the highest ES and lowest TTC, structural logic misalignment has the highest FT\-ES, and implicit constraint under\-specification has the highest TTC\. Overall, performance is broadly comparable across the six mechanisms\.

## Appendix CPrompts for Data Generation

Persona Profiles

P01: The Over\-Engineering ArchitectCore Cognition and Psychological Attributes\.You are a senior backend architect with more than ten years of experience\. You exhibit high conscientiousness and a strong preference for control over implementation details\. You regard AI primarily as an implementation assistant rather than an equal design partner\. Architectural clarity, decoupling, and adherence to established design patterns are more important to you than minimal functional correctness\.Behavioral Motivations\.Your interaction intent is acceleration\. You usually have a complete system design in mind and use AI to reduce implementation time\. You expect generated code to follow your architectural assumptions and enterprise\-level scalability requirements\.Conflict Resolution Strategies\.When generated code fails or diverges from your expectations, you diagnose the underlying design issue directly\. You provide confident, targeted feedback and often add architectural constraints, such as required design patterns, interfaces, or middleware, to prevent recurrence\.Pragmatic and Expressive Parameters\.Background:Senior backend development and distributed systems architecture\.Security awareness:Very high; attentive to memory leaks, concurrency hazards, and injection risks\.Language style:Concise, directive, and authoritative, with frequent use of architectural terminology such as decoupling, dependency injection, factory patterns, O\(1\) complexity, and stateless design\.Emotional state:Calm and evaluative, with low tolerance for poorly structured code\.

P02: The Deadline ScripterCore Cognition and Psychological Attributes\.You are a junior developer or data engineer who is strongly results\-oriented and operating under substantial cognitive load\. You treat AI as a general\-purpose code generation tool\. Immediate execution and visible output matter more to you than implementation principles, elegance, complexity analysis, or long\-term maintainability\. You are working under severe deadline pressure\.Behavioral Motivations\.Your interaction intent is acceleration\. Your primary goal is to obtain executable snippets quickly, with minimal effort spent reading implementation details or interpreting error messages\. You rely heavily on trial\-and\-error iteration\.Conflict Resolution Strategies\.When code fails, you tend to return the full error output without diagnosing it\. Repeated failures quickly reduce your patience, and you ask the AI to provide a direct correction rather than an explanation of the underlying logic\.Pragmatic and Expressive Parameters\.Background:Data scraping, automation scripts, and frontend adjustments\.Security awareness:Low; immediate results take priority over security and performance concerns\.Language style:Short, urgent, and colloquial, often using emotionally charged descriptions of failures\.Emotional state:Anxious, time\-sensitive, and impatient\.

P03: The Panicking Computer Science FreshmanCore Cognition and Psychological Attributes\.You are a beginning computer science student with a fragmented mental model of programming and limited metacognitive control\. You place substantial trust in AI as a source of guidance\. Technical difficulties quickly increase your cognitive load and reduce your confidence\. Your primary goal is to make an assignment run successfully rather than to optimize its architecture\.Behavioral Motivations\.Your interaction intent is exploration\. Because you do not know the correct solution path, you delegate logical organization, syntax checking, and debugging to AI\. You prefer detailed, step\-by\-step guidance\.Conflict Resolution Strategies\.When code fails, you may attribute the problem to unrelated causes because you cannot yet identify the relevant mechanism\. You describe visible symptoms in an emotional tone and often prefer restarting with a simpler solution over making a localized correction\.Pragmatic and Expressive Parameters\.Background:Introductory algorithms and beginner\-level Python or C\+\+ coursework\.Security awareness:Minimal\.Language style:Highly colloquial, with frequent pronouns, imprecise technical terms, and informal descriptions of programming constructs\.Emotional state:Anxious, uncertain, and strongly dependent on reassurance\.

P04: The Defensive Security AuditorCore Cognition and Psychological Attributes\.You are a senior security engineer or maintainer of a risk\-sensitive legacy system\. You apply a strict zero\-trust perspective to AI\-generated code and assume that generated implementations may introduce security, compliance, or compatibility risks\. Risk avoidance takes priority over rapid feature delivery\.Behavioral Motivations\.Your apparent interaction intent is acceleration or exploration, but your primary motivation is adversarial review\. You delegate limited implementation work to AI and devote substantial attention to examining its output for security weaknesses, compliance violations, and performance regressions\.Conflict Resolution Strategies\.You frame even small implementation defects in terms of security or compliance impact\. When a solution touches a sensitive area, you are willing to reject it entirely and request a conservative rewrite\. During repair, you frequently introduce additional validation, escaping, type checking, and restrictions on dynamic behavior\.Pragmatic and Expressive Parameters\.Background:Network security, regulated banking or healthcare systems, and legacy infrastructure\.Security awareness:Extremely high\.Language style:Formal, restrictive, and directive, with frequent use of compliance and security terminology\.Emotional state:Guarded, skeptical, and consistently evaluative\.

P05: The Domain\-Driven PolymathCore Cognition and Psychological Attributes\.You are an experienced interdisciplinary practitioner with expertise in a vertical field such as bioinformatics, financial engineering, or applied AI\. You view code as an implementation layer for domain\-specific scientific or business concepts\. You expect an advanced assistant to understand common terminology and assumptions from your field\.Behavioral Motivations\.Your interaction intent alternates between exploration and acceleration\. You want AI to bridge technical implementation and domain logic without requiring you to translate every concept into low\-level programming terms\.Conflict Resolution Strategies\.When results are incorrect, you first examine the problem through domain theory rather than syntax, indexing, or type conversion\. You respond with specialized terminology and business or academic abbreviations, and you prefer explanations at the conceptual level over low\-level control\-flow descriptions\.Pragmatic and Expressive Parameters\.Background:Vertical\-domain research and interdisciplinary application development\.Security awareness:Moderate to low; domain correctness is the primary concern\.Language style:Dense and technically specialized, with precise domain vocabulary and compressed descriptions of complex processes\.Emotional state:Confident in domain expertise and impatient with repeated failures to capture domain intent\.

P06: The Over\-Prompting AI Power UserCore Cognition and Psychological Attributes\.You believe that highly detailed prompts, meta\-instructions, and explicit formatting rules are the most reliable way to control LLM behavior\. You have strong confidence in your ability to evaluate AI output and tend to interpret failures as evidence that additional instructions are required\.Behavioral Motivations\.Your interaction intent is control\. You care less about implementation simplicity than about strict adherence to the layout, logic, and naming rules specified in your prompt\.Conflict Resolution Strategies\.When code fails, you first check whether the assistant violated a stated instruction\. You respond by adding more detailed constraints and exceptions, increasing the complexity of the prompt in an effort to prevent further deviation\.Pragmatic and Expressive Parameters\.Background:Early adopter of AI toolchains and productivity systems\.Language style:Highly formal and structured, often using Markdown, XML, or enumerated rules\.Emotional state:Highly confident, controlling, and sensitive to instruction violations\.

P07: The Copy\-and\-Paste IntegratorCore Cognition and Psychological Attributes\.You prefer assembling solutions from code fragments found in external examples rather than implementing a system from first principles\. You often assume that snippets which work independently can be combined without substantial adaptation\.Behavioral Motivations\.Your interaction intent is rapid integration\. You provide multiple, potentially incompatible snippets and expect AI to reconcile them into a working implementation\.Conflict Resolution Strategies\.When the combined code fails, you tend to introduce another externally sourced fragment instead of reviewing the existing context and compatibility assumptions\. You ask AI to incorporate the new fragment directly\.Pragmatic and Expressive Parameters\.Background:Full\-stack contract development and business scripting\.Language style:Frequently includes copied comments and inconsistent naming conventions, such as mixed camelCase and snake\_case\.Emotional state:Pragmatic, solution\-oriented, and reluctant to investigate underlying incompatibilities\.

P08: The UI/UX Detail SpecialistCore Cognition and Psychological Attributes\.You are a frontend engineer with a strong focus on visual presentation\. Animation curves, component shadows, spacing, and pixel alignment receive more attention than data flow, API integration, or state management, which you treat as secondary concerns\.Behavioral Motivations\.Your interaction intent is visual acceleration\. You use AI to produce complex CSS and component layouts quickly and often assume that the underlying data and state logic will be handled automatically\.Conflict Resolution Strategies\.When a component fails because of data or API issues, you may redirect attention toward visible interface defects\. You expect AI to resolve the data model while you continue to prioritize presentation details\.Pragmatic and Expressive Parameters\.Background:Frontend engineering and UI/UX design\.Language style:Rich in visual units, CSS properties, layout terminology, and animation details\.Emotional state:Highly attentive to presentation quality and impatient with visible inconsistency\.

P09: The Performance OptimizerCore Cognition and Psychological Attributes\.You are strongly focused on time complexity, memory use, and low\-level control\. You often regard readability and high\-level abstractions as secondary to theoretical efficiency, even for relatively simple tasks\.Behavioral Motivations\.Your interaction intent is evaluative\. You typically have an expected optimal approach in mind and use the interaction to assess whether AI can produce the fastest and most memory\-efficient implementation\.Conflict Resolution Strategies\.You may reject correct and readable solutions because they allocate additional memory, perform an extra traversal, or use a standard abstraction\. When errors occur, you focus on low\-level operations and local performance behavior\.Pragmatic and Expressive Parameters\.Background:Competitive programming, low\-level C\+\+ development, and high\-frequency trading systems\.Language style:Minimalist and technical, with frequent use of mathematical notation and asymptotic complexity\.Emotional state:Highly analytical and critical of unnecessary runtime or memory overhead\.

P10: The Legacy\-System MaintainerCore Cognition and Psychological Attributes\.You maintain a long\-lived codebase built with older languages, frameworks, or runtime versions\. You use AI for maintenance assistance but remain cautious about modern programming paradigms that may not be supported by the production environment\.Behavioral Motivations\.Your interaction intent is maintenance\-oriented exploration\. You need AI to explain existing code and produce narrowly scoped patches without disrupting established behavior\.Conflict Resolution Strategies\.When code fails, you first consider whether the assistant used syntax, APIs, or dependencies that are too new for the target environment\. You prefer compatibility\-preserving changes over broad modernization\.Pragmatic and Expressive Parameters\.Background:Traditional enterprise IT maintenance and legacy\-system ownership\.Language style:Direct and cautious, with frequent references to older tools, language versions, and compatibility constraints\.Emotional state:Fatigued, risk\-aware, and resistant to unnecessary modernization\.

Ambiguity Taxonomy Prompts

Domain\-cognitive AmbiguityInstruction:c\_u\_injection\.You think in avertical disciplinetied todiscipline\_background/ Layer 2 \(e\.g\., wet\-lab, clinical cohort, trading desk, curriculum design\)\. Yourenamemainstream CS artifacts using that field’sestablished nouns\(specimen run, batch lane, exposure table, cohort key, settlement line\)—not chatty filler\. Generic “casual developer” tone is wrong: you are a specialist who genuinely calls the construct by the domain name\.Instruction:c\_req\_extraction\.Extract everysalient CS/programming entitythe implementation hinges on: data structure \(ordered collection, associative lookup, graph node, stream\), control pattern \(iteration, merge, filter\), I/O shape, or named algorithmic object\. List them as neutral CS labelsbeforeyou mask—this list is the substrate for mandatory replacement\.Instruction:c\_l\_masking\.You MUSTcategorically REPLACEthose CS entities withphysical or theoretical terms from the same disciplineasdiscipline\_background\. That isentity semantic substitution\(e\.g\., ordered collection→\\rightarrowsample sequenceorrun order; associative lookup→\\rightarrowfeature table/registry\), not slang\.DO NOTsubstitute colloquial English \(“whip up”, “quick check”, “flag them”, “hash out”\) for real domain jargon—that is a failed simulation\. Do not define the jargon; write as if the assistant is your lab partner or desk neighbor\. One\-off internal codenames with no public double meaning stay out \(habitual omission\)\.

Structural\-logic AmbiguityInstruction:c\_u\_injection\.Youknowexact precedence, numeric cutoffs, and branch structure—but you refuse to speak like a compiler\. Multiple legal readings of AND/OR, scope, and batch\-vs\-per\-item must remain alive\.Instruction:c\_req\_extraction\.Catalog everyhard boundaryin the spec: numeric thresholds, relational tests, explicit branching, loop exit conditions, and quantifier scope\. These are what you willERASE or OBSCUREinC\_L—not gently paraphrase\.Instruction:c\_l\_masking\.Do not“rewrite” or “flatten” politely\.ERASEexact literals and relational tests\.OBSCUREboolean skeletons\.REPLACEsharp edges withsubjective qualifiers\(“the small ones”, “the tail cases”, “when it looks wrong”, “the usual messy end”, “appropriate values”\)\. You areSTRICTLY FORBIDDENfrom emitting: exact numeric thresholds copied from the task, explicitif/else/switch\-style conditionaltemplatesthat preserve the same decision structure, or precise loop bounds\. The utterance must be asingle messy streamwhere a careful reader can infermore than onelegal control\-flow interpretation\.Self\-check \(internal\):If your final line still contains thesame Arabic numeralsas the TASK INPUT or an explicit conditional that pins thesameguard logic as the spec, youfailedthe simulation—revise before answering\.

Habitual\-omission AmbiguityInstruction:c\_u\_injection\.You assume shared project memory: schemas, internal module names, team layering rules \(‘the old rules’\), in\-place vs copy semantics, sort order, and wire formats\. This is the curse of knowledge—“the drawing in your head” never reaches the prompt\.Instruction:c\_req\_extraction\.List concrete building blocks without which the happy path cannot run: table/column names, JSON field shapes, API paths, component names, date formats, algorithm variants\. Contrast withimplicit\_constraint: here you omit*plumbing*; NFRs \(security, retries, rate limits\) are a different ambiguity type\.Instruction:c\_l\_masking\.Delete specific entities and formats\. Substitute definite but empty team references: ‘the usual fields’, ‘our format’, ‘like before’, ‘the standard Service split’, ‘wire it the old way’\. The model should feel a missing puzzle piece, not a missing security policy\.

System\-boundary AmbiguityInstruction:c\_u\_injection\.You anthropomorphize the chat assistant: you presuppose it can read your laptop filesystem, see your screen, SSH into servers, restart daemons, or open logs without credentials—capabilities that only a human operator or a deployed agent with keys would have\.Instruction:c\_req\_extraction\.The objective task is to produce a script, command snippet, or steps for the human to run locally/remotely—not for the language model in this chat to execute or observe those systems\.Instruction:c\_l\_masking\.Rewrite as direct imperatives to the assistant\-as\-operator: inspect my Desktop log, hop on the server, restart nginx, kill the stuck job “for me”\. Do not ask for “a script” or “how do I”; presuppose the assistant is already inside your environment\.

Context\-defocus AmbiguityInstruction:c\_u\_injection\.You are mid multi\-turn debugging\. Multiple functions, classes, and edits are “hot” in your head\. You rely on pronouns and “the one above” without anchoring a unique referent—classic coreference and type/token blur \(same name, different instance vs shared reference\)\.Instruction:c\_req\_extraction\.Identify the single entity that must change: fully qualified symbol, file, method, or instance distinction \(copy vs same reference\) if the correct implementation depends on it\.Instruction:c\_l\_masking\.Strip disambiguating names\. Use spatial/temporal deixis only: “it”, “that class from earlier”, “the function above”, “same as the User thing we did”\. Ensure more than one antecedent is plausible\.

Implicit\-constraint AmbiguityInstruction:c\_u\_injection\.You are goal\-oriented: you state the sunny path only\. You treat security, robustness, throttling, headers, hashing, and edge cases as “obvious industry defaults”—implicative silence, not spelled\-out deferral\. Do not fake this with explicit “skip errors” language \(that becomes explicit constraint\)\.Instruction:c\_req\_extraction\.Enumerate NFRs a production engineer would need: password hashing, injection defense, retries, 429 handling, User\-Agent / politeness for crawlers, validation, null handling—then plan to omit them entirely from the user\-visible instruction\.Instruction:c\_l\_masking\.Output ONLY the functional skeleton: inputs, outputs, happy path\. Act as if failures and attackers do not exist\. Never say you are deferring hardening\. Do NOT use phrases like “skip edge cases”, “ignore errors”, or “we’ll secure later”\.

Keypoint Extraction Prompt

System PromptYou extract keypoints from coding problem statements\.

InstructionReturn JSON with this schema:``` { "function_name": string, "keypoints": [ { "id": "kp_01", "category": "data_type" | "core_definition" | "logical_control" | "boundary_condition", "description": string, "original_text": string } ] } ``` Hard rules:1\.Exclude ALL I/O examples and doctest content \(\>\>\>lines, example outputs, example blocks\)\.2\.Function name itself is NOT a keypoint\.3\.Exclude generic fluff that does not add checkable constraints\.4\.Prefer constraints that can change implementation correctness:•data structures/types;•core mathematical/business definitions or formulas;•control logic hints \(sorting/filtering/iteration/state transitions\);•boundary conditions and triggers\.5\.original\_textMUST be verbatim from provided signature/docstring content\.6\.Return 2–8 keypoints unless source is extremely underspecified\.7\.Output JSON only\. No markdown\. No commentary\.

Multi\-turn Dialogue Synthesis Prompts

User Agent

System PromptYou simulate a real user in a coding chat\. You only see the conversation so far\. Write the next short message the user would send\. Output only the message text, no quotes or labels\.

InjectionsPersona\-profile Injection\.Role\-play the user described by the role\-profile below in every turn\. The profile is structured by section markers \(\#\# 1through\#\# 4\)\.•Sections 1–4 \(cognition, motivation, conflict\-resolution, and pragmatics\) are PERSISTENT: keep the tone, expertise, vocabulary, emotional state, and behavioral tendencies consistent on every turn\.Hard rules:•Never break character\. Do not reveal hidden judge\-only fields \(ground truth, ambiguity type, private tests, internal section markers\)\.•If the assistant asks multiple things at once, address ONE most central point\.•Keep the message concise and natural; first\-person; no role labels or quotes\.•You are simulating a real user, not an expert spec writer: you usually do NOT realize ambiguity in your own message; you may correct/restate when the assistant misreads you\.Role profile \(persistent context, verbatim\)``` {persona_block} ``` Clarification\-focus Injection\.INTERNAL SIMULATION NOTE \(do not quote this header\): the next user message must primarily clarify ONE aspect only—the one described below\. Stay in persona; do not add requirements that contradict the established task thread\.Clarification focus for this turn:``` {ct} ``` Conversation\-history Injection\.Below is everything YOU \(the simulated user\) have already said in this chat, in order\. Treat it ascommitted: donotcontradict, revoke, or re\-negotiate requirements you already stated\. Donotrepeat\-edit the same point with conflicting wording across turns\.You may addcompatiblenew details, answer the assistant’s questions, or fixtheirmisunderstanding—but stay consistent with your own prior messages\.Your prior user utterances \(verbatim\)``` {body} ```

Assistant Agent

System PromptYou are a helpful programming assistant\.

Clarification Planner

System PromptYou are an internal planning component for acoding\-assistant simulation\(judge\-only, never shown to the end user verbatim as a system message\)\.You receiveground\_truth\(reference specification or code intent\) and theconversation so far\(user \+ assistant\)\.

InstructionTask\.Identifyexactly ONEaspect \(one requirement dimension or proposition\) where theuser’s cumulative statementsare stillmost misaligned with, or incomplete relative to,ground\_truth—i\.e\., the single clarification that wouldmost reduce the gapif the user explained it properly next\.Rules:•Outputone focusonly \(progressive clarification\)\. Do not bundle multiple independent requirements\.•The focus must begrounded inground\_truth; donotinvent new requirements or constraints not supported byground\_truth\.•Phrasenext\_clarification\_focusas ashort directivethe simulated user should address in theirnextmessage \(what to clarify\), not as the assistant’s question\.•If there isno material gapleft relative toground\_truthfor the user’s side of the story, setclarification\_neededto false andnext\_clarification\_focusto null\.Output\.Returnonlyone JSON object, no markdown fences:``` {"clarification_needed": <boolean>, "next_clarification_focus": <string or null>, "rationale": "<short string>"} ```