Every commit I push now gets reviewed by an AI before any human sees it. Not because I don’t trust my own code — because I don’t trust my own attention at 11 PM on a Friday when I’m trying to ship a fix before the weekend.
The AI reviewer catches things I miss: a variable declared but never used, an API key accidentally left in a comment, a function that handles the happy path but crashes on empty input. Small things. The kind of things that code review exists to catch, but that tired human reviewers also miss.
Here’s how I connected OpenClaw to GitHub Actions for automated AI-assisted code review.
The Setup
Trigger: A GitHub Action workflow that runs on every pull request. When a PR is opened or updated, the workflow fires.
What it does: The workflow extracts the PR diff, sends it to OpenClaw for review, and posts the review as a PR comment. Total execution time: 30-60 seconds depending on the size of the diff.
What OpenClaw reviews for:
1. Bugs: null references, off-by-one errors, unhandled edge cases
2. Security: hardcoded secrets, SQL injection patterns, insecure defaults
3. Style: inconsistencies with the codebase, unclear variable names, missing comments on complex logic
4. Performance: obvious inefficiencies, unnecessary loops, unoptimized queries
What it doesn’t review for: Architecture decisions, feature design, business logic correctness. These require human context that the AI doesn’t have.
The GitHub Action Workflow
The workflow is straightforward:
1. Checkout the code
2. Extract the diff between the PR branch and main
3. Send the diff to OpenClaw via its API (or CLI)
4. Format the response as a PR comment
5. Post the comment
The diff extraction is the important step. You don’t send the entire codebase — just the changes. This keeps the token count reasonable (and the cost low) while focusing the review on what actually changed.
For large PRs (500+ lines of changes), I split the diff by file and review each file separately. This produces more focused feedback than throwing everything at the model at once.
The Review Quality
After 3 months and about 200 PRs reviewed:
True positives (caught real issues): About 25% of reviews. Roughly one in four PRs has something the AI catches that matters. Most common: missing error handling, inconsistent naming, unused variables.
Useful suggestions (not bugs but improvements): About 40% of reviews. Style improvements, readability suggestions, documentation gaps. Not critical but helpful.
False positives (wrong or irrelevant): About 35% of reviews contain at least one incorrect suggestion. The AI misunderstands the context, suggests changes that would break functionality, or flags intentional patterns as issues.
The 35% false positive rate sounds high, but in practice it’s manageable. The comments are clearly labeled as AI-generated, and developers quickly learn which suggestions to take seriously and which to ignore.
Making It Useful Instead of Annoying
The difference between a helpful AI reviewer and an annoying one:
Prioritize findings. Label each finding as: 🔴 Bug (fix before merging), 🟡 Warning (consider fixing), 🟢 Suggestion (optional improvement). Developers address the red items, consider the yellow, and skim the green.
Be specific. “There might be an issue with error handling” is useless. “Function `processOrder()` on line 47 doesn’t handle the case where `order.items` is undefined, which will throw a TypeError” is actionable.
Don’t repeat the obvious. Developers know they should write tests. Don’t tell them on every PR. Focus on specific, non-obvious findings.
Limit comment count. Cap the AI review at 5 comments per PR. If there are more issues than that, prioritize and show the top 5. A PR with 20 AI comments gets ignored entirely; a PR with 3-5 focused comments gets read.
Beyond Code Review
Once the GitHub Actions integration is working, you can extend it:
PR description generation. When a PR is opened with an empty description, the AI reads the diff and generates a summary: what changed, why it likely changed, and what to look for during review.
Test coverage analysis. The AI checks whether the changed code has corresponding test changes. “You modified `auth.js` but didn’t update `auth.test.js` — was the test update intentional or forgotten?”
Changelog entry suggestion. Based on the diff, the AI suggests a changelog entry in the appropriate format. The developer approves or edits it.
Release notes compilation. When it’s time to release, the AI compiles all merged PRs since the last release and generates release notes. This saves 30-60 minutes per release.
The Cost
Average cost per PR review: about $0.08.
Monthly cost for 200 PRs: about $16.
For context, a human spending 15 minutes reviewing each of those PRs would spend 50 hours per month on code review. The AI doesn’t replace human review — it pre-processes it, catching the mechanical issues so humans can focus on design and logic.
My team’s review process now: AI review first (automated, 30 seconds). Human review second (focused on what the AI can’t assess, typically 5-10 minutes instead of 15). Total review quality: higher than before, in less time.
🕒 Last updated: · Originally published: December 30, 2025