Fluent generation, unstable bugfix
Completion looks fine; locating the defect and shipping a compile-ready patch does not. You need samples with position and type — not another public-repo dump.
Training data for Code LLMs
Code-repair and large-model training datasets
Pretrain and fine-tune on data you can score: bug location and type, before/after pairs, multilingual code pairs, and comment/doc labels — so the model finds the fault, changes the right lines, and writes notes that match the code.
What you may be hitting
The model can complete code — it still patches wrong and explains poorly
Fix one place, break another
Without before/after pairs, the model never learns the smallest change that works. Same problem, two snapshots, and why the change is valid.
Quality drops when the language changes
Python holds; Java, C++, Go, or frontend stacks fall off. You need same-task pairs across languages, not a single-language crawl.
Code runs; docs do not match
Stale comments, slogan-like function notes. Align code ↔ comments/docs if you want explanation and doc generation that is usable.
What we produce
Four data types Code LLMs usually lack
Bug labels
Locate bugs in authorized repos: file, line span, trigger. Classify (NPE, bounds, concurrency, leaks, error handling, injection) and add a short repro. The model learns “where it is wrong” before “how to change it.”
Repair pairs
Before / after for the same issue: smallest change that compiles or runs. Intent note (why, which constraint, tests). Avoid rewrite-the-file noise so fine-tune learns reusable patches.
Multilingual pairs
Same task in Python, Java, C/C++, Go, JavaScript/TypeScript — same algorithm, or the same defect repaired in each language. Language, version, and deps in the fields. No non-runnable fragments as positives.
Comments and docs
Function, module, and API notes that match the code: params, returns, exceptions. “Missing docs → should-write” or “stale comment → corrected” pairs — not empty README slogans.
Why work with us
Engineering-grade data — not another public scrape
Lock the spec, then scale
Defect types, languages, runnable or not, tests or not — frozen in the pilot. Then batch. Avoid a pile of labels that never train.
People who can read the code own the guide
Classification and repair pairs need context. Label and spot-check are separate. “It compiles” is not the only bar.
Spot-check and a written ship note
Language mix, defect mix, whether repair pairs run — in the delivery note. Under the bar, it does not ship. Same QA gates as video data: quality.
License and desensitization
Customer-authorized code, our own exercises, or contract-allowed OSS. Repo names, accounts, and internal hosts can be stripped. Encrypted handoff.
How we work
From brief to handoff
Use (complete / repair / docs), languages, defect types, scale (rows or repos).
A small gold set: how to mark a bug, what counts as a valid pair.
Four data types on the frozen guide. Auto rules catch empty labels and bad language fields.
Spot-check runnable patches, type consistency, docs vs code.
JSONL / repo slices + field notes + coverage stats, encrypted.
Where this data is used
Typical uses
No live customer names. Details on inquiry.
Repair fine-tune
Add “defect → smallest fix” pairs to an existing Code LLM. Higher chance the patch compiles and tests pass; fewer rewrite-the-file answers.
Multilingual and docs
Same task in several languages, or internal API comments that match the code, for a private model.
What you receive
Code + labels + notes, as one pack
| Included | What it means |
|---|---|
| Source slices | Agreed languages and licenses; minimal runnable context when needed |
| Bug and repair labels | Location, type, before/after, intent; tests when required |
| Language / doc pairs | Language fields, aligned task IDs, comment and doc text |
| Project notes | Counts by type, language mix, spot-check result |
| Handoff | Encrypted transfer to storage you name |
Field case
Code-repair dataset — React double-render conflict
A sealed sample: the brief, the red-screen error, the root cause, the build-layer fix, and before/after slices. Download the JSON for eval or fine-tune on “how to fix a messy environment.”
Resolved
React + Vite
Build conflict
CODEREPAIR
The job
Add multi-model image pick under the brief on a self-hosted studio page, plus delete-one and clear-all on the image list.
What broke
The feature code was in. Model options showed at the bottom. The whole page was covered by a red overlay. Error: NotFoundError: Failed to execute 'removeChild' on 'Node' — the node was not owned by the React tree that tried to remove it. Dual instances, not a bad picker.
What we did
Traced the build. The entry and the studio page each loaded a copy of React. In vite.config.ts we set resolve.dedupe so there is one React, plus optimizeDeps to prebundle it — the DOM ownership clash stops at the root.
Outcome
Red screen gone. Model pick, generate, delete-one, and clear all work. Brief → error → locate → fix is packed (before/after slices and the conclusion).
Why this sample matters
Code training data is not only function-level patches. Dual runtimes and build config — “the feature looks right, the page is dead” — are worth as much to a Code LLM. The model has to learn to fix the build, not only one business line.
Desensitized
Inquiry
Ask about code data
Tell us the use (repair / complete / docs), languages, and rough scale. Quote after scope — this page does not list prices.