APPLIED AI / SECURE DEVELOPMENTCASE STUDY / 4 minute read

CodeGuard

REVIEW THE DIFF.QUESTIONTHE ANSWER.

An AI-assisted review tool that narrows attention to changed code and translates model responses into structured findings a developer can inspect.

Independent project · Recorded offline provider fixturesThe 60-second overview

Checked against GitHub

Last successful check · 2026-09-05 22:54 UTC399a13aRefresh Career Atlas after public repository changes

★ 1 stars 0 forks ↗Commit · 2026-09-05No published releaseLatest default-branch run · success · 2026-09-05 · 399a13a ↗

THE SHORT VERSION

WHAT THIS
DEMONSTRATES.

01
A unified-diff parser identifies changed files and hunks before review.
02
The reviewer assembles prompts, calls a selectable provider, and validates returned findings.
03
A local review passed 181 tests. The demonstration uses fixed public response fixtures, with no model or paid service called.

01 / CONTEXT

THE PROBLEM.

Model feedback becomes difficult to use when it is detached from a file, severity, or proposed correction. The tool creates a narrow interface between a code change, a provider response, and the review workflow.

Constraints that shaped the work

Support OpenAI, Anthropic, and local Ollama provider interfaces.
Skip deleted files and unsupported or binary content.
Keep CWE and OWASP references with findings.
Make provider limitations visible to the human reviewer.

02 / FOLLOW THE SYSTEM

ARCHITECTURE.

Choose a stage to explore its purpose and supporting source.

ARCHITECTURE WALKTHROUGH01 / 04

Identify the change

The parser extracts files, language, line ranges, and hunks. The reviewer skips deleted files and binary or unknown languages.

WHAT TO INSPECT

Parser tests include multiple files, deleted files, binary content, and an empty diff.

Read the implementation

RECORDED FROM PUBLIC SOURCE

CHANGE THE SCENARIO.

5 SEP 2026
OFFLINE RECORDING

Inspect inputs and outputs captured from the repository. Switching scenarios replays saved results; it does not run cloud services or a model.

INPUT / SCENARIO

{
  "diff": "tests/fixtures/diffs/sql_injection.diff",
  "provider": "fixed response; no model called",
  "simulateFailure": false,
  "response": "{\n  \"findings\": [\n    {\n      \"title\": \"SQL Injection Vulnerability\",\n      \"severity\": \"CRITICAL\",\n      \"category\": \"security\",\n      \"description\": \"User input is concatenated directly into SQL query string without sanitization.\",\n      \"suggestion\": \"Use parameterized queries with placeholders instead of string concatenation.\",\n      \"line_number\": 13,\n      \"cwe_id\": \"CWE-89\",\n      \"owasp_ref\": \"A03:2021\"\n    },\n    {\n      \"title\": \"Hardcoded Database Path\",\n      \"severity\": \"LOW\",\n      \"category\": \"style\",\n      \"description\": \"Database path is hardcoded. Consider using configuration.\",\n      \"suggestion\": \"Move database path to environment variable or config file.\",\n      \"line_number\": 12,\n      \"cwe_id\": null,\n      \"owasp_ref\": null\n    }\n  ]\n}\n"
}

RECORDED OUTPUT

[
  {
    "title": "SQL Injection Vulnerability",
    "severity": "CRITICAL",
    "category": "security",
    "description": "User input is concatenated directly into SQL query string without sanitization.",
    "suggestion": "Use parameterized queries with placeholders instead of string concatenation.",
    "file_path": "app/db.py",
    "line_number": 13,
    "cwe_id": "CWE-89",
    "owasp_ref": "A03:2021",
    "code_snippet": null
  },
  {
    "title": "Hardcoded Database Path",
    "severity": "LOW",
    "category": "style",
    "description": "Database path is hardcoded. Consider using configuration.",
    "suggestion": "Move database path to environment variable or config file.",
    "file_path": "app/db.py",
    "line_number": 12,
    "cwe_id": null,
    "owasp_ref": null,
    "code_snippet": null
  }
]

A fixed public fixture returned two findings, which the actual reviewer associated with app/db.py. This verifies data handling, not the quality of an AI model.

Inspect the complete recording

03 / ENGINEERING JUDGMENT

THE TRADEOFFS.

Review changed code

Send per-file diff hunks instead of an entire repository.

The tradeoffRequests are focused, but surrounding application context may be missing and unsupported files are skipped.

Inspect the decision

Normalize provider output

Translate model text into a shared finding model.

The tradeoffA well-formed finding can still be wrong. Invalid output may be dropped, so validation does not equal detection accuracy.

Inspect the decision

Continue after provider errors

Warn and continue when a file review raises an exception.

The tradeoffPartial work remains available, but zero findings can hide incomplete coverage. A future improvement is an explicit incomplete-review state.

Inspect the decision

04 / WHAT THE WORK SHOWS

OUTCOMES & LIMITS.

181 tests passed in the recorded review

Parser, provider adapters, prompts, response handling, orchestration, and report tests passed locally on 5 September 2026.

Supporting source

Failure behavior is demonstrated

The offline replay records two findings from a valid fixture, zero from malformed content, and zero plus a warning from a failed provider. These are integration results, not model accuracy measurements.

Supporting source

THE LESSON

The most important AI engineering boundary is between “the model returned nothing” and “the work was checked.” The project makes that boundary available for inspection and points to a concrete reliability improvement.

Where the evidence ends

All displayed model responses are fixed test fixtures, not a live AI review.
No vulnerability-detection rate, false-positive rate, or benchmark accuracy is established.
The reviewed metadata counts parsed files as files_reviewed, including files that can be skipped or fail. It should not be used as a completed-coverage metric.

05 / CHECK THE WORK