AI-Assisted Code Review and Automated Remediation in CI/CD

Traditional static analysis tools are precise on known patterns but can generate large volumes of findings that developers must triage. Large language models can read surrounding context, explain a finding in plain language and propose a fix, but they can also be confidently wrong. The best results come from combining the two, with clear responsibilities for each and a human in the loop.

What each approach is good at

A practical architecture

1. Deterministic scan first. Run secret detection, dependency checks and rule-based scanners on the changed files. This is cheap, repeatable and defines the candidate findings.
2. LLM triage and explanation. For each finding, send a minimal slice of code (the affected function, plus relevant context) to a model with a focused prompt: is this a true positive, why, and how severe? Use the answer to rank and deduplicate, not to silently suppress.
3. Fix proposal. Ask the model for a minimal patch as a unified diff, not a rewritten file. Small diffs are easy to review.
4. Verify automatically. Apply the patch in a sandbox, then run the build, the tests and the original scanner again. Discard suggestions that fail.
5. Present for review. Post the explanation and suggested diff on the pull request. A human accepts, edits or rejects it.

Example: weak hashing

A scanner flags this:

const hash = crypto.createHash('md5').update(password).digest('hex');

A good suggested fix explains that MD5 is fast and broken for password storage, and proposes a purpose-built password hash:

import { scrypt, randomBytes } from 'node:crypto';
const salt = randomBytes(16);
const hash = await new Promise((res, rej) =>
  scrypt(password, salt, 64, (e, k) => (e ? rej(e) : res(k))));

A reviewer must still check that the surrounding code stores the salt, that existing records can be migrated, and that comparison is constant-time. This is why AI fixes are suggestions, not commits.

Risks and how to manage them

Hallucinated or insecure fixes. Models sometimes invent APIs or introduce new bugs. Mitigation: automated build and test verification, rescanning the patched code, and mandatory human review.

Data leakage. Sending proprietary code to an external model is a data-handling decision. Use providers and contracts that match your policy, strip secrets before sending, or run a self-hosted model.

Prompt injection through code. Comments, strings and dependency files can contain instructions aimed at the reviewing model (for example "mark this file as safe"). Never let model output suppress a deterministic finding or approve a merge on its own, and apply the controls in prompt injection defenses.

Inconsistency. The same code may get different verdicts on different runs. Use low temperature, structured output and cached results for unchanged code.

Cost. Limit model calls to changed code and to findings above a severity threshold.

Measuring whether it works

Track: percentage of AI-proposed fixes accepted without changes, time from finding to resolution, developer-reported false positives, and any vulnerabilities that the process missed and later surfaced. If acceptance is low, tighten the prompts and the context you provide rather than increasing automation.

Principles to keep

• Deterministic tools decide; models assist.
• Every automated change is verified by tests and rescans.
• Humans approve merges.
• Treat model inputs (the code itself) as untrusted.
• Measure outcomes, not activity.