{"id":"46ab371a-8b67-46ea-99f7-078e2ebcc609","arxiv_id":"2411.10351","paper_version":4,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"An evaluation framework and 343-task benchmark show that four code LLMs produce socially biased code, and iterative bias feedback reduces measured bias substantially.","lead":"This paper introduces a framework called Solar that automatically creates tests to detect social bias in code written by large language models, then uses feedback to reduce that bias. It finds bias in all four tested code models and shows that iterative prompting can cut measured bias by more than 85 percent in one model.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"CBS hinges on unverified reclassification of legitimate protected attributes; audit Solar's 343 task labels before trusting the severe-bias and 90%-mitigation claims.","rationale":"The central claim is not internally inconsistent, and the paper has real strengths: a reusable dataset of 343 tasks, a black-box metamorphic-testing framework, and mitigation experiments with a concrete artifact. The empirical result that code LLMs exhibit demographic stereotypes is plausible and consistent with adjacent NLP-bias work. The load-bearing weak point is external validity of the bias measure: CBS/BLS are meaningful only if Solar's sensitive-attribute set never includes a characteristic that the task legitimately requires. The paper asserts a manual adjustment step ('adjust some related attributes that should be considered as sensitive attributes') but gives no per-task mapping, no inter-rater reliability, and no example of a task where age/employment was moved from sensitive to related. Because the dataset categories explicitly include domains where such attributes are often legitimate, this is a concrete, checkable threat rather than a philosophical dispute about fairness notions. The reader's weakest_assumption is essentially right, though I soften 'no allowance' to 'unverified allowance'; the pipeline might survive the audit. For that reason the appropriate disposition is unchanged from the reader's CONDITIONAL: require the audit before treating the severe-bias and 90%-mitigation claims as established.","tokens_in":12429,"tokens_out":8946,"duration_ms":84324,"concrete_test":"Audit SocialBias-Bench: for each of the 343 task definitions, independently annotate whether any protected attribute (especially age, employment status, or marital status) is a legitimate functional criterion given the task docstring and category (e.g., age for senior health programs, employment status for unemployment benefits), with two annotators and reported agreement. For tasks where a protected attribute is legitimate, move it from the sensitive set to the related set in Solar and recompute CBS (Eq. 2), BLS (Eqs. 3-4), and the Table 5 iterative-prompting results. If GPT-3.5's CBS_overall drops materially below 60.58%, or age/employment CBS columns drop sharply, the severe-bias claim is inflated; if numbers barely change, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Solar's bias definition (Eq. 1) counts any output difference caused by changing a protected attribute as social bias. The methodology says a demographic dimension that is relevant to a task is moved into the 'related attributes' set, but the paper does not report how that reclassification was done for the 343 SocialBias-Bench tasks, nor does it publish the resulting sensitive/related label mapping. This is the linchpin of the empirical claim: three task categories (social benefits, health exams/programs, licenses) plausibly require legitimate use of age, employment status, or marital status (e.g., senior health screening, unemployment benefits, spousal benefits). If any such protected attribute remains in the sensitive set, Solar labels correct code as biased. The high per-dimension CBS values for age (31.25%) and employment status (33.24%) on GPT-3.5 are exactly where false positives are most likely. The same flaw propagates to mitigation: iterative prompting lowers CBS by telling the model to avoid sensitive attributes, and Pass@attribute rises in part because it rewards not using sensitive attributes, so the reported 90% reduction inherits the same label-dependency. An audit is therefore the minimal step needed before the 'severe bias' conclusion can be taken at face value.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces Solar, a black-box metamorphic-testing framework for detecting and mitigating social bias in LLM-generated code. Solar parses task definitions into code prompts and executable test cases that mutate one protected attribute at a time, and it reports Code Bias Score (CBS), Bias Leaning Score (BLS), and a proposed Pass@attribute correctness metric. The authors contribute SocialBias-Bench, a dataset of 343 human-centered coding tasks across seven categories, evaluate four LLMs (GPT-3.5-turbo-0125, codechat-bison@002, CodeLlama-70b-instruct-hf, claude-3-haiku-20240307), report severe bias (e.g., 60.58% CBS for GPT-3.5), and find that iterative prompting with Solar feedback substantially reduces CBS (e.g., to 8.77% for GPT-3.5) while Pass@attribute improves.","tokens_in":12643,"tokens_out":6926,"duration_ms":61932,"significance":"If the measurement framework is valid, this is a useful step toward automated, black-box fairness testing for code generation. Strengths include the publicly released artifacts, an extensible dataset with 343 tasks, the use of metamorphic testing as a concrete oracle mechanism, and the comparison of four LLMs under identical prompting conditions. The paper also goes beyond detection by exploring mitigation strategies and reporting statistical significance for the mitigation effects. The central quantitative claims, however, depend on the construct validity of the bias definition and on the independence of the evaluation oracle; the manuscript currently leaves both under-supported.","major_comments":[{"comment":"Equation (1) defines bias as any output difference caused by changing a protected attribute value. This is only a valid definition if protected attributes are never legitimate inputs for the task. The methodology states that when a demographic dimension is related to a task it is moved into the 'related attributes' set, but the paper does not report this reclassification for the 343 tasks, nor does it publish the resulting sensitive/related label mapping. Table 2 even states that all tasks in a category share the same related attributes, which is implausible across scenarios such as childcare-assistant eligibility and unemployment benefits. This is load-bearing because the dataset includes social benefits, health exams/programs, and licenses, where age, employment status, or marital status can be legitimate eligibility criteria. The high age (31.25%) and employment-status (33.24%) CBS values for GPT-3.5 in Table 3 are exactly where false positives would occur. Please audit the per-task labels, release the mapping, and recompute or re-analyze CBS after separating legitimate from illegitimate attribute use.","section":"Methodology: Task generation and Eq. (1)"},{"comment":"Pass@attribute counts sensitive attributes not used in the code as true negatives, so a snippet that omits all sensitive attributes is rewarded rather than penalized. This metric therefore cannot support the paper's claim that mitigation improves functional correctness 'without sacrificing functional correctness' (Section 'Results of Bias Mitigation Strategies'). The observed Pass@attribute increase from 66.60% to 85.66% in Table 5 is consistent with the model learning to drop attributes, not with improved task-level correctness. Please add a functional correctness measure that is independent of attribute usage, or reword the correctness claims to match the metric actually used.","section":"Testing Code Bias, Eq. (5)"},{"comment":"The mitigation evaluation uses the same Solar oracle for both feedback and assessment: Solar generates the iterative-prompting feedback and also computes the CBS and Pass@attribute values reported as outcomes. The reported reduction from 60.58% to 8.77% for GPT-3.5 is therefore not an independent demonstration of bias reduction. Please validate the mitigation results with an external bias test set or human annotation, and provide the exact feedback prompts used in each iteration so that the reader can distinguish 'removing sensitive attributes from the decision rule' from 'making a fair decision on the basis of all available information.'","section":"Bias Mitigation Strategies and Table 5"}],"minor_comments":[{"comment":"The final sentence, 'Last, we make the code and data publicly available is highly extensible to evaluate new social problems,' is ungrammatical and should be rewritten.","section":"Abstract"},{"comment":"The definition of $N_{bias}$ in the BLS formula is ambiguous; the text says 'as indicated by $N_b$' but the denominator is written as $N_{bias}$. Please align the notation and define what counts as a 'prejudicial reference' in code.","section":"Testing Code Bias, Eq. (3)"},{"comment":"The table caption and body use inconsistent spellings ('Pass@attr', 'Pass@attribte', 'CBSdemographic'); also, the abstract's 'up to 90%' reduction is not directly visible in Table 5, so please state which model and iteration produces exactly 90%.","section":"Table 5"},{"comment":"The description of temperature effects is incomplete; phrases such as 'CBS increased from (t= 0.4) for GPT-3.5-turbo-0125' lack the actual CBS values at the relevant temperatures.","section":"Figure 4"},{"comment":"CBS point estimates in Table 3 are reported as single percentages for 1,715 generated snippets per model; please add confidence intervals or per-task variances so the reader can assess the precision of the cross-model ordering.","section":"Evaluation Results"},{"comment":"The claim that Solar's bias testing 'does not have false positive detection' should be qualified: false positives can still arise from the label definitions in Eq. (1), even if the test execution is deterministic.","section":"Conclusion / Related Work"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know this paper before citing the 60% CBS number. The benchmark and framework are real contributions, but the headline severity and the 90% mitigation result both rest on a label mapping that isn't reported in the paper. An audit of that mapping is needed before the severity claim is taken at face value.\n\nWhat's actually new: SocialBias-Bench gives 343 real-world human-centered tasks across seven categories, which goes beyond the contrived method-signature prompts in Liu et al. and the one-sentence prompts in Huang et al. Solar's DSL-based test generation is a reasonable black-box approach, and the BLS metric for bias direction is a useful addition. The comparison of mitigation strategies—CoT, role-playing, iterative prompting—is informative, and the finding that dialogue with Solar reduces bias while keeping functional correctness (as they measure it) is the kind of practical result practitioners want. The code and data are public, which is good.\n\nWhere it's soft: The construct validity of Eq. (1) is the load-bearing issue. It defines any outcome difference when a protected attribute changes as bias, with no allowance for legitimate use. The authors claim to handle this by reclassifying relevant demographics as related attributes, but they never show the per-task mapping. The stress-test worry is not hypothetical: three of the seven task categories (social benefits, health exams, licenses) plausibly require age, employment status, or marital status. Without the mapping, we can't tell whether a senior health screening task correctly treats age as related or incorrectly flags it as bias. The high age CBS (31.25%) and employment status (33.24%) for GPT-3.5 are exactly where false positives would concentrate. The methodology is not obviously wrong; it's just insufficiently documented.\n\nSecond, Pass@attribute is gameable. It counts sensitive attributes not used in the code as true negatives. So a model that simply drops all sensitive attributes gets a high score. Iterative prompting explicitly tells the model to avoid sensitive attributes, so the improvement from 66.60% to 85.66% is partially an artifact of the metric. This needs to be validated against a real functional correctness check.\n\nMinor issues: only GPT-3.5 results are shown in the main table, there are no confidence intervals around CBS point estimates, and the 'up to 90%' claim doesn't match the 60.58% to 8.77% drop for GPT-3.5 (about 85%). These are minor by comparison.\n\nWho it's for: SE and fairness researchers, and anyone deploying code LLMs in human-centered domains. The dataset and framework have value even if the severity conclusion is overstated. It deserves a serious referee, but the revision needs to release the sensitive/related mapping, fix Pass@attribute, and tone down the severity claim accordingly.\n\nRecommendation: engage with it, but treat the severity numbers as provisional until the mapping is audited and the metric is tightened.","headline":"Valuable benchmark and framework, but the headline severity and 90% mitigation claims rest on an unverified sensitive/related attribute mapping that an audit must clear.","tokens_in":13138,"tokens_out":3361,"would_cite":true,"duration_ms":32056,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that social bias in LLM-generated code is widespread, quantifiable, and largely mitigable through iterative prompting guided by automated fairness tests.","keywords":["social bias","code generation","fairness testing","metamorphic testing","large language models","bias mitigation","prompt engineering","LLM-generated code"],"falsifier":"Run Solar on a task where the protected attribute is the actual eligibility criterion, for example a function that grants senior benefits only to people over 60. A deliberately correct implementation would still fail Equation 1 for the age attribute, so the Code Bias Score would not be zero; observing that would show the metric cannot distinguish legitimate attribute use from social bias.","tokens_in":12244,"feed_emoji":"⚖️","tokens_out":4641,"duration_ms":43132,"temperature":0.7,"pith_summary":"The paper claims that LLMs that write code carry measurable social bias, and that a black-box testing loop can both quantify and reduce it. It introduces Solar, which turns human-centered task descriptions into code prompts and executable test cases, then checks whether generated code changes its output when only a protected attribute such as gender, race, or age changes. Applied to four code-generation models on 343 tasks, the framework reports severe bias in all of them, with GPT-3.5-turbo-0125 scoring a 60.58% Code Bias Score. Feeding the failing test results back as prompts over three iterations drops that score to 8.77% while functional correctness, measured by attribute usage, rises from 66.60% to 85.66%. The point of caring: social bias in generated code is not just a text-generation artifact; it is testable and partly fixable through prompting alone.","feed_headline":"Solar-guided prompts cut LLM code bias by up to 90%","feed_subtitle":"A black-box fairness tester found high bias in all four models tested and reduced it without hurting code quality.","key_machinery":"The central object is Solar's test-case generator, built on a domain-specific language (textX), together with the bias definition in Equation 1: a code snippet is biased if changing one protected attribute while holding everything else fixed changes the output. From each task definition, Solar generates a class skeleton and executable tests that instantiate individuals identical except for one sensitive attribute and assert equal outcomes. The Code Bias Score (CBS) is the fraction of biased executable snippets, the Bias Leaning Score with its range (BLS@Range) captures which demographic value a model favors, and Pass@attribute tracks whether the right related attributes are used and sensitive attributes are avoided. This machinery carries the argument because it converts an abstract fairness concern into runnable assertions and a feedback signal for prompt refinement.","core_discovery":"On the paper's own terms, the central claim is that social bias in LLM-generated code is widespread and quantifiable, and that iterative prompting guided by automated fairness testing can mitigate it without sacrificing functional correctness. The paper supports this with a dataset of 343 real-world human-centered coding tasks in seven categories, a framework that generates prompts and test cases from task definitions, and the Code Bias Score, Bias Leaning Score, and Pass@attribute metrics. The headline numbers are that all four subject models have overall Code Bias Scores above 28%, with GPT-3.5-turbo-0125 highest at 60.58%, and that after three Solar-guided iterations the same model's Code Bias Score falls to 8.77% while Pass@attribute rises from 66.60% to 85.66%. This establishes that a black-box testing pipeline can serve as both a bias detector and a mitigation engine for code-generation models.","pith_inferences":["The paper's demographic-parity definition implies that Solar would flag legitimate use of a protected attribute as bias; a natural extension is to separate 'protected attribute used as the genuine criterion' from 'protected attribute used as a proxy' based on the task's stated eligibility rule.","Because Solar is black-box and prompt-only, the same iteration loop could be adapted to other code-side harms, such as security vulnerabilities or privacy leaks, by replacing the fairness oracle with a security or privacy oracle.","The large improvement from iterative feedback suggests that much of the bias is elicited by the prompt rather than deeply fixed in the model weights; testing whether the residual 8.77% can be pushed toward zero with more iterations would probe that hypothesis.","The Pass@attribute metric measures attribute usage, not behavioral correctness; combining it with assertion-based functional tests would give a stronger guarantee that bias removal does not silently break intended conditions."],"forward_implications":["Social bias in LLM-generated code is measurable by black-box testing, so models can be screened for bias without access to weights or training data.","Iterative prompting with test feedback can cut the overall Code Bias Score for GPT-3.5-turbo-0125 from 60.58% to 8.77% while improving Pass@attribute from 66.60% to 85.66%.","Chain-of-Thought and positive role-play prompts alone do not reliably reduce bias and can even increase it, so naive 'be fair' prompting is not a sufficient mitigation strategy.","Temperature changes alter the Code Bias Score unevenly across models, so reported bias scores should be accompanied by the sampling configuration used."],"supporting_citations":[{"why":"Supplies the HumanEval benchmark and the code-model lineage whose Pass@1 scores are used to position the subject models.","marker":"Chen et al. 2021"},{"why":"Provides the Code Bias Score definition and the prior bias-in-code-generation benchmark that this paper extends.","marker":"Liu et al. 2023"},{"why":"Prior work on bias testing and mitigation in LLM-based code generation whose limitations motivate Solar's design.","marker":"Huang et al. 2023"},{"why":"Introduces fairness testing for software and the notion of causal discrimination that underlies Solar's test oracle.","marker":"Galhotra, Brun, and Meliou 2017"},{"why":"Supplies the demographic parity fairness notion formalized in the paper's Equation 1.","marker":"Corbett-Davies et al. 2017"},{"why":"Introduces metamorphic testing, the testing concept Solar adapts to generate executable fairness tests.","marker":"Chen, Cheung, and Yiu 2020"},{"why":"The textX domain-specific language tool used to automate prompt and test-case generation.","marker":"Dejanović et al. 2017"}],"fun_headline_variants":["Solar dialogue cuts LLM code bias up to 90%","All four code LLMs show bias; Solar reduces it","Black-box tester finds and fixes code bias","Solar: automated bias detection and mitigation","Bias in every code LLM; Solar dialogue slashes it"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire measurement rests on treating any difference in output caused by changing a protected attribute as bias; if a task legitimately requires that attribute, such as age for senior health care or employment status for unemployment benefits, the metric will count correct code as biased and the 'severe bias' finding is inflated.","fun_headline_variants_meta":{"raw":{"variants":["Solar dialogue cuts LLM code bias up to 90%","All four code LLMs show bias; Solar reduces it","Black-box tester finds and fixes code bias","Solar: automated bias detection and mitigation","Bias in every code LLM; Solar dialogue slashes it"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00047,"raw_usage":{"total_tokens":2332,"prompt_tokens":933,"completion_tokens":1399,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":1322}},"tokens_in":549,"tokens_out":1399,"duration_ms":12573,"temperature":1.0,"reasoning_tokens":1322,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T19:41:59.049383+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run Solar on a task where the protected attribute is the actual eligibility criterion, for example a function that grants senior benefits only to people over 60. A deliberately correct implementation would still fail Equation 1 for the age attribute, so the Code Bias Score would not be zero; observing that would show the metric cannot distinguish legitimate attribute use from social bias.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the Code Bias Score definition and the prior bias-in-code-generation benchmark that this paper extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior work on bias testing and mitigation in LLM-based code generation whose limitations motivate Solar's design."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces fairness testing for software and the notion of causal discrimination that underlies Solar's test oracle."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the demographic parity fairness notion formalized in the paper's Equation 1."}],"review_version":1}