DEV Community

Riley Wu
Riley Wu

Posted on

A Free AI Code Reviewer: Hooking MonkeyCode's Server to GitHub PRs

Every pull request deserves a second pair of eyes. Most solo developers don't have one. A free AI server can fill that gap, but only if you wire it correctly. This post shows you how to build a PR review bot on MonkeyCode's free server. It won't replace a human reviewer. It will catch the obvious mistakes before your reviewer looks. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The core idea is simple. A GitHub Action triggers on every PR. It sends the diff to a local MonkeyCode server. The server returns a list of issues. The Action posts them as a comment. The whole pipeline costs nothing in tokens for a small project.

Why use a free server for code review? Code review is a short-context task. The diff is small. The prompt is clear. The response is a list. That fits the free tier's sweet spot. Long conversations and heavy context are where free tiers struggle. Code review avoids both.

Let's start with the server. Assuming you have MonkeyCode installed, run this command in a terminal:

monkeycode serve --free
Enter fullscreen mode Exit fullscreen mode

Check your docs for the exact flags. The server listens on localhost:8080 by default. Keep it running while you test.

Now write the review script. Create a file called review.py. It reads a diff from stdin, sends it to the server, and prints a comment.

#!/usr/bin/env python3
import json
import sys
import urllib.request

def review(diff):
    prompt = (
        "You are a code reviewer. Analyze this diff. "
        "List only concrete issues: bugs, security risks, or performance problems. "
        "Be terse. Output as a numbered list.\n\n"
        + diff
    )
    payload = json.dumps({"prompt": prompt, "max_tokens": 300}).encode()
    req = urllib.request.Request(
        "http://localhost:8080/v1/completions",
        data=payload,
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=60) as resp:
        data = json.load(resp)
    return data["choices"][0]["text"].strip()

if __name__ == "__main__":
    diff = sys.stdin.read()
    if len(diff) > 4000:
        diff = diff[:4000] + "\n... (truncated)"
    print(review(diff))
Enter fullscreen mode Exit fullscreen mode

This script has a hard limit of 4000 characters. That keeps the context short and the latency low. If the diff is larger, it truncates. That is a deliberate trade-off. The bot will miss issues in the tail. You can adjust the limit later.

Now wire it into GitHub Actions. Create a workflow file at .github/workflows/review.yml.

name: AI Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Get diff
        run: git diff origin/${{ github.base_ref }}...${{ github.sha }} > diff.txt
      - name: Run review
        run: |
          python review.py < diff.txt > comment.txt
      - name: Post comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const comment = fs.readFileSync('comment.txt', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: comment
            });
Enter fullscreen mode Exit fullscreen mode

This workflow assumes you run the MonkeyCode server on the same machine. In reality, you might run it on a separate box. You can replace localhost with your server's address. For a public repo, you should not expose your server. Use a private network or a tunnel with authentication.

The prompt matters more than the model. A vague prompt gives vague comments. The prompt above is explicit about what to look for and how to format the output. You can extend it with your project's specific rules. For example, add "Check for missing error handling" or "Flag any use of eval."

Test the pipeline on a small repo first. Open a PR with a deliberate bug. The bot should catch it. If it doesn't, adjust the prompt. If it catches too many false positives, tighten the scope.

What are the limits? The free server is shared. Latency varies. Your token allowance is finite. A typical review uses about 2,000 input tokens and 300 output tokens. Ten million tokens cover roughly 4,000 reviews. That is plenty for a solo project. But if you run the bot on a busy repo, you will hit the limit fast.

Privacy is another concern. The diff is sent to the server. If your code is proprietary, do not use a remote free server. Run the open-source version locally if you can. Even then, the model may send data to a third-party API. Read the docs before you trust it.

Who should not use this approach? Teams with strict SLAs. A free server can go down. It can be slow. It can return nonsense. If your review process depends on it, you will be disappointed. Use it as a triage tool, not a gate. Also, don't use it for security-sensitive code. The bot is a helper, not an auditor.

The bot works best for small, well-scoped PRs. It catches missing null checks, obvious typos, and simple logic errors. It struggles with architectural issues and cross-file changes. That is fine. The human reviewer handles those. The bot handles the boring stuff.

This setup is a starting point. You can extend it with more prompts, a queue, or a local model. The architecture is simple: an event, a script, a server, a comment. That simplicity makes it easy to debug and cheap to run.

If you want to try it, MonkeyCode's free tier is a low-risk way to experiment. Point it at a test repo, break a few lines, and see what the bot catches. You might be surprised at how much it finds.

MonkeyCode provides free models that can run this workflow.

Top comments (0)