Zovda
A code review contains something most datasets pay for: a human describing what is wrong with a piece of code, in the language the team actually uses.
It is usually discarded, because it lives in a system nobody thinks of as training data.
A comment is a label with a reason
"Use the helper here" is a decision plus a rule. "This will break on empty input" is a defect plus a condition. Both are more informative than a pass or fail.
To use them, keep the diff, the comment, and the resolution: whether the author changed the code, argued, or ignored it.
Resolution is what makes it trustworthy
A comment that was never acted on might be wrong, stale, or a matter of taste. A comment that changed the code has evidence behind it.
Filtering on resolution gives you a high-precision set without a single annotation hour.
What a review record holds
- The diff under discussion
- The comment, verbatim, with its position
- The author's reply, if any
- Whether the code changed, and how
- The reviewer's role, coarsely: peer, senior, maintainer
The last field lets a buyer weigh opinions differently, or at least know whose taste they are learning.
Style and correctness are different targets
Most comments are style. That is fine and it is not what a model learning to patch needs. Tag the comment type so the two can be separated at training time.
Zovda builds these collections through Datuva, where the diff, the comment and its resolution stay in one row. The code and agent collection shows the structure.
Tell us what your reviewers keep repeating. We reply within one business day.