The ML Paper Reproducibility Crisis: 60% of Code Contains Fatal Bugs — Should Top Conferences Mandate Code Submission?

A Reviewer's Warning: Only 1 Out of 12 Papers Had Complete Code

As the NeurIPS review season wraps up, a researcher who participated in the review process for three top conferences this year posted a disturbing observation on Reddit. His core demand was straightforward: it's time to desk reject papers that don't provide reproducible code.

A desk reject is a rapid screening mechanism in academic publishing where a paper is rejected by the program committee chair or area editor before entering formal peer review. This is typically reserved for papers that clearly fail to meet submission requirements, such as irrelevant topics, serious formatting violations, or rule breaches. Making the lack of reproducible code a criterion for desk rejection means this would no longer be a quality issue left to reviewer discretion — it would become a hard admission threshold on par with formatting requirements.

This proposal may seem radical, but it's backed by solid data. Among the 12 papers this reviewer examined this year, only 1 provided complete code — meaning a full training pipeline that runs from input dataset all the way to output AUROC metrics. AUROC (Area Under the Receiver Operating Characteristic Curve) is one of the core metrics for evaluating classification model performance in machine learning. It plots the relationship between true positive rate and false positive rate at different thresholds, then calculates the area under the curve to assess the model's discriminative ability. A "complete training pipeline" refers to the full chain of code from raw data loading, preprocessing, model definition, and training loop to final evaluation metric output — missing any single link makes end-to-end reproduction impossible. Another 4 papers provided fragmentary partial code that couldn't reproduce experiments end-to-end, while the remaining 7 papers provided no code whatsoever.

reddit discussion original post

Even more alarming: among those 5 papers that at least provided partial code, 3 contained obvious bugs that were severe enough to completely invalidate the paper's conclusions. As for what lurks within those 7 papers without code, nobody knows.

Small Bugs, Big Disasters: How Code Errors Invalidate Paper Conclusions

Machine learning is a highly technical field where a seemingly trivial code error in a critical location can have an enormous impact on final results.

Why Reproducibility Is So Fragile

In ML research, experimental results often depend on numerous implementation details: data preprocessing methods, random seeds, batch normalization, evaluation metric computation logic, and more. These details are extremely difficult to describe completely in the paper text.

Take Batch Normalization as an example — a widely used technique in deep learning that accelerates training by normalizing inputs within each mini-batch. However, its behavior differs fundamentally between training mode and inference mode: during training it uses the current batch's statistics, while during inference it uses moving averages accumulated throughout training. This means different batch sizes, data ordering, or even failing to correctly switch modes will all produce different experimental results. Random seeds control all stochastic operations including weight initialization, data shuffling order, and dropout masks — even with identical code, different random seeds can produce significantly different results. These details are usually mentioned in passing in papers, yet they have decisive impact on reproducibility.

An even more typical example is data leakage — where test set information inadvertently infiltrates the training process. Such errors are nearly impossible to detect in written descriptions but are often immediately obvious in code. Common forms of data leakage include: normalizing the entire dataset before splitting into train/test sets (so the training set's normalization parameters contain test set statistics), using future data for feature construction in time series prediction, or performing feature selection outside cross-validation folds. These errors are extremely difficult to spot in a paper's methodology text, because authors typically only write "we split the data into 80/20 train/test sets" without mentioning the specific order of normalization operations. But in code, such errors usually manifest as a few lines in the wrong order, which trained reviewers can quickly identify.

The original poster pointed out that this is precisely why judging a work's reliability based solely on paper text is extremely dangerous. When 60% of papers that provided code were found to contain fatal bugs, we have good reason to suspect that the actual error rate among papers that provide no code at all is likely even higher.

The Cascading Risk of Unverifiable Results

Non-reproducible research pollutes the entire academic ecosystem. Subsequent researchers may build their work on flawed baselines, wasting enormous amounts of time and compute chasing a performance level that never actually existed.

In machine learning research, a baseline refers to the reference method used for comparison — a new method's contribution is typically demonstrated by surpassing the baseline. If a widely cited paper reports inflated performance numbers (whether due to code bugs or data leakage), subsequent researchers will treat this erroneous number as "the target to beat." This creates a vicious cycle: to surpass an unrealistic baseline, researchers may resort to overfitting, cherry-picking results, or other questionable practices. More seriously, when multiple papers in an entire subfield are built on the same flawed baseline, the cost of correction grows exponentially — because admitting the baseline is flawed means the conclusions of numerous published works need to be revisited. This systematic waste of resources ultimately damages the entire field's research efficiency.

Broken Incentives: Why Hiding Code Is Actually Safer

The original poster hit the nail on the head: the essence of this crisis is a failure of incentive mechanisms.

Under the current review process, hiding code carries virtually no cost. On the contrary, releasing code actually increases the risk of rejection — because reviewers might find bugs in it. This creates a perverse game:

Release code: Face the risk of reviewers finding implementation issues, potentially leading to rejection;
Hide code: Reviewers have no way to verify, making it paradoxically "safer."

Under these rules, rational submitters naturally tend not to release code. Honesty and transparency become a competitive disadvantage. This is a classic adverse selection dilemma of the "bad money drives out good" variety. In game theory, this scenario is called "moral hazard under information asymmetry" — when hiding information cannot be effectively monitored and punished, rational individuals will tend to choose strategies that benefit themselves but harm the collective, ultimately leading to systemic trust collapse.

Changing the Rules of the Game: From Bonus Points to Hard Requirements

The original poster argues that the only solution is to change the rules of the game itself — imposing real penalties for hiding code. That is, transforming "providing reproducible code" from a bonus item to a hard submission threshold. If you don't provide it, desk reject.

Only when the cost of hiding code exceeds the potential risk of releasing it will submitter behavior fundamentally change.

The Real-World Controversy and Compromise Solutions Around Mandatory Code Submission

Despite this proposal's strong legitimacy in pursuing research integrity, it still faces considerable real-world challenges in implementation — which is where community discussions tend to diverge.

Arguments in Favor of Mandatory Code Submission

Mandatory code submission can significantly improve reproducibility and filter out large volumes of work with implementation errors;
Top conferences like NeurIPS and ICML have already begun encouraging or even requiring submission of reproducibility checklists — mandatory code is the natural next step. Since 2019, NeurIPS has required authors to submit such checklists covering experimental setup, hyperparameter search ranges, computational resources, code availability, and more. ICML and ICLR subsequently adopted similar practices. NeurIPS also established a dedicated Reproducibility Challenge encouraging students to attempt reproducing experimental results from published papers. However, these measures currently remain primarily "encouraged" and "self-reported" without constituting mandatory constraints — for the "is code provided" item on the checklist, authors need only check "yes/no" and give a brief reason, and not providing code doesn't directly lead to rejection;
Technical solutions like anonymous code repositories (such as anonymous GitHub links) can already adequately balance the needs of double-blind review. Double-blind Review is a review system where both reviewers and authors are unaware of each other's identities, aimed at reducing review bias. Releasing code under this system faces a technical challenge: commit histories, usernames, and organization information in code repositories can all reveal author identity. To resolve this tension, the community has developed multiple anonymization approaches: Anonymous GitHub allows creation of identity-stripped repository mirrors, the OpenReview platform supports anonymous attachment uploads, and some conferences allow code submission as zip packages in supplementary materials. While imperfect, these technical solutions can effectively balance transparency and anonymity in most situations.

Real-World Constraints to Consider

Some research involves proprietary datasets, commercially sensitive data, or extremely large-scale compute — even if code is released, true reproduction may remain impossible;
Industry research teams may be constrained by intellectual property policies and unable to open-source core code;
Reviewers are already heavily burdened — running and reviewing code for each paper would further increase review costs.

For these constraints, a compromise might be: making "whether reproducible code is provided" an explicit scoring criterion in reviews, rather than a blanket hard-reject standard, while providing an exemption pathway for work that has legitimate reasons for not releasing code.

Transparency Is the Floor of Science

This discussion about code reproducibility touches on a deep structural contradiction in contemporary ML research: in an era of explosive growth in paper volume and unprecedented publication pressure, how do we ensure the authenticity and reliability of research outcomes?

Code is not an appendage to a paper — it is the evidence for experimental conclusions. When more than half of a field's top conference papers cannot even provide basic reproducible code, that itself is a signal worthy of serious reflection by the entire community. Perhaps as the original poster said, it's time to change the rules so that transparency once again becomes the default in scientific research, rather than the exception.