How Reasoning Shapes Social Bias in LLM-Generated Code?

How Reasoning Shapes Social Bias in LLM-Generated Code? Weifeng Sun

Jieke Shi

Zhou Yang

Singapore Management University Singapore, Singapore wfsun@smu.edu.sg

Singapore Management University Singapore, Singapore jiekeshi@smu.edu.sg

University of Alberta Alberta Machine Intelligence Institute Alberta, Canada zy25@ualberta.ca

Yuchen Chen

Hongyan Li∗

Meng Yan

Nanjing University Nanjing, China yuc.chen@smail.nju.edu.cn

Chongqing University Chongqing, China hongyan.li@cqu.edu.cn

mengy@cqu.edu.cn Chongqing University Chongqing, China

David Lo

arXiv:2608.06829v1 [cs.SE] 7 Aug 2026

Singapore Management University Singapore, Singapore davidlo@smu.edu.sg

Abstract Large language models (LLMs) are increasingly used for code generation, but recent studies have shown that generated programs can exhibit code bias, i.e., unfair or differential treatment encoded in code logic with respect to sensitive demographic attributes. Although prior work has investigated this problem in a direct generation setting, it remains unclear how bias behaves in reasoning-based code generation, where models produce intermediate reasoning traces before generating the final code. To bridge this gap, we conduct the first systematic empirical study of social bias in reasoning-based code generation. We evaluate 9 models spanning both standard LLMs and large reasoning models (LRMs) on realistic bias-sensitive coding tasks covering three human-centered decision scenarios. Our results reveal four main findings. First, reasoning generally reduces code bias, lowering the average bias rate from 0.64 to 0.40, but the improvement is highly model-dependent. Second, reasoningbased generation does not consistently preserve code quality, with the average quality dropping from 0.72 to 0.59. We further find that biased reasoning strongly predicts biased code, and that simply adjusting generation configurations is insufficient for robust bias mitigation. Motivated by these findings, we propose ProbeDebias, a reasoning-aware debiasing framework that detects biased reasoning traces and rewrites them before final code generation. Extensive experiments demonstrate that ProbeDebias achieves 87.76% F1 on reasoning-bias detection and reduces code bias by 83.73% on average while largely preserving code quality. Compared with SOTA baselines, it further reduces average bias rate by 52.70%–54.42% and improves quality by 9.79%–36.79%. These results highlight the ∗ Corresponding author.

This work is licensed under a Creative Commons Attribution 4.0 International License. ASE ’26, Munich, Germany © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2882-2/2026/10 https://doi.org/10.1145/3832783.3834387

importance of reasoning-stage analysis for trustworthy code generation and suggest that detecting and repairing biased reasoning is a promising direction for mitigating code bias.

CCS Concepts • Software and its engineering → Software reliability; • Computing methodologies → Artificial intelligence; • Social and professional topics → User characteristics.

Keywords Large language models, Code generation, Code bias, Fairness ACM Reference Format: Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo. 2026. How Reasoning Shapes Social Bias in LLM-Generated Code?. In Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE ’26), October 12–16, 2026, Munich, Germany. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/ 3832783.3834387

1

Introduction

As large language models (LLMs) are widely adopted for code generation [8, 22, 55] and integrated into AI-assisted programming tools such as GitHub Copilot [37], the trustworthiness of LLMgenerated code has become an important concern [23, 44, 45, 60], spanning issues such as security vulnerabilities [12, 35], correctness failures [5, 30], and social bias [18, 29, 33]. In particular, recent studies have shown that LLM-generated code can exhibit code bias, i.e., social biases manifested in the decision logic of code [19, 29, 33], such as unfair treatment based on gender, age, race, or socioeconomic status. Empirical evidence suggests that such biases are far from isolated: up to 49.10% of generated functions exhibit biased behaviors in tasks involving sensitive demographic decisions, such as hiring, credit assessment, and healthcare [18], potentially leading to unfair automated outcomes once deployed. Prior studies have begun to investigate code bias through dedicated testing frameworks and benchmarks. Huang et al. [18] propose a bias-testing framework for code generation, while Du et

ASE ’26, October 12–16, 2026, Munich, Germany

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

Prior Work: Bias in Direct Code Generation

This Paper: Bias in Reasoning-Based Code Generation

[User Prompt]

[User Prompt] Huang et al.

[LLM (Standard)] Direct Generation (no reasoning)

[Generated Code]

Our Work

[LLM (Standard) + Large Reasoning Model]

Up to 49.10% of generated functions show biased behavior

[Bias Testing / Evaluation]

Limited / incomplete understanding – bias is observed but the reasoning process is not considered

[Reasoning Trace <think>…</think>] <think>…Intermediate reasoning steps…</think>

[Generated Code]

Research Question: “Does reasoning influence bias?”

[Bias Ayalysis at Both stages]

Reasoning-based paradigm-unexplored for code bias

Figure 1: Prior work vs. our problem setting. al. [9] introduce FairCoder, a benchmark that assesses bias in coderelated tasks spanning both function implementation and unit test generation. Ling et al. [29] further develop Solar, an automated framework that uses generated test cases to uncover social bias in synthesized code. Despite differences in evaluation design, such studies mainly examine bias in standard LLMs operating under a direct generation paradigm, where code is generated directly from the prompt without an explicit reasoning stage, as shown in Figure 1. Recent advances in large reasoning models (LRMs), including DeepSeek-R1 [15], Qwen3/QwQ [53], and Phi-4-reasoning [3], have introduced a new generation paradigm in which models produce explicit reasoning traces (RTs), i.e., intermediate thinking steps that decompose the task before generating the final code output, often strengthened through reinforcement learning and additional test-time compute [27, 32, 42, 57, 63]. This reasoning-based paradigm is increasingly adopted in code generation and has shown strong performance [42, 51, 54, 64, 65]. However, it is worth noting that the final output is shaped by both the prompt and the intermediate reasoning process, introducing a new and unexplored source of potential bias. This raises a critical question that we aim to investigate: Does the reasoning process itself influence the emergence of social bias in generated code? That is, whether reasoning traces reduce bias by enabling explicit deliberation over fairness concerns, or conversely, amplify it if the reasoning process reflects stereotypical assumptions. To answer this question, we conduct the first systematic empirical study of social bias in reasoning-based code generation. Specifically, we evaluate 9 models spanning both standard/nonreasoning LLMs (e.g., Llama-3.1-8B, Qwen2.5-Coder-7B) and LRMs (e.g., Qwen3-32B and DeepSeek-R1-Distill-Llama-8B) on realistic bias-sensitive coding tasks covering three human-centered decision scenarios: job hiring, college admission, and medical treatment. To isolate the effect of reasoning, we compare two forms of reasoningenabled generation: Chain-of-Thought (CoT) prompting via a simple “Let’s think step-by-step!” instruction that elicits reasoning from standard LLMs, and the native reasoning mechanisms of LRMs. Importantly, the prompts do not mention fairness requirements, so as to reflect realistic code generation settings where such constraints are often absent. We further jointly evaluate code bias and quality, allowing us to characterize the trade-off of fairness–quality introduced by reasoning. Our study finds that: • Effects of Reasoning on Code Bias (RQ1, Section 4.1) (1) Reasoning generally reduces code bias, lowering the average bias rate from 0.64 to 0.40. However, this reduction stems from

generating biased code less frequently, rather than mitigating the severity of the bias when it does occur. (2) CoT-prompted standard LLMs benefit significantly more from reasoning than LRMs with native reasoning, possibly because native reasoning is optimized primarily for task performance rather than fairness considerations. (3) The bias reduction from reasoning comes at a cost: code quality drops from 0.72 to 0.59 on average, revealing a fairness–quality trade-off. • Bias Propagation from Reasoning to Code (RQ2, Section 4.2) (4) Biased reasoning frequently leads to biased code, with the propagation rate being highest in high-stakes scenarios such as medical treatment (56.1%). (5) Unbiased reasoning does not guarantee unbiased outputs, indicating that bias can emerge in the transition from reasoning to code, even when the reasoning is unbiased. • Effects of Generation Configurations on Code Bias (RQ3, Section 4.3) (6) Longer reasoning budgets, higher sampling temperatures, and later placement of sensitive attributes in the prompt can reduce code bias for standard LLMs (e.g., bias rate from 0.56 to 0.35 under longer reasoning), but consistently degrade code quality. (7) LRMs remain largely robust to all configuration changes, including reasoning length, temperature, and sensitive attribute position. Motivated by these findings, we propose ProbeDebias, a reas oning-aware debiasing framework that explicitly intervenes at the reasoning stage. ProbeDebias consists of two key components: (1) a lightweight bias detector that identifies biased reasoning traces by measuring how easily the target model predicts a bias-indicative probe sentence appended to the trace, and (2) a rewriting module that removes biased reasoning patterns and generates fair code conditioned on the debiased trace. Experiments show that ProbeDebias achieves strong performance on both bias detection and mitigation: it reaches 87.76% F1-score on reasoning-bias detection and reduces code bias by 83.73% on average while largely preserving code quality, outperforming prompt-based mitigation baselines. Our contributions can be summarized as follows: 1) We present the first comprehensive empirical study of code bias under reasoning-based code generation, covering standard LLMs and LRMs across three real-world decision scenarios. 2) We reveal that biased reasoning often leads to biased code, while unbiased reasoning does not guarantee fair outputs, and that simple configuration tuning is insufficient for bias mitigation. 3) We propose ProbeDebias, a reasoning-aware framework that detects and repairs biased reasoning traces, achieving 87.76% F1-score in reasoning-bias detection and reducing code bias by 83.73% on average while preserving nearly the same code quality.

2 Background and Related Work 2.1 Bias in Code Generation Models As LLMs are increasingly used for automated code generation, concerns have emerged that generated code may inherit social biases from training data. Unlike biased natural-language outputs, such bias can be directly embedded into program logic, decision rules,

How Reasoning Shapes Social Bias in LLM-Generated Code?

❏ Requirement: Write a function to evaluate a job applicant’s score based on their qualifications. ✗ Biased code score = 0

✓ Unbiased code score = 0

if applicant.gpa >= 3.7: score += 2

if applicant.gpa >= 3.7: score += 2

if applicant.gender == "male": score += 1

if applicant.skills >= 8: score += 1

Figure 2: Illustration of biased and unbiased code. and control flow. For example, a model may generate a candidatescoring function that assigns additional scores based on gender rather than task-relevant attributes such as GPA or skills (Figure 2), encoding discriminatory rules into executable code that directly affects deployed software in human-centered decision scenarios. Recent work has begun to investigate this problem from different perspectives [21, 25, 36, 39, 61]. Liu et al. [33] uncover social bias in code generation models through carefully designed prompts and demographic templates, showing that pre-trained code models can produce systematically biased outputs. Huang et al. [18] and Du et al. [9] further study code bias under more realistic coding tasks and introduce task-specific evaluation frameworks and benchmarks, such as FairCoder, to assess bias in generated code. Ling et al. [28] propose Solar, an automated framework that uses generated test cases to uncover and mitigate social bias in synthesized code. However, existing work mainly focuses on direct generation, where code is produced directly from the prompt, and does not examine how bias emerges under reasoning-based code generation. In contrast, our work studies code bias in the presence of explicit reasoning traces, analyzes the relationship between reasoning bias and final code bias, and further proposes a reasoning-aware framework to detect and mitigate biased reasoning before final code generation.

2.2

Reasoning in Large Language Models

Reasoning in LLMs is commonly realized in two forms: CoT-induced reasoning in standard LLMs and native reasoning in large reasoning models (LRMs). For standard LLMs, CoT prompting elicits intermediate reasoning steps at inference time and has been shown to improve performance on complex tasks [50], with subsequent extensions such as zero-shot CoT [24], self-consistency [49], and Tree-of-Thoughts [56]. However, prior work on reasoning has primarily focused on improving task performance, with little attention to how reasoning may shape social bias in generated code. In this work, we study code bias under both settings: CoT-induced reasoning in standard LLMs and native reasoning in LRMs.

3 Study Design 3.1 Overall Framework Figure 3 illustrates the overall experimental framework of our study on social bias in reasoning-based code generation. Starting from bias-sensitive tasks, we construct prompts that require models to generate decision-making code involving sensitive attributes. For LRMs, we use their native reasoning mechanism to produce reasoning traces and final code outputs. For standard LLMs, we employ Chain-of-Thought (CoT) prompting to elicit intermediate reasoning before code generation. Our study is organized into four parts:

ASE ’26, October 12–16, 2026, Munich, Germany

(1) We evaluate code bias using the metrics introduced in Section 3.6, including Bias Rate, Preference Entropy, and Fairness Score to quantify how reasoning affects bias in generated programs (RQ1). (2) We then analyze the reasoning traces to examine whether biased reasoning is associated with biased code (RQ2). (3) Next, we study how generation configurations influence bias, including reasoning length, sampling strategy, and the placement of sensitive attributes in prompts (RQ3). (4) Finally, we explore whether code bias can be mitigated without substantially reducing code quality (RQ4).

3.2

Task Definition

In this paper, we use social bias to refer to unfair treatment related to sensitive attributes, and use code bias to denote its manifestation in generated code. We first formalize the concepts used in our study. Definition 1 (Sensitive attribute). A sensitive attribute refers to a personal attribute such as race or gender that should not influence decision-making to prevent social bias. We denote the set of sensitive attributes as A, where |A| ≥ 1. Following the notions of causal discrimination and statistical parity in fairness research [7, 13], we define code bias as follows. Definition 2 (Code bias). Let 𝑓 denote a generated program whose input attributes consist of sensitive attributes A and nonsensitive attributes N A. Given a sensitive attribute 𝑎𝑖 ∈ A, we say that the generated program exhibits code bias if its decision logic treats distinct values of 𝑎𝑖 unequally while holding all nonsensitive attributes constant.

3.3

Research Questions

In this work, we address the following Research Questions (RQs): RQ1. How does reasoning influence social bias in generated code? RQ2. Is bias in intermediate reasoning associated with code bias? RQ3. How do generation configurations affect code bias? RQ3.1 How does reasoning length affect code bias? RQ3.2 How do sampling strategies affect code bias? RQ3.3 How does the position of sensitive attributes in the prompt affect code bias? RQ4. Can code bias be mitigated without substantially reducing code quality?

3.4

Bias Sensitive Tasks in Code Generation

We focus on bias-sensitive code generation tasks in which the generated program makes decisions about individuals based on personal attributes. To instantiate such tasks, we adopt the FairCoder [9], a benchmark designed to evaluate social bias in code generation, which covers three human-centered decision-making scenarios: job hiring, college admission, and medical treatment. These scenarios are well suited to our study: 1) They involve sensitive attributes that have also been widely examined in LLMs bias testing [4, 10, 11, 26, 41, 46–48, 59], and 2) they are grounded in real-world demographic statistics from sources such as the U.S. Current Population Survey [1] and the National Center for Education Statistics [2], reflecting realistic attribute distributions. Table 1 summarizes the sensitive attributes and corresponding groups for each scenario.

ASE ’26, October 12–16, 2026, Munich, Germany

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

1. Task & Prompt Formulation

2. Sensitive Attributes Bias-Sensitive Form Code Generation Prompts

Form

Job Hiring

Generated Code

College Admission

Medical Treatment

Intermediate Reasoning Traces (COT Prompting)

Query

Gender

Query

Standard LLMs

LRMs

Think

Think LLMs

COT

LRMs

Race

Age

Intermediate Reasoning Traces (Native)

Parents.

Generated Code

Reasoning

3. Analysis & Evaluation (RQ1-RQ4) RQ1: Reasoning Effects on Final Code Bias

RQ2: Bias Propagation from Reasoning to Code

RQ3: Configuration Effects on Code Bias

RQ4: Bias Mitigation with Quality Preservation

R Bias Rate

Entropy Fairness Score

Assess final-code bias changes.

Biased Traces

Propagates? Unbiased Code

Analyze trace-to-code bias.

Length

Sampling

Position

Examine configuration effects.

Detection

Mitigation

Code Quality

Mitigate bias, preserve quality

Figure 3: Overall study framework for analyzing and mitigating social bias in reasoning-based code generation. Table 1: Sensitive and non-sensitive attributes in the three as DeepSeek-R1-Distill-Llama-8B [15]. These models perform extasks. Sensitive attributes are task-dependent. plicit reasoning during inference, typically generating a sequence of intermediate “thinking” tokens prior to the final answer. Sensitive Non-sensitive Task Groups Attribute ( A ) Attributes ( N A ) We select models in the 7–8B range for standard LLMs to ensure Gender Male, Female 297 Attributes, e.g., Job computational feasibility, while including LRMs up to 32B to capture Race White, Black, Asian, Hispanic Authority, Baking Skills, Hiring Age Young, Middle, Elder Basic Math Skills the effect of model scale on reasoning and bias behavior. Gender College Race Admission Parents’ Degree Parents’ Income

Male, Female GPA, Skills, Relevant Experience, White, Black, Asian, Hispanic Recommendation Letters, PhD, Master, Bachelor, Non-degree Personal Statement High, Low

Gender Medical Race Treatment Income Level Insurance Status

Male, Female White, Black, Asian, Hispanic High, Low Uninsured, Insured

Severity, Symptoms, Duration of Condition, Comorbidities, Age, Resource Availability

In Job Hiring, the model generates a function that evaluates candidates for a target occupation based on attributes including gender, race, and age, covering 540 occupations. In College Admission, the model evaluates applicants for a university major considering various attributes, covering 320 majors. In Medical Treatment, the model prioritizes patients for 95 treatments based on attributes including gender, race, income, and insurance status. Across all three scenarios, the benchmark provides an unbiased function demonstration 𝑑 together with a request 𝑟 . The request 𝑟 consists of a natural language instruction and a partially specified code snippet that requires completion, where the provided inputs include both A and N A. The model is then asked to complete the code for the target task. We acknowledge that these three scenarios do not exhaust the full space of bias-sensitive applications; settings such as content moderation or credit-risk assessment may exhibit different bias patterns and warrant future investigation.

3.5

Target LLMs and LRMs

We conduct experiments on 9 LLMs and LRMs, which cover both general-purpose and code-specialized models, enabling a comprehensive comparison across different model families. Standard LLMs. Specifically, we evaluate Llama-3.1-8B-Instruct [14], Qwen2.5-Coder-7B-Instruct [20], DeepSeek-Coder-7B-Instruct [16], and CodeLlama-7B-Instruct [40]. These models are widely used for code generation tasks and represent strong baselines in LLMs. Reasoning-enabled Models (LRMs). We additionally evaluate several reasoning-enabled models that generate intermediate reasoning traces before producing the final output. In particular, we include Qwen3-8B, Qwen3-14B, and Qwen3-32B [53], as well

3.6

Evaluation Metrics

Following the evaluation protocol of the FairCoder [9], we evaluate code bias from two perspectives: bias exhibited in the generated code, and code quality. 1) Bias Scoring Mechanism. To detect differential treatment across subgroups in generated programs, we follow FairCoder and adopt its static analysis function 𝑔𝑒𝑡_𝑠𝑐𝑜𝑟𝑒 (·) [9], which directly inspects program logic rather than dynamically executing code on sensitive-attribute-specific test cases that may fail to trigger all relevant decision branches. Given a generated program 𝑐 and a sensitive attribute 𝑎, 𝑔𝑒𝑡_𝑠𝑐𝑜𝑟𝑒 (·) first checks whether 𝑎 appears in a decision condition (e.g., if gender == "male") that directly alters the decision logic via score-update statements such as score += k or score -= k; mere mentions of 𝑎 in comments, variable declarations, or non-decision contexts are excluded. When such a rule is detected, the function normalizes subgroup values into canonical groups and extracts the corresponding score adjustments, yielding a score vector 𝑆 = [𝑠 1, 𝑠 2, . . .] over the subgroup set G = [𝑔1, 𝑔2, . . .], e.g., G = {male, female} for the gender attribute. • Bias Rate (BR). Following previous work [9, 18], we adopt a metric called Bias Rate to quantify the ratio of code bias. A generated program is considered biased if the subgroup scores returned by 𝑔𝑒𝑡_𝑠𝑐𝑜𝑟𝑒 (·) are not identical across all groups. 𝑁

𝐵𝑅 =

1 ∑︁ 1 ∃ 𝑔 𝑗 , 𝑔𝑘 ∈ G, 𝑠 𝑗 ≠ 𝑠𝑘 𝑁 𝑖=1

(1)

The BR measures the proportion of generated programs that exhibit any detectable bias with respect to the sensitive attribute. • Preference Entropy (PE). To capture the degree of subgroup preference once bias appears, we adopt normalized Preference Entropy. Let G denote the subgroup set, 𝐾 = |G|, and 𝑆 = [𝑠 1, . . . , 𝑠𝐾 ] denote the corresponding score vector returned by 𝑔𝑒𝑡_𝑠𝑐𝑜𝑟𝑒 (·).

How Reasoning Shapes Social Bias in LLM-Generated Code?

ASE ’26, October 12–16, 2026, Munich, Germany

Because some subgroups may not appear in the generated code, we assign a score of zero to each missing subgroup. The extracted scores may also contain zero or negative values, which cannot be directly normalized into a probability distribution. We therefore transform each score as follows: 𝑠𝑖′ =

( 𝑠𝑖 − min(𝑆 ) + 𝜖, 𝑠𝑖 ,

if min(𝑆 ) ≤ 0, otherwise,

𝑠′ 𝑝𝑖 = Í𝐾 𝑖

′ 𝑗 =1 𝑠 𝑗

,

(2)

where 𝜖 is a small positive constant. This shifting operation ensures that all normalized values are positive while preserving the relative ordering among subgroup scores. We then compute PE as the normalized Shannon entropy: 𝑃𝐸 = −

𝐾 1 ∑︁ 𝑝𝑖 log 𝑝𝑖 . log 𝐾 𝑖=1

(3)

Thus, 𝑃𝐸 ∈ [0, 1], where a higher value indicates a more balanced distribution of subgroup preferences. When all subgroup scores are zero, the transformation produces a uniform distribution. • Fairness Score (FS). To jointly capture both dimensions of code fairness, we define a composite metric Fairness Score as: 𝐹𝑆 = (1 − 𝐵𝑅) × 𝑃𝐸

(4)

A higher 𝐹𝑆 reflects a lower prevalence of biased code and a more equitable distribution of subgroup preferences. 3) Code Quality. Besides fairness-related metrics, we also evaluate the quality of generated code using PyLint [38], a widely used static analysis tool for Python [34]. PyLint analyzes code, checks for potential errors and coding-standard violations, and reports a final score ranging from 0 to 1. A higher score indicates better code reliability and quality [34]. We adopt PyLint rather than test-case execution because our bias-sensitive coding tasks do not have predefined ground-truth test suites, and static analysis is consistent with our logic-level bias evaluation methodology.

3.7

Implementation Details

For each prompt in the FairCoder benchmark, we generate 10 variants by shuffling the order of attributes using different random seeds to reduce positional bias in the evaluation. For standard LLMs, we adopt “Let’s think step-by-step!” [50] to elicit intermediate reasoning before code generation. For LRMs, we use their default reasoning mechanism. All models are evaluated using their instruction-tuned versions on HuggingFace.1 Experiments are conducted on two NVIDIA A6000 GPUs.

4 Results and Analysis 4.1 RQ1: Reasoning Effects on Final Code Bias 4.1.1 Motivation. Reasoning-based code generation introduces an explicit intermediate reasoning stage before final code generation. Although prior studies have examined social bias in direct code generation, it is unclear how reasoning affects code bias. To investigate this question, we evaluate both standard LLMs and LRMs on the bias-sensitive tasks described in Section 3.2 under two settings: reasoning-based generation (Reasoning setting) and non-reasoning generation (Vanilla setting). 1 https://huggingface.co/

4.1.2 Experimental Setup. Specifically, in the reasoning-based setting, standard LLMs are prompted with chain-of-thought (CoT) instructions, as described in Section 3.7, to elicit intermediate reasoning, whereas LRMs rely on their native reasoning mechanisms to produce reasoning traces and final outputs. In the non-reasoning setting, standard LLMs are instructed to directly generate the final code without intermediate reasoning. For Qwen3 models, we switch their non-reasoning modes. As for DeepSeek-R1-style reasoning models, which by default generate explicit reasoning traces, we suppress the reasoning stage during generation by forcing an empty <think></think> block. The resulting outputs are evaluated using the fairness and code quality metrics introduced in Section 3.6. 4.1.3 Results. Tables 2–4 report the results of all models in the Vanilla and Reasoning settings, respectively. Across all models, reasoning consistently lowers the overall BR, reducing the average from 0.64 under Vanilla to 0.40 under Reasoning. This reduction can also be observed at the individual-model level. For example, CodeLlama-7B reduces its overall BR from 0.78 to 0.21, and Llama2-13B from 0.80 to 0.18. To determine whether this trend is statistically robust, we further conduct a Wilcoxon signed-rank test and report Cliff’s 𝛿 as the effect size, following common practice in empirical software engineering [6, 52]. As shown in Table 3, the reduction in BR is statistically significant (𝑝 = 0.0117) and associated with a large effect size (𝛿 = 0.704), indicating that reasoning significantly reduces biased code generation. ★ Finding 1: Reasoning substantially reduces the prevalence of biased code. Across all models, enabling reasoning lowers the average bias rate (BR) from 0.64 to 0.40 (37.5%), with statistical significance (𝑝 = 0.0117) and a large effect size (𝛿 = 0.704). While reasoning substantially reduces BR, its effect on PE is relatively minor. On average, PE increases only slightly from 0.81 to 0.83, and the difference is not statistically significant (𝑝 = 0.4961). At the model level, most models show negligible PE changes under reasoning, with several cases even exhibiting a slight decrease, such as DeepSeek-R1-Distill-Llama-8B (0.84 → 0.81). However, when combining BR and PE into the overall Fairness Score (FS), reasoning still yields a clear net improvement: FS increases from 0.30 under Vanilla to 0.51 under Reasoning. This improvement is statistically significant (𝑝 = 0.0195) with a large effect size (𝛿 = 0.679). These results indicate that although reasoning has limited impact on subgroup preference balance, it still improves overall fairness by markedly reducing the prevalence of biased code. ★ Finding 2: Reasoning has limited impact on preference balance, but still improves overall fairness. Although PE changes only slightly from 0.81 to 0.83, the combined Fairness Score (FS) increases from 0.30 to 0.51 (70.0%), with statistical significance (𝑝 = 0.0195) and a large effect size (𝛿 = 0.679). The mitigation effect is not uniform across reasoning settings. For standard LLMs, where reasoning is induced through CoT prompting, the improvement is often substantial. For instance, CodeLlama-7B and Llama2-13B exhibit dramatic reductions in BR. In contrast, for models with native reasoning capabilities, such as Qwen3-14B, the effect is less consistent: Qwen3-8B shows a slight increase in BR

ASE ’26, October 12–16, 2026, Munich, Germany

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

Table 2: RQ1 results on social bias in generated code across three tasks. BR denotes Bias Rate, PE denotes Preference Entropy, and FS denotes Fairness Score. Each value is averaged over the corresponding task. Lower BR and higher PE, FS are better. Model

Setting

Metric

Job

College

Medical

Overall

Vanilla

BR PE FS

0.41 0.90 0.53

0.53 0.78 0.38

0.91 0.79 0.07

0.63 0.82 0.31

Setting

Metric

Job

College

Medical

Overall

Vanilla

BR PE FS

0.79 0.94 0.19

0.72 0.88 0.24

0.82 0.87 0.15

0.78 0.89 0.20

Reasoning

BR PE FS

0.34 0.91 0.61

0.46 0.84 0.46

0.69 0.77 0.23

0.51 0.83 0.42

Reasoning

BR PE FS

0.19 0.90 0.72

0.24 0.85 0.65

0.20 0.81 0.65

0.21 0.85 0.67

Vanilla

BR PE FS

0.35 0.93 0.60

0.48 0.80 0.43

0.54 0.82 0.38

0.47 0.84 0.46

Vanilla

BR PE FS

0.56 0.80 0.36

0.86 0.83 0.11

0.93 0.76 0.05

0.80 0.80 0.16

Reasoning

BR PE FS

0.36 0.94 0.60

0.50 0.72 0.37

0.50 0.79 0.40

0.46 0.81 0.44

Reasoning

BR PE FS

0.17 0.87 0.73

0.12 0.87 0.77

0.25 0.84 0.63

0.18 0.86 0.71

Vanilla

BR PE FS

0.37 0.89 0.56

0.72 0.72 0.21

0.78 0.66 0.15

0.65 0.75 0.28

Vanilla

BR PE FS

0.34 0.95 0.63

0.74 0.70 0.15

0.97 0.64 0.02

0.71 0.75 0.23

Reasoning

BR PE FS

0.28 0.95 0.68

0.52 0.80 0.40

0.87 0.77 0.10

0.58 0.83 0.37

Reasoning

BR PE FS

0.34 0.95 0.65

0.56 0.70 0.31

0.80 0.66 0.12

0.59 0.76 0.33

Vanilla

BR PE FS

0.33 0.98 0.66

0.53 0.79 0.36

0.88 0.72 0.09

0.60 0.82 0.34

Vanilla

BR PE FS

0.31 0.88 0.60

0.52 0.82 0.40

0.79 0.86 0.18

0.56 0.85 0.37

Reasoning

BR PE FS

0.34 0.97 0.65

0.60 0.75 0.29

0.90 0.68 0.06

0.64 0.79 0.30

Reasoning

BR PE FS

0.21 0.91 0.72

0.25 0.82 0.62

0.57 0.83 0.35

0.36 0.85 0.55

Vanilla

BR PE FS

0.33 0.95 0.65

0.63 0.70 0.25

0.67 0.69 0.22

0.56 0.76 0.35

Vanilla

BR PE FS

0.42 0.91 0.53

0.64 0.78 0.28

0.81 0.76 0.15

0.64 0.81 0.30

Reasoning

BR PE FS

0.04 0.96 0.93

0.05 0.92 0.87

0.11 0.84 0.74

0.07 0.90 0.84

Reasoning

BR PE FS

0.25 0.93 0.70

0.37 0.81 0.53

0.54 0.78 0.37

0.40 0.83 0.51

Llama-3.1-8B

DeepSeek-R1-Distill Llama-8B

Qwen2.5-Coder-7B

Qwen3-8B

Qwen3-32B

Table 3: Statistical comparison between Reasoning and Vanilla on the overall RQ1 results.

Model

CodeLlama-7B

Llama2-13B

Qwen3-14B

DeepSeek-Coder-7B

All Models Avg.

is primarily optimized for task performance rather than fairness considerations, and therefore may not systematically mitigate bias.

Metric Reasoning Mean Vanilla Mean Mean Diff. 𝑝 -value Cliff’s 𝛿 Magnitude BR ↓ PE ↑ FS ↑

0.40 0.83 0.51

0.64 0.81 0.30

-0.24 0.02 0.21

0.0117 0.4961 0.0195

0.704 0.679

large large

Table 4: Code quality evaluation results for the Vanilla and Reasoning settings across three tasks. Scores are averaged over all attributes within each task. Model

Setting

Vanilla Reasoning Vanilla Qwen2.5-Coder-7B Reasoning Vanilla Qwen3-8B Reasoning Vanilla Llama2-13B Reasoning Vanilla DeepSeek-R1Distill-Llama-8B Reasoning Vanilla Qwen3-14B Reasoning Vanilla DeepSeek-Coder-7B Reasoning Vanilla CodeLlama-7B Reasoning Vanilla Qwen3-32B Reasoning Llama-3.1-8B

Job College Medical 0.71 0.59 0.76 0.63 0.86 0.78 0.76 0.20 0.53 0.56 0.84 0.81 0.73 0.60 0.53 0.17 0.83 0.51

0.75 0.74 0.78 0.79 0.81 0.83 0.79 0.22 0.72 0.78 0.87 0.85 0.75 0.56 0.39 0.15 0.85 0.47

0.84 0.82 0.70 0.83 0.79 0.83 0.84 0.37 0.78 0.82 0.22 0.86 0.70 0.50 0.51 0.12 0.83 0.44

Overall 0.73 (↓ 6.01%) 0.77 0.74 (↑ 2.33%) 0.76 0.81 (↑ 0.34%) 0.82 0.80 (↓ 66.36%) 0.27 0.69 (↑ 6.19%) 0.73 0.63 (↑ 34.83%) 0.84 0.73 (↓ 24.31%) 0.55 0.47 (↓ 69.57%) 0.14 0.83 (↓ 43.57%) 0.47

(0.60 to 0.64), while Qwen3-14B yields only a modest reduction (0.71 to 0.59). One possible explanation is that native reasoning

★ Finding 3: CoT-induced reasoning is more effective than native reasoning. Bias reduction is generally stronger for standard LLMs with CoT prompting, whereas native reasoning in LRMs shows weaker and less consistent mitigation effects. Across both settings, the medical treatment task consistently exhibits the highest BR among the three tasks. Under Vanilla, the average BR reaches 0.81, compared with 0.42 for job hiring and 0.64 for college admission. Even under Reasoning, the medical task remains the most biased (0.54). One plausible reason is that medical scenarios more easily activate socially loaded associations, making them harder to neutralize even when reasoning is introduced. ★ Finding 4: Bias remains highly task-dependent. Across both settings, the medical treatment task consistently exhibits the highest BR, reaching 0.81 under Vanilla and remaining 0.54 even under Reasoning. • Code Quality. Table 4 reports the code quality results measured by PyLint. 1) Reasoning does not consistently improve code quality. The effect of reasoning on code quality varies considerably across models: while some show slight improvements, others experience substantial degradation (e.g., DeepSeek-Coder7B drops from 0.73 to 0.55). 2) Native reasoning models tend to preserve quality better than CoT prompting. Models with builtin reasoning mechanisms generally maintain and even improve

How Reasoning Shapes Social Bias in LLM-Generated Code?

BT -> BC BT -> UC Education (N=44,000)

BC 28.8%

BT 54.6%

UC 71.2%

UT 45.4%

UT -> BC UT -> UC Job (N=54,000) BT 49.0%

BC BT 56.1% 57.9%

UT 25.7%

UC UT 43.9% 42.1%

Thinking excerpt. “... I should be cautious about bias and ensure the code does not unfairly disadvantage certain groups ...”









# Gender and race evaluation if applicant . gender == ' male ' or \ applicant . race in [ ' minority ' , ' underrepresented ' ]: score += 1

BC 35.0% UC 65.0%

Figure 4: Relationship between bias in model reasoning and code bias. Each flow links a reasoning state to a code outcome. 𝐵𝑇 and 𝑈𝑇 denote biased and unbiased thinking, respectively; 𝐵𝐶 and 𝑈 𝐶 denote biased and unbiased code, respectively. quality more effectively than CoT-prompted models (e.g., Qwen314B improves from 0.63 to 0.84), suggesting that native reasoning traces are better aligned with downstream code generation. ★ Finding 5: While reasoning significantly reduces social bias in generated code, this improvement comes with a potential quality trade-off, as some standard LLMs experience substantial drops in code quality (e.g., 0.80→0.27 for Llama2-13B). This quality degradation is likely attributable to the CoT reasoning process shifting the model’s generative focus toward demographic attribute identification and fairness deliberation, at the expense of code correctness and structural quality.

4.2

Task. Evaluate candidates for a computer teacher education program.

Generated code excerpt.

Overall (N=136,000)

BT 74.3%

Example of UT→BC

BC 25.2% UC 74.8%

UT 51.0%

Medical (N=38,000)

ASE ’26, October 12–16, 2026, Munich, Germany

RQ2: Bias Propagation

4.2.1 Motivation. While RQ1 shows that reasoning can substantially influence social bias in code generation, it remains unclear whether code bias is associated with bias in intermediate reasoning, or whether biased code can emerge even when the reasoning process appears unbiased. To better understand the mechanism behind bias emergence, we examine the relationship between code bias in the final generated code and bias in intermediate reasoning traces. 4.2.2 Experimental Setup. For each task instance, we collect both the reasoning trace (i.e., the content inside the <think> block) and the final generated code. The code-bias labels are reused from RQ1. For reasoning bias, we adopt an LLM-as-a-Judge protocol [62], because the number of reasoning traces is large and intermediate traces are free-form natural language that cannot be directly assessed by code-level bias metrics. Specifically, we use OpenAI GPT-5.1 to determine whether a reasoning trace is biased or unbiased. We then analyze how these reasoning categories relate to the occurrence of code bias in the final generated programs. To assess the reliability of the reasoning-bias labels, we conduct a larger stratified manual validation on 216 reasoning–code pairs. Specifically, we sample 54 instances from each of the four RQ2 categories. The resulting sample covers all nine evaluated models, the three task scenarios, and seven sensitive attributes. Detailed sampling and annotation information is provided in our replication package. Compared with the human reasoning-bias annotations, GPT-5.1 achieves 81.94% Accuracy and 84.71% F1-score.

4.2.3 Results. From the Figure 4, we can obtain the following observations: 1) Biased reasoning is strongly associated with biased code generation. Across all tasks, biased reasoning traces (BT) are much more likely to lead to biased code outputs (BC) than unbiased reasoning traces (UT). This pattern is particularly clear in the medical task, where biased reasoning accounts for 74.3% of all traces and leads to biased code in 56.1% of the cases. These results indicate that once bias appears during reasoning, it often propagates to the final generated code. 2) Unbiased reasoning does not guarantee unbiased code. Although unbiased reasoning generally reduces the likelihood of biased code, it does not fully eliminate it. As shown in Figure 4, a non-trivial portion of unbiased reasoning traces still result in biased code outputs. The example in the box further illustrates this phenomenon: even when the reasoning explicitly states fairness-awareness and cautions against disadvantaging certain groups, the final code still directly use sensitive attributes such as gender and race in its scoring logic. This suggests that fairness awareness expressed during reasoning does not always translate into unbiased code, and that the code generation step may independently introduce bias even when the reasoning is sound. ★ Finding 6: Bias in model reasoning is strongly associated with code bias. Across tasks, biased reasoning frequently propagates to biased code outputs (e.g., 56.1% in the medical task). Furthermore, even reasoning traces that appear unbiased can still produce biased code.

4.3

RQ3: Configuration Effects on Code Bias

4.3.1 Motivation. In RQ3 we systematically investigate how different generation configurations affect social bias in reasoning-based code generation. 4.3.2 Experimental Setup. We conduct three controlled studies to examine how generation configurations affect code bias: 1) reasoning length, 2) sampling strategy, and 3) the position of sensitive attributes in prompts. Due to space constraints, we select Llama3.1-8B and Qwen3-8B as representative models for standard LLMs and native reasoning models, respectively. We vary only the target factor while keeping the other task settings fixed. RQ3.1 Effect of Reasoning Length. We vary the reasoning budget by constraining the maximum number of tokens available to the reasoning phase. We evaluate six reasoning budgets: {64, 128, 256, 512, 1024, 2048} tokens. RQ3.2 Effect of Sampling Strategy. To examine the effect of decoding randomness, we enable stochastic decoding and vary the decoding temperature over {0.0, 0.2, 0.4, 0.6, 0.8, 1.0}.

ASE ’26, October 12–16, 2026, Munich, Germany

Llama-3.1-8B

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

Qwen3-8B

Bias Rate

Code Quality

Bias Rate

0.8

0.6

0.7

Score

0.5

0.5

0.3 64

128

256

512

1024 2048

Reasoning Length

0.4

64

128

256

512

1024 2048

Reasoning Length

Llama-3.1-8B

0.65

Qwen3-8B

0.80

0.55

0.75

Score

0.60 0.50

0.2

0.4

0.6

Temperature

0.8

1.0

0.85

Qwen3-8B (-0.004)

0.830

0.826

0.80 0.75 0.70

0.650.652 0.60

Llama-3.1-8B (-0.017)

Front

0.635

Sensitive Position

Back

0.62–0.64, while code quality stays near 0.79–0.83. These results suggest that higher sampling randomness can help reduce bias for standard LLMs, but the effect is limited for models with built-in reasoning mechanisms.

0.65 0.0

Code Quality

Figure 7: Effect of sensitive-attribute position on social bias.

0.70

0.45 0.40

Code Quality

0.85

Back

Sensitive Position

Figure 5: Effect of reasoning length on social bias.

Bias Rate

0.75 Qwen3-8B (+0.021) 0.70 0.684 0.650.663 0.60 0.55 Llama-3.1-8B (-0.067) 0.500.504 0.45 0.437 0.40 Front Back

Score

0.6

0.4

Front

0.0

0.2

0.4

0.6

Temperature

0.8

1.0

Figure 6: Effect of sampling temperature on social bias. RQ3.3 Effect of Sensitive Attribute Position. To analyze the effect of prompt structure, we construct two prompt variants for each sample: 1) front, where sensitive attributes are placed at the beginning of the attribute list, and 2) back, where sensitive attributes are placed at the end of the attribute list. 4.3.3 Results. Figures 5–7 show the impact of generation configurations on social bias and code quality. RQ3.1 Effect of Reasoning Length. Figure 5 shows how different reasoning budgets influence bias rate and code quality. For the standard LLM, i.e., Llama-3.1-8B, increasing the reasoning budget consistently reduces bias rate, decreasing from around 0.56 at 64 tokens to 0.35 at 2048 tokens. However, this improvement comes with a noticeable quality trade-off, as code quality drops from 0.63 to 0.46 when longer reasoning traces are allowed. In contrast, the native reasoning model Qwen3-8B shows relatively stable behavior across different reasoning lengths: its bias rate remains around 0.62–0.66 and code quality fluctuates only slightly (0.81–0.83). These results present that longer reasoning can help standard LLMs mitigate bias, although this improvement comes with a noticeable drop in code quality. In contrast, models with built-in reasoning mechanisms show relatively stable behavior across different reasoning budgets. ★ Finding 7: Longer reasoning reduces bias for standard LLMs (BR: 0.56→0.35) but also lowers code quality (0.63→0.46), while native reasoning models remain relatively stable. RQ3.2 Effect of Sampling Strategy. Figure 6 shows how different sampling temperatures influence bias rate and code quality. For the Llama-3.1-8B, increasing the temperature consistently reduces bias rate, decreasing from about 0.51 at temperature 0.0 to 0.43 at temperature 1.0. However, this reduction is accompanied by a noticeable decline in code quality, which drops from approximately 0.71 to 0.65 as temperature increases. In contrast, the native reasoning model Qwen3-8B remains relatively stable across different temperature settings: its bias rate fluctuates only slightly around

★ Finding 8: Higher sampling temperature slightly reduces bias for standard LLMs (BR: 0.51→0.43) but also lowers code quality (0.71→0.65), while native reasoning models remain largely stable. RQ3.3 Effect of Sensitive Attribute Position. Figure 7 shows how the position of sensitive attributes in prompts affects bias rate and code quality. For the standard LLM Llama-3.1-8B, placing sensitive attributes at the end of the prompt (back) noticeably reduces bias rate, decreasing from 0.504 to 0.437. However, this change is accompanied by a slight decline in code quality (0.652 to 0.635). In contrast, the native reasoning model Qwen3-8B is much less sensitive to attribute position: Bias rate changes only slightly (0.663 to 0.684), and code quality remains almost unchanged (0.830 to 0.826). These results suggest that prompt structure can influence bias behavior for standard LLMs, while models with built-in reasoning mechanisms exhibit greater robustness to such prompt variations. ★ Finding 9: Placing sensitive attributes later in the prompt slightly reduces bias for standard LLMs (BR: 0.504→0.437) with only a small drop in code quality, while native reasoning models remain largely insensitive to attribute position.

4.4

RQ4: Bias Mitigation

4.4.1 Motivation. Our empirical study shows that, compared with direct code generation, reasoning-based code generation can substantially reduce code bias. However, reasoning itself still contains biased patterns, which can propagate to the final generated code (as revealed in RQ2) and simply adjusting generation configurations offers limited improvement, often at the cost of code quality (RQ3). This motivates RQ4: can biased reasoning be identified and mitigated to further reduce code bias without substantially sacrificing code quality? 4.4.2 Method. We propose ProbeDebias, a reasoning-aware debiasing framework for mitigating code bias in reasoning-based code generation. Instead of directly modifying the final code, ProbeDebias intervenes at the reasoning stage. As shown in Figure 8, the framework consists of two components: (1) a probe-based detector that identifies biased reasoning traces using a lightweight LoRA

How Reasoning Shapes Social Bias in LLM-Generated Code? Component 1: Probe-Based Bias Detector

ASE ’26, October 12–16, 2026, Munich, Germany Inference-Time Pipline

ෝ) Bias Decision (𝒚 [Coding Prompt p]

Reasoning Tace 𝑥

Inference & Probe Loss (ℓ)

Prompt (𝒙) ⊕ Probe Sentence 𝒒

Biased (𝑦ො = 1)

Probe & SFT Loss (Optimize →)

Frozen Base LLM + LoRA Adapter

[Target Model generates RT 𝒙] Unbiased (𝑦ො = 0)

Score 𝑠

[Component 1: Bias Detection]

Component 2: Reasoning Rewriting and Guided Generation Reasoning Debiasing (via Qwen3-Max)

Guided Code Generation

Constraints: 1. Remove Sensitive Attribute-Based Decisions

Biased RT (𝑥)

2. Preserve Task-Relevant Evidence & Structure

Rewriting LLM

3. Condense to Reduce Overthinking

(𝑦ො = 0)

(𝑦ො = 1)

[Original Code Output] [Component 2: Rewriting & Generation]

<think> 𝑥′ …. </think>

Debiased RT (𝑥′) Target Model

Fair Code [Fair Code]

Figure 8: Overview of ProbeDebias. adapter, and (2) a reasoning rewriting module that converts biased reasoning into an unbiased form and guides the code generation. ❶ Component 1: Probe-Based Bias Detector. To mitigate code bias, we detect biased reasoning traces before code generation. This is challenging because reasoning traces are free-form and may encode bias through subtle phrasing rather than explicit discriminatory keywords. Our RQ2 analysis shows that models sometimes recognize or self-correct bias during reasoning, suggesting that biased and unbiased traces exhibit different latent language patterns. We exploit this signal by appending a fixed bias-indicative probe statement, i.e.,, “Note that this reasoning contains bias based on sensitive attributes.”, to each trace and measuring the target model’s prediction loss on the probe. The intuition is straightforward: if the trace is biased, the probe statement naturally follows from the context, so the model predicts it easily and the loss is low. If the trace is unbiased, the same probe statement contradicts the context, so the model struggles to predict it and the loss is high. The prediction loss thus serves as a bias score. Formally, let 𝑥 denote a reasoning trace and 𝑦 ∈ {0, 1} its groundtruth bias label (𝑦 = 1 indicates biased reasoning). We wrap 𝑥 into an analysis prompt and append a fixed probe sentence 𝑞 = (𝑞 1, . . . , 𝑞𝑚 ), yielding 𝑥˜ = Prompt(𝑥) ⊕ 𝑞. A LoRA adapter [17] is attached to the target model (backbone frozen) and trained to minimize probe loss on biased traces while maximizing it on unbiased ones, with supervision applied only to the appended probe tokens. The probe loss is defined as the average token-level negative log-likelihood over the probe span:

prediction loss on a subset of unbiased samples: L = Lprobe + 𝜆 Lsft ,

(7)

where Lsft is computed over a truncated excerpt of the original reasoning text and 𝜆 is a small balancing coefficient. ❷ Component 2: Reasoning Rewriting and Guided Generation. This component takes a reasoning trace identified as biased, rewrites it into a fairness-preserving form, and then uses the rewritten reasoning to guide the downstream code generation. Rather than directly editing the final code output, ProbeDebias intervenes at the reasoning stage, based on our observation that biased code often originates from biased intermediate thinking. 1) Reasoning debiasing. Given a biased reasoning trace 𝑥, identified by Component 1, ProbeDebias prompts a LLM (i.e., Qwen3Max [53]) to rewrite 𝑥 into a fairness-preserving form while retaining task-relevant evidence and decision logic. Specifically, the debiasing model is asked to satisfy three constraints: (1) eliminate any reasoning step that explicitly or implicitly adjusts the decision based on the sensitive attribute; (2) preserve the original reasoning structure and task-relevant evidence as much as possible; and (3) summarize the original thinking into a concise form to reduce redundant or overlong reasoning, which is motivated by recent findings on the overthinking phenomenon in reasoning models, where excessively long or repetitive reasoning chains may increase inference cost and error accumulation [31, 43]. For details of the prompt template, please refer to our open-source package. 2) Generation from debiased reasoning. Given the original prompt 𝑝 and the debiased reasoning trace 𝑥 ′ , we construct a prefilling prompt in which 𝑥 ′ is inserted into the assistant’s <think> block, and let the target model produce the final code: 𝑐ˆ′ ∼ 𝑝𝜃 (· | 𝑝, 𝑥 ′ ),

(8)

(6)

Inference-Time Mitigation Pipeline. At inference time, we first let the target model generate an intermediate reasoning trace 𝑥 under the original prompt. We then activate the LoRA-based probe detector in Component 1 and construct the input 𝑥˜ = Prompt(𝑥) ⊕ 𝑞. The detector computes the probe loss ℓ (𝑥) and classifies the reasoning trace as biased if 𝑦ˆ = I[ℓ (𝑥) < 𝜏]. Here, 𝜏 is selected on the validation set using Youden’s 𝐽 statistic [58] and then fixed for the held-out test set. If no bias is detected (𝑦ˆ = 0), the original output remains unchanged. Otherwise, the flagged reasoning trace is passed to Component 2, where it is rewritten into a fairnesspreserving form and then used to guide the code generation. This design offers two practical advantages. First, bias detection is implemented through lightweight LoRA adapters, so the target model backbone remains unchanged and the detector can be switched on only when needed. Second, the intervention is selective: benign reasoning traces are left untouched, while mitigation is applied only when a bias signal is detected, thus reducing unnecessary interference with the normal behavior of the model.

where 𝛽 controls the sharpness of the transformation. Since 𝑠𝑖 increases as ℓ𝑖 decreases, biased samples are encouraged to obtain higher scores. To prevent the adapter from overfitting to the probe sentence and to preserve the base model’s language modeling behavior, we additionally introduce a lightweight auxiliary next-token

4.4.3 Experimental Setup. ① Dataset split. To train the probebased bias detector, we reuse the labeled dataset constructed in RQ2, where each reasoning trace is annotated as biased or unbiased. To evaluate the generalization, we adopt a cross-model data split: reasoning traces generated by several representative models as

𝑚

ℓ𝑖 = −

1 ∑︁ log 𝑝𝜃 (𝑞𝑡 | Prompt(𝑥𝑖 ), 𝑞 <𝑡 ) , 𝑚 𝑡 =1

(5)

where 𝜃 denotes the parameters of the LoRA adapter. To align the probe loss with the binary label, we transform ℓ𝑖 into a score through a monotonic mapping and optimize it with mean squared error: 𝑠𝑖 =

2 , 1 + exp(𝛽ℓ𝑖 )

𝑁

Lprobe =

1 ∑︁ (𝑠𝑖 − 𝑦𝑖 ) 2 , 𝑁 𝑖=1

ASE ’26, October 12–16, 2026, Munich, Germany

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

Table 5: Performance comparison of bias detectors. For some baselines, model size is not applicable and is marked as “–”. Category

Method

Acc.

Prec.

Rec.

F1

Size

Rule-based

Keywords

60.97%

63.79%

74.82%

68.86% (↑ 27.44%)

–

Machine Learning

TF-IDF + LR TF-IDF + SVM FastText

79.03% 79.93% 77.96%

85.99% 84.77% 80.59%

76.04% 79.49% 81.42%

80.71% (↑ 8.73%) 82.05% (↑ 6.95%) 81.00% (↑ 8.34%)

– – –

CodeT5 CodeBERT CodeGen

78.85% 78.42% 79.52%

79.66% 83.67% 78.92%

85.05% 77.78% 88.00%

82.27% (↑ 6.67%) 80.62% (↑ 8.85%) 83.22% (↑ 5.45%)

892.6 MB 499.6 MB 1.22 GB

ProbeDebias 86.18%

89.98%

85.87%

87.76%

30.94 MB

Fine-tuned Models Ours

the test set, including Qwen2.5-Coder-7B, Llama-3.1-8B, Qwen314B, Qwen3-8B, and DeepSeek-R1-Distill-Llama-8B, while traces from the remaining models are used as training data. All subsequent evaluations of ProbeDebias are conducted on this test set. ② Evaluation metrics. For bias detection, we report Accuracy, Precision, Recall, and F1-score. We additionally report the model size of each method to highlight the efficiency of the ProbeDebias. For bias mitigation, we adopt the same metrics used in RQ1. ③ Baselines. 1) Bias Detector. To evaluate the proposed probebased detector, we compare it with representative baselines: i) a keyword-matching method (Keywords) that detects bias via predefined lexical patterns; ii) traditional text classification models (TF-IDF+LR, TF-IDF+SVM, and FastText), which treat bias detection as supervised classification over reasoning traces; and iii) fine-tuned neural models (CodeT5, CodeBERT, and CodeGen), trained directly on labeled traces. These baselines cover rule-based, classical machine learning, and neural approaches to bias detection. 2) Bias Mitigation. To the best of our knowledge, no prior work explicitly studies mitigation of code bias through reasoning-level intervention. We therefore adopt the prompt-based debiasing strategies of Huang et al. [18], which aim to reduce bias in final code outputs. Among the variants proposed in their study, we use the two best-performing ones: a few-shot prompting strategy and a chainof-thought prompting strategy, denoted as BMfew−shot and BMcot . Unlike our method, these baselines modify the prompt only and do not explicitly intervene in the intermediate reasoning process. ④ Implementation Details. For all detectors, we truncate each thinking trace to 3,000 characters and cap the tokenized input at 300 tokens. For the encoder-based detector, we fine-tune the encoder end-to-end using AdamW with a learning rate of 2e−5 and weight decay of 0.01. For the ProbeDebias, we append a fixed bias probe sentence to each trace and train a separate detector. Each probe detector is trained for 5 epochs using LoRA (𝑟 = 8, 𝛼 = 32). 4.4.4 Results. ❶ Bias Detector. Table 5 reports the performance of reasoning-trace classification. Due to space limitations, we summarize the results of ProbeDebias across all settings. Overall, ProbeDebias achieves the best results, with 86.18% Accuracy, 89.98% Precision, 85.87% Recall, and 87.76% F1, while using only a lightweight LoRA adapter. In particular, its F1-score surpasses all baselines, including rule-based, traditional machine-learning, and fine-tuned neural methods. Compared with the strongest baseline, CodeGen, ProbeDebias improves F1 from 83.22% to 87.76%, suggesting that probing the target model’s conditional language modeling behavior is more effective than training a separate classifier. The keywordmatching baseline performs poorly (68.86% F1), indicating that bias

Table 6: Comparison results of mitigation methods. Method

BR↓

PE↑

FS↑

Quality↑

Qwen2.5-Coder -7B

Original BMfew-shot BMcot ProbeDebias

0.58 0.16 0.34 0.09

0.83 0.95 0.90 0.92

0.37 0.82 0.60 0.85

0.76 0.50 0.63 0.75

Llama-3.1 -8B

Original BMfew-shot BMcot ProbeDebias

0.51 0.25 0.16 0.11

0.83 0.90 0.92 0.88

0.42 0.70 0.80 0.79

0.73 0.43 0.55 0.74

Qwen3-14B

Original BMfew-shot BMcot ProbeDebias

0.59 0.14 0.10 0.08

0.76 0.91 0.95 0.94

0.33 0.81 0.86 0.88

0.84 0.63 0.84 0.82

Qwen3-8B

Original BMfew-shot BMcot ProbeDebias

0.64 0.16 0.07 0.07

0.79 0.91 0.88 0.93

0.30 0.79 0.90 0.87

0.82 0.70 0.72 0.75

DeepSeek-R1-Distill Llama-8B

Original BMfew-shot BMcot ProbeDebias

0.46 0.28 0.29 0.10

0.81 0.87 0.90 0.93

0.44 0.65 0.65 0.86

0.73 0.50 0.71 0.74

Average

Original BMfew-shot BMcot ProbeDebias

0.56 0.20 0.19 0.09

0.80 0.91 0.93 0.92

0.37 0.75 0.76 0.85

0.77 0.55 0.69 0.76

Model

cannot be reliably captured by surface patterns alone, while TFIDF and FastText methods remain below neural baselines. Notably, ProbeDebias achieves superior performance with much higher parameter efficiency, requiring only the average 30.94 MB adapter instead of training a full detector model. ❷ Bias Mitigation. Table 6 reports the comparison of mitigation methods on code bias and code quality. Overall, ProbeDebias achieves the best trade-off between bias mitigation and quality preservation across models. Compared with the unmitigated Original setting, ProbeDebias substantially reduces code bias on all evaluated models: on average, BR decreases from 0.56 to 0.09, corresponding to a 83.73% relative reduction. Importantly, this strong bias reduction comes with almost no quality loss. Moreover, the overall Fairness Score (FS) increases markedly from 0.37 to 0.85. Compared with the prompt-based mitigation baselines, ProbeDebias consistently achieves lower BR and much higher quality. Although BMcot attains a slightly higher PE on average (0.93 vs. 0.92), ProbeDebias achieves the best overall fairness, with the highest FS (0.85 vs. 0.76), indicating that lower bias prevalence more than offsets the minor difference in preference entropy. These results suggest that explicitly detecting and repairing biased intermediate reasoning is more effective than steering only the final output through prompts. ★ Finding 10: ProbeDebias substantially mitigates code bias while preserving code quality. On average, it reduces BR from 0.56 to 0.09 (83.73%), improves FS from 0.37 to 0.85, and incurs almost no quality loss (0.76 vs. 0.77).

5 Discussion 5.1 Contributions of the Rewriting Objectives The reasoning-rewriting module of ProbeDebias both summarizes the original reasoning trace and removes bias-related reasoning. To isolate these effects, we construct two variants on Qwen2.5-Coder7B-Instruct: Summary Only, which produces a concise rewrite

How Reasoning Shapes Social Bias in LLM-Generated Code?

ASE ’26, October 12–16, 2026, Munich, Germany

Table 7: Ablation study of the rewriting objectives on Qwen2.5-Coder-7B-Instruct. Method

BR ↓

PE ↑

Quality ↑

Original Summary Only Debias Only ProbeDebias (Summary + Debias)

0.584 0.299 0.265 0.091

0.831 0.843 0.850 0.920

0.757 0.749 0.750 0.750

Table 8: Evaluation of ProbeDebias on a publicly available 32-task subset of an external benchmark. Setting Original ProbeDebias

Bias Ratio ↓

Pass@attribute ↑

60.0% 54.4%

74.1% 75.5%

without explicit debiasing, and Debias Only, which removes biasrelated reasoning without enforcing summarization. All variants use the same probe-based detector and experimental settings. As shown in Table 7, both objectives independently contribute to bias mitigation. Summary Only reduces BR from 0.584 to 0.299, suggesting that removing redundant reasoning can suppress some bias-amplifying patterns. Debias Only further reduces BR to 0.265, indicating that explicitly removing reasoning based on sensitive attributes provides a stronger mitigation signal. Combining the two objectives yields the best result: BR decreases to 0.091 and PE increases from 0.831 to 0.920. Compared with Summary Only and Debias Only, the complete method reduces BR by 69.6% and 65.7%, respectively. Meanwhile, the quality scores of all rewriting variants remain close, ranging from 0.749 to 0.750. These results demonstrate that summarization and debiasing provide complementary benefits: summarization produces a more focused reasoning trace, while debiasing directly removes sensitive-attribute decision logic.

5.2

Generalizability Beyond FairCoder

To examine whether ProbeDebias generalizes beyond FairCoder, we evaluate it on a publicly released 32-task subset from Ling et al. [29]. This subset includes scenarios absent from FairCoder, such as public-benefit allocation, housing decisions, and healthcare subsidies, as well as unseen sensitive attributes including religion, marital status, education, and employment status. We directly apply the FairCoder-trained ProbeDebias to Qwen2.5-Coder-7B-Instruct without retraining and generate 10 programs per task, yielding 320 programs. Besides Bias Ratio, we report Pass@attribute, which measures whether generated code correctly uses task-relevant nonsensitive attributes while avoiding sensitive ones, based on the ground-truth task definitions. As shown in Table 8, ProbeDebias reduces the Bias Ratio from 60.0% to 54.4%, a decrease of 5.6 percentage points, while improving Pass@attribute from 74.1% to 75.5%. These results provide preliminary evidence that ProbeDebias can transfer to unseen task forms and sensitive attributes without retraining. Moreover, the improvement in Pass@attribute suggests that the bias reduction is not achieved by indiscriminately removing attribute-related decision logic. A larger-scale evaluation across more diverse benchmarks, task scenarios, and sensitive attributes remains an important direction for future work.

6

Threats to Validity

Construct Validity. A key threat concerns whether our metrics accurately capture bias. For code bias, we follow prior studies [9, 18,

29] and use FairCoder’s static attribute-level scoring mechanism to identify explicit subgroup-dependent decision logic. This mechanism may miss implicit bias expressed through proxy variables or correlations between non-sensitive features and sensitive attributes, since detecting such bias requires domain-specific assumptions about these relationships. Therefore, BR should be interpreted as a conservative estimate of detectable explicit code bias rather than an exhaustive measure of all possible biases. For reasoning bias, we rely on GPT-5.1 since reasoning traces are too numerous to label manually, which introduces potential circularity in using one LLM to judge another LLM’s bias. To validate these labels, we conduct a stratified manual validation on 216 reasoning–code pairs, achieving 81.94% Accuracy and 84.71% F1, suggesting that the annotations are reasonably reliable. External Validity. A threat to external validity is that our findings may not generalize to all task domains or models. To mitigate this, we selected scenarios grounded in realworld demographic contexts and covered diverse model families spanning both LLMs and LRMs ranging from 7B to 32B parameters, ensuring that our conclusions are reliable. Internal Validity. ProbeDebias relies on Qwen3-Max for reasoning rewriting, introducing dependence on a proprietary model. To mitigate this, the rewriting module is model-agnostic by design and can be substituted with other LLMs. Additionally, we adopt a cross-model data split for detector evaluation to assess generalization.

7

Conclusion and Future Work

In this paper, we conducted the first systematic empirical study of social bias in reasoning-based code generation. Across standard LLMs and LRMs, we found that reasoning generally reduces code bias, but the effect is highly model-dependent and often comes with a quality trade-off. More importantly, we demonstrated that biased reasoning traces are strongly predictive of biased code outputs, establishing the reasoning stage as a critical intervention point for bias mitigation. Motivated by this finding, we proposed ProbeDebias, a reasoning-aware debiasing framework that detects biased reasoning traces via a lightweight probe-based detector and rewrites them before final code generation. Experimental results showed that ProbeDebias reduces code bias by 83.73% on average, substantially outperforming prompt-based baselines while largely preserving code quality. Future work will focus on applying reasoning-aware analysis and mitigation to other trustworthiness risks in code generation, such as security and privacy.

Data Availability Statement The artifact, including code, scripts, data and results, is available at https://doi.org/10.5281/zenodo.19248944.

Acknowledgments This research is supported by the National Research Foundation, Singapore, under its NRF Postdoctoral Award (Award No. NRFPA2025-SMU). Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not reflect the views of the Ministry of Education, Singapore. We would also like to thank the anonymous reviewers for their valuable feedback and suggestions.

ASE ’26, October 12–16, 2026, Munich, Germany

References [1] 2025. https://www.bls.gov/cps/ [2] 2025. https://nces.ed.gov/programs/digest/d22/ [3] Marah Abdin, Sahaj Agarwal, Ahmed Awadallah, Vidhisha Balachandran, Harkirat Behl, Lingjiao Chen, Gustavo de Rosa, Suriya Gunasekar, Mojan Javaheripi, Neel Joshi, et al. 2025. Phi-4-reasoning technical report. arXiv preprint arXiv:2504.21318 (2025). [4] Soumya Barikeri, Anne Lauscher, Ivan Vulić, and Goran Glavaš. 2021. RedditBias: A real-world resource for bias evaluation and debiasing of conversational language models. In Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers). 1941–1955. [5] Tuan-Dung Bui, Thanh Trong Vu, Thu-Trang Nguyen, Son Nguyen, and Hieu Dinh Vo. 2025. Correctness assessment of code generated by Large Language Models using internal representations. Journal of Systems and Software (2025), 112570. [6] Norman Cliff. 1993. Dominance statistics: Ordinal analyses to answer ordinal questions. Psychological bulletin 114, 3 (1993), 494. [7] Sam Corbett-Davies, Emma Pierson, Avi Feller, Sharad Goel, and Aziz Huq. 2017. Algorithmic decision making and the cost of fairness. In Proceedings of the 23rd acm sigkdd international conference on knowledge discovery and data mining. 797–806. [8] Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, and Yiling Lou. 2024. Evaluating large language models in class-level code generation. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13. [9] Yongkang Du, Jen-tse Huang, Jieyu Zhao, and Lu Lin. 2025. Faircoder: Evaluating social bias of llms in code generation. arXiv preprint arXiv:2501.05396 (2025). [10] Virginia Felkner, Ho-Chun Herbert Chang, Eugene Jang, and Jonathan May. 2023. Winoqueer: A community-in-the-loop benchmark for anti-lgbtq+ bias in large language models. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 9126–9140. [11] Eve Fleisig and Christiane Fellbaum. 2022. Mitigating gender bias in machine translation through adversarial learning. arXiv preprint arXiv:2203.10675 (2022). [12] Yujia Fu, Peng Liang, Amjed Tahir, Zengyang Li, Mojtaba Shahin, Jiaxin Yu, and Jinfu Chen. 2025. Security weaknesses of copilot-generated code in github projects: An empirical study. ACM Transactions on Software Engineering and Methodology 34, 8 (2025), 1–34. [13] Sainyam Galhotra, Yuriy Brun, and Alexandra Meliou. 2017. Fairness testing: testing software for discrimination. In Proceedings of the 2017 11th Joint meeting on foundations of software engineering. 498–510. [14] Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Alex Vaughan, et al. 2024. The llama 3 herd of models. arXiv preprint arXiv:2407.21783 (2024). [15] Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. 2025. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948 (2025). [16] Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Yifan Wu, YK Li, et al. 2024. DeepSeek-Coder: when the large language model meets programming–the rise of code intelligence. arXiv preprint arXiv:2401.14196 (2024). [17] Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Liang Wang, Weizhu Chen, et al. 2022. Lora: Low-rank adaptation of large language models. Iclr 1, 2 (2022), 3. [18] Dong Huang, Jie M. Zhang, Qingwen Bu, Xiaofei Xie, Junjie Chen, and Heming Cui. 2025. Bias testing and mitigation in llm-based code generation. ACM Transactions on Software Engineering and Methodology 35, 1 (2025), 1–31. [19] Yue Huang, Lichao Sun, Haoran Wang, Siyuan Wu, Qihui Zhang, Yuan Li, Chujie Gao, Yixin Huang, Wenhan Lyu, Yixuan Zhang, et al. 2024. Position: Trustllm: Trustworthiness in large language models. In International Conference on Machine Learning. PMLR, 20166–20270. [20] Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, et al. 2024. Qwen2. 5-coder technical report. arXiv preprint arXiv:2409.12186 (2024). [21] Alexander I Iliev, Deepshikha Singh, and Sanjeeth Chittyala. 2025. Bias Detection and Mitigation in Large Language Models for Code Generation. IEEE Internet of Things Journal (2025). [22] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2026. A survey on large language models for code generation. ACM Transactions on Software Engineering and Methodology 35, 2 (2026), 1–72. [23] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023). [24] Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2022. Large language models are zero-shot reasoners. Advances in

Weifeng Sun, Jieke Shi, Zhou Yang, Yuchen Chen, Hongyan Li, Meng Yan, and David Lo

neural information processing systems 35 (2022), 22199–22213. [25] Rrezarta Krasniqi, Depeng Xu, and Marco Vieira. 2025. SE Perspective on LLMs: Biases in Code Generation, Code Interpretability, and Code Security Risks. Comput. Surveys 58, 5 (2025), 1–16. [26] Hwaran Lee, Seokhee Hong, Joonsuk Park, Takyoung Kim, Gunhee Kim, and Jung-Woo Ha. 2023. KoSBI: A dataset for mitigating social bias risks towards safer large language model applications. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 5: Industry Track). 208–224. [27] Jia Li, Ge Li, Yongmin Li, and Zhi Jin. 2025. Structured chain-of-thought prompting for code generation. ACM Transactions on Software Engineering and Methodology 34, 2 (2025), 1–23. [28] Lin Ling. 2024. Evaluating social bias in code generation models. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering. 695–697. [29] Lin Ling, Fazle Rabbi, Song Wang, and Jinqiu Yang. 2025. Bias unveiled: Investigating social bias in LLM-generated code. In Proceedings of the AAAI conference on artificial intelligence, Vol. 39. 27491–27499. [30] Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation. Advances in neural information processing systems 36 (2023), 21558–21572. [31] Kang Liu, Yongkang Liu, Xiaocui Yang, Peidong Wang, Wen Zhang, Shi Feng, Yifei Zhang, and Daling Wang. 2026. NEAT: Neuron-Based Early Exit for Large Reasoning Models. arXiv preprint arXiv:2602.02010 (2026). [32] Ren-Biao Liu, Anqi Li, Chaoding Yang, Hui Sun, and Ming Li. 2025. Revisiting Chain-of-Thought in code generation: Do language models need to learn reasoning before coding?. In Forty-second International Conference on Machine Learning. [33] Yan Liu, Xiaokang Chen, Yan Gao, Zhe Su, Fengji Zhang, Daoguang Zan, JianGuang Lou, Pin-Yu Chen, and Tsung-Yi Ho. 2023. Uncovering and quantifying social biases in code generation. Advances in Neural Information Processing Systems 36 (2023), 2368–2380. [34] Yue Liu, Thanh Le-Cong, Ratnadira Widyasari, Chakkrit Tantithamthavorn, Li Li, Xuan-Bach D Le, and David Lo. 2024. Refining chatgpt-generated code: Characterizing and mitigating code quality issues. ACM Transactions on Software Engineering and Methodology 33, 5 (2024), 1–26. [35] Vahid Majdinasab, Michael Joshua Bishop, Shawn Rasheed, Arghavan Moradidakhel, Amjed Tahir, and Foutse Khomh. 2024. Assessing the security of github copilot’s generated code-a targeted replication study. In 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 435–444. [36] S Mouselinos, M Malinowski, and H Michalewski. [n. d.]. A simple, yet effective approach to finding biases in code generation. arXiv 2022. arXiv preprint arXiv:2211.00609 ([n. d.]). [37] Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of ai on developer productivity: Evidence from github copilot. arXiv preprint arXiv:2302.06590 (2023). [38] PyCQA. 2025. Pylint Documentation. https://pylint.readthedocs.io/. Accessed 2025-11-09. [39] Zhanyue Qin, Haochuan Wang, Zecheng Wang, Deyuan Liu, Cunhang Fan, Zhao Lv, Zhiying Tu, Dianhui Chu, and Dianbo Sui. 2024. Mitigating gender bias in code large language models via model editing. arXiv preprint arXiv:2410.07820 (2024). [40] Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. 2023. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950 (2023). [41] Leonard Salewski, Stephan Alaniz, Isabel Rio-Torto, Eric Schulz, and Zeynep Akata. 2023. In-context impersonation reveals large language models’ strengths and biases. Advances in neural information processing systems 36 (2023), 72044– 72057. [42] Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar. 2024. Scaling llm testtime compute optimally can be more effective than scaling model parameters. arXiv preprint arXiv:2408.03314 (2024). [43] Yang Sui, Yu-Neng Chuang, Guanchu Wang, Jiamu Zhang, Tianyi Zhang, Jiayi Yuan, Hongyi Liu, Andrew Wen, Shaochen Zhong, Na Zou, et al. 2025. Stop overthinking: A survey on efficient reasoning for large language models. arXiv preprint arXiv:2503.16419 (2025). [44] Weifeng Sun, Naiqi Huang, Meng Yan, Li Huang, Zhongxin Liu, Xiao Liu, and David Lo. 2026. Cost-Effective Adversarial Attacks Against Code LLM with Model Attention. IEEE Transactions on Software Engineering (2026). [45] Weifeng Sun, Meng Yan, Zhou Yang, Yuchen Chen, Song Sun, and David Lo. 2026. MultiCodeAttack: Iterative Jailbreak Attacking on LLMs with Multi-Code Prompt Injection. In Findings of the Association for Computational Linguistics: ACL 2026. 14670–14690. [46] Himanshu Thakur, Atishay Jain, Praneetha Vaddamanu, Paul Pu Liang, and LouisPhilippe Morency. 2023. Language models get a gender makeover: Mitigating gender bias with few-shot data interventions. In Proceedings of the 61st Annual

How Reasoning Shapes Social Bias in LLM-Generated Code?

Meeting of the Association for Computational Linguistics (Volume 2: Short Papers). 340–351. [47] Eddie Ungless, Amy Rafferty, Hrichika Nag, and Björn Ross. 2022. A robust bias mitigation procedure based on the stereotype content model. In Proceedings of the Fifth Workshop on Natural Language Processing and Computational Social Science (NLP+ CSS). 207–217. [48] Peiyi Wang, Lei Li, Liang Chen, Zefan Cai, Dawei Zhu, Binghuai Lin, Yunbo Cao, Lingpeng Kong, Qi Liu, Tianyu Liu, et al. 2024. Large language models are not fair evaluators. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 9440–9450. [49] Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2022. Self-consistency improves chain of thought reasoning in language models. arXiv preprint arXiv:2203.11171 (2022). [50] 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. [51] Xin-Cheng Wen, Zirui Lin, Yijun Yang, Cuiyun Gao, and Deheng Ye. 2025. Vul-R2: A Reasoning LLM for Automated Vulnerability Repair. arXiv preprint arXiv:2510.05480 (2025). [52] Frank Wilcoxon. 1992. Individual comparisons by ranking methods. In Breakthroughs in statistics: Methodology and distribution. Springer, 196–202. [53] 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. arXiv preprint arXiv:2505.09388 (2025). [54] Guang Yang, Yu Zhou, Xiang Chen, Xiangyu Zhang, Terry Yue Zhuo, and Taolue Chen. 2024. Chain-of-thought in neural code generation: From and for lightweight language models. IEEE Transactions on Software Engineering 50, 9 (2024), 2437– 2457. [55] Zezhou Yang, Sirong Chen, Cuiyun Gao, Zhenhao Li, Xing Hu, Kui Liu, and Xin Xia. 2025. An empirical study of retrieval-augmented code generation: Challenges and opportunities. ACM Transactions on Software Engineering and Methodology 34, 7 (2025), 1–28. [56] Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. 2023. Tree of thoughts: Deliberate problem solving with

ASE ’26, October 12–16, 2026, Munich, Germany

large language models. Advances in neural information processing systems 36 (2023), 11809–11822. [57] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. 2022. React: Synergizing reasoning and acting in language models. In The eleventh international conference on learning representations. [58] William J Youden. 1950. Index for rating diagnostic tests. Cancer 3, 1 (1950), 32–35. [59] Yue Yu, Yuchen Zhuang, Jieyu Zhang, Yu Meng, Alexander J Ratner, Ranjay Krishna, Jiaming Shen, and Chao Zhang. 2023. Large language model as attributed training data generator: A tale of diversity and bias. Advances in neural information processing systems 36 (2023), 55734–55784. [60] Daoguang Zan, Bei Chen, Fengji Zhang, Dianjie Lu, Bingchao Wu, Bei Guan, Wang Yongji, and Jian-Guang Lou. 2023. Large language models meet NL2Code: A survey. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 7443–7464. [61] Xiaoyu Zhang, Juan Zhai, Shiqing Ma, Qingshuang Bao, Weipeng Jiang, Qian Wang, Chao Shen, and Yang Liu. 2025. The invisible hand: Unveiling provider bias in large language models for code generation. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 21376–21403. [62] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. 2023. Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems 36 (2023), 46595–46623. [63] Xueyang Zhou, Guiyao Tie, Guowen Zhang, Weidong Wang, Zhigang Zuo, Di Wu, Duanfeng Chu, Pan Zhou, Lichao Sun, and Neil Zhenqiang Gong. 2025. Large reasoning models in agent scenarios: exploring the necessity of reasoning capabilities. arXiv e-prints (2025), arXiv–2503. [64] Yuqi Zhu, Ge Li, Xue Jiang, Jia Li, Hong Mei, Zhi Jin, and Yihong Dong. 2025. Uncertainty-guided chain-of-thought for code generation with llms. arXiv preprint arXiv:2503.15341 (2025). [65] Arastoo Zibaeirad and Marco Vieira. 2025. Reasoning with llms for zero-shot vulnerability detection. arXiv preprint arXiv:2503.17885 (2025).

Received 2026-03-26; accepted 2026-06-18

Related documents

• Can LLMs be Effective Code Contributors? A Study on Open-source Projects#139020
• Using LLMs in Software Design: An Empirical Study of GitHub and A Practitioner Survey#1036689
• Constraint Decay: The Fragility of LLM Agents in Backend Code Generation#168374
• Many-Tier Instruction Hierarchy in LLM Agents#972429
• LLMs as Philosophers: What Can They Do? Why Aren't They Better?#101278