KodCode: A Diverse, Challenging, and Verifiable Synthetic Dataset for Coding
Abstract
We introduce KodCode, a synthetic dataset that addresses the persistent challenge of acquiring high-quality, verifiable training data across diverse difficulties and domains for training Large Language Models for coding. Existing code-focused resources typically fail to ensure either the breadth of coverage (e.g., spanning simple coding tasks to advanced algorithmic problems) or verifiable correctness (e.g., unit tests). In contrast, KodCode comprises question-solution-test triplets that are systematically validated via a self-verification procedure. Our pipeline begins by synthesizing a broad range of coding questions, then generates solutions and test cases with additional attempts allocated to challenging problems. Finally, post-training data synthesis is done by rewriting questions into diverse formats and generating responses under a test-based reject sampling procedure from a reasoning model (DeepSeek R1). This pipeline yields a large-scale, robust and diverse coding dataset. KodCode is suitable for supervised fine-tuning and the paired unit tests also provide great potential for RL tuning. Fine-tuning experiments on coding benchmarks (HumanEval(+), MBPP(+), BigCodeBench, and LiveCodeBench) demonstrate that KodCode-tuned models achieve state-of-the-art performance, surpassing models like Qwen2.5-Coder-32B-Instruct and DeepSeek-R1-Distill-Llama-70B.
Community
KodCode is the largest fully-synthetic open-source dataset providing verifiable solutions and tests for coding tasks. It contains 12 distinct subsets spanning various domains (from algorithmic to package-specific knowledge) and difficulty levels (from basic coding exercises to interview and competitive programming challenges). KodCode is designed for both supervised fine-tuning (SFT) and RL tuning.
- 🕸️ Project Website
- đź“„ Technical Report - Discover the methodology and technical details behind KodCode
- đź’ľ Github Repo - Access the complete pipeline used to produce KodCode V1
- 🤗 HF Datasets: KodCode-V1 (For RL); KodCode-V1-SFT-R1 (for SFT)
This is an automated message from the Librarian Bot. I found the following papers similar to this paper.
The following papers were recommended by the Semantic Scholar API
- Learning to Solve and Verify: A Self-Play Framework for Code and Test Generation (2025)
- ACECODER: Acing Coder RL via Automated Test-Case Synthesis (2025)
- IterPref: Focal Preference Learning for Code Generation via Iterative Debugging (2025)
- RefineCoder: Iterative Improving of Large Language Models via Adaptive Critique Refinement for Code Generation (2025)
- Building A Proof-Oriented Programmer That Is 64% Better Than GPT-4o Under Data Scarsity (2025)
- Robust Learning of Diverse Code Edits (2025)
- Scoring Verifiers: Evaluating Synthetic Verification in Code and Reasoning (2025)
Please give a thumbs up to this comment if you found it helpful!
If you want recommendations for any Paper on Hugging Face checkout this Space
You can directly ask Librarian Bot for paper recommendations by tagging it in a comment:
@librarian-bot
recommend
Any clue as to why it does so poorly on the “hard” LiveCodeBench benchmark? Your models were almost dead last on that specific benchmark and the score you all received on the “medium” one represented a huge fall off from the “easy” questions where you all received SOA scores among all open source models.
Not suggesting anything here by pointing that out, just genuinely curious to see if you all have a hypothesis that would explain your model’s notably poor performance on that one specific benchmark (relative to the other models whose scores you provided, namely Qwen & DeepSeek variations).
I have a hypothesis, though I'm not entirely certain if this is the root cause. When examining LiveCodeBench's questions, I noticed many utilize Online Judge style inputs and outputs (receiving data through stdin and producing results via stdout). In contrast, we developed KodCode using pytest as our testing framework, which evaluates functions through direct return values and assertions. This might explain the performance degragation.
(If that is the case, I will probably create a new oj style subset)
Models citing this paper 0
No model linking this paper
Datasets citing this paper 2
Spaces citing this paper 0
No Space linking this paper