AI code review.
On your terms.
Your GitLab. Your model. Your rules.
Evaluation setup · Contact us for a package
payments/query.py
39def get_payment(cursor, user_input):40 sql = "SELECT * FROM payments WHERE id = "4142− cursor.execute(sql + user_input)43+ cursor.execute(sql + "%s", [user_input])4445 return cursor.fetchone()SQL injection risk
Keep SQL and user input separate.
Pass values as parameters.
New SHA → Re-review → CI + team decision
Choose how you start.
A review you can reason about.
More than a list of comments. Context, evidence and a clear next step.
The context that matters
Selected diff, task, criteria and rules. Inspect the data before a model call.
A finding with evidence
What could break, where the risk is and which fix to consider.
New version, fresh review
Recheck the new SHA. Keep AI findings, CI and task acceptance separate.
Your rules and feedback
Choose language and style. GitLab reactions and replies help refine team rules.
One real MR.
The whole decision trail.
In recorded MR3, the model found a SQL risk. The fix received a separate review and CI with operator involvement. Some acceptance criteria remained open.
Inspect the outcome and its limits- Before the fix
- One SQL risk
- New version
- Zero AI findings
- CI
- Passed with operator involvement
- Overall task decision
- Needs remaining checks
Choose the model.
Keep the control.
Connect API or official CLI separately from the review engine. Agree on source-code handling before starting.
Model compatibility and quality are verified in your deployment. An external model remains an external recipient of data.
Connections and the data routeStart with your workflow.
One repository. An accountable lead. Measurable pilot criteria.
The current package is for technical evaluation. Full pilot acceptance remains open.