Most developers want feedback on their code - but they wait until they put up a pull request to ask for it. What if you could get a review before creating that pull request? I built that into my open source project ZapCircle, and I use it to make ZapCircle better!

When I was at Google I/O last week (May 2025), I got a chance to talk to a lot of other developers who were there for LLMs and AI. One comment I heard from a few folks was that they spent a lot of their time doing code reviews and managing pull requests, especially if they were tech leads.

There are several tools out there that provide code reviews for a pull request (GitHub Copilot being one choice) - but what if you did the code review before the pull request? That way any messy code gets cleaned up ahead of time, and you’re not wasting time with a pull request that has to be re-worked.

As I develop ZapCircle, I’m the only developer - so everything is on me. Like anyone, I need some second opinions, and some feedback - this is where npx zapcircle review comes in handy. It’s a command-line tool that looks at the files you’ve changed from your main branch, whether they are staged, unstaged, or committed.

How I use local code review

I’m working on a big improvement to the zapcircle new feature - making it so it generates a runnable React Router/Vite/Tailwind project from a single prompt. Everything’s going well with testing, and I’m almost ready to put up a pull request for the code.

Before I do so, I run npx zapcircle review, which does a command-line review for me - here’s an abbreviated version of the review only showing what changed with the new.ts file, as this was a pretty big change:

Running ZapCircle Review…

🔍 Fetching changed files…

🧐 Analyzing 9 modified files…

🔎 Reviewing zapcircle/zapcircle-cli/src/commands/new.ts…

This pull request significantly enhances the project scaffolding functionality by restructuring the zapcircleNew command, improving user interaction, and introducing a new utility for handling TOML deduplication…

/Users/jefflinwood/Projects/zapcircle/zapcircle-cli/src/commands/new.ts

• 🟡 Line 22: Stray console log for project definition prompt.
• 🟠 Line 48: Redundant assignment of ideaPrompt for existing condition.
• 🟠 Line 64: The first instance of calling rl.close() can be removed.
• 🟠 Line 89: Unreachable code detected after early return if projectTomlPath does not exist.
• 🔴 Line 40: Direct use of user input for projectType can lead to security risks. Consider sanitizing the input.

…

ZapCircle CI is non-blocking, but these improvements are recommended.

🚀 Review process completed!

The LLM categorizes the issues by priority. For ZapCircle, the console.log command is actually useful for the developer experience, so I can safely ignore those. Later on, I could add a custom rule to my ZapCircle installation to ignore those in code review.

The highest priority item was to sanitize user input - I fixed this by removing the ability to directly specify the project type altogether, as ZapCircle only supports one project type right now.

Here’s the before:

 let projectType = initialProjectType;
  if (!projectType) {
    projectType = await rl.question(
      "What type of project? (default: react-tsx): ",
    );
    if (!projectType.trim()) projectType = "react-tsx";
  }

And after:

  const projectType = "react-tsx";

Of course, this is only possible because there is just one project type supported with ZapCircle right now.

Benefits of ZapCircle review locally vs pull request

The biggest advantage of ZapCircle review running locally is that it’s easy to run - and you don’t have to trigger it by pushing a commit up to a PR. Even if you squash your commits, it ends up being a tedious process.

You can also get pull request reviews from multiple LLMs, if you want to try Claude and OpenAI, for instance.

ZapCircle will run as part of a GitHub action, and you can include it in your workflow - follow the directions on the Reviewing Changes docs page.

You also have the ability to have a clean pull request the first time other people see it - hopefully the obvious errors get pointed out by the LLM, so you can address them. This should shorten the amount of time it takes for a pull request to get merged.

What’s next

Because it’s only me working on ZapCircle right now, it’s really great to have a second opinion on the code I’m writing. Having that right in my terminal is a big win.

The next steps for ZapCircle are to turn the results of this review into issues that the ZapCircle agent can address automatically - closing the loop on really effective pull requests. As a developer, I’m still in the driver’s seat, but I’ve got the LLM making sure everything’s squared away.

Try it out

If you want to try this out, you’ll need Node installed, and an API key from one of the major LLM API Providers - OpenAI, Anthropic, or Google Gemini - or a URL.

Run one command to setup your chosen LLM and API key for all your projects:

npx zapcircle configure

After that, you can run npx zapcircle review from the command line as often as you like:

npx zapcircle review

For more, check out the docs at Reviewing Changes.

Any questions or comments? Reach out to me - jlinwood@gmail.com