Our reviews are often just "LGTM". Is there anything useful?

Light reviews add less, but most teams have a share of substantive threads, especially on larger changes. The assessment estimates how much of your review history carries real discussion.

Do we need to include the code as well as the comments?

Review comments are much more useful with the code they refer to. Both are usually scoped together, but you decide what is included.

Can reviewers be identified from writing style?

Names, handles and emails are removed or replaced. Specific protections are set in the agreement, and you can exclude threads you consider sensitive.

Which platforms can review data come from?

GitHub, GitLab, Bitbucket, Gerrit, Azure DevOps and similar tools all store review history. Each has its own export route, which is planned after the NDA.

← All data sources

Code & Engineering · AI training data

Code Reviews & Pull Requests as AI training data

Code review is where engineering judgment is written down. A reviewer flags a race condition, asks for a test, suggests a simpler approach, and the author pushes a follow-up commit. Those exchanges, tied to exact lines of code and an eventual approve or reject decision, are close to what AI developers need to teach models to review and revise code.

Can Code Reviews & Pull Requests be used as AI training data?

Code reviews and pull requests can be licensed as AI training data that teaches models to review and revise code. Inline comments anchored to specific lines, suggested changes with the commits that applied them, and approve or reject outcomes carry the most value. Personal remarks about colleagues are removed, and reviews of client code may need client permission.

Become a data partner How it works

No files needed upfront. We sign an NDA before reviewing any sample.

What can be included

You choose the scope. These are the parts of Code Reviews & Pull Requests that are typically most useful.

✓Pull or merge request descriptions explaining the intent of a change
✓Inline comments anchored to specific files and line numbers
✓Suggested changes and the commits that applied or rejected them
✓Review states such as approved, changes requested and dismissed
✓Back-and-forth threads where author and reviewer reached agreement
✓Rejected or abandoned pull requests and the reason they were closed

Why AI labs value it

Critique tied to code

Each comment points to exact lines, so a model can learn which code patterns prompt which concerns. General discussions about code quality cannot provide that precision.

Revision after feedback

The diff between the first push and the approved version shows how code improved in response to review. This before-and-after pairing is useful for training models to act on feedback.

Negative examples

Closed or rejected pull requests explain why a change was not acceptable. Models benefit from seeing what should not be merged, and these examples rarely appear publicly.

Team standards made explicit

Recurring review comments reveal unwritten rules about naming, error handling and security. That tacit knowledge is a large part of what makes enterprise review data distinctive.

How it is scoped, exported and anonymized

Export threads, not just diffs

Review data lives in the hosting platform's database, not in git. It is exported through platform APIs so that comment threads, positions and review states stay linked to the right commits.

Handle tone and personal remarks

Reviews sometimes include personal comments, performance-related remarks or names of colleagues. These are reviewed and removed or replaced, along with mentions and emails.

Mind client and partner repos

Reviews on code built for clients may describe their systems in detail. That material may need client permission or must be excluded from scope.

How a partnership begins

01 / CONTACT

Share Basic Information

Share only your contact, company, industry, and partnership interests—no raw data required.

02 / DISCOVER

Initial Value Assessment

We discuss the data type, completeness, scarcity, and the tasks it could support.

03 / PROTECT

Define the NDA and Boundaries

Before reviewing any sample, we define confidentiality, permitted use, retention, and security requirements.

04 / PARTNER

Receive an Offer and Begin the Partnership

We provide a purchase proposal and contract, then support de-identification and secure data transfer.

Frequently asked questions

Our reviews are often just "LGTM". Is there anything useful?: Light reviews add less, but most teams have a share of substantive threads, especially on larger changes. The assessment estimates how much of your review history carries real discussion.
Do we need to include the code as well as the comments?: Review comments are much more useful with the code they refer to. Both are usually scoped together, but you decide what is included.
Can reviewers be identified from writing style?: Names, handles and emails are removed or replaced. Specific protections are set in the agreement, and you can exclude threads you consider sensitive.
Which platforms can review data come from?: GitHub, GitLab, Bitbucket, Gerrit, Azure DevOps and similar tools all store review history. Each has its own export route, which is planned after the NDA.

Data sourceGitHub Repositories →Data sourceGitLab Repositories →Data sourceCommit & Version History →GuideWhat Makes Data Valuable for AI Training? →

Let's talk about your Code Reviews & Pull Requests.

Share only the essential details. No files are required at this stage.

Contact the Momentra team