Benchmarking | Xinyue Zheng

UniCode: Augmenting Evaluation for Code Reasoning

Wed, 01 Jul 2026 00:00:00 +0000

ICML 2026 · · ·

UniCode is a generative evaluation framework for code reasoning. Instead of asking whether a model can solve a familiar static benchmark, UniCode asks whether the model can still reason when the problem is structurally rewritten, recomposed, scaled, and tested against robust corner cases.

Background: the evaluation paradox

Modern code LLMs score impressively on standard benchmarks, yet often fail when requirements shift in realistic coding settings. This is the evaluation paradox: high benchmark accuracy does not necessarily mean robust reasoning. Static benchmarks can be saturated, contaminated, or solved through familiar templates and statistical shortcuts rather than genuine algorithmic adaptation.

UniCode addresses this by moving from static evaluation to generative evaluation. Instead of repeatedly testing a fixed set of problems, UniCode expands a dynamic problem space by transforming high-quality seed tasks into new variants that preserve rigor while changing the reasoning path required to solve them.

Why existing benchmarks are still insufficient

Many recent benchmark variants improve coverage, but a large portion of them still rely on shallow perturbations—for example variable renaming, story rewriting, or surface-level rephrasing. As we argue in the paper, these settings often focus on superficial variations rather than changing the underlying reasoning logic.

That means a model can appear robust simply because the old solution template still works. But in realistic coding, the challenge is not just reading a different story — it is adapting when the constraint changes, when the complexity budget changes, or when multiple algorithmic ideas must be composed together.

UniCode is designed to test exactly this deeper form of reasoning.

Methodology

UniCode has three main components.

1. Multi-dimensional task augmentation

UniCode starts from high-quality seed programming problems and generates new tasks along five reasoning axes:

Axis	What changes	What it probes
Narrative perturbation	Theme, variable names, or irrelevant context	Whether the model is biased by surface tokens
Rule modification	Operational rules or boundary conditions	Whether the model follows new constraints instead of a memorized solution
Efficiency scaling	Input scale and computational budget	Whether the model switches to a more efficient algorithm when needed
Sequential composition	Multiple algorithmic steps are chained together	Whether the model can maintain long reasoning chains
Concept fusion	Multiple algorithmic concepts are merged into one task	Whether the model can perform combinatorial generalization

These augmentations intentionally change the reasoning graph, not just the wording.

2. Stress-driven test generation

For newly generated tasks, human-written reference solutions do not scale. UniCode therefore constructs reliable test suites through a stress-driven pipeline.

The pipeline combines random cases, adversarial cases, and corner cases. For ground-truth outputs, UniCode uses brute-force solvers on small inputs, filters optimized candidates through trusted stress tests, uses majority voting on larger inputs, and finally applies LLM adjudication when solver outputs disagree.

3. Fine-grained diagnosis

A single pass/fail score hides why a model fails. UniCode therefore categorizes failures into modeling errors, logic bugs, complexity errors, indexing/cache bugs, and other implementation mistakes. This turns the benchmark from a simple leaderboard into a diagnostic tool for reasoning analysis.

Experimental results

UniCode evaluates 19 LLMs across reasoning-focused, general-purpose, and open-source families. The benchmark is both challenging and discriminative: even the top model reaches only 70.3% average Pass@1, and the average performance drop from seed problems to UniCode variants is 31.2%.

Main takeaways

Large performance collapse: strong performance on seed benchmarks does not reliably transfer to structurally augmented variants.
Hard split is still very difficult: several models drop to 0.0% on the hard subset.
Narrative shifts are easier than structural shifts: models are relatively robust to surface changes, but often fail when the logic, scale, or composition changes.
Reliable automatic evaluation: the stress-driven pipeline achieves 94.5% correctness and 86.0% coverage in the test-generation quality study.

Where do models fail?

UniCode reveals that model failures are structured, not random. The paper highlights three key findings:

1. Large variance across reasoning dimensions

Aggregate benchmark scores hide substantial within-model variance. Even strong models can perform well on one reasoning axis and collapse on another. This means a single average score often masks important blind spots.

2. Structural changes are much harder than surface changes

Models are comparatively robust to narrative perturbations, but they deteriorate sharply once the underlying reasoning graph changes. The hardest settings are typically efficiency scaling, sequential composition, and concept fusion, which require the model to adapt its strategy rather than reuse a familiar template.

3. Seed-problem regression

The most revealing phenomenon is seed-problem regression: models frequently fall back to the logic of the original seed task even when the augmented problem invalidates that logic. In other words, the model recognizes the old template, but fails to integrate the new constraints.

Beyond accuracy, UniCode also shows that the dominant error types are not small implementation mistakes. Instead, the main failures are modeling errors and complexity errors, revealing weaknesses in conceptualization, algorithm selection, and computational scaling.

Figure 5 provides concrete case studies of these failures. The examples show that models often reuse a memorized modeling paradigm or a low-efficiency solution that was valid for the seed task, but becomes wrong once new structure or new constraints are introduced.

Together, these results suggest that current code LLMs are often strong at syntax and familiar templates, but still fragile in zero-shot adaptation to novel algorithmic requirements.

Resources

Paper:
Code:
Dataset:

from datasets import load_dataset

dataset = load_dataset("grandsmile/Generative_Coding_Dataset")

Citation

@article{zheng2026unicode,
 title = {UniCode: Augmenting Evaluation for Code Reasoning},
 author = {Zheng, Xinyue and Lin, Haowei and Cai, Shaofei and Zheng, Zilong and Yang, Yaodong and Liang, Yitao},
 journal = {arXiv preprint arXiv:2510.17868},
 year = {2026}
}

The Illusion of Mastery: Breaking the Cycle of Benchmark Memorization with Generative Evaluation

Mon, 27 Apr 2026 00:00:00 +0000

1. Introduction

The development of Large Language Models (LLMs) is accelerating at a breakneck pace . On the surface, the progress appears dazzling: benchmarks are being saturated in record time, and models now achieve superhuman performance on specialized tasks such as coding or math competitions .

Yet a critical question remains: why do models that score “perfectly” on standardized benchmarks often “fail” in real-world applications? Why, for instance, can GPT-4 solve Olympiad-level math problems but sometimes get stuck in a loop while debugging simple code? What explains this persistent gap?

In a recent interview , Ilya Sutskever pinpointed a core issue: post-training optimization tends to overfit to leaderboard benchmarks. Models are fine-tuned via reinforcement learning tailored specifically to static test sets , enabling them to excel in exam-like environments while performing like rote learners in the real world.

Figure 1: The vicious cycle: memory capacity vs. reasoning ability. Image generated by Nano Banana pro.

This points to an important issue: the fragility of models stems not merely from data or training limitations, but from systemic overfitting to the specific reasoning paradigms present in current static evaluations. Every time a static benchmark is “solved”, the field falls into a cycle: Propose a harder static dataset $\rightarrow$ Scale up the model to overfit the new structure pattern $\rightarrow$ Propose an even harder dataset. This is a race of “memorization capacity vs. reasoning ability.” We mistakenly believe the model is getting smarter, but it is often just expanding its capacity to memorize patterns, thereby missing the opportunity to discover genuine reasoning algorithms and moving further away from the goal of AGI. As a result, in real-world applications, models frequently fail when users introduce novel “reasoning patterns” that are simple for humans but inaccessible through memorization.

In this post, we argue that the path to AGI requires a fundamental shift in how we measure intelligence. We will examine how current static evaluation misleads the industry and introduce generative evaluation—not merely as a new metric, but as a dynamic engine for discovering novel reasoning patterns that remain challenging for models to generalize.

2. The Failures of Static Evaluation

The current reliance on fixed, static evaluation benchmarks is actively misleading the industry. It fosters an “illusion of mastery,” where improving scores on stagnant datasets does not translate to reasoning intelligence. This systematic flaw is rooted in the following key issues:

2.1 The Contamination Illusion

The acceleration of data collection and model training has created a race we are losing: human benchmark design cannot keep pace with data crawler speed. A benchmark considered challenging upon release often sees a rapid, dramatic performance leap within months . This improvement frequently signals not an advancement in the model’s reasoning, but data contamination: the test data has leaked into the training set, effectively allowing the model to memorize the answers.

The Misleading Result: This data contamination results in deceptively inflated scores. This is evidenced by the significant performance gap observed on benchmarks like LiveCodeBench . As shown in Figure 2, models excel on problems released before their training cutoff dates but show a marked drop in performance on problems released afterward. This gap strongly suggests that the pre-release data was likely included in the model’s training corpus.

Figure 2: DeepSeek-Instruct and GPT-4o perform considerably worse on problems released after their respective release and cutoff dates, indicating potential contamination in the earlier problems .

The Memorization Trap: When test data leaks into the training corpus, models exploit those leaks to reproduce surface patterns instead of learning transferable reasoning strategies. This is exemplified by OpenAI’s Procgen test : models trained on a fixed order of levels (progressing only upon success) perform perfectly. However, at test time, when the level order is randomized, they fail completely. This strongly suggests that the agents did not acquire a generalizable policy for the game, but rather memorized action sequences specific to the fixed level order.

Figure 3: The agent achieves promising results during training on a fixed sequence but fails to generalize when the level order is shuffled at test time .

2.2 The Stagnant $80\%$ Crisis

While increasing model and dataset sizes have equipped current models with a degree of reasoning (e.g., solving unseen math problems), the “memorization trap” persists. It has simply evolved into a higher-level fixed pattern matching. Models memorize the fixed path to solve a specific set of problems but lack the ability to dynamically adjust reasoning path on novel context. A clear symptom of this trend is the widespread $80\%$ crisis, where models excel at the majority of common tasks but performance sharply drops on the remaining $20\%$ of novel challenges.

Early models like BERT made huge leaps, quickly reaching around $80\%$ accuracy on challenging benchmarks like SuperGLUE . However, vastly larger models such as GPT-4 and LLaMA variants only push performance up by a few marginal percentage points. This slowdown occurs because the final $20\%$ consists of rare and diverse corner cases. We are essentially spending billions of dollars to buy those final, expensive $1\%$ gains.

This leads to a resource paradox: according to scaling laws, improving performance on these sparse long-tail examples requires exponentially more parameters and data. Scaling laws describe how model loss $L$ decreases as we scale up model size $N$ and dataset size $D$. A common form is:

$$ L \propto \alpha N^{-\beta} D^{-\gamma} $$

Here:

$L$ is the model’s loss (lower is better)
$N$ is the number of model parameters
$D$ is the dataset size
$\alpha, \beta, \gamma$ are constants (typically less than 1)

As $N$ or $D$ increases, loss decreases but at a slowing rate. Early gains are rapid; later improvements become far more expensive. We are now spending billions for each marginal gain, chasing perfection via fixed pattern matching instead of developing reasoning algorithms for future challenges. Relying only on scaling is inefficient and unsustainable.

Static benchmarks typically mirror real-world data distributions, which makes them appear representative but also introduces a hidden bias: they underweight the most consequential failures. A substantial body of work documents that corner cases follow a long-tail distribution and are therefore extremely rare in collected logs . These rare events carry outsized safety impact so models can achieve high average performance on large static datasets while still failing catastrophically on corner cases. Empirical studies of autonomous driving quantify this sparsity: Waymo’s WOD-E2E dataset curates challenging long-tail driving cases and reports that such corner cases occur with frequency below $0.03\%$ in daily driving . Together these findings imply that static datasets will systematically underrepresent high-impact situations unless evaluation intentionally oversamples or emphasizes those corner cases.

Figure 4: Long-tail scenario examples from the Waymo Open Dataset for End-to-End Driving (WOD-E2E). WOD-E2E captures the long-tail scenarios with a frequency of less than 0.03% in daily driving..

2.4 The Mismatch on the Path to AGI

If our final destination is AGI, we have a fundamental problem: we are currently using finite sets to evaluate an AGI that is defined by its ability to solve unlimited diverse tasks. There is a mismatch between our target and our actual evaluation methods, creating a gap between AGI and current SOTA models. We want agents to be open-ended, possessing the capacity to generate endless solutions for scenarios that may not yet exist . As Elon Musk said in an interview : For self-driving, even if the road is painted completely wrong and a UFO lands in the middle of the road, the car still cannot crash and still needs to do the right thing. Our objective is a “super-agent” capable of handling infinite novelty, not merely taking a fixed exam.

3. The Blueprint of Generative Evaluation

As we have discussed, static benchmarks are facing an existential crisis due to their inability to assess true reasoning capabilities. To escape this cycle, the industry is gradually shifting toward a new paradigm: generative evaluation. Here, the benchmark is not a fixed dataset but an intelligent engine capable of producing an infinite, dynamic stream of novel tasks.

This shift is already visible in several research threads. OpenAI’s Procgen introduce programmatic generation to create new game levels by shuffling key variables. Dynabench incorporate a human‑in‑the‑loop to iteratively add adversarial examples. LiveCodeBench and SWE‑bench-Live employ live updates from the web to resist contamination. Efforts like SWE‑rebench, DARG and UniCode vary evaluation environments to identify memorization patterns. Frameworks like MCU and OMGEval extend evaluation into open‑ended domains to explore the broader boundaries of reasoning ability.

3.1 Core Concepts

Building on the related work above, we distill the common objective of generative evaluation. Crucially, this objective addresses the issues of pattern memorization and probes true reasoning capabilities through three key mechanisms:

Infinite Diversity: By generating an unbounded stream of diverse and novel tasks, the system ensures test cases are truly unseen during training, making rote memorization mathematically impossible. This forces models to rely on genuine reasoning and generalization.
Targets Novel Reasoning Pattern: Unlike static benchmarks biased toward high-frequency patterns, generative evaluation can be deliberately engineered to probe high-impact corner cases and “sensible factors” that challenge a model’s true generalization limits. Thus, evaluation shifts from measuring average performance to stress-testing critical weaknesses.
Scalability and Efficiency: It replaces costly, slow human labor with an automated pipeline that continuously generates and verifies tasks. Since tasks are generated programmatically, the time and financial costs are often orders of magnitude lower than manual curation, making sustainable, long-term progress feasible.

3.2 Generating Diverse, Contamination-Resistant Tasks

Simply instructing an LLM to “generate 100 new questions” often yields repetitive, low-quality output. A robust generative framework must follow a structured pipeline ensuring both diversity (to prevent memorization) and validity (to ensure fairness). Based on recent cutting-edge research in generative evaluation , we can distill diversity into two main directions:

3.2.1 Inter-task Diversity: The Breadth of Knowledge

This dimension represents coverage across distinct domains. Just as a student must study Math, History, and Science, an AI agent must be tested across different domains. Inter-task diversity has long been valued in static datasets (e.g., the ALE benchmark with 55 different games). Generative evaluation frameworks maintain this breadth: for instance, MCU spans 11 major categories and 41 subcategories (e.g., Combat, Farming) , UniCode organizes tasks by 15 algorithmic tags (e.g., Dynamic Programming) , and KUMO generates scenarios across 100 distinct domains . This prevents models from becoming narrow specialists.

Figure 5. The MCU task set is sourced from the Minecraft wiki, in-game data, existing benchmarks, and brainstorming sessions. It spans 11 major categories and 41 subcategories, ensuring high inter-task diversity. .

3.2.2 Intra-task Diversity: The Depth of Variation

This often-overlooked dimension refers to generating variations within a single task type—tasks that share a goal but differ in their initial states or parameters. Using ALE as an example: a game level’s layout is fixed, allowing an agent to memorize a specific trajectory. However, generative evaluation enables state space explosion. Consider this comparison: adding 100 different game levels merely requires the model to memorize 100 separate solutions. In contrast, by introducing intra-task diversity, e.g., identifying 5 control variables for a game level (monster count, enemy health, inventory tools, etc.), each with 10 possible values, the state space grows to $10^{5}$ distinct configurations. This dramatically raises the difficulty of rote memorization and encourages generalized problem-solving.

Figure 6. The Procgen benchmark expands intra-task diversity, increasing the state space to massive magnitudes (x-axis). As observed, only when the state space exceeds a certain threshold can we truly measure generalization performance (where training and testing curves converge) .

3.3 Discovering Novel Reasoning Patterns

However, not all task variables are effective. A common pitfall is altering superficial variables of a task without introducing novel reasoning challenges. Research from UniCode reveals that merely changing the textual description without altering the core logic does not create novel challenges. For example, LLMs perform the same on card‑game queue/stack simulation and an operating‑system scheduling scenario—different narratives but the same logic. This indicates that textual diversity alone is a solved problem for advanced LLMs and is not an “effective variable” for rigorous evaluation. Figure 7 shows that under certain variable changes, model performance can drop sharply.

Figure 7: Case study from DARG. Left: Increasing numerical complexity causes GPT-4 Turbo to make calculation errors. Right: Increasing the width of the reasoning graph causes Mistral 7B to generate an incorrect reasoning process . This highlights how controlled variable manipulation in generative evaluation can isolate specific model failures.

Therefore, the key is to identify “effective variables”—factors where a model’s generalization is prone to break down. Current approaches often use expert intuition: decompose a task into candidate variables, and adjust one at a time while keeping others fixed. If a variable causes significant performance variation, it signals incomplete reasoning and qualifies as effective. By identifying the right set of such variables, we unlock an infinite array of unique test cases, each embodying a novel reasoning pattern. As shown in Figure 8, DARG introduces three effective complexity variables: numerical complexity, depth of the reasoning graph, and width of the reasoning graph. It compares the robustness of state-of-the-art models across these three dimensions when solving mathematical problems.

Figure 8. DARG visualizes the original accuracy of LLMs against their robustness across three complexity dimensions on GSM8K. 'N', 'D', and 'W' denote the CIARR for numerical complexity, depth, and width of the reasoning graph, respectively. .

3.4 Ensuring Reliability in the Generative Pipeline

The biggest risk in generative evaluation is producing “garbage”—unsolvable problems or incorrect metrics. Since we cannot rely on human annotators for infinite tasks, we must automate the verification process.

3.4.1 Ensuring Solvability

We must guarantee that the generated preconditions allow for a solution. Domain-specific tools are often used for verification. Here are two examples:

Symbolic Guarantees: KUMO employs a SAT Solver (Boolean Satisfiability) during the generation phase. This mathematically enforces that every generated game board has a valid logical path to the truth, preventing impossible scenarios.
Simulator Verification: MCU utilizes the MineStudio simulator, a popular test bed for the Minecraft platform, as a ground-truth verifier. The LLM-generated initialization commands are executed in the game engine; if the engine throws an error (e.g., Spawning a mob type that doesn’t exist.), the system detects it and triggers a self-reflection loop to correct the initial configuration.

Figure 9. MineStudio acts as a natural verification environment, returning error codes to help correct mistakes in generative tasks .

3.4.2 Ensuring Label Correctness

In the absence of human-provided labels, the scoring of model outputs must also be automated. The method depends on the nature of the task:

Programmatic Signals: For tasks on platforms with clear objectives (e.g., “mine a diamond” in Minecraft), the environment itself provides inherent success or failure signals.
Model-as-Judge: For open-ended, creative tasks (e.g., “build a scary-looking house”), advanced LLMs or Vision-Language Models (VLMs) are employed as judges . For instance, MCU uses GPT-4V, providing it with specific, generated evaluation criteria (e.g., “Does the structure have a roof?”), achieving 91.5% alignment with human raters .
Algorithmic Oracles: For tasks grounded in formal logic or mathematics, deterministic algorithms serve as the ground truth. KUMO computes an optimal search policy as its oracle , while Unicode uses brute-force computation to verify solutions .

The reliability of both the solvability check and the labeling process can be further validated by periodically sampling generated tasks for human review.

3.5 Generative Evaluation as a Self-Improvement Engine

Generative evaluation need not be only a measurement mechanism — it can also provide a scalable training signal that enables models to improve continuously. A striking recent example is DeepSeek’s release of DeepSeekMath-V2 , a self-verifiable mathematical reasoning model that the authors report achieves gold-level performance on IMO 2025 problems. DeepSeekMath-V2 showcases a self-verifiable loop for mathematical reasoning: a generator proposes candidate proofs, a learned verifier scores and critiques them, and the generator is optimized using the verifier as a reward, while the verifier itself is strengthened by labeling harder examples produced in later rounds. A different line of work rStar-Coder illustrates how a large, self-verified dataset for code reasoning can scale model competence. Combining these ideas with a generative evaluation framework thus creates a virtuous cycle: the evaluation engine uncovers challenging and novel cases, including rare corner cases; the model attempts to solve and self-check them; and the verified outcomes are fed back as training signals to strengthen both the generator and the verifier.

4. Discussion

4.1 Managing Errors in Generative Frameworks

One might worry: “Is an automated evaluation pipeline as accurate as human evaluation?” In practice, as data scales up, 100% accuracy becomes an impractical goal. When the test set is uncontaminated, the total error primarily comes from two sources:

Sampling error, influenced by the number of tasks;
System error, introduced by the generative evaluation process.

Human-curated evaluation carries zero system error, but due to the limited number of tasks, sampling error can be high. For example, if Model A and Model B perform equally well overall but excel in different areas, a small task set biased toward Model A’s strengths may misleadingly show it as superior.

In contrast, a generative evaluation system, while having some inherent system error, allows that error to be estimated and corrected. For instance, by testing the model on a small set of known wrong examples, we can measure its false pass rate $q_e$. Then, using the formula:

$$ p = \frac{p_{\text{obs}} - \varepsilon \cdot q_e}{1 - \varepsilon} $$

we can recover a calibrated estimate $p$ of the model’s true performance. Here, $p_{\text{obs}}$ is the observed pass rate, and $\varepsilon$ is the error rate of the generative process.

Moreover, with a sufficiently large and diverse set of tasks, the sampling error of the generative system becomes negligible. Therefore, by combining scalable task generation with systematic error correction, we can achieve a more reliable evaluation framework, even if it requires embracing a small amount of controlled noise.

4.2 Potential Influence on Society

Static datasets inevitably suffer from inherent human bias, conflicts of interest, and financial incentives . For instance, when an evaluation firm also provides training data, it faces an ethical conflict, incentivized to design benchmarks that favor its clients’ models. Furthermore, expert annotators introduce subjective preference bias; if they previously contributed to a model’s training data, their unconscious criteria may align with that model’s style. This systematic human bias prevents scores from reflecting real-world performance for a diverse user base.

Generative Evaluation offers a critical path to mitigate these external biases by automating and standardizing the task creation process, potentially utilizing multiple LLM generators to further diversify and neutralize output biases.

4.3 Limitations & Future Work

Generative evaluation still heavily rely on human priors to pick variables. Previously, datasets like Dynabench used human annotators to manually flag adversarial examples where models failed . Now, we have elevated the abstraction level from the “sample” to the “variable,” which significantly saves time and allows for automated generation. However, the selection of these variable factors still relies strongly on expert knowledge. Future work may explore adaptive generation systems that can dynamically decompose these variables and adjust difficulty based on model behavior.