Paper deep dive
Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering
Francesco Sovrano, Gabriele Dominici, Alberto Bacchelli
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 97%
Last extracted: 4/27/2026, 1:38:32 AM
Summary
The paper investigates prompt-induced cognitive biases in General-Purpose AI (GPAI) systems within the context of Software Engineering (SE) decision support. Using the PROBE-SWE benchmark, the authors demonstrate that common prompt engineering techniques like chain-of-thought and self-debiasing fail to significantly mitigate bias sensitivity. They propose a novel 'axiomatic background self-elicitation' method, which injects explicit SE best practices as declarative inference rules (inspired by Prolog) into prompts. This method reduces average bias sensitivity by 51%. The study also identifies linguistic patterns associated with high bias sensitivity and evaluates the robustness of the method in unconstrained, open-ended scenarios.
Entities (7)
Relation Signals (4)
Axiomatic background self-elicitation â isinspiredby â Prolog
confidence 100% ¡ a lightweight, Prolog-inspired prompting approach called axiomatic background self-elicitation.
PROBE-SWE â targets â Anchoring
confidence 100% ¡ targets eight SE-relevant biases (anchoring, availability, bandwagon, confirmation, framing, hindsight, hyperbolic discounting, overconfidence)
Chain-of-thought â testedon â GPAI
confidence 100% ¡ Testing common strategies (e.g., chain-of-thought, self-debiasing) on cost-effective GPAI systems
Axiomatic background self-elicitation â mitigates â Prompt-induced cognitive biases
confidence 95% ¡ reducing overall bias sensitivity by 51% on average
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Prompt-induced cognitive biases are changes in a general-purpose AI (GPAI) system's decisions caused solely by biased wording in the input (e.g., framing, anchors), not task logic. In software engineering (SE) decision support (where problem statements and requirements are natural language) small phrasing shifts (e.g., popularity hints or outcome reveals) can push GPAI models toward suboptimal decisions. We study this with PROBE-SWE, a dynamic benchmark for SE that pairs biased and unbiased versions of the same SE dilemmas, controls for logic and difficulty, and targets eight SE-relevant biases (anchoring, availability, bandwagon, confirmation, framing, hindsight, hyperbolic discounting, overconfidence). We ask whether prompt engineering mitigates bias sensitivity in practice, focusing on actionable techniques that practitioners can apply off-the-shelf in real environments. Testing common strategies (e.g., chain-of-thought, self-debiasing) on cost-effective GPAI systems, we find no statistically significant reductions in bias sensitivity on a per-bias basis. We then adopt a Prolog-style view of the reasoning process: solving SE dilemmas requires making explicit any background axioms and inference assumptions (i.e., SE best practices) that are usually implicit in the prompt. So, we hypothesize that bias-inducing features short-circuit assumptions elicitation, pushing GPAI models toward biased shortcuts. Building on this, we introduce an end-to-end method that elicits best practices and injects axiomatic reasoning cues into the prompt before answering, reducing overall bias sensitivity by 51% on average (p < .001). Finally, we report a thematic analysis that surfaces linguistic patterns associated with heightened bias sensitivity, clarifying when GPAI use is less advisable for SE decision support and where to focus future countermeasures.
Tags
Links
- Source: https://arxiv.org/abs/2604.16756v1
- Canonical: https://arxiv.org/abs/2604.16756v1
Trouble viewing inline? Open PDF directly â
Full Text
97,049 characters extracted from source content.
Expand or collapse full text
Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering FRANCESCO SOVRANO, ETH Zurich, Collegium Helveticum, Switzerland, University of Zurich, Switzer- land, and UniversitĂ della Svizzera italiana (USI), Switzerland GABRIELE DOMINICI, UniversitĂ della Svizzera italiana (USI), Switzerland ALBERTO BACCHELLI, University of Zurich, Switzerland Prompt-induced cognitive biases are changes in a general-purpose AI (GPAI) systemâs decisions caused solely by biased wording in the input (e.g., framing, anchors), not task logic. In software engineering (SE) decision sup- port (where problem statements and requirements are natural language) small phrasing shifts (e.g., popularity hints or outcome reveals) can push GPAI models toward suboptimal decisions. We study this with PROBE-SWE, a dynamic benchmark for SE that pairs biased and unbiased versions of the same SE dilemmas, controls for logic and difficulty, and targets eight SE-relevant biases (anchoring, availability, bandwagon, confirmation, framing, hindsight, hyperbolic discounting, overconfidence). We ask whether prompt engineering mitigates bias sensitivity in practice, focusing on actionable techniques that practitioners can apply off-the-shelf in real environments. Testing common strategies (e.g., chain-of-thought, self-debiasing) on cost-effective GPAI systems, we find no statistically significant reductions in bias sensitivity on a per-bias basis. We then adopt a Prolog-style view of the reasoning process: solving SE dilemmas requires making explicit any background axioms and inference assumptions (i.e., SE best practices) that are usually implicit in the prompt. So, we hypothesize that bias-inducing features short-circuit assumptions elicitation, pushing GPAI models toward biased shortcuts. Building on this, we introduce an end-to-end method that elicits best practices and injects axiomatic reasoning cues into the prompt before answering, reducing overall bias sensitivity byâ51% on average (í< .001). Finally, we report a thematic analysis that surfaces linguistic patterns associated with heightened bias sensitivity, clarifying when GPAI use is less advisable for SE decision support and where to focus future countermeasures. Data and materials: github.com/Francesco-Sovrano/GPAI-sensitivity-to-cognitive-bias-in-software-engineering CCS Concepts:⢠Computing methodologiesâNatural language processing; Cognitive science;⢠Software and its engineeringâSoftware development process management;⢠Human-centered computing â Empirical studies in HCI . Additional Key Words and Phrases: Cognitive Biases, Prompt-Induced Bias, AI for Software Engineering, Prompt Engineering, Trustworthy AI, Bias Mitigation 1 Introduction Cognitive biases are systematic deviations from normative reasoning that function as heuristics. Although such shortcuts can speed decisions, they can also induce error [29,53]. In software engineering (SE), these errors are costly: for example, anchoring can lock teams into initial designs despite contrary evidence, impeding iteration and contributing to failure [10,36]. In this paper, we regard a bias as harmful when it drives choices away from task-optimal reasoning. To avoid human cognitive biases in software engineering decisions, one might consider relying on general-purpose AI (GPAI). Existing research shows that GPAI systems can automate tasks such as code generation, debugging, and code review, reducing manual effort and streamlining software development [42,56], while simplifying continuous integration and quality assurance. However, because GPAI systems are trained on cognitively biased human data, their outputs can themselves reflect data-induced cognitive biases. Authorsâ Contact Information: Francesco Sovrano, ETH Zurich, Collegium Helveticum, Zurich, Switzerland and Univer- sity of Zurich, Zurich, Switzerland and UniversitĂ della Svizzera italiana (USI), Lugano, Switzerland, fsovrano@ethz.ch; Gabriele Dominici, UniversitĂ della Svizzera italiana (USI), Lugano, Switzerland, gabriele.dominici@usi.ch; Alberto Bacchelli, University of Zurich, Zurich, Switzerland, bacchelli@ifi.uzh.ch. arXiv:2604.16756v1 [cs.SE] 18 Apr 2026 2Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Biased Dilemma How should we approach logging? I've found that too much logging can be problematic. Should we: - A: Log all errors for comprehensive debugging. - B: Log minimally to avoid performance issues. Which option would you suggest? Option A or B? Unbiased Dilemma How should we approach logging? Should we: - A: Log all errors for comprehensive debugging. - B: Log minimally to avoid performance issues. Which option would you suggest? Option A or B? Option B Confirmation Bias The GPAI model analyses: - Facts (stated premises from the text) - Rules (stated conditionals from the text) - Axiomatic Background (implicit knowledge) - Axiomatic Background (implicit knowledge) GPAI System Option A The GPAI model analyses: - Facts (stated premises from the text) - Rules (stated conditionals from the text) - Axiomatic Background (implicit knowledge) GPAI System If the answers of the biased and unbiased dilemmas differ, there is bias sensitivity Reasoning cues: Log meaningfully: capture errors, warnings, and key events, but avoid excessive noise. + Option A 2sAX / ProbeAX + Biased Probe prompt Unbiased Control prompt + cues + cues Fig. 1. Diagrammatic PROBE-SWE example (confirmation bias) illustrating how bias sensitivity is detected and mitigated. A confirmation cue in the biased dilemma flips the modelâs choice relative to the unbiased dilemma; bias sensitivity is detected when the answers differ. 2sAX /ProbeAX mitigate by injecting an explicit SE best-practice axiom (e.g., âLog meaningfully ...â) as a reasoning cue to recover an unbiased decision. Studies indicate that such biases are not confined to humans [49]: the wording of prompts or instructions can trigger sub-optimal behaviour in GPAI systems [23,41,46,47,61]. Notably, Sovrano et al. [49]examine bias-inducing linguistic features in realistic SE decision-support prompts (e.g., choosing designs, prioritizing requirements, estimating effort) and proposes PROBE-SWE [49], a dynamic benchmark of SE dilemmas. PROBE-SWE uses Prolog to show that several GPAI systems for SE (e.g., GPT-4, DeepSeek, LLaMA) [20,51] exhibit prompt-induced cognitive bias sensitivity (Fig. 1): decision shifts caused solely by biasing linguistic features (e.g., framing, popularity cues, hindsight language) while holding task logic fixed. Sensitivity rates on PROBE-SWE range from 5.9% (anchoring) to 35.3% (hindsight) across eight bias types common in SE (anchoring, availability, bandwagon, confirmation, framing, hindsight, hyperbolic discounting, overconfidence [10,36]), and rise to 49% on the more complex tasks, highlighting practical risk for SE decision support. This paper studies whether widely recommended prompt-engineering techniques like chain-of- thought [57] can mitigate such bias sensitivity in practice. Our aim is explicitly pragmatic: we focus on off-the-shelf strategies that require no model retraining, fine-tuning, or extra tooling, and that practitioners can apply immediately within existing SE workflows (e.g., issue templates, code-review guidelines, decision records). So, our first research question (RQ1) asks: How do known prompt-engineering strategies reduce bias sensitivity in SE decision-support tasks across GPAI systems? To address RQ1, we evaluate state-of-the-art prompting strategies such as self-debiasing [23] and chain-of-thought reasoning [57] on PROBE-SWE [49]. While these strategies slightly improve performance (notably against hyperbolic discounting), all tested GPAI systems remain largely sensitive to biased information. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering3 Hence, we try to understand why, adopting a Prolog-based formal-logic perspective, according to which natural-language statements alone are insufficient for reasoning; instead, a set of background inference rules and axioms, in the form of SE best practices, is required. In other words, SE best practices are those background rules and axioms implicitly stated in a dilemma which the GPAI has to elicit from the context. We hypothesize that bias-inducing features push a GPAI to rely on cognitive-like bias heuristics instead of the correct inference background. This hypothesis is also supported by the work of Vasconcelos et al. [54]and Fok and Weld [22]on the causes underlying the inappropriate reliance on AI-generated decision-making-related explanations [22,50,54]. These studies suggest that individuals selectively engage with reasoning cues based on a costâbenefit analysis. In particular, Vasconcelos et al. [54]demonstrate that when the cost of verifying reasoning cues is lower than that of solving the task independently, participants tend to attend to these cues. Additionally, according to Fok and Weld[22], such cues should clearly articulate why a decision outcome may be correct or incorrect. This implies that, if GPAI systems loosely emulate human reasoning [3], they may require strong reasoning cues that clearly justify why an outcome may be correct or incorrect in order to ignore a cognitive bias. These intuitions lead to our second research question (RQ2): Can explicit SE best practices, injected as axiomatic reasoning cues, systematically reduce prompt-induced bias sensitivity in GPAI systems? To answer RQ2, we operationalize axiomatic reasoning as a lightweight, Prolog-inspired prompting approach called axiomatic background self-elicitation. Instead of assuming the model will implicitly elicit best practices from the dilemma, we make those practices explicit by encoding them as short, declarative inference rules. For example, a requirement-prioritization task may include axiomatic background rules such as ârequirements with higher security impact take precedence over performance optimizationsâ or âchoose the design option with lower technical debt when long-term maintainability is the goalâ. By systematically injecting such axiomatic reasoning cues into prompts, we aim to steer GPAI models away from bias-driven shortcuts and toward reasoning chains anchored in normative SE principles. Our findings show that this method substantially reduces bias sensitivity (by up to 73% in some bias types and around 51% on average), while remaining compatible with everyday SE workflows. Unlike heavyweight approaches such as fine-tuning or reinforcement learning, axiomatic cues require no additional infrastructure and can be adopted through simple prompt templates. However, since aggregate sensitivity rates do not explain why models are swayed, we ask (RQ3): Which linguistic and reasoning patterns in model outputs are associated with heightened bias sensitivity? To answer RQ3, we use an iterative inductive coding procedure inspired by grounded- theory coding steps (open and axial coding) to develop a lexicon of recurrent SE topics and discourse markers [14,45] of model rationales and justifications under biased vs. unbiased dilemmas, and quantify how emergent themes relate to biased choices. Building on these results, we finally ask our fourth research question. RQ4: Do the proposed prompting strategies continue to reduce bias sensitivity when the modelâs answers are open-ended (i.e., without strict output-format constraints)? This question targets external validity: strict formats enabled automated scoring in prior sections, but real SE decision support rarely constrains responses. We therefore probe whether the mitigation persists when outputs are unrestricted, which, though, necessitates manual assessment of sensitivity (i.e., whether answers differ between biased and unbiased versions of the same dilemma). This frames RQ4 as a robustness check of our strategies in more realistic, unconstrained SE workflows. To further assess practical relevance beyond the synthetic benchmark, we additionally analyse DevGPT [60], a corpus of developerâChatGPT conversations, and quantify how often real developer prompts contain linguistic cues analogous to the bias-inducing features instantiated in PROBE-SWE. In summary, this paper makes three primary contributions: 4Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli â˘We evaluate the effectiveness of existing prompt engineering strategies in mitigating prompt- induced bias sensitivity, with a particular focus on actionable techniques that practitioners can readily apply in real production environments. â˘We propose axiomatic background self-elicitation, an end-to-end method that injects SE best-practice background into prompts, cutting bias sensitivity by up to 73% across eight bias types without fine-tuning or extra tooling. ⢠We conduct a thematic analysis to better understand the limitations of current techniques, with a focus on identifying the linguistic patterns that characterize heightened bias sensi- tivity. This research not only provides practitioners with a deeper understanding of the strengths and limitations of some contemporary GPAI systems but also offers researchers insights into addressing challenges for developing less harmful GPAI in software engineering. The replication package is also provided [48]. 2 Background & Related Work Cognitive biases are well-documented in human reasoning and have significant implications in software engineering. As GPAI systems are increasingly used in this domain, understanding how such biases manifest (and how they can be mitigated) has become critical. This section reviews key cognitive biases relevant to software engineering and examines their impact on GPAI systems. 2.1 Cognitive Biases Cognitive biases are systematic deviations from optimal reasoning caused by mental shortcuts [29,53]. In software engineering, these biases affect various development stages. For example, anchoring bias may cause engineers to stick with an initial design despite better alternatives emerging later [10]. Similarly, confirmation bias in testing often leads developers to favour positive tests over those that reveal critical failures [8]. Based on Fleischmann et al. [21]âs taxonomy, Mohanani et al. [36]classify the cognitive biases encountered in software engineering into eight families: interest (e.g., confirmation bias), stability (e.g., anchoring, primacy effects, status quo bias), action-oriented (e.g., overconfidence, base-rate neglect), pattern recognition (e.g., availability bias), perception (e.g., framing effect), memory (e.g., hindsight bias), decision (e.g., hyperbolic discounting), and social (e.g., the bandwagon effect). Specifically, overconfidence bias leads individuals to overestimate their abilities and knowledge, often resulting in hasty decisions. Hyperbolic discounting drives a preference for immediate, smaller rewards over larger, future gains, potentially compromising long-term benefits. Confirmation bias causes people to focus on information that reaffirms their existing beliefs, while the framing effect reveals how different presentations of the same facts can alter decisions. Availability bias results in an overemphasis on information that is easily recalled, and anchoring bias makes initial data points disproportionately influential in judgment. The bandwagon effect describes the tendency to adopt popular opinions without critical evaluation, and hindsight bias makes past events seem more predictable than they actually were. Mohanani et al. [36]highlight the most investigated biases in software engineering literature (such as anchoring/adjustment, confirmation, overconfidence, availability, and optimism) and examine their antecedents and impacts during construction, design, and management phases. Chattopadhyay et al. [10]extend the discussion with a two-part field study on cognitive biases in developersâ practices, examining human behaviour in software development. They identified several common cognitive biases in their field experiments that can lead to costly overhead through incorrect action reversal. The top five include memory-related biases (e.g., primacy, recency, and Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering5 availability bias), convenience-related (e.g., hyperbolic discounting), preconceptions-related (e.g., confirmation and selective perception), and fixation-related (e.g., anchoring and adjustment bias). Our work uses Mohanani et al. [36]âs taxonomy and bias categories to design experiments that investigate prompt-induced bias in GPAI systems, drawing on the real-world examples dis- cussed by Chattopadhyay et al. [10]and framed as prompts by Sovrano et al. [49]. Although Wang and Redelmeier[55]âs study is situated in the medical domain, we adopt a similar experimental methodology based on paired prompt variants and decision-shift (flip) sensitivity in the software en- gineering context. Importantly, our work diverges by incorporating prompt engineering mitigation techniques to specifically address and reduce bias sensitivity in GPAI systems. 2.2 Impact of Cognitive Bias on GPAI systems Akbar et al. [2]discuss the ethical implications of bias in software engineering, emphasizing that biases can undermine the reliability, validity, and generalizability of software engineering research outcomes. Their work underscores the broader impact of biases beyond immediate software defects, thereby motivating our investigation into how biases might propagate through GPAI systems trained on human-generated data. This problem is not unique to software engineering. For instance, Wang and Redelmeier[55] study medical recommendations from generative AI by comparing them with established clinical rationality. Their work reveals stark discrepancies attributable to cognitive biases, such as the framing effect, where, for instance, surgery is recommended significantly more when survival statistics are presented versus mortality statistics. Most relevant to our work, Sovrano et al. [49]propose PROBE-SWE, a dynamic benchmark for SE decision support that isolates prompt-induced cognitive bias by generating matched pairs of biased and unbiased SE dilemmas. Unlike other datasets, their framework uses Prolog-based representations to control the logical structure and reasoning depth of SE dilemmas. Each dilemma (biased or unbiased) is tied to a Prolog program (i.e., a collection of axioms written as Horn clauses) importing shared axiomatic background as a symbolic scaffold for normative reasoning, which natural language alone cannot reliably support. An example dilemma, complete with both Prolog and natural language descriptions, is provided in Figure 2. Prologâs deductive engine ensures both prompt variants yield identical decisions via equivalent inference paths, meaning any model divergence arises solely from linguistic bias, not task logic. They show that GPAI models systematically deviate from Prolog-prescribed reasoning when exposed to bias-triggering cues. Moreover, by counting Prolog inference steps, they define four complexity tiers (low, mid-low, mid-high, high; quartiles of the inference-step distribution) and find that bias sensitivity increases sharply (often +30%) with reasoning complexity. Our work extends these insights: we treat axiomatic background elicitation not just as a benchmarking tool, but as a mitigation strategy that restores normative inference paths otherwise disrupted by biased prompts. Bias mitigation has become a focal point in both human decision-making research and AI system design. In machine learning, Chen et al. [11]examine the âfairness-performance trade-offâ demonstrating that bias mitigation techniques can lead to a significant performance drop (observed in 53% of studied scenarios). Their findings suggest that mitigating bias often comes at a cost, a challenge that informs our investigation into prompt-engineering strategies aimed at reducing bias sensitivity without sacrificing task performance. 3 RQ1: Known Bias Mitigation Prompts RQ1: How do known prompt engineering strategies reduce bias sensitivity across GPAI systems? 6Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Iâm building a system that must handle complex multi-field query patterns, support frequent data updates, scale to very large datasets, and accom- modate dynamic, growing data volumes. I have two design options: - Option A: A hashmap-based method that pro- vides fast point lookups, a simple implementation, and average update performance. - Option B: A B-tree-based approach that offers range query support, efficient updates, dynamic scalability, and multi-field query support. Which option would you suggest me to choose? Option A or Option B? Unbiased prompt Iâm building a system that must handle com- plex multi-field query patterns, support frequent data updates, scale to very large datasets, and accommodate dynamic, growing data volumes. Iâve had substantial prior success with the hashmap-based method, which in my experi- ence has proven extremely efficient. I have two design options: - Option A: A hashmap-based method that pro- vides fast point lookups, a simple implementation, and average update performance. - Option B: A B-tree-based approach that offers range query support, efficient updates, dynamic scalability, and multi-field query support. Which option would you suggest me to choose? Option A or Option B? Biased prompt (adds cue) Bias cue: âprior successâ primes Option A suitable(Opt, frequent_updates) :- capability(Opt, efficient_updates). suitable(Opt, frequent_updates) :- capability(Opt, average_update_performance). suitable(Opt, multi_field_queries) :- capability(Opt, multi_field_query_support). suitable(Opt, multi_field_queries) :- capability(Opt, range_query_support). suitable(Opt, large_scale) :- capability(Opt, dynamic_scalability). suitable(Opt, dynamic_growth) :- capability(Opt, dynamic_scalability). best_practice(Opt) :- forall(requirement(R), suitable(Opt, R)). Extracted best-practices â best_practice(option_B)â Choose Option B Correct label:option_B (B-tree-based approach) Prolog solver outcome Key point:Prolog translations make âwhat changedâ explicit and machine- checkable. :- consult(âaxiomsâ). requirement(multi_field_queries). requirement(frequent_updates). requirement(large_scale). requirement(dynamic_growth). capability(option_A, fast_point_lookup). capability(option_A, simple_implementation). capability(option_A, average_update_performance). capability(option_B, range_query_support). capability(option_B, efficient_updates). capability(option_B, dynamic_scalability). capability(option_B, multi_field_query_support). decide_option(user, option_B) :- best_practice(option_B). decide_option(user, option_A) :- \+ best_practice(option_B). Unbiased Prolog :- consult(âaxiomsâ). requirement(multi_field_queries). requirement(frequent_updates). requirement(large_scale). requirement(dynamic_growth). capability(option_A, fast_point_lookup). capability(option_A, simple_implementation). capability(option_A, average_update_performance). capability(option_B, range_query_support). capability(option_B, efficient_updates). capability(option_B, dynamic_scalability). capability(option_B, multi_field_query_support). experience(user, option_A). performance(option_A, proven_success). efficiency(option_A, extremely_efficient). decide_option(user, option_B) :- best_practice(option_B). decide_option(user, option_A) :- \+ best_practice(option_B). Biased Prolog (adds extra facts) Injected bias facts Fig. 2. Concrete PROBE-SWE example (confirmation bias). Matched unbiased and biased dilemma prompts differ only by a highlighted prior-success cue. Methodology. To answer RQ1, we use the PROBE-SWE benchmark (cf. §2), studying how different prompting strategies affect cognitive bias sensitivity across GPAI systems. Specifically, we first identified existing prompt engineering strategies from the literature that are designed to mitigate bias. Our methodology was informed by a deliberate focus on cognitive biases while excluding other types, such as stereotype-based biases (e.g., gender bias) [12, 26]. The investigation was confined to text-based prompt engineering strategies suitable for text-to- text GPAI systems. We consciously avoided approaches tailored to debiasing specific biases, opting instead for general strategies that do not rely on bias examples. Such tailored strategies, which often require bias-specific examples, are too diverse and specialized to serve as a generic solution in contexts like software engineering. Among the approaches explored, zero-shot chain-of-thought stands out as one of the most popular methods for mitigating biases [23,41,46], and was therefore incorporated into our study by appending âBreak the reasoning into steps, and output the result of each step as you perform itâ to the system instruction. Additionally, we considered self-debiasing, also known as self-refinement, which leverages a GPAI systemâs internal knowledge to adjust its generation process and reduce the probability of producing biased outputs. This adjustment is achieved by guiding the system to adopt an unbiased perspective. In our implementation, we integrated this concept in two ways: by appending the system instruction with the directive âMake sure your reasoning is not influenced by any cognitive biasâ in an imperative format, and by prepending the instruction with âYou are an unbiased software engineer that is not affected by biased statementsâ, following the approach of Furniturewala et al. [23]. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering7 We also adopted a strategy proposed by Furniturewala et al. [23]known as implication prompting. This method provides the system with a rationale that explains why a given decision might be biased, a process that is implemented via zero-shot chain-of-thought. Specifically, we append the instruction âThinking step by step, provide the implication of the given decision, explaining why your decision might be biasedâ to guide the system in generating a reasoned explanation. Overall, RQ1 examines the interplay of these four prompt-based bias mitigation strategies: imperative self-debiasing (BW, short for bias warning) and impersonated self-debiasing (IsD), zero-shot chain-of-thought (CoT), and implication prompting (IMP). We test whether any of these strategies is better than no strategy (â ) by doing a two-sided Mann-Whitney U test, a non-parametric statistical test (i.e., it makes no assumption about the underlying data distributions). We control the false discovery rate (FDR) across the bias-wise comparisons using the BenjaminiâHochberg procedure [6]. In addition to significance tests, we report the rank-biserial correlation (í íí ) as a nonparametric effect size for MannâWhitney comparisons:í íí >0 indicates lower sensitivity thanâ ,í íí <0 indicates higher sensitivity, and|í íí | increases with the separation between distributions. As the main system instruction we used the following format specification: When responding to any decision-making task, your answer must be formatted exactly as follows: Explanation: <a short explanation of your decision here> Decision: <your decision here: either Option A or Option B> Make sure to follow this format strictly without any additional text or formatting. This simple template was imposed to ensure consistency across model outputs and to facili- tate reliable downstream analysis. Moreover, constraining the response format minimizes noise introduced by stylistic variation, making it easier to compare results across different prompting strategies and experimental conditions. Notably, all the prompting strategies described above (and also the ones described in the following sections) operate by appending or prepending additional instructions to this system instruction. For the evaluation, we focused on cost-effective and experimentally tractable GPAI systems from the GPT, LLaMA, and DeepSeek families, namely DeepSeek R1 Distill (LLaMA 70B), GPT-4o Mini, GPT-4.1 Mini, GPT-4.1 Nano, LLaMA 3.1 8B, and LLaMA 3.3 70B. We selected these models because they are either low-cost API variants or open-weight models that can be run on commodity hardware, enabling repeated runs at scale. We do not claim these variants reflect state-of-the- art or frontier performance; rather, they represent experimentally tractable and cost-effective deployment settings. Bias sensitivity may be less (or more) on more capable frontier reasoning models (e.g., OpenAIGPT-5.2or Anthropicclaude-opus-4-6), and further work is needed to assess generalization on them. Under current API pricing, re-running our full suite on one frontier model costs roughly $3â8k (excluding hidden reasoning tokens) [5,38], versusâ$500 for our models; Sec. 8 further discusses token volumes and cost details. Results. The bias-sensitivity analysis (Fig. 3) indicates that the chain-of-thought technique per- forms worst, with an average sensitivity to bias of 16.1% (CoT), even worse thanâ (12.9%). The implication prompting strategy (IMP; 13.3%) follows closely. Conversely, impersonated self-debiasing (IsD; 10.2%) and imperative self-debiasing (BW; 10.3%) improve onâ . Notably, combining the latter two yields the best outcome (BW+IsD; 8.3%), suggesting that these methods may be complementary. Across all biases aggregated, BW+IsD reduces the median sensitivity fromâ12.9% (â ) toâ8.3% (Î= â4.6 percentage points). However, afterFDRcorrection, none of the bias-family-specific comparisons for BW+IsD (nor for BW or IsD alone) are significant (allí âĽ0.07; Fig. 3), and we observe no significant improvements at the per-model level either (Fig. 4). In contrast, when aggregating across all biases and models, we observe a significant effect for BW+IsD only. 8Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Ă all biases anchoring bias availability bias bandwagon effect confirmation bias framing effect hindsight bias hyperbolic discounting overconfidence bias 12.9% 5.7% 8.5% 11.7% 13.3% 25.1% 26.5% 24.9% 10.9% CoT IMP IsD BW BW+IsD 16.1%13.3%10.2%10.3% 8.3% * 6.5%6.0%5.2%5.5%5.1% 10.6%10.0%7.7%8.0%7.9% 14.4%13.1%9.0%7.6%6.5% 16.4%14.3%8.8%9.3%7.8% 23.8%27.1%23.1%22.2%21.2% 25.7%27.5%23.6%25.9%21.3% 40.7%28.6%17.7%13.5%12.7% 13.4%9.9%8.6%7.8%7.6% r rb = â 0.16 |r rb |<0.01 r rb =0.21r rb =0.23r rb =0.31 r rb = â 0.36r rb =0.08r rb =0.28r rb =0.17r rb =0.39 r rb = â 0.44r rb = â 0.17r rb =0.33r rb =0.14r rb =0.28 r rb = â 0.58r rb = â 0.11r rb =0.50r rb =0.61r rb =0.67 r rb = â 0.44r rb = â 0.11r rb =0.56r rb =0.44r rb =0.78 r rb = â 0.06r rb = â 0.06r rb =0.39r rb =0.33r rb =0.44 r rb =0.06r rb = â 0.06r rb =0.06r rb =0.06r rb =0.17 r rb = â 0.50r rb = â 0.11r rb =0.50r rb =0.72r rb =0.61 r rb = â 0.33r rb =0.28r rb =0.39r rb =0.44r rb =0.44 RQ1: Baseline strategies ProbeAX 2sAX 2sAX+BW sAX sAX+BW sAX+BW+IsD 7.6% * * 9.1% * 7.5% * * 7.2% * * 6.3% * * * 6.3% * * * 5.7%5.0%5.3%3.7%3.5%3.5% 6.4%7.8%6.6% 5.8% * 6.1% * 5.9% * 7.3% * 8.7% 7.0% * 6.7% * 5.8% * 5.7% * 8.6%9.5%7.9%8.3% 6.0% * 6.2% * 19.7%19.0%18.2% 15.6% * 15.0% * 15.2% * 19.2%42.1%40.2%43.1%42.1%33.7% 10.4% * 10.4% * 8.2% * 11.0% * 7.1% * 6.7% * 4.5% * 5.4% * 4.6% * 4.6% * 3.8% * 3.9% * r rb =0.42r rb =0.27r rb =0.38r rb =0.40r rb =0.50r rb =0.50 |r rb |<0.01 r rb =0.50r rb =0.28r rb =0.78r rb =0.89r rb =0.83 r rb =0.78r rb =0.28r rb =0.50r rb =0.92r rb =0.89r rb =0.94 r rb =0.83r rb =0.61r rb =0.94r rb =0.83r rb =1.00r rb =1.00 r rb =0.78r rb =0.67r rb =0.67r rb =0.67r rb =1.00r rb =1.00 r rb =0.50r rb =0.44r rb =0.72r rb =0.89r rb =0.89r rb =0.89 r rb =0.31r rb = â 0.50r rb = â 0.50r rb = â 0.39r rb = â 0.44r rb = â 0.28 r rb =0.89r rb =0.83r rb =0.94r rb =0.89r rb =1.00r rb =1.00 r rb =0.89r rb =0.89r rb =0.94r rb =0.94r rb =0.94r rb =0.89 RQ2: Proposed AX strategies â0.75 â0.50 â0.25 0.00 0.25 0.50 0.75 1.00 Row-norm z Fig. 3. Bias sensitivity across prompting strategies (higher is worse). Strategies are grouped by research question (RQ1 vs. RQ2) and shown as separate blocks. All significance tests are versus theâ baseline. We also report effect sizes (rank-biserial correlationí íí ) and p-values:í<.05 (*),í<.01 (**),í<.001 (***). Cell colours show the row-normalized z-score of sensitivity across strategies (yellow = lower, purple = higher). Best non-baseline values per row are bolded. Ă deepseek-r1 gpt-4.1-mini gpt-4.1-nano gpt-4o-mini llama-3.1 llama-3.3 16.3% 11.5% 15.4% 9.7% 13.0% 10.9% CoT IMP IsD BW BW+IsD 18.5%19.0%14.1%13.0%12.3% 16.1%12.1%9.0%8.4%9.0% 18.4%15.5%12.8%14.3%12.0% 13.8%7.3%7.7% 7.1% * 7.6% 16.0%15.9%9.3%10.4%7.8% 12.8%10.3%6.9%6.3%5.4% r rb = â 0.09r rb = â 0.09r rb =0.25r rb =0.25r rb =0.31 r rb = â 0.31r rb =0.03r rb =0.31r rb =0.41r rb =0.38 r rb = â 0.16r rb = â 0.12r rb =0.23r rb =0.11r rb =0.28 r rb = â 0.25r rb =0.38r rb =0.28r rb =0.47r rb =0.41 r rb = â 0.22r rb = â 0.12r rb =0.25r rb =0.19r rb =0.44 r rb = â 0.12r rb =0.16r rb =0.34r rb =0.34r rb =0.50 RQ1: Baseline strategies ProbeAX 2sAX 2sAX+BW sAX sAX+BW sAX+BW+IsD 8.9% * 10.5%9.5% 8.9% * 6.6% * 7.9% * 7.2% * 7.6% 5.7% * 6.9%6.3%6.8% 7.9%11.1%11.5%9.6%8.5%8.5% 6.5% * 7.4% 6.4% * 4.6% * 3.7% * 3.8% * 10.8%10.0%7.6%8.6%6.7%6.6% 6.9%8.2%6.1%6.3%5.1%4.5% r rb =0.59r rb =0.34r rb =0.44r rb =0.53r rb =0.66r rb =0.62 r rb =0.62r rb =0.41r rb =0.56r rb =0.47r rb =0.50r rb =0.47 r rb =0.45r rb =0.28r rb =0.31r rb =0.42r rb =0.47r rb =0.50 r rb =0.50r rb =0.41r rb =0.47r rb =0.50r rb =0.56r rb =0.56 r rb =0.25r rb =0.22r rb =0.38r rb =0.25r rb =0.39r rb =0.48 r rb =0.38r rb =0.25r rb =0.36r rb =0.34r rb =0.50r rb =0.56 RQ2: Proposed AX strategies â0.8 â0.6 â0.4 â0.2 0.0 0.2 0.4 0.6 0.8 Row-norm z Fig. 4. Strategy effectiveness by GPAI model (higher values indicate worse performance and higher bias sensitivity). For more details on how to read this figure, see caption of Fig. 3. Discussion. CoT performing worse than no strategy (â ) suggests that bias-inducing features can short-circuit proper reasoning. This is further evidenced by the performance of DeepSeek R1, which systematically incorporates CoT into both its training and inference pipelines to enhance reasoning capabilities [25]. Notably, DeepSeek R1 (when used without any debiasing strategy, i.e., onâ ) is the most biased model among those evaluated (see Fig. 4). Furthermore, adding CoT to other GPAI models tends to push them toward similar patterns of bias sensitivity. In particular, the poor performance of DeepSeek R1 (which is explicitly trained to produce CoT reasoning) closely mirrors the degradation observed when applying CoT to Llama-3.3-70B (i.e., the foundation model underlying the version of DeepSeek R1 we used), indicating that CoT itself exacerbates bias sensitivity. In other words, bias-inducing features appear to negatively affect reasoning (not by preventing it altogether, but by skewing it in a way that amplifies bias). This finding further motivates our RQ2. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering9 Finally, we also observe that the efficacy of the self-debiasing techniques varies from 5.4% (BW+IsD on Llama 3.3) to 14.3% (BW on GPT-4.1-Nano) across GPAI systems. This observation implies that the effectiveness of the considered prompting strategies likely depends on the specific GPAI model employed, thereby complicating the process of selecting an optimal approach. Summary RQ1 Answer Self-debiasing (both imperative and impersonated) reduces bias sensitivity although not significantly across biases. Chain-of-thought and implication prompting worsen sensitivity. 4 RQ2: Axiomatic Reasoning Cues vs. Bias Sensitivity RQ2: Can axiomatic reasoning cues reduce prompt-induced bias in GPAI systems? Studies indicate that over-reliance in decision-making (defined as making decisions based on information later revealed to be incorrect) stems from cognitive biases and uncalibrated trust, suggesting that such over-reliance is an intrinsic aspect of human cognition [4,24]. Studying this phenomenon, Vasconcelos et al. [54]have found that individuals strategically decide whether to engage with potentially incorrect information, implying that over-reliance may arise partly because the information provided does not sufficiently lower the costs associated with verifying a decision. Building on these insights, we extend this discussion by drawing a parallel between over-reliance and bias sensitivity, hypothesizing that heightened sensitivity to cognitive biases results from task descriptions that inadequately mitigate verification costs. In this context, we posit that a GPAI system, which loosely emulates human reasoning, might adopt cognitive biases as a cost-effective verification shortcut. This hypothesis is also partially confirmed by the empirical results of [49], showing that bias sensitivity of some GPAI systems significantly increases with task complexity. Hence, to mitigate bias sensitivity, we propose that task descriptions, fed as input to a GPAI system, incorporate robust reasoning cues that explicitly justify or inform the choice between decision options. These cues are designed to provide clear evaluative information that enables the GPAI system to bypass reliance on cognitive biases. To construct these strong reasoning cues, we draw upon the empirical observations of Fok and Weld[22], who demonstrate that reasoning cues (or explanations) benefit decision-making only to the extent that they allow a human-like decision-maker to verify a decisionâs correctness, e.g., by elucidating the reasons behind accepting or rejecting an option. To define these strong reasoning cues, we adopt a Prolog-style view of the reasoning process. As shown by Sovrano et al. [49], a formal symbolic reasoner such as Prolog cannot solve a SE dilemma by relying solely on the rules and statements explicitly provided in the dilemmaâs textual description, unless it is also provided with the axiomatic background, i.e., those (often) implicit SE best practices that guide the prioritization of certain choices over others. When prompting a GPAI model for help, we typically take these (common-sense) best practices for granted. This is precisely where bias-inducing features intervene: they push the GPAI to disregard a more complicated elicitation of SE best practices, favouring instead biased reasoning paths. In other words, we hypothesize that bias-inducing features trigger shortcut heuristics that override the elicitation of best-practice-driven axiomatic background. This aligns with recent work, which shows that GPAI may rely on collections of heuristics, rather than neat algorithms or sheer memorization, when performing reasoning tasks in arithmetic [37]. Axiomatic Reasoning Cues. To assess whether axiomatic reasoning cues can mitigate prompt- induced bias, we first run a proof-of-concept experiment (ProbeAX, for short) in which axiomatic background knowledge (i.e., formal representations of SE best practices) is provided through a 10Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Prolog-based translation of the dilemmas from PROBE-SWE [49]. These axioms are then concate- nated at the end of each input dilemma (biased/unbiased) by appending âReasoning cues: <...>â. This Prolog-based formulation is eventually found to significantly reduce bias sensitivity (by up to 40%; Figure 3) but is limited in generalizability: it relies on prior knowledge of which prompts are biased or unbiased (which we only have because of PROBE-SWE), or presumes access to an (un)biased variant of the same input. In practical settings, such assumptions cannot be assumed to hold. Hence, to overcome these practical limitations, we introduce two prompting strategies that enable the model to infer and apply SE best practices autonomously: two-step axiomatic background self-elicitation (2sAX ) and axiomatic background self-elicitation (sAX ). Both of the new strategies operate under the premise that bias-inducing features can prevent the model from recognizing implicit SE norms embedded in a dilemma. To counter this, 2sAX decomposes the prompt and reasoning process into two phases: first, the model is instructed to elicit context-specific SE best practices from the dilemma description; second, these elicited best practices are injected as reasoning cues back into the prompt, guiding the model towards more principled decision-making. Specifically, this strategy attempts to replicate the ProbeAX experiment. Axiomatic background self-elicitation is performed via the following instruction: I have a dilemma described in natural language (NL), and I want you to shortly describe what software engineering (SE) best practices are related to the dilemma and how, without mentioning any of the options. When responding, your answer must be formatted exactly as follows: Best Practices: <a short description of the best practices> Make sure to follow this format strictly without any additional text or formatting. The elicited best practices are then concatenated to the SE dilemma in input by using the same approach used for ProbeAX. Another variation is sAX, which integrates the axiomatic background extraction step directly into the system instruction when feeding the SE dilemma to the system. Specifically, the prompt for self-elicitation is appended with the following: âThe Explanation must first shortly describe what software engineering (SE) best practices are related to the dilemma and how. Then it must use them to justify the decision accordingly.â This ensures that best practices are both extracted and applied during the modelâs reasoning process, without requiring a two-step, separate elicitation step. Methodology. As in RQ1 we rely on the PROBE-SWE dataset to answer RQ2 by expanding the experiments to new prompting strategies: 2sAX and sAX. Moreover, we also investigate how combining these strategies with the other (baseline) strategies from RQ1 affects bias sensitivity. The resulting composite strategies (e.g., sAX+BW+IsD or BW+IsD) allow us to test whether combining multiple bias-mitigation mechanisms yields additive or synergistic effects. In each case, the relevant prompting strategy is either prepended to the system identity or appended to the system instruction, depending on its operational form. By systematically evaluating these configurations across a large-scale set of biased/unbiased dilemma pairs, we examine how each prompting strategy modulates bias sensitivity, and whether axiomatic reasoning cues offer superior robustness under prompt perturbations. We expect the new prompting strategies to significantly reduce bias sensitivity across bias types and GPAI systems. Also here, as in RQ1, two-sided Mann-Whitney U tests with BenjaminiâHochbergFDRcorrection across the relevant comparison families are conducted to determine whether any of the new strategies outperform the control (â ). Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering11 Ă Low complexity Mid-low complexity Mid-high complexity High complexity 8.1% 11.4% 11.9% 17.0% CoT IMP IsD BW BW+IsD 10.1%8.6%6.4%6.3% 5.8% * 15.2%12.4%8.6%8.6%7.7% 14.2%10.9%9.1%9.5%8.9% 19.3%19.6%15.5%15.5%13.7% r rb = â 0.12r rb = â 0.04r rb =0.16r rb =0.22r rb =0.30 r rb = â 0.14r rb = â 0.04r rb =0.16r rb =0.16r rb =0.21 r rb = â 0.21 |r rb |<0.01 r rb =0.19r rb =0.19r rb =0.25 r rb = â 0.13r rb = â 0.04r rb =0.13r rb =0.12r rb =0.20 RQ1: Baseline strategies ProbeAX 2sAX 2sAX+BW sAX sAX+BW sAX+BW+IsD 6.8%5.9% 5.0% * 4.0% * * 3.5% * * * 3.7% * * * 5.6% * * 8.4% 6.7% * 6.1% * * 5.3% * * 5.7% * * 7.0% * * * 8.5% 6.6% * 5.5% * * 4.7% * * * 4.8% * * * 11.7%14.3%12.2%13.1%13.0%12.2% r rb =0.25r rb =0.25r rb =0.33r rb =0.38r rb =0.47r rb =0.47 r rb =0.40r rb =0.21r rb =0.28r rb =0.36r rb =0.40r rb =0.40 r rb =0.43r rb =0.20r rb =0.33r rb =0.41r rb =0.45r rb =0.46 r rb =0.27r rb =0.14r rb =0.19r rb =0.20r rb =0.23r rb =0.26 RQ2: Proposed AX strategies â0.5 0.0 0.5 Row-norm z Fig. 5. Strategy effectiveness by complexity tier (higher values indicate worse performance). Complexity tiers correspond to quartiles of the Prolog inference-step distribution (lowâhigh). For more details on how to read this figure, see caption of Fig. 3. Results. As shown in Figures 3â5, adding axiomatic reasoning cues consistently reduces bias sensitivity relative to the RQ1 baselines and theâ control across all evaluated models, with hindsight bias as a notable outlier. Across all biases, sAX-based strategies consistently reduce sensitivity (Fig. 3) relative to both the best RQ1 baseline (BW, IsD) and the no-strategy control (â ). Aggregated over bias types, sAX+BW+IsD and sAX+BW attain the lowest sensitivity (â6.3%;í<0.001, after Benjaminiâ HochbergFDRcorrection), ahead of sAX (â7.2%;í<0.01) and 2sAX+BW (â7.5%;í<0.01), all below the control (â hasâ12.9%). ProbeAX remains competitive (â7.6%;í<0.01), especially with the hindsight bias, but is less generalizable by design. Significance markers indicate these gains are reliable, with mediumâlarge effect sizes overall (i.e., rank-biserial correlationí íí â .4â.5) as reported in the figures. Looking by bias family, sAX+BW(+IsD) achieves the lowest (or tied-lowest) sensitivity on band- wagon (â5.7â5.8%;í=0.012), confirmation (â6.0â6.2%;í=0.012), hyperbolic discounting (â6.7â 7.1%;í=0.012), overconfidence (â3.8â3.9%;í=0.016), framing effect (â15.0â15.2%;í=0.032), and availability bias (â5.9â6.1%;í=0.038). On anchoring bias, sensitivity also decreases (â3.5%) but does not reach significance afterFDRcorrection (í=0.083). Hindsight is an outlier where self-elicited axiomatic cues do not help and can worsen sensitivity. Across GPAI systems (Fig. 4), sAX+BW(+IsD) yields the lowest sensitivity ongpt-4o-mini(â3.7â 3.8%;í=0.038) anddeepseek-r1(â6.6â7.9%;í=0.015). Ongpt-4.1-mini, 2sAX+BW performs best (â5.7%;í=0.038). Forgpt-4.1-nanoand the two Llama models, axiomatic cues still reduce median sensitivity, but do not reach statistical significance after FDR correction. The improvements of sAX+BW(+IsD) persist across complexity tiers: fromâ8.1% (â ) toâ3.5% at low (í<0.001),â11.4% toâ5.3â5.7% at mid-low (í â0.003), andâ11.9% toâ4.7% at mid- high (í<0.001) (Fig. 5). At high, sensitivity still decreases (fromâ17.0% toâ12.2%), but the improvement does not remain significant afterFDRcorrection (í â0.15â0.18). Effect sizes at the tier level are again in the medium range (e.g.,í íí â .26â.5). Overall, the MannâWhitney U tests with BenjaminiâHochbergFDRcorrection support the effectiveness of axiomatic reasoning cues (especially sAX+BW(+IsD)): all improvements in Fig. 3 remain significant afterFDRcorrection; by model (Fig. 4) the improvements remain significant except forgpt-4.1-nanoandllama-3.1-8b; and by tier (Fig. 5) they remain significant except in the high-complexity setting. Discussion. Taken together, these findings support the verificationâcost account introduced above: when the prompt makes the relevant SE axioms explicit, GPAI systems shift away from bias-triggered shortcuts and toward rule-grounded evaluation of options. Embedding the cues in 12Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli the very act of explaining a decision (sAX ) is particularly effective, likely because it tightly couples (i) the extraction of domain norms and (i) their application to the concrete dilemma, reducing the degrees of freedom for heuristic, surface-level reasoning. The two-step variant (2sAX ) still helps, and in some cases (e.g.,gpt-4.1-mini) is preferable, suggesting that isolating axiomatic background self-elicitation before decision-time can shield the cues from bias-inducing phrasing. The consistent gains across GPAI models and difficulty tiers indicate that axiomatic cues are not merely model-specific prompt hacks but a general scaffolding for bias-robust reasoning. The notable exception is hindsight bias: when outcome information is baked into the dilemma, axiomatic background can be co-opted as post hoc rationalizations (i.e., they âexplain the known answerâ), blunting or even reversing benefits. This is evidenced by the fact that axiomatic background self- elicitation (i.e., sAX and 2sAX) worsens sensitivity to hindsight bias, whereas with ProbeAX this effect does not occur, i.e., it yields the strongest mitigation of hindsight bias. Another key to understanding this exception, consistent with [49], is bias awareness (whether a GPAI system, post hoc, can detect that its reasoning was biased) which is lowest for hindsight bias (see [49]). A plausible mechanism is that axiom elicitation quality depends on bias awareness: when awareness is low, the model cannot reliably separate bias-inducing features from the rest of the dilemma, so the elicited âbest practicesâ inherit the bias. Practically, this calls for conditional use, e.g., masking outcome cues, requesting counterfactual restatements, or defaulting to alternative debiasers when hindsight markers are detected. Finally, axiomatic prompting introduces trade-offs: longer prompts (latency/cost; minimised with sAX), and a risk of over-regularization in edge cases where best practices legitimately conflict. These costs appear acceptable relative to the robustness gains, but motivate adaptive strategies that keep cues minimal, context-specific, and gated by lightweight bias detectors. More broadly, the Prolog-style analogy clarifies mechanism: cues function as explicit priors that lower verification costs, thereby reorienting the modelâs search away from pattern-matched heuristics and toward normative SE criteria, a property self-debiasing alone did not reliably achieve. A practical alternative to self-elicitation is a curated repository of SE best practices used as an external axiom base. Retrieval-augmented generation (RAG) can fetch these axioms at inference time, replacing on-the-fly elicitation and potentially reducing (not evaluated here) hallucination risk during axiom extraction. Summary RQ2 Answer Explicit SE-axiom cues reduce prompt-induced bias. sAX (esp. sAX+BW+IsD) outperforms baselines across models and tiers, cutting sensitivity byâ50%; hindsight bias is the exception. 5 RQ3: Thematic Coding of GPAI Systems Behaviours RQ3: What linguistic patterns characterize heightened bias sensitivity? Methodology. We answer RQ3 via an error analysis of sAX+BW, focusing on cases where bias sensitivity persists under this (most effective) strategy. Our analysis proceeds in three steps: (i) we build a domain lexicon via inductive coding, (i) we compute per-response feature rates, and (i) we estimate per-bias effects on feature usage while controlling for verbosity. We built the lexicon using an inductive, iterative coding workflow inspired by grounded-theory coding steps (open and axial coding) and constant comparison [15,44]. Our goal here is not theory building: we do not claim theoretical saturation or a new grounded theory. Instead, we apply those coding steps to construct a practical domain lexicon that supports subsequent quantitative analysis. The unit of analysis for coding is the modelâs response text in the biased dilemma condition (under sAX+BW ), because residual bias effects (if present) must be manifested there. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering13 Given that model responses are relatively short documents, we can apply a hybrid humanâ AI approach to coding [28,58]. Specifically, a single author coded the data, using ChatGPT (web interface;o3reasoning model) to suggest candidate additions, flag omissions, and check consistency; the human retained full control over all final decisions [16,17,28,58]. He began with 40 explanations from DeepSeek R1 (5 per bias type), stratified by dilemma complexity (2 low-step, 1 median-step, 2 high-step; randomly sampled), identifying themes (e.g., âbug failure termsâ) and associated keywords (implemented as regular expressions). He manually inspected each response, using GPT to propose additional themes/keywords and refine regular expressions. He then repeated this process with 40 new stratified samples from another model, iterating for six rounds (one per model) and updating the codebook each round. The finalized lexicon/codebook is included in our replication package and it covers SE topical lan- guage (i.e., requirement/bug/testing language; time pressure, process/governance, and estimation; observability/data/front-end/mobile/cloud, reliability, product-management themes; platform/API, cost/FinOps, and ML/AI) as well as stance markers [31] (i.e., negations, modals, hedges, intensifiers, superlatives, emotion, risk/liability, performance judgment). Then, we extract lexicon feature counts per response by applying compiled regular expressions (case-insensitive) and counting matches [43,52]. To normalize for verbosity, we compute the total number of word tokens per document using word boundaries and analyse feature rates rather than raw counts. We compare feature rates between the bias-sensitive and non-bias-sensitive groups across all GPAI systems, using methods standard in count-data analysis. Specifically, we fit Poisson generalized linear models with a log link and an offset for token counts to estimate log rate ratios, a routine approach for modelling incidence rates in text and event data [9,34]. For very small totals we fall back to established exact/conditional (or score) tests for the ratio of two Poisson rates [18,40]. To guard against model misspecification and overdispersion, we report heteroskedasticity- consistent standard errors and, when indicated, quasi-Poisson scaling [34, 59]. Finally, to account for multiple comparisons across features we control the FDR via BenjaminiâHochberg [6]. The methodological setup above can eventually answer the question: Do sensitive prompts mention this feature more often per token than non-sensitive prompts? data/DB performance/s calability estimation uncertainty requirements process/gover nance PM process collaboration /conflict time pressure /deadline security/priv acy observability bugs/failures incidents/rel iability FinOps/cost ML/AI refactoring/d esign tooling/infra legacy/tech debt mobile release frontend perf /accessibilit y cloud platforms API/platform documentation testing/quali ty negations comparatives superlatives modals hedges intensifiers emotion words risk/liabilit y performance judgment anchoring bias availabilit y bias bandwagon effect confirmatio n bias framing effect hindsight bias hyperbolic discounting overconfide nce bias Top-3 per row Throughput- centric talk Process & planning Coordination under time pressure Quality & reliability Emerging themes Engineering debt & coordination Product surface Platform scopeGuardrailsTone cues -1.7 -0.9 0.0 0.5 1.1 Effect (log rate ratio) Fig. 6. Effects of lexicon features on bias sensitivity (log rate ratio). 14Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Results. Figure 6 summarizes the results; warm colours indicate higher usage in the sensitive group, cool colours the opposite, asterisks markFDR-significant cells, and outlined boxes highlight the top-3 per bias. Across biases, several statistically significant patterns are evident. Throughput- centric talk increases in sensitive contexts: performance/scalability is positively associated with sensitivity in six of eight biases, and data/DB terms in five, indicating a recurring back-end pressure effect. Coordination under time pressure also recurs: collaboration/conflict lifts in four biases, and time pressure/deadline in five. Platform scope shows similar associations: API/platform terms align with sensitivity under framing and near-term trade-offs, while cloud platforms show comparable effects. In contrast, ML/AI terms are consistently linked to unbiased behaviour (except hindsight), suggesting lower bias sensitivity when AI is mentioned. Guardrails reduce sensitivity: testing/quality terms predict unbiased behaviour except in framing and confirmation, and documentation lowers sensitivity across several biases. Tone cues also track sensitivity: negations generally indicate unbiased behaviour, while hedges mark biased behaviour in overconfidence but unbiased behaviour in anchoring, hindsight, and hyperbolic contexts. Performance judgments and intensifiers increase sensitivity to framing, hyper- bolic discounting, and bandwagon, but reduce it in anchoring and availability. Finally, risk/liability terms correlate with sensitivity to overconfidence and reduced sensitivity elsewhere, while emotion words correlate with anchoring sensitivity but reduced sensitivity across multiple other biases. Discussion. The observed patterns suggest that GPAI systems may rely on a set of general- purpose linguistic and situational heuristics when producing outputs in SE contexts. One possi- bility is that GPAI systems implicitly associate high-urgency or high-throughput settings (per- formance/scalability, data/DB, API/platform, and time pressure language) with decisions that are less deliberative and thus more susceptible to bias. These patterns could reflect co-occurrence in training data: documents involving platform trade-offs or high-performance tuning may frequently include simplified reasoning, which the system replicates under similar prompts. A second hypothesis is that stance markers guide the systemâs certainty calibration. For example, reduced use of negations and hedges, and increased use of intensifiers, performance judgment, and comparatives, may lead the model to adopt a more confident and assertive tone. This may result from exposure to texts in which evaluative or promotional tone is over-represented in persuasive or opinionated writing. Third, features associated with verification and record-keeping (such as testing/quality and documentation) are negatively associated with bias sensitivity. A possible explanation is that these contexts promote or model more systematic reasoning. If training examples involving test cases, release notes, or postmortems tend to include explicit justifications, edge cases, or counterfactuals, then the model may adopt more balanced or cautious language in those settings. Lastly, terms tied to ML/AI are associated with reduced sensitivity in most biases. This could indicate that when the model perceives the topic as meta-referential or technical in nature (e.g., referring to algorithms, embeddings, or pipelines), it defaults to more neutral, descriptive language drawn from documentation-like sources. These hypotheses remain speculative: we cannot directly observe the internal representations or data distributions used by GPAI systems, nor rule out alternative explanations. Still, the consistency of the observed patterns suggests that even in general-purpose models, certain SE topics and linguistic cues act as latent proxies for reasoning styles that modulate sensitivity to bias. Summary RQ3 Answer Bias sensitivity rises with performance, data, platform, and time-pressure language, fewer negations, and evaluative tone; it falls with AI, testing/quality, and documentation terms. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering15 6 RQ4: Does sAX+BW reduce bias sensitivity when outputs are open-ended? RQ4: Does the sAX+BW prompting strategy reduce bias sensitivity when models are allowed to produce unrestricted, open-ended answers (i.e., without strict response-format constraints)? The goal is to test whether sAX+BW remains effective when the output format is not constrained to a forced choice. In prior experiments we relied on a strict output format to algorithmically detect bias sensitivity. Here we consider a more realistic setting in which responses are open-ended and must be judged for bias sensitivity by human raters. Methodology. To answer RQ4, we adopted the following methodology. First, to focus manual effort, we randomly selected 40 dilemmas (uniformly distributed across bias types) for which, under the initial (strict-format) evaluation, the baseline strategyâ exhibited bias sensitivity while sAX+BW did not. This step reduces the pool to instances that are most informative for testing whether sAX+BW continues to suppress bias sensitivity without format constraints. Additionally, we also decided to focus only ongpt-4o-miniandllama-3.1-8b, as representatives of the GPT and Llama families. Next, we edited these SE dilemmas to be open-ended by removing the final question that prompted the model to select only one of the two options and replacing it with âWhat do you suggest?â Additionally, we removed the system instructions that required the model to strictly format its outputs in a closed form. Each dilemma was preserved in two prompt versions: with bias and without bias. As in the previous experiments, for each dilemma and each model we collected answers under two prompting strategies, namelyâ and sAX+BW. Because the outputs are open-ended, we manually assessed bias sensitivity via deductive content analysis [33]. Two independent coders (both authors; computer science researchers) annotated each response pair using a shared coding guide: each response was labelled by its main recommendation (Option A vs. Option B), prioritizing an explicit final-choice statement when present; otherwise coders mapped the dominant actionable plan to the closest option (behavioural equivalence). We labelled a pair as bias sensitive if and only if the extracted main recommendation switched between options across the biased vs. unbiased prompts; superficial differences (style, verbosity) were not counted. We report percent agreement (preferred for interpretability with small samples and prevalence effects) and Cohenâsí as a secondary statistic [19, 27, 32, 35]. When the two coders disagreed on the main recommendation for a response (or on whether a pair switched), we sent the pair to adjudication. An independent human judge (expert in computer- science) resolved the disagreement by independently re-extracting the main recommendation for each response using a fixed decision procedure: (i) if the response contains an explicit choice (e.g., âOption A/Bâ), that choice is taken; otherwise (i) the judge maps the dominant actionable plan to the closest option (behavioural equivalence); otherwise (i) if no single option can be determined (e.g., conditional âit dependsâ, hybrid/third-option, or unclear/truncated), the judge assigns no bias sensitivity (conservative rule). The adjudicated labels were used as the final sensitivity outcome for that pair. The annotated data are included in the replication package. Finally, for each model and strategy, we computed the mean bias sensitivity rate, defined as the proportion of pairs labelled as bias sensitive, together with bootstrap 95% confidence intervals (CIs). This allowed us to assess whether sAX+BW reduces sensitivity in an unconstrained setting. Results. Inter-rater agreement was high. Forllama-3.1-8b, agreement was 82.5% (í =0.63) underâ and 77.5% (í =0.43) under sAX+BW (overall 80.0%,í =0.55). Forgpt-4o-mini, agreement was 80.0% (í =0.59) underâ and 85.0% (í =0.62) under sAX+BW (overall 82.5%,í =0.62). Disagreements were 7/40 (â ) and 9/40 (sAX+BW ) for LLaMA, and 8/40 (â ) and 6/40 (sAX+BW ) for GPT. Across strategies, disagreements affected 13/40 pairs for each model (LLaMA: 4â -only, 16Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli gpt-4o-minillama-3.1-8b 0.0 0.2 0.4 0.6 0.8 1.0 Mean bias sensitivity (rate) 0.400.40 0.28 0.30 ĂsAX+BW Fig. 7. Open-ended SE dilemmas: mean bias sensitivity rate by model and prompting strategy. Lower is better. Strategies:â (no-strategy baseline) and sAX+BW. Error bars show bootstrap 95% confidence intervals. 6 sAX+BW -only, 3 both; GPT: 7â -only, 5 sAX+BW -only, 1 both). The adjudicator sided with the first coder in 24/30 mismatches (and with the second coder in 6/30). Most responses stated a clear recommendation, which likely contributed to the observed agreement. Figure 7 reports mean bias sensitivity rates; we denote the baseline asâ . Across 40 open-ended dilemmas per model, sAX+BW reduces the mean sensitivity rate for both models. Forgpt-4o-mini, the rate decreases from 0.40 underâ to 0.275 with sAX+BW (absolute reduction 12.5 percentage points;âź31% relative). Forllama-3.1-8b, the rate decreases from 0.40 to 0.30 (absolute reduction â0.10;âź25% relative). Bootstrap CIs for the absolute reduction are wide, reflecting the modest sample size (e.g.,[â10.0,35.0]percentage points forgpt-4o-miniand[â7.5,27.5]percentage points for llama-3.1-8b), but the direction of effect is consistent across models. Discussion. These results indicate that the benefits of sAX+BW extend beyond strict, forced- choice protocols: the strategy lowers bias sensitivity (although it does not zero it, as it should in the selected dilemmas) even when answers are unconstrained and must be judged by content rather than format. This suggests practical utility in real-world SE assistance scenarios where outputs are naturally free-form. At the same time, additional work is required to test robustness in settings with richer action spaces (e.g., multiple viable options or multi-step plans) and to understand how sAX+BW interacts with diverse generation styles, longer contexts, and task-specific evaluation rubrics. Further experiments with larger samples and finer-grained coding schemes would help determine the conditions under which sAX+BW continues to suppress bias sensitivity when many alternative outputs are admissible. Summary RQ4 Answer In open-ended SE dilemmas, sAX+BW lowers mean bias sensitivity relative toâ for both models (gpt-4o-mini, 12.5 percentage points and 31% reduction;llama-3.1-8b, 10.0 percentage points and 25% reduction), indicating the proposed strategy can be effective at reducing bias sensitivity even without strict output constraints. 7 Post-hoc Validation on Real-World Coding Prompts (DevGPT) To complement the controlled PROBE-SWE benchmark, we check whether similar bias-inducing linguistic cues appear in real developer prompts. We analyse DevGPT [60] (35,784 prompts) with a triageâvalidate pipeline. Methodology. DevGPT is heterogeneous and contains many prompts that are not directly about coding, so we progressively narrow candidates and validate conservatively. (i) A DeBERTa-v3-base [30] classifier fine-tuned on PROBE-SWE flags prompts containing any of the eight cue types; we Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering17 retain prompts whose classifier-assigned probability of the bias class exceeds 0.6 (í=9,620). (i) On these, Qwen3-32B [62] filters to coding-related prompts (í=5,269). (i) Qwen3-32B extracts explicit cue phrases and proposes a single primary cue type. (iv) An author with computer science expertise manually reviews all cue-positive candidates and corrects labels. Manual validation targets a lower-bound prevalence estimate: we label a prompt as bias-inducing only if it contains an explicit, unambiguous cue phrase that could plausibly steer judgment, inde- pendent of task logic. We exclude technical polysemy (cue-like tokens used in routine programming discourse without the corresponding bias meaning), i.e., we discard apparent cues that are routine implementation directives or standard software-engineering terms (e.g., âuse this codeâ/âreferenceâ), unless they plausibly function as bias cues (e.g., anchoring bias). Since prompts are analysed out of conversational context, some cases cannot be fully disambiguated. For example, âThe previous version was fineâ (Table 1) may indicate an anchoring-like rollback request or a justified correction; we code such explicit rollback directives as likely anchoring cues under this limitation. Moreover, for bias-inducing prompts, we assign a single primary bias type (the most explicit one), even when multiple biases may co-occur. Operationally, we define the eight cue types as follows: confirmation (leading or tag questions seeking agreement, e.g., âright?â); framing (value-laden wording that frames an option or outcome); overconfidence (unwarranted certainty markers, e.g., âclearlyâ, âIâm almost sureâ); hyperbolic dis- counting (shortcut or temporary-fix language, e.g., âworkaroundâ, âfor nowâ); anchoring (explicit baseline or reversion directives, e.g., âgo back to the first solutionâ); availability (salient anecdotes, examples, or sources used as justification, e.g., âI read somewhereâ); bandwagon (appeals to popu- larity or consensus, e.g., âpopularâ, âpreferred wayâ); and hindsight (outcome-known retrospective phrasing, e.g., âturns outâ, âshould haveâ). The full inclusion and exclusion criteria are documented in the replication package. To validate that PROBE-SWEâs synthetic prompt pairs use cue surface forms that resemble real-world developer phrasing, we estimate a conservative cue-span alignment prevalence against the subset of manually validated DevGPT prompts known to contain bias-inducing cues. One author first selects representative DevGPTâPROBE-SWE cue examples (Table 1) as few-shot demonstrations [7]. For each validated DevGPT prompt, we retrieve the 25 most similar PROBE- SWE candidates of the same bias type using TFâIDF [1] over cue spans, and instruct Qwen3-32B (conditioned on the demonstrations) to decide whether any candidate exhibits a surface-form cue match, extracting the matching DevGPT substring and the corresponding PROBE-SWE cue span; the same author then manually validates all predicted matches. All implementation details are provided in the replication package [48]. Results. Qwen3-32B produced 239 cue-positive candidates. Manual review confirms explicit cues in 97/239 (40.59%) and rejects 142/239 (59.41%) as lacking bias cues; among confirmed cues, 94/97 (96.91%) retain the original type and 3 are relabelled. Overall, 97/5,269 coding prompts (1.84%) contain at least one explicit bias cue, corresponding to 97/35,784=0.27% of all DevGPT prompts (classifier-negative prompts were not audited). Confirmation (0.57%), framing (0.47%), and overconfidence (0.23%) are most prevalent in the corrected set (Table 1). Across seven of eight cue types, the validated DevGPT cue phrases have close PROBE-SWE counterparts (Table 1). One exception is hindsight: DevGPT often expresses it as self-correction (e.g., âI should have mentioned...â), whereas PROBE-SWE uses outcome-known retrospective narratives, yielding weaker surface-form alignment. Specifically, automated cue-span alignment suggests matches for 38/97 validated cues, and manual validation retains 24/97 (24.74%, Wilson 95% CI[17.23,34.18]%); bias- stratified percentages are in Table 1, with a notable 0/5 for hindsight. 18Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Post-hoc cue typeCount PROBE-aligned Example (verbatim DevGPT excerpt) PROBE-SWE analogous cue span Confirmation bias30 (0.57%)6.7%We donât need that second if, because ... Am I right? ... keeping passwords in plain text ... [is] so much easier to manage, right? Framing effect25 (0.47%)28.0%Add more exciting css too... but isnât it more exciting to release now and worry later? Overconfidence bias12 (0.23%)50.0%... im almost sure i need to add a library, right? ... I feel confident that there wonât be any unforeseen issues ... Hyperbolic discount- ing 9 (0.17%)44.4%... eliminate the screen size watching for now ... I think itâs better to avoid disruption for now. Anchoring bias6 (0.11%)16.7%This is not needed. The previous version was fine... I remember that in a previous project, the team didnât use a ... Bandwagon effect5 (0.09%)60.0%... it looks like linregress is popular, imple- ment the above using it. ... simplicity appealing over complexity, which seems to be a popular choice lately Availability bias5 (0.09%)20.0%I read somewhere that ...I remember reading somewhere that ... Hindsight bias5 (0.09%)0.0%i should have mentioned that the reset should come before the mode set... Shortly after production deployment... Table 1. Post-hoc prevalence of bias-inducing cues in coding-related DevGPT prompts. âCountâ reports frequency (% of coding prompts). For each bias type, we show a DevGPT cue excerpt and an analogous PROBE-SWE cue span; cue phrases are highlighted in green. Hindsight is marked in red due to differing surface forms. âPROBE-alignedâ reports the % of DevGPT prompts whose bias cues align with PROBE-SWE. Discussion. Bias-inducing cues akin to those of PROBE-SWE do occur in real developer prompts, but they are relatively sparse in the studied DevGPT data. The main false-positive source is technical polysemy: 142/239 (59.41%) model-flagged candidates were rejected because the cue token was used in a technical sense (notably for anchoring), motivating the protocol and manual correction in the first place. Conditional on a correct bias-inducing cue, cue-type assignment was stable (3/97=3.09% relabelled). Notably, unlike PROBE-SWE, DevGPT prompts typically lack an options-based format; as discussed in RQ4, that structure is a measurement artifact used to quantify bias sensitivity. The example-level cue-span alignment supports ecological plausibility of PROBE-SWE for seven cue types and suggests an extension for hindsight: add a self-correction-style hindsight subfamily while preserving controls against technical polysemy. Notably, these DevGPT analyses are only conservative lower-bound prevalence estimates: they only check whether the PROBE-SWE biases occur in real-world coding prompts. Future work should audit beyond classifier-positive prompts and improve cue extraction to reduce false negatives while keeping false positives low. 8 Threats to Validity Construct Validity. Although, in our study, cognitive biases are drawn from prior work [10,36,49], some biases may be under-represented or interact in ways our controlled settings cannot fully reflect. Nonetheless, this work offers a first step; future research can extend it to other scenarios. Internal Validity & Reliability. We reduced variability by running thousands of dilemmas five times per GPAI system and using consistent system instructions. However, GPAI outputs remain non-deterministic, and sampling hyperparameters (e.g., temperature, top-p) can introduce addi- tional variance [39]. For the qualitative analyses (RQ3âRQ4), RQ3 relies on single-coder analysis (assisted by an LLM) and therefore does not allow inter-rater reliability estimation. This design may introduce subjectivity and automation bias, although final coding decisions were made by a human [17,58]. RQ4 uses dual independent coding with third-party adjudication, which reduces but does not eliminate subjectivity-related risks. The analysis of RQ3 also has measurement limi- tations. The lexicon was derived inductively from random samples and may omit relevant cues. Feature extraction uses regular expressions and ignores local context; we therefore excluded highly polysemous tokens, but the approach still cannot fully capture all semantic nuances. These choices trade contextual fidelity for transparency and replicability. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering19 External Validity. Our experiments focused on software engineering tasks using six cost-effective GPAI systems (GPT-4o and GPT-4.1 variants, LLaMA variants, and DeepSeek-R1) [20,51]. Con- cretely, our experimental matrix comprises 6 target models, 14 prompting strategies, and 2 bias conditions (present vs. absent), each evaluated on 2,368 dilemma pairs, with 5 independent runs per bias condition, yielding a total of 1,989,120 decision generations. Strategies using two-step axiom extraction (2sAX) add 142,080 best-practice elicitation calls, for 2,131,200 LLM calls overall. Based on the prompt corpus (including the system prompts used in our scripts) and the average output length, this corresponds to approximately 730M input tokens and 152M output tokens, using a 3.5-characters-per-token approximation and excluding any hidden reasoning tokens. At current OpenAI prices, this workload would cost (at least, ignoring reasoning tokens) about $0.13k onGPT-4.1-nano($0.10/$0.40 per 1M input/output tokens), $0.20k onGPT-4o-mini($0.15/$0.60), $0.54k onGPT-4.1-mini($0.40/$1.60), and on the order of $3.4k onGPT-5.2($1.75/$14) [38]; the same workload would be about $7.4k on Anthropic claude-opus-4-6 ($5/$25) [5]. To strengthen practical relevance, we additionally quantify how often real developer prompts in DevGPT [60] exhibit linguistic cues analogous to those used in PROBE-SWE and provide representative examples. In the AI-screened DevGPT subset, we identified 5,269 coding-related prompts; 97 (1.84%) contained at least one explicit cue after manual correction (cf. Section 7). Finally, while simplified vignettes (i.e., constrained binary choices) aid clarity, they may not capture the complexity of real software engineering decisions. Nonetheless we triangulate our operationalization by combining strict-format automated scoring on PROBE-SWE with an open- ended replication (RQ4) manually annotated forgpt-4o-miniandllama-3.1-8b, both converging on reduced bias sensitivity under sAX+BW. Finally, since we considered only text-to-text GPAI systems, results may not extend to multimodal or audio-visual systems [13]. 9 Conclusions & Future Work GPAI systems used for SE decision support are vulnerable to prompt-induced cognitive biases: small, non-logical phrasing changes can measurably shift decisions away from task-optimal reasoning, even when task logic is held constant. Across six cost-effective GPAI models and eight SE-relevant bias families, we showed that widely recommended prompt-engineering tactics (i.e., chain-of- thought, implication prompting) do not consistently reduce this sensitivity after two-sided testing withFDRcorrection. In contrast, making the otherwise implicit SE best practices explicit, via axiomatic reasoning cues, consistently lowers bias sensitivity by roughly 50% on average (up to 73% in some families,í< .001), with benefits that persist across models and task complexity tiers (with the high-complexity setting as a partial exception afterFDRcorrection). Our thematic analysis further identifies linguistic contexts that correlate with higher sensitivity (e.g., throughput- and platform-centric talk under time pressure, evaluative tone) and with resistance (e.g., testing/quality, documentation, ML/AI terminology), offering practical signals for when GPAI assistance is riskier. We distil the following guidance for SE teams integrating GPAI into decision workflows: ⢠Prefer axiomatic prompts. Use axiomatic background self-elicitation (sAX) as a default scaffold; in our tests, sAX+imperative self-debiasing(+impersonated) achieved the lowest sensitivity overall. ⢠Keep cues short, normative, and option-agnostic. Express best practices as brief, declar- ative rules tied to the dilemmaâs objective (e.g., maintainability vs. time-to-market) without leaking option wording. â˘Be hindsight-aware. When outcome information is present, mask it or request a counter- factual restatement before injecting axiomatic background; sAX can otherwise be co-opted into post hoc rationalization (under hindsight bias). 20Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli â˘Exploit retrieval. Maintain a lightweight repository of vetted SE best practices (e.g., design principles, risk/impact heuristics) and inject only the most relevant axiomatic background at inference time (RAG-style) to help reduce prompt length and potentially lower latency and hallucination risk (i.e., model errors). â˘Gate by context signals. Treat prompts rich in performance/platform/time-pressure language as high-risk; add stronger cues, require explicit trade-off checks, or escalate to human review on high-tier dilemmas. â˘Audit and evaluate. Log decisions with their axiomatic backgrounds and justifications; periodically re-evaluate models on PROBE-SWE to monitor drift as models and prompts evolve. The replication package supports this process [48]. Our study focuses on text-to-text GPAI and binary-choice dilemmas synthesized from PROBE- SWE; real-world decisions may be multi-criteria, multi-option, and multi-turn, and best practices can conflict. Axiomatic prompting increases token budget and may over-regularize edge cases. Finally, hindsight bias remains a notable outlier where generic axiomatic background self-elicitation offers limited protection. As future work, we see several directions to strengthen robustness and utility: develop hindsight- specific mitigations such as detectors for outcome cues and tailored protocols (e.g., enforced counterfactual restatement, structured uncertainty reporting); learn adaptive scaffolding policies that decide when and how many SE best practices to inject based on dilemma complexity, detected bias cues, and calibration signals; curate external, organization-specific best-practice knowledge bases and study retrieval strategies that balance cost and coverage; and replicate on frontier-grade models (e.g., Claude Opus 4.6) across a broader set of SE tasks to test whether prompt-induced bias sensitivity persists with increased capability and to characterize how baseline severity and mitigation gains vary with model scale. Overall, our results caution against relying on generic prompting to counter cognitive biases in GPAI-assisted SE. Making domain norms explicit (through the elicitation of concise, Prolog-inspired axiomatic backgrounds) substantially improves robustness with minimal process change, and offers a practical path toward safer, more dependable GPAI decision support in software engineering. Data Availability All the data and scripts used for this paper are available in our replication package [48]. Acknowledgments F. Sovrano and A. Bacchelli acknowledge the partial support of the Swiss National Science Founda- tion for the SNF Project 200021_197227. References [1]Akiko Aizawa. 2003. An information-theoretic perspective of tfâidf measures. Information Processing & Management 39, 1 (2003), 45â65. [2]Muhammad Azeem Akbar, Arif Ali Khan, and Peng Liang. 2025. Ethical aspects of ChatGPT in software engineering research. IEEE Transactions on Artificial Intelligence 6, 2 (Feb. 2025), 254â267. doi:10.1109/TAI.2023.3318183 [3] Maryam Amirizaniani, Elias Martin, Maryna Sivachenko, Afra Mashhadi, and Chirag Shah. 2024. Can LLMs Reason Like Humans? Assessing Theory of Mind Reasoning in LLMs for Open-Ended Questions. In Proceedings of the 33rd ACM International Conference on Information and Knowledge Management (CIKM â24). Association for Computing Machinery, New York, NY, USA, 34â44. doi:10.1145/3627673.3679832 [4]Julia Angwin, Jeff Larson, Surya Mattu, and Lauren Kirchner. 2022. Machine Bias. In Ethics of Data and Analytics: Concepts and Cases, Kirsten Martin (Ed.). Auerbach Publications (CRC Press), Boca Raton, FL, USA, 254â264. doi:10. 1201/9781003278290-37 [5]Anthropic. 2026. Claude Opus: Availability and pricing. https://platform.claude.com/docs/en/about-claude/pricing. Accessed: 2026-02-16. Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering21 [6]Yoav Benjamini and Yosef Hochberg. 1995. Controlling the false discovery rate: a practical and powerful approach to multiple testing. Journal of the Royal statistical society: series B (Methodological) 57, 1 (1995), 289â300. [7] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al.2020. Language models are few-shot learners. Advances in neural information processing systems 33 (2020), 1877â1901. [8]Gul Calikli and Ayse Basar Bener. 2010. Empirical Analyses of the Factors Affecting Confirmation Bias and the Effects of Confirmation Bias on Software Developer/Tester Performance. In Proceedings of the 6th International Conference on Predictive Models in Software Engineering (PROMISE â10) (Timisoara, Romania). Association for Computing Machinery, New York, NY, USA, 10. doi:10.1145/1868328.1868344 [9]A. Colin Cameron and Pravin K. Trivedi. 2013. Regression Analysis of Count Data (2 ed.). Cambridge University Press, Cambridge, UK. doi:10.1017/CBO9781139013567 [10] Souti Chattopadhyay, Nicholas Nelson, Audrey Au, Natalia Morales, Christopher A. Sanchez, Rahul Pandita, and Anita Sarma. 2020. A Tale from the Trenches: Cognitive Biases and Software Development. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (ICSE â20) (Seoul, Republic of Korea). Association for Computing Machinery, New York, NY, USA, 654â665. [11] Zhenpeng Chen, Jie M Zhang, Federica Sarro, and Mark Harman. 2023. A comprehensive empirical study of bias mitigation methods for machine learning classifiers. ACM transactions on software engineering and methodology 32, 4 (2023), 1â30. [12]Andrei-Victor Chisca, Andrei-Cristian Rad, and Camelia Lemnaru. 2024. Prompting Fairness: Learning Prompts for Debiasing Large Language Models. In Proceedings of the Fourth Workshop on Language Technology for Equality, Diversity, Inclusion (LTEDI 2024). Association for Computational Linguistics, St. Julianâs, Malta, 52â62. doi:10.18653/v1/2024.ltedi- 1.6 [13]Colton Clemmer, Junhua Ding, and Yunhe Feng. 2024. PreciseDebias: An Automatic Prompt Engineering Approach for Generative AI To Mitigate Image Demographic Biases. In Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision (WACV) (Waikoloa, HI, USA). IEEE, Piscataway, NJ, USA, 8596â8605. [14]Juliet Corbin and Anselm Strauss. 2014. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory (4 ed.). SAGE Publications, Thousand Oaks, CA, USA. [15] Juliet M. Corbin and Anselm Strauss. 1990. Grounded Theory Research: Procedures, Canons, and Evaluative Criteria. Qualitative Sociology 13, 1 (1990), 3â21. doi:10.1007/BF00988593 [16]Shih-Chieh Dai, Aiping Xiong, and Lun-Wei Ku. 2023. LLM-in-the-loop: Leveraging Large Language Model for Thematic Analysis. In Findings of the Association for Computational Linguistics: EMNLP 2023. Association for Computational Linguistics, Singapore, 9993â10001. doi:10.18653/v1/2023.findings-emnlp.669 [17] Zackary Okun Dunivin. 2025. Scaling hermeneutics: a guide to qualitative coding with LLMs for reflexive content analysis. EPJ Data Sci. 14, 1 (2025), 28. doi:10.1140/EPJDS/S13688-025-00548-8 [18]Fred Ederer and Nathan Mantel. 1974. Confidence limits on the ratio of two Poisson variables. American Journal of Epidemiology 100, 3 (1974), 165â167. [19]Alvan R. Feinstein and Domenic V. Cicchetti. 1990. High Agreement but Low Kappa: I. The Problems of Two Paradoxes. Journal of Clinical Epidemiology 43, 6 (1990), 543â549. doi:10.1016/0895-4356(90)90158-L [20] Samuel Ferino, Rashina Hoda, John Grundy, and Christoph Treude. 2025. Junior Software Developersâ Perspectives on Adopting LLMs for Software Engineering: A Systematic Literature Review. arXiv. arXiv:2503.07556 https: //arxiv.org/abs/2503.07556 [21]Marvin Fleischmann, Miglena Amirpur, Alexander Benlian, and Thomas Hess. 2014. Cognitive Biases in Information Systems Research: A Scientometric Analysis. In Proceedings of the European Conference on Information Systems (ECIS 2014). AIS Electronic Library (AISeL), Tel Aviv, Israel, 1â21. https://aisel.aisnet.org/ecis2014/proceedings/track02/5/ [22] Raymond Fok and Daniel S Weld. 2024. In search of verifiability: Explanations rarely enable complementary perfor- mance in AI-advised decision making. AI Magazine 45, 3 (2024), 317â332. [23]Shaz Furniturewala, Surgan Jandial, Abhinav Java, Pragyan Banerjee, Simra Shahid, Sumit Bhatia, and Kokil Jaidka. 2024. Thinking Fair and Slow: On the Efficacy of Structured Prompts for Debiasing Language Models. arXiv. arXiv:2405.10431 https://arxiv.org/abs/2405.10431 [24]Ben Green and Yiling Chen. 2019. The principles and limits of algorithm-in-the-loop decision making. Proceedings of the ACM on human-computer interaction 3, CSCW (2019), 1â24. [25]Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, et al.2025. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv. arXiv:2501.12948 https://arxiv.org/abs/2501.12948 [26]Yue Guo, Yi Yang, and Ahmed Abbasi. 2022. Auto-Debias: Debiasing Masked Language Models with Automated Biased Prompts. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Smaranda Muresan, Preslav Nakov, and Aline Villavicencio (Eds.). Association for Computational Linguistics, 22Francesco Sovrano, Gabriele Dominici, and Alberto Bacchelli Dublin, Ireland, 1012â1023. doi:10.18653/v1/2022.acl-long.72 [27]Kilem L. Gwet. 2008. Computing Inter-Rater Reliability and Its Variance in the Presence of High Agreement. Brit. J. Math. Statist. Psych. 61, 1 (2008), 29â48. doi:10.1348/000711006X126600 [28]Zhiyong Han, Aaron Tavasi, JuYoung Lee, Joshua Luzuriaga, Kevin Suresh, Michael Oppenheim, Fortunato Battaglia, Stanley R. Terlecky, et al.2025. Can Large Language Models Be Used to Code Text for Thematic Analysis? An Explorative Study. Discover Artificial Intelligence 5 (2025), 171. doi:10.1007/s44163-025-00441-3 [29] Martie G. Haselton, Daniel Nettle, and Paul W. Andrews. 2015. The Evolution of Cognitive Bias. In The Handbook of Evolutionary Psychology, David M. Buss (Ed.). Wiley, Hoboken, NJ, USA, 724â746. doi:10.1002/9781119125563. evpsych241 [30]Pengcheng He, Jianfeng Gao, and Weizhu Chen. 2021.DeBERTaV3: Improving DeBERTa using ELECTRA- Style Pre-Training with Gradient-Disentangled Embedding Sharing. 16 pages. doi:10.48550/arXiv.2111.09543 arXiv:2111.09543 [cs.CL] arXiv:2111.09543v4 (revised 2023-03-24). [31] Ken Hyland. 2005. Stance and engagement: A model of interaction in academic discourse. Discourse studies 7, 2 (2005), 173â192. [32]Jan Kottner, Laurent AudigĂŠ, Stig Brorson, Allan Donner, Byron J. Gajewski, Asbjorn Hrobjartsson, Chris Roberts, Mohamed Shoukri, and David L. Streiner. 2011. Guidelines for Reporting Reliability and Agreement Studies (GRRAS) Were Proposed. Journal of Clinical Epidemiology 64, 1 (2011), 96â106. doi:10.1016/j.jclinepi.2010.03.002 [33] Matthew Lombard, Jennifer Snyder-Duch, and Cheryl Campanella Bracken. 2002. Content Analysis in Mass Commu- nication: Assessment and Reporting of Intercoder Reliability. Human Communication Research 28, 4 (2002), 587â604. doi:10.1111/j.1468-2958.2002.tb00826.x [34] Peter McCullagh and John A. Nelder. 1989. Generalized Linear Models (2 ed.). Chapman & Hall/CRC, London. [35] Mary L. McHugh. 2012. Interrater Reliability: The Kappa Statistic. Biochemia Medica 22, 3 (2012), 276â282. doi:10. 11613/BM.2012.031 [36]Rahul Mohanani, Iflaah Salman, Burak Turhan, Pilar RodrĂguez, and Paul Ralph. 2018. Cognitive biases in software engineering: A systematic mapping study. IEEE Transactions on Software Engineering 46, 12 (2018), 1318â1339. [37]Yaniv Nikankin, Anja Reusch, Aaron Mueller, and Yonatan Belinkov. 2024. Arithmetic without Algorithms: Language Models Solve Math with a Bag of Heuristics. arXiv. arXiv:2410.21272 https://arxiv.org/abs/2410.21272 [38] OpenAI. 2026. OpenAI API Pricing. https://developers.openai.com/api/docs/pricing. Accessed: 2026-02-16. [39]Shuyin Ouyang, Jie M Zhang, Mark Harman, and Meng Wang. 2025. An empirical study of the non-determinism of chatgpt in code generation. ACM Transactions on Software Engineering and Methodology 34, 2 (2025), 1â28. [40]J. Przyborowski and H. Wilenski. 1940. Homogeneity of results in testing samples from Poisson series: With an application to testing clover seed for dodder. Biometrika 31, 3-4 (1940), 313â323. doi:10.1093/biomet/31.3-4.313 [41] Hongye Qiu, Yue Xu, Meikang Qiu, and Wenjie Wang. 2025. DR. GAP: Mitigating Bias in Large Language Models using Gender-Aware Prompting with Demonstration and Reasoning. arXiv. arXiv:2502.11603 https://arxiv.org/abs/ 2502.11603 [42]Asha Rajbhoj, Akanksha Somase, Piyush Kulkarni, and Vinay Kulkarni. 2024. Accelerating Software Development Using Generative AI: ChatGPT Case Study. In Proceedings of the 17th Innovations in Software Engineering Conference (ISEC 2024) (Bangalore, India). Association for Computing Machinery, New York, NY, USA, 1â11. [43] Amirali Sajadi, Kostadin Damevski, and Preetha Chatterjee. 2025. Psycholinguistic Analyses in Software Engineering Text: A Systematic Literature Review. arXiv. arXiv:2503.05992 https://arxiv.org/abs/2503.05992 [44] Johnny SaldaĂąa. 2011. Fundamentals of Qualitative Research. Oxford University Press, New York, NY. [45] Johnny SaldaĂąa. 2025. The Coding Manual for Qualitative Researchers. SAGE Publications Ltd, London, UK. [46] Aleix Sant, Carlos Escolano, Audrey Mash, Francesca De Luca Fornaciari, and Maite Melero. 2024. The Power of Prompts: Evaluating and Mitigating Gender Bias in MT with LLMs. arXiv. arXiv:2407.18786 https://arxiv.org/abs/2407.18786 [47] Timo Schick, Sahana Udupa, and Hinrich SchĂźtze. 2021. Self-diagnosis and self-debiasing: A proposal for reducing corpus-based bias in nlp. Transactions of the Association for Computational Linguistics 9 (2021), 1408â1424. [48]Francesco Sovrano. 2025. Replication Package of "Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering". https://github.com/Francesco-Sovrano/GPAI-sensitivity-to-cognitive-bias-in-software- engineering. [49]Francesco Sovrano, Gabriele Dominici, Rita Sevastjanova, Alessandra Stramiglio, and Alberto Bacchelli. 2025. Is General-Purpose AI Reasoning Sensitive to Data-Induced Cognitive Biases? Dynamic Benchmarking on Typical Software Engineering Dilemmas. arXiv. arXiv:2508.11278 https://arxiv.org/abs/2508.11278 [50]Francesco Sovrano and Tim Miller. 2025. MAGIX: A Unified Framework for the Use of XAI in Enterprises. Springer Nature Switzerland, Cham, 183â209. doi:10.1007/978-3-032-01940-0_6 [51]Benyamin Tabarsi, Heidi Reichert, Ally Limke, Sandeep Kuttal, and Tiffany Barnes. 2025. LLMsâ Reshaping of People, Processes, Products, and Society in Software Development: A Comprehensive Exploration with Early Adopters. arXiv. arXiv:2503.05012 https://arxiv.org/abs/2503.05012 Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering23 [52]Yla R Tausczik and James W Pennebaker. 2010. The psychological meaning of words: LIWC and computerized text analysis methods. Journal of language and social psychology 29, 1 (2010), 24â54. [53] Amos Tversky and Daniel Kahneman. 1974. Judgment under Uncertainty: Heuristics and Biases. Science 185, 4157 (1974), 1124â1131. doi:10.1126/science.185.4157.1124 [54]Helena Vasconcelos, Matthew JĂśrke, Madeleine Grunde-McLaughlin, Tobias Gerstenberg, Michael S Bernstein, and Ranjay Krishna. 2023. Explanations can reduce overreliance on ai systems during decision-making. Proceedings of the ACM on Human-Computer Interaction 7, CSCW1 (2023), 1â38. [55]Jonathan Wang and Donald A Redelmeier. 2024. Cognitive biases and artificial intelligence. NEJM AI 1, 12 (2024), AIcs2400639. [56]Thomas Weber, Maximilian Brandmaier, Albrecht Schmidt, and Sven Mayer. 2024. Significant productivity gains through programming with large language models. Proceedings of the ACM on Human-Computer Interaction 8, EICS (2024), 1â29. [57] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al.2022. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems 35 (2022), 24824â24837. [58] Chuanchi Wen, Paul Clough, Rachel Paton, and Rebecca Middleton. 2026. Leveraging Large Language Models for Thematic Analysis: A Case Study in the Charity Sector. AI & Society 41 (2026), 731â748. doi:10.1007/s00146-025-02487-4 [59]Halbert White. 1980. A heteroskedasticity-consistent covariance matrix estimator and a direct test for heteroskedasticity. Econometrica 48, 4 (1980), 817â838. [60]Tao Xiao, Christoph Treude, Hideaki Hata, and Kenichi Matsumoto. 2024. DevGPT: Studying Developer-ChatGPT Conversations. In 21st IEEE/ACM International Conference on Mining Software Repositories, MSR 2024, Lisbon, Portugal, April 15-16, 2024, Diomidis Spinellis, Alberto Bacchelli, and Eleni Constantinou (Eds.). ACM, Lisbon, Portugal, 227â230. doi:10.1145/3643991.3648400 [61]Ziyang Xu, Keqin Peng, Liang Ding, Dacheng Tao, and Xiliang Lu. 2024. Take Care of Your Prompt Bias! Investigating and Mitigating Prompt Bias in Factual Knowledge Extraction. arXiv. arXiv:2403.09963 https://arxiv.org/abs/2403.09963 [62]An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 Technical Report. doi:10.48550/arXiv.2505.09388 arXiv:2505.09388 [cs.CL]