Last month, a PR made it through two human reviewers on my team. Clean diff, green tests, clear description. It introduced a subtle SQL injection in a raw query that Entity Framework Core doesn’t parameterize automatically. Nobody caught it. Not the reviewers, not the test suite, not the linter.
An AI reviewer would have flagged it in seconds. Not because AI is smarter than your team — but because it reads every line with equal attention, every time, without getting tired at 4pm on a Friday.
Here’s how to put Claude Code in your CI/CD pipeline so it reviews every PR before a human ever sees it.
What Claude Code can do in CI/CD
Claude Code has a non-interactive mode designed exactly for automation. The -p flag (or --print) lets you pipe a prompt and get a response without any human interaction.
claude -p "Review the changed files in this PR for security issues, naming violations, and test coverage gaps."
That’s the entire interface. Claude reads the prompt, does the work, and writes the result to stdout. The exit code tells you whether it succeeded (0) or failed (non-zero), so your pipeline can gate on the result.
You can also pass the --output-format json flag if you want structured output to parse programmatically. And --max-turns limits how many tool-use rounds Claude takes, which keeps cost and duration predictable.
The key insight: Claude Code in -p mode has full access to the filesystem. It can read your .sln, check your .editorconfig, look at the diff, and understand your project structure — just like it does in your terminal.
GitHub Actions example
Here’s a complete workflow that runs Claude Code on every pull request. It checks out the code, installs Claude Code, and asks it to review the changed files.
name: Claude Code PR Review
on:
pull_request:
branches: [main]
permissions:
contents: read
pull-requests: write
jobs:
claude-review:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Get changed files
id: changed
run: |
FILES=$(git diff --name-only origin/main...HEAD -- '*.cs' '*.csproj' | head -50)
echo "files=$FILES" >> $GITHUB_OUTPUT
- name: Run Claude Code review
if: steps.changed.outputs.files != ''
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude -p "You are reviewing a pull request for a .NET project.
Changed files:
${{ steps.changed.outputs.files }}
Review these files for:
1. Security issues (SQL injection, path traversal, hardcoded secrets)
2. Naming convention violations (.NET standards)
3. Missing null checks or exception handling
4. Test coverage gaps (are new public methods tested?)
Read each changed file and provide a concise review.
If you find issues, list them with file name and line number.
If everything looks good, say so." --max-turns 10 > review.txt
- name: Post review comment
if: steps.changed.outputs.files != ''
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const review = fs.readFileSync('review.txt', 'utf8');
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: `## 🤖 Claude Code Review\n\n${review}`
});
The fetch-depth: 0 is important — Claude needs the full git history to compare against main. The head -50 on the changed files list keeps you within token limits for large PRs.
Store your ANTHROPIC_API_KEY as a repository secret. That’s the only setup you need.
Azure DevOps equivalent
If your team uses Azure DevOps, the same approach works in a pipeline YAML:
trigger: none
pr:
branches:
include:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: self
fetchDepth: 0
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '8.0.x'
- script: npm install -g @anthropic-ai/claude-code
displayName: 'Install Claude Code'
- script: |
FILES=$(git diff --name-only origin/main...HEAD -- '*.cs' '*.csproj' | head -50)
claude -p "Review these changed .NET files for security issues and standards violations: $FILES" \
--max-turns 10 > $(Build.ArtifactStagingDirectory)/review.txt
displayName: 'Run Claude Code review'
env:
ANTHROPIC_API_KEY: $(ANTHROPIC_API_KEY)
- publish: $(Build.ArtifactStagingDirectory)/review.txt
artifact: claude-review
displayName: 'Publish review'
Store ANTHROPIC_API_KEY as a secret variable in your pipeline. The review output gets published as a build artifact you can check from the pipeline summary.
What to review
Don’t ask Claude to “review everything.” You’ll get vague, generic feedback. Be specific about what you care about.
Here’s what works well for .NET projects:
Security checks. SQL injection in raw queries, path traversal in file operations, secrets hardcoded in configuration, insecure deserialization. Claude is good at pattern-matching these because they follow predictable shapes.
Naming conventions. PascalCase for public members, camelCase for private fields, I prefix on interfaces, Async suffix on async methods. Boring to check manually, trivial for an AI.
Test coverage gaps. “Are there unit tests for the new public methods in this PR?” is a concrete question Claude can answer by reading both the source files and the test project.
EF Core migration safety. If a PR includes a migration, ask Claude to check for data loss operations — column drops, type changes, table renames without a data migration. This is one of those things reviewers consistently miss because the migration file looks like generated noise.
API contract changes. If controller actions changed their return types, parameters, or routes, Claude can flag potential breaking changes for consumers.
Honest limitations
Before you roll this out for your whole team, know what you’re getting into.
Cost adds up. Each review run uses API tokens. A PR that changes 20 files in a .NET solution can cost $0.50–$2.00 per review, depending on file sizes and how many turns Claude needs. For a team with 30 PRs a day, that’s real money. Use --max-turns to cap spending and consider running reviews only on PRs that touch critical paths.
Large PRs hit token limits. If your PR changes 80 files across 15 projects, Claude can’t read them all in one pass. The head -50 filter in the workflow helps, but you might need to split the review into focused passes — security first, then naming, then tests.
It’s not deterministic. Run the same review twice and you might get slightly different feedback. This matters if you’re using Claude’s output to gate merges. Treat it as a reviewer comment, not a test result. Flag issues for humans to evaluate, don’t auto-block PRs based on AI output alone.
It doesn’t replace human review. Claude catches surface-level issues reliably. It doesn’t understand your business domain, your team’s architectural decisions, or why that awkward workaround exists. Think of it as a thorough first pass that frees your human reviewers to focus on design and intent.
Cold start time. Installing Claude Code and running a review adds 1–3 minutes to your pipeline. For teams that optimize CI to the second, that’s worth considering.
Start here
Pick one repository. Add the GitHub Actions workflow above. Set it to run only on PRs that touch *.cs files. Keep the prompt focused on security issues — that’s where AI reviews deliver the clearest value.
Watch it for a week. Read the review comments it posts. You’ll quickly see what it catches that your team misses, and what it flags that isn’t useful. Tune the prompt based on what you learn.
Then expand: add naming conventions, test coverage checks, migration safety. Build a prompt that reflects your team’s actual standards, not generic best practices.
The goal isn’t to replace your reviewers. It’s to make sure every PR gets a thorough, consistent first read — even the one submitted at 5:47pm on a Friday.