Social Bias in LLM-Generated Code: Benchmark and Mitigation

1. Problem Statement

Large Language Models (LLMs) are increasingly used to generate code for human-centered applications (e.g., hiring, healthcare, financial aid). While existing benchmarks (like HumanEval) focus on functional correctness, they ignore social bias.

• The Gap: Current evaluations do not assess whether generated code treats demographic groups equitably.
• The Risk: LLMs may generate code that systematically discriminates against protected attributes (e.g., gender, race, age) by embedding biased logic into executable code.
• The Challenge: Mitigating this bias is difficult because standard prompt engineering (e.g., Chain-of-Thought) often fails or exacerbates the problem, and many real-world scenarios lack executable test suites (oracles) to detect bias.

2. Methodology & Framework

The authors propose a comprehensive empirical study involving a new benchmark, a fairness evaluation framework, and a novel mitigation agent.

A. SocialBias-Bench (The Benchmark)

• Scope: A dataset of 343 real-world coding tasks across seven categories: Social benefits, University admissions, Employee development, Health exams, Licenses, Hobbies, and Occupations.
• Design: Tasks are structured as Python classes with a Person dataclass containing sensitive attributes (e.g., gender, race, religion) and related attributes (e.g., GPA, income).
• Goal: To force LLMs to make decisions based on task-relevant logic rather than demographic shortcuts.

B. Solar (The Evaluation Framework)

• Mechanism: A fairness evaluation framework based on Metamorphic Testing.
• Process:
  1. Generates executable test cases where all attributes are identical except for one sensitive attribute (e.g., changing gender from "male" to "female").
  2. Executes the generated code on these inputs.
  3. Bias Detection: If the code produces different outputs for inputs that differ only in a protected attribute, it is flagged as biased.
• Metrics:
  • Code Bias Score (CBS): Percentage of biased code snippets.
  • Bias Leaning Score (BLS): Directional preference toward specific demographic values.
  • Pass@attribute: Functional correctness regarding the use of required vs. sensitive attributes.

C. Mitigation Strategies Investigated

The paper evaluates four distinct approaches to mitigate bias:

1. Prompt-Level Interventions: Chain-of-Thought (CoT) reasoning and "Fairness Persona" assignment (P-CoT).
2. Structured Multi-Agent Workflows (FlowGen): Using software process models (Waterfall, Scrum) with specialized roles (Requirement Engineer, Architect, Developer, Tester).
3. Fairness Monitor Agent (FMA): A modular, oracle-free system that intercepts code generation pipelines.
   • Architecture:
     • Fairness Requirements Analyst: Classifies attributes as "Required" or "Restricted" based solely on the task description (no test data needed).
     • Developer: Generates code based on these constraints.
     • Fairness Reviewer & Repairer: Perform static LLM-based analysis to detect violations and iteratively rewrite the code to remove biased logic.

3. Key Contributions

1. SocialBias-Bench: The first comprehensive benchmark of 343 human-centered coding tasks spanning seven demographic dimensions.
2. Solar Framework: An automated, oracle-free method to quantify social bias using metamorphic testing.
3. Empirical Findings on Bias:
   • Demonstrated that bias is structural (embedded in model weights) rather than a sampling artifact.
   • Showed that prompt-level interventions (CoT, Persona) often amplify bias rather than reduce it.
   • Revealed that structured workflows (Waterfall) reduce bias, but adding explicit fairness instructions to all roles causes a "diffusion of responsibility," worsening outcomes.
4. FMA (Fairness Monitor Agent): A novel, plug-and-play agent system that reduces bias by 65.1% without requiring test oracles, outperforming all other studied approaches.

4. Key Results

RQ1: Severity of Bias

• Prevalence: All four evaluated LLMs (GPT-3.5, CodeLlama, Claude, etc.) exhibited severe bias.
  • GPT-3.5-turbo had the highest bias (CBS: 60.58%).
  • CodeLlama-70b had the lowest (CBS: 28.34%).
• Temperature Sensitivity: Bias is not monotonic with temperature. For some models (e.g., CodeLlama), lower temperatures (0.2) forced the model toward its most stereotyped outputs, increasing bias significantly.

RQ2: Prompt-Level Interventions

• Failure of CoT & Persona: Both Chain-of-Thought and Positive Role-Playing increased bias scores.
  • Example: GPT-3.5 CBS rose from 60.58% (Default) to 72.65% (CoT).
  • Reason: These methods force the model to surface its internal stereotypical associations rather than suppressing them.

RQ3: Multi-Agent Workflows

• Structure Helps: The Waterfall workflow reduced bias to 24.49% (vs. 60.58% baseline) by having upstream roles (Requirement Engineer) define scope early.
• Instructions Backfire: Adding fairness instructions to all agents increased bias to 31.06% (worse than baseline) due to diffusion of responsibility.
• Critical Role: The Requirement Engineer is the most critical role; removing them caused bias to spike to 36.97%.

RQ4: Fairness Monitor Agent (FMA)

• Performance: FMA reduced overall CBS from 48.40% (Developer baseline) to 16.91% (a 65.1% relative reduction) after three repair rounds.
• Dual Benefit: Unlike other methods, FMA improved functional correctness (Pass@attribute) from 75.80% to 83.97% by correcting both bias and missing logic.
• Limitation: Bias related to Employment Status was harder to mitigate (only reduced from 22.16% to 16.62%) because it is often inferred implicitly through world knowledge rather than explicit attribute checks.

5. Significance and Implications

• Paradigm Shift: The paper proves that "telling the model to be fair" via prompts is ineffective. Bias is a structural property of the model weights that requires external, structural intervention.
• Oracle-Free Mitigation: FMA is significant because it does not require a pre-existing test suite or ground-truth data. It relies on static analysis of the task description, making it applicable to real-world scenarios where automated fairness oracles do not exist.
• Process Engineering: The findings suggest that software development processes (like Waterfall) naturally aid fairness if upstream roles (Requirements) strictly define what attributes are allowed. However, this must be enforced by dedicated agents, not just generic role instructions.
• Future Direction: The persistence of implicit bias (e.g., employment status) highlights the need for future systems to reason about semantic correlations in world knowledge, not just explicit attribute usage.

In conclusion, the paper establishes that social bias in code generation is a critical, structural issue that cannot be solved by simple prompting. It offers FMA as a robust, modular solution that simultaneously improves fairness and code quality without relying on external test data.