Oops 上线：一晚肝出的开源 GitHub PR AI 评审机器人

Using Tencent Cloud ADP Sandbox + Hunyuan Model, a developer built an open-source GitHub PR AI review bot called **Oops** overnight. The core code is only 300 lines, designed for plug-and-play use and capable of reading context across files.

Yet Another PR Review Bot — But This Time It’s “Built Overnight”

CodeRabbit is too expensive, and Claude Code Review is still in limited release, so someone decided to build their own.

On the night of May 28, an open-source project called Oops quietly went live on the Linux.do community. The author’s description was straightforward: “I wanted to build a PR auto-review tool. Tried CodeRabbit, found it too expensive, so I decided to make my own.” The project went from idea to working prototype in a single night, with about 300 lines of core code spread across three ports.

It might sound like another weekend toy, but after reading the code and trying the demo, you realize it’s more interesting than it seems — it offloads the most annoying parts of building such bots (sandbox, isolation, concurrency, lifecycle management) to Tencent Cloud’s ADP service. The author only needed to focus on writing the review logic and prompts.

This is actually a snapshot of AI app development today: infrastructure is becoming like utilities — water, electricity, gas — and the code developers actually write is getting thinner and thinner.

Screenshot of Oops automatically leaving review comments on a PR

It Doesn’t Just Make AI “Look at the Diff” — It Makes AI “Go Into the Code”

To understand where Oops sits, you first need to grasp the two main approaches used by AI code review tools today.

The first is the diff-based approach. Early versions of CodeRabbit, various GitHub Action scripts, and many personal projects basically follow this pattern:

GitHub Webhook → Pull PR diff → Feed to LLM → Write back comments

This method is simple to implement — you can do it in a few dozen lines of Python, and Tencent’s Developer Community even has ready-made tutorials. But the problem is obvious: the model only sees a few changed lines and has no context. For example, you change a function signature, but the model doesn’t know that the function is called in 17 other files; you add a dependency, but it doesn’t realize the project already has a similar helper; you modify a constant, but the model can’t see its default value in a config file.

The result is lots of “plausible but useless” suggestions, and developers quickly get frustrated and turn off the bot.

The second is the environment-based approach. Anthropic’s new Claude Code Review follows this path — it spawns multiple agents to inspect real code environments in parallel. Oops takes the same route — the AI doesn’t just look at diffs; it enters a sandbox, pulls the repository, reads any file, runs commands, and checks context.

The author summed it up nicely: “For cross-file issues, this is a lot more reliable than just throwing the diff at a model.”

Simple words, but they capture the biggest mindset shift in AI coding tools this year: it’s more important for models to “see” code than to be “smart.” Tools like Cursor, Claude Code, and Codex CLI succeed mainly because they solve the context-access problem — not just by switching to a stronger model.

Outsourcing the Hard Work: The Importance of ADP Sandboxes

Actually implementing an environment-based approach yourself is tedious. The author listed out a checklist that pretty much captures every pain point faced by anyone who’s built similar tools from scratch:

Prepare isolated code execution environments for AI
Handle concurrent tasks (what if multiple PRs come in at once?)
Manage timeouts, exceptions, and resource cleanup
Deal with VPS, Docker, queues, and scheduling

Individually, none of these are hard, but together they form a mini distributed system — stabilizing it alone can cost multiple weekends. For a side project, that’s serious overkill.

Diagram showing Oops architecture: Webhook, sandbox, AI, review comment flow

Oops solves this by using Tencent Cloud ADP (AI Developer Platform) in “Claw mode.” In simple terms, it’s a cloud sandbox service for AI apps. You call an API, it spins up an isolated Linux environment where you can run anything, and automatically recycles it when done. Concurrency, timeouts, and resource limits are all handled by the platform.

The model used is Tencent’s own Hunyuan3, and for now both the sandboxes and the model are free on ADP — making it very friendly for personal projects.

Here’s the key idea: Once sandboxes become a service, AI app development changes fundamentally. In the past, building an AI tool that could “execute code” meant spending 70% of your time on container orchestration; now you just focus on “what the AI should do inside the sandbox.” OpenAI’s Code Interpreter, Anthropic’s Computer Use, and various Agent frameworks all rely on this type of infrastructure. Tencent turning it into an open service is essentially a bid for the “cloud function” position in the AI era.

What Fits in 300 Lines of Code

Looking at the GitHub repo (Oops-AI-Team/GithubCodeReview), the design is strikingly minimal. The core flow follows the classic Webhook pipeline:

GitHub Webhook trigger
  ↓
Verify signature + parse PR metadata
  ↓
Call ADP to create a sandbox and pull PR snapshot
  ↓
AI Agent reads and analyzes code in sandbox
  ↓
Generate review → Write back via GitHub Review Comment API
  ↓
Recycle sandbox

The three ports correspond to: receiving GitHub Webhooks, communicating with ADP, and writing back to GitHub’s API. This kind of “thin” design is increasingly common in LLM apps — business logic goes in the prompt, engineering logic goes to cloud services, and the rest is glue.

The upsides: simple, readable, easy to modify. The downsides: your moat depends entirely on prompt engineering and the infrastructure you use. That’s why these projects all feel similar — there’s no real technical secret; differences lie in product decisions.

Oops has two clear differentiators:

Works out of the box — install as a GitHub App, no need to configure per-repo actions.
Self-hosted and open source — teams with data sensitivity can deploy privately, keeping code in-house.

The second point matters. Commercial tools like CodeRabbit and Greptile are great, but they need to send code to third-party servers — compliance departments won’t like that. That’s why domestic self-hosted open-source tools (like ai-code-review-helper or helloworldtang’s ai-pr-reviewer) still have strong traction.

Just How Crowded Is This Field?

A quick scan shows that just in the past six months, at least these AI PR review tools have appeared publicly:

CodeRabbit: established commercial tool, pricey, most complete experience
Greptile: YC-backed, focuses on overall codebase understanding
Claude Code Review: official Anthropic release, launched in May, multi-agent parallel
Kody (Kodus): open source, supports custom rules and severity filtering
WasmEdge tutorial version: early community project, pure diff approach
Various domestic self-hosted tools: ai-code-review-helper, ai-pr-reviewer, etc.
Oops: the newcomer

All with the same pattern: Webhook in, Review Comment out, swapping out the model, prompt, or sandbox in between. Real differentiation comes down to just three things: handling large repositories, understanding project conventions, and noise control.

In plain language: Can it handle monorepos, adapt to team coding style, and avoid flooding with comments? No open-source tool yet nails all three — including Oops. The author admits it’s a one-night project, still far from production-ready.

That said, the sheer number of people building such tools on weekends shows PR review pain is very real. Every PR needs a reviewer, and reviewer time is one of the scarcest resources in engineering teams. If AI can catch 80% of low-level issues, human reviewers can focus on real design decisions.

Tips for Those Wanting to Build Their Own

If you’re thinking about building one yourself, here are some lessons worth following:

Model selection: Review workloads are not latency-sensitive but require high reasoning quality, so don’t cheap out on models. Claude Sonnet, GPT-4 series, DeepSeek-V3, and Qwen3 are solid starting points. Hunyuan3 performs well for Chinese projects, but English repos may vary — benchmark multiple models. Aggregators like OpenAI Hub make swapping models easy using a single key — handy for testing.

Prompt design: Asking a model to simply “review this code” will perform poorly. Define role (senior engineer), focus areas (bugs, security, performance, maintainability, prioritized), output format (Markdown, with severity levels), and what not to do (don’t nitpick style, don’t repeat obvious points). This accounts for at least half of result quality.

Sandbox setup: If you don’t want to use cloud services, local Docker + queue setups also work, but ensure proper resource isolation and timeout handling. Managed sandboxes like ADP, E2B, and Modal are the simpler alternative.

Feedback loop: Review Comments (linked to lines) are far better than Issue Comments (whole PR level), but GitHub’s API requires precise file paths and line numbers — LLMs often fail here, so post-processing validation is essential.

Oops is still in an early stage — the author clearly admits it’s a one-night project — but the idea is right: offload infrastructure to the cloud, focus on prompts and product. This “30-minute MVP, spend the rest polishing UX” model may be the ideal rhythm for AI app development.

Whether it can grow into the next CodeRabbit depends on whether the author keeps investing in it. After all, the biggest enemy of weekend projects has never been technology.