I built an AI code review bot because I was mass-approving PRs at work.

I'll be honest — I was that reviewer.

The one who opens a PR, skims the diff, leaves a "looks good" comment, and hits approve. Not because I didn't care, but because there were 12 PRs in the queue, a sprint deadline, and I'd already spent 40 minutes reviewing one massive refactor.

Sound familiar?

I work at a large tech company. Code reviews are supposed to be our safety net. In practice, they're a bottleneck everyone races through. The dangerous stuff — hardcoded secrets, SQL injection, missing error handling — slips through not because reviewers are bad, but because they're human and tired.

So I started building something on weekends.

What it actually does

MicroReview is an AI code review bot that installs as a GitHub App. When someone opens a PR, it:

• Scans for hardcoded secrets (API keys, passwords, tokens — you'd be surprised how often this happens)
• Catches security issues like SQL injection, command injection, path traversal
• Runs language-specific rules for TypeScript, Python, and Java
• Uses GPT-4.1 to find logic bugs that static analysis misses
• Posts inline comments directly on the PR — exactly where the issue is
• Generates a risk score and summary so you know which PRs need careful human review and which are safe

It's not trying to replace human reviewers. It's trying to catch the stuff humans miss when they're on their 8th PR of the day.

Here's what the summary looks like on an actual PR — risk score, findings breakdown, and a full walkthrough of what changed:

![MicroReview PR summary showing risk score 100/100 with findings table]

The bug that convinced me this was worth building

I was testing MicroReview on a side project. It flagged this in a Python migration script — a hardcoded database password sitting right there in the source code:

![MicroReview catching a hardcoded password in Python with AI explanation and suggested fix]

It didn't just flag it — it explained why it's dangerous, what could happen if the repo gets compromised, and suggested the exact code change to fix it. One click on "Commit suggestion" and the fix is applied.

Same thing with a Java config class — hardcoded credentials that would've gone straight to production:

![MicroReview catching hardcoded password in Java with suggested fix using System.getenv]

These aren't hypothetical examples. This is real output from a real PR. I'd written this code myself and missed it during my own review.

How it's different from CodeRabbit

I looked at CodeRabbit before building this. It's good. But two things bothered me:

Per-seat pricing. A team of 20 developers reviewing 3 repos pays the same as a team of 20 reviewing 30 repos. That doesn't make sense.

MicroReview charges per repo — $5/month per repository. A solo developer with 2 repos pays $10. A 50-person team with 2 repos also pays $10. You pay for what you protect, not how many people you have.

GitHub Checks integration. MicroReview creates a proper GitHub Check on every PR — green checkmark if clean, red X if critical issues found. You can make it a required check so PRs with hardcoded secrets literally cannot be merged.

The whole thing is ~4,000 lines of TypeScript. It's not a massive system. Most of the intelligence is in how the rules are structured and how the AI prompts are tuned.

What I learned building this

1. AI catches different things than static analysis.
Static rules find patterns (regex matches for secrets, known bad function calls). AI finds logic bugs — "you're checking for null after you already dereferenced it" or "this loop condition will never terminate for empty arrays." You need both.

2. False positives are the #1 killer.
If your bot posts 50 comments and 40 are noise, developers will ignore all of them. I spent more time reducing false positives than adding new rules. The deduplication system alone went through 4 rewrites.

3. Incremental reviews matter.
Nobody wants to see the same 20 findings every time they push a fix. MicroReview tracks the last reviewed commit and only comments on NEW changes. Push a fix? It only reviews the diff since last review.

4. The summary comment is more important than inline comments.
Most reviewers don't read every inline comment. But they DO read a summary that says "Risk: 85/100 — 3 critical issues found." That's the hook that makes them actually look at the details.

Try it

If you want to try it on your repos: microreview.dev

It takes about 30 seconds to install — just authorize the GitHub App, pick your repos, and open a PR.

First repo is free. No credit card needed.

If you have questions or feedback, drop a comment below — I'm actively building this and genuinely want to hear what developers need from a tool like this.