The DevSecOps Review Prescription Guide: How to Review Thousands of Merge Requests a Month

How do you review thousands of merge requests a month? Most teams answer with a queue: developers push, a senior engineer reviews when they can, CI runs linters, and a security scan fires after merge. The pipeline is automated. The review is not.

This prescription guide describes a reference architecture for automated code and security review with production context. It follows the format of an AWS solution guide: the problem, the architecture, the components, what it costs, and reference deployments running today. You can read it in full below, or download the PDF to circulate with your team.

Overview

This guidance is for engineering and platform teams that ship through GitHub or GitLab and can no longer review every merge request by hand. It deploys two AI reviewers on one agent runtime:

• Code Review catches logic bugs, always-true conditions, unsafe defaults, and convention violations. It traces the full backend logic, not only the changed diff.
• Security Review finds injection, authorization gaps, cross-tenant access, leaked secrets, dependency issues, and IaC drift. Every finding ships with an attack path and a safe proof on staging.

Both reviewers read the same production context on every review: runtime signals, cloud and Kubernetes state, incident history, business logic from Jira, and your repo conventions declared as Skills. Findings arrive as merge request comments with severity and proof, a fix PR that gets re-reviewed automatically, and a release gate that passes or blocks in CI.

The problem this guidance addresses

In a traditional pipeline, review breaks down at five points:

The cost shows up in four places: days in the review queue, senior hours spent rubber-stamping, weeks before a leak is noticed, and manual evidence rebuilt for every audit.

Architecture

Where review triggers

Review runs at four points in the release pipeline, so nothing depends on a human remembering to ask:

1. MR opened or updated. A GitHub or GitLab webhook starts a review on every merge request.
2. CLI review. Developers run a review in the terminal before the MR even exists.
3. CI build and deploy. The IaC plan, the image, and the staging environment are reviewed as part of the pipeline.
4. Release tag. A final gate runs before anything reaches production.

How the runtime handles an event

The agent runtime processes every trigger the same way:

1. Receive the event.
2. Load Skills and Memory: your conventions, standards, and past findings.
3. Run both reviewers. Code Review and Security Review cross-reference their findings.
4. Apply policy: what may auto-fix, what needs approval, what blocks.
5. Post, record, and gate.

Where results land

• MR review comment with severity, attack path, and proof.
• Fix PR opened, then re-reviewed automatically when it updates the MR.
• Release gate that passes or blocks as a CI status.
• Slack, Jira, and an audit trail with evidence ready for compliance.

Solution components

Code Review agent

Runs on every merge request at 97% precision and $0.12 per MR. It looks for logic bugs, always-true conditions, and unsafe defaults, traces the full backend logic instead of the diff alone, and enforces your conventions declared as Skills. When it finds something, it opens a fix PR and re-reviews it.

Security Review agent

Runs on every release, pre-production. It covers injection, authorization gaps, cross-tenant access, secrets, dependencies, and IaC drift. Each finding comes with an attack path and a safe proof on staging. It opens a remediation PR and blocks the release if the finding stays unfixed.

Shared runtime

• Skills Framework: your rules and standards, declared once and applied on every review.
• Memory: incidents and past findings, so the reviewer learns your system over time.
• Policy and approvals: explicit control over what may auto-fix.
• Frontier models: routed per task.

Production context

Both reviewers read the running system on every review: runtime signals, cloud and Kubernetes state, incident history from Resolve, business logic from Jira, and the code and repos themselves. That context is what separates a finding with an attack path from a linter warning.

Cost

Code Review is priced per merge request: $0.12 per MR. There is no per-seat fee for the reviewer, so cost scales with how much you ship, not how many people can see the results. Compare that with the current spend: senior engineering hours in the review queue, and incident cost when an approved MR reaches a customer.

Reference deployments

Both reviewers run today on production workloads, on the same stack: one agent runtime, two reviewers, one production context.

FPT Cloud, Code Review. AI code review on production merge requests at cloud-provider scale. Roughly 97% review precision held at scale, 68.6% of verified defects caught before QC, full backend logic coverage, and cross-tenant security issues caught before human review.

Diaflow, Security Review. SOC 2, HIPAA, and GDPR compliance automated across three regions. Four weeks to continuous, auditable evidence, and 80% less ops load at 99.9% uptime. Findings are remediated in the pipeline instead of a dashboard, and audits read from the running system instead of a spreadsheet.

More published results live at cloudthinker.io/case-studies.

Deploy this guidance

1. Connect a repo. Install the GitHub or GitLab integration and open a merge request. The first review lands as an MR comment.
2. Declare your conventions as Skills. Feed the reviewer your standards and requirement sources, so findings match how your team actually works.
3. Turn on the Security Review gate. Start in report-only mode, then let it block releases once you trust the signal.
4. Set policy for auto-fix. Decide which findings the agent may fix on its own and which need an approval.

Resources

• Download the PDF guide to share internally.
• Read the full FPT Cloud evaluation and the Diaflow compliance sprint.
• Talk to us about running a pilot on your own merge requests.