I've been experimenting with reviewing AI-generated code using a second model without spending additional coding-agent tokens or paying for API calls.

I built AI Badger, a free, open-source VS Code extension that packages your Git changes into a review prompt you can paste into ChatGPT, Claude, Grok, or another browser-based AI chat.

You can use free chat tiers or an existing subscription. No API key or separate AI service is required. Your normal chat usage limits still apply, but you're not consuming your coding agent's quota.

For more complex reviews, it also supports an iterative workflow where the reviewer can request additional repository context instead of guessing from the diff.

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=pvrlabs.ai-badger

Article and walkthrough: https://pvrlabs.xyz/articles/reviewing-ai-generated-code-vscode-aibadger.html

I'm curious whether others use separate AI chats for code review or stick with their coding agent's built-in review tools.

I’ve been building a tool where several AI models work on the same codebase. One makes the changes; the others review them.

About ten weeks in, the part I keep coming back to is what a reviewer’s approval is actually worth.

Early on, I’d get a “looks good” from the second model and feel more confident about the change. But reading back through the transcripts, I often couldn’t tell what it had checked. Had it opened the surrounding code? Run the tests? Or just read the diff and found nothing obvious?

That made the approvals hard to use, so I changed a few things:

• Reviewers can inspect files and run builds and tests on the same machine, with restrictions on what commands they can use.
• The tool records the commands that actually ran, their exit codes, and their output. A model saying “tests passed” doesn’t count as evidence by itself.
• An approval without any checks is marked “unverified.” If a reviewer approves while a check is failing, that gets flagged too.

There are still gaps. Passing tests don’t help much if the tests miss the bug. I’m wary of calling something “verified” when all we really know is that a particular set of checks passed.

The command restrictions also limit what reviewers can confirm, especially when a change needs writes or a deployment to test properly.

And I haven’t benchmarked this against ordinary review, so I don’t know how many additional bugs it catches. So far, the benefit is that I can see what an approval is based on.

How do you decide an AI-generated change is done? Do you rerun the tests yourself, trust the agent’s report, or have another model review it? If that second model approves without running anything, does its approval carry any weight for you?

Disclosure: I’m building LetThemBuild, by GPULogy AI. It’s free to try. I’ve left the link out of the post, but can share it in the comments if anyone asks.

Principal software dev and responsible for a ton. The diff and pr diff aren't good enough. The size of the changes and complexity often need a walkthrough. I tried a few others, but they just weren't good enough. This has an MCP you can use to walk through changes or walk through any part of the codebase. I can quickly spot missing functionality or spot complexity that needs breakdown using this tool.

Adding a QA view that shows test coverage and gaps, with an MCP tool to allow your agent to suggest improvements to coverage as well. Hope it's helpful to someone who still needs to keep track of tricky changes.

https://github.com/aitakemyjob/codediver

Repository-aware coding agents can still miss architecture that exists outside the repository.

I built AIP, an open-source MCP server that combines runtime observations, deployment information and architecture contracts to give agents evidence-qualified distributed-system context.

In the Pitstop demo, a change to MaintenanceJobFinished has 5 receivers on its messaging path, including ReportingService, which is not in the upstream repository the agent is reading.

AIP does not pretend to know which receiver actually uses StartTime or EndTime. That still requires source inspection.

The split I’m testing is:

architecture evidence tells the agent where to inspect; source analysis tells it what the implementation does.

Hosted demo, public and read-only, no account or token:

https://github.com/michaelegner/architecture-intelligence-platform/blob/main/examples/pitstop-demo/TRY_IT_HOSTED.md

Source:

https://github.com/michaelegner/architecture-intelligence-platform

Not much to say here xd

My website, there are 2 subpages that you can check out!

Maker here, full disclosure. After hitting "Hydration failed" in Cursor-built Next.js apps one too many times, I started collecting fixes. That turned into FixKit: paste the error and get the cause, the fix, and a follow-up prompt for Cursor/Lovable/Bolt. It's free to try: https://fixkit-ai.netlify.app/products/error-fixer.html

What error eats the most of your time? I'll write a guide for the top answers.