Zovda
Ask a team how they built their coding agent and they describe the model. Ask what it learned from and they point at a folder of commits. A commit is the answer to the task, not the path to it.
The difference matters more than most teams expect. An agent that has only ever seen clean final patches has never watched a wrong turn being corrected, and correcting wrong turns is most of the job.
A diff is the last frame of a movie
A coding agent works in a loop: read something, decide, act, look at the result, decide again. The training signal lives in that loop. If the corpus only keeps the last state, the model learns what a finished change looks like and nothing about how to get there.
Trajectories are also where the failure modes are recorded — the tool call with the wrong argument, the file that did not exist, the loop that repeated three times before someone gave up.
What a usable trajectory record holds
- The task as the user actually phrased it, not a cleaned-up version
- A snapshot of the starting state: revision plus any uncommitted changes
- One row per step: what was observed, which tool was called, with what arguments, what came back, and whether it succeeded
- The terminal outcome: tests passed, tests failed, abandoned, or timed out
- A short failure label where the run went wrong: wrong tool, wrong path, loop, gave up
Without the per-step rows, the record is an anecdote. With them, it is filterable — you can build a subset of runs that recovered from a failed command, or runs that never touched a test file.
Keep the failed branches
The instinct is to ship only successful runs. It is the wrong instinct. Recovery behavior is learned from failures that were then fixed, and those runs are the rarest thing in any agent corpus.
Failures are also the cheapest way to teach the model when to stop. An agent that never saw a dead end has no calibrated sense of one.
Split by repository and by time
Random row splits leak. The same helper function appears in training and in the held-out set, and the score goes up for reasons that will not survive contact with a new codebase.
Split by repository first. Where a repository must appear in both sides, split by date so the held-out tasks come from work the model could not have seen. Then check the two sides for near-duplicate files before training, not after.
The checklist we run
- Does every step have an observation, an action, and a result?
- Can you tell a recovered failure from a clean success without reading the diff?
- Is the starting state recorded, so a run can be replayed?
- Are held-out tasks separated by repository or by time?
- Does the manifest say which languages and which kinds of tasks each collection covers?
If a corpus cannot answer these five, the model will still train. It will just learn to look confident, which is the expensive failure.
Where to start
If you are training an agent rather than a code completer, start from the collection that matches the loop you want it to run. The code and agent trajectory collection describes what each family contains, and the corpus catalogue shows how the same material maps to training stages.
Zovda produces these trajectory collections through Datuva, where each step, tool call, and patch is versioned together, so a reward signal can be traced to one specific run.
Tell us the loop you are training and the volume you need. We reply within one business day, and the field documentation is shared once the scope is confirmed.