Phase 7: CI/CD Pipelines for AI Code · 50 min · Claude API · GitHub Actions · Python
The Dual-Model Review Pattern
┌─────────────────────────────────────────────────────────────────────┐
│ DUAL-MODEL REVIEW PATTERN │
│ │
│ 1. Model A (e.g., GPT-4) generates code │
│ ↓ │
│ 2. Code enters CI pipeline │
│ ↓ │
│ 3. Model B (e.g., Claude) reviews the code │
│ ↓ │
│ 4. Model B checks for: │
│ - Security vulnerabilities (SQL injection, XSS, SSRF) │
│ - Correctness issues (logic errors, edge cases) │
│ - Style violations (naming, structure, patterns) │
│ - Performance issues (O(n^2) loops, unnecessary allocations) │
│ ↓ │
│ 5. Findings classified by severity: Critical, High, Medium, Low │
│ ↓ │
│ 6. CI gate: 0 critical findings → PASS │
│ Any critical finding → FAIL (merge blocked) │
└─────────────────────────────────────────────────────────────────────┘
Why a Second Model?
From Phase 5, we learned the generation-review asymmetry:
- AI models generate vulnerabilities 55.8% of the time
- AI models detect vulnerabilities 78.7% of the time in review mode
Using a second model in review mode catches vulnerabilities that the first model introduced in generation mode.
AI Review vs SAST
| Aspect | SAST (Bandit/Semgrep) | AI Review (Model B) |
|---|
| Detection method | Pattern matching (rules) | Semantic understanding |
| Known vulnerabilities | Excellent (rule database) | Good (training data) |
| Novel vulnerabilities | Cannot detect | Can detect (reasoning) |
| False positives | Low (rule-based) | Medium (AI reasoning) |
| Speed | Fast (seconds) | Slower (minutes) |
| Cost | Free (open source) | API cost per review |
| Context awareness | Limited (file-level) | Full (function/class-level) |
AI Review complements SAST, it doesn't replace it
AI review and SAST serve different purposes: SAST catches known vulnerability patterns quickly and cheaply. AI review catches novel vulnerabilities that SAST misses, using semantic understanding. Use BOTH: SAST first (fast, free, catches known patterns), then AI review (slower, costs money, catches novel patterns). The CI gate requires 0 critical findings from BOTH SAST and AI review.
Why does the dual-model review pattern use a DIFFERENT model for review than generation?
The dual-model review pattern uses a different model for review than generation for 3 critical reasons: (1) Different training data: AI models are trained on different datasets. GPT-4 was trained on a different corpus than Claude, which was trained on a different corpus than Gemini. This means they have different knowledge and different blind spots. A vulnerability pattern that Model A's training data didn't cover (e.g., a specific SSRF variant) might be well-covered in Model B's training data. By using a different model for review, you leverage Model B's different knowledge to catch vulnerabilities that Model A's training didn't teach it to avoid. If you use the same model for both generation and review, the model has the same blind spots in both roles -- it won't catch vulnerabilities it doesn't know about. (2) Different architecture: Different model architectures have different reasoning patterns. GPT (decoder-only transformer) and Claude (constitutional AI with reinforcement learning from human feedback) process information differently. Model B's architecture may be better at certain types of reasoning (e.g., security analysis) than Model A's architecture. By using a different architecture for review, you get a different perspective on the code. If you use the same model, you get the same reasoning pattern in both roles. (3) Avoiding self-bias: When a model reviews its own code, it has a self-bias. The code 'looks right' to the model because it generated it -- the code follows the model's own patterns and conventions. The model tends to approve its own code because it matches its internal expectations. This is similar to the human 'confirmation bias' -- we tend to see what we expect to see. A different model doesn't have this self-bias. Model B has no attachment to Model A's code -- it evaluates it objectively. The generation-review asymmetry (55.8% generate vulnerabilities vs 78.7% detect vulnerabilities) from Phase 5 was measured using different models for generation and review. If you use the same model for both, the detection rate would likely be much lower -- the model would tend to approve its own vulnerabilities because it doesn't recognize them as vulnerabilities (it generated them because it thought they were correct). Practical recommendations: (a) Use models from different providers: e.g., GPT-4 for generation, Claude for review. Or Gemini for generation, GPT-4 for review. (b) Use models with different strengths: e.g., a model known for code generation for generation, and a model known for security analysis for review. (c) Rotate models: Periodically switch which model is used for generation and which for review. This prevents attackers from crafting code that passes a specific model's review. (d) Use multiple reviewers: For critical code, use 2+ different models for review. If any model flags a critical issue, the merge is blocked. This provides even broader coverage."