Civium Systems for Code Review

• 

  Civium offers two ways to try out the experience.

• 

  on the demo web, the companion chatbot that does the clicks for you.

• 

  on the demo web, the findings are presented inline for your approval.

• 

  on the demo web, once posted, civium will remember.

• 

  on GitHub with extension installed, the companion box shows on PRs page.

• 

  on GitHub with extension installed, the PR details page presents a pointer to all the findings.

• 

  on GitHub with extension installed, the findings are displayed inline on the changes page.

Inspiration

Code review is one of the highest-leverage parts of software development, but it also demands sustained attention. Reviewers have to understand context, trace impact, spot risks, and decide what actually matters.

AI can reduce the mechanical work in that first pass. But replacing the reviewer with a bot creates a different problem: noisy comments, shallow conclusions, and unclear human ownership.

Civium Systems for Code Review is built around a simple idea: let the agent prepare the review, and let the reviewer make the judgment.

What it does

Civium Systems for Code Review turns the pull-request queue into a shared workspace for a reviewer and an agent.

The agent can:

• review one pull request or the entire open queue;
• surface pull requests that still need a decision; and
• organize the queue so reviewers can focus on the changes that deserve attention.

The reviewer sees the results inside the normal review flow. Pull requests with no findings are clearly marked, so they can be skipped without opening the diff. Findings appear directly below the relevant changed lines, with the surrounding code still visible.

Every finding starts as a private draft. The reviewer decides whether to dismiss it or approve it. Nothing is published simply because the agent found it.

For this demo, the review engine intentionally uses one narrow, deterministic rule: it finds snake_case variable declarations on changed JavaScript and TypeScript lines. This keeps the behavior repeatable and the scope honest. The goal is not to present a complete review engine, but to demonstrate a better workflow for people and agents to review code together.

WebMCP makes that workflow practical for an agent. Instead of inspecting page markup and guessing which controls to use, the agent gets a small set of meaningful actions exposed directly by the application. The same workflow still works manually when WebMCP is unavailable.

How we built it

The application uses:

• React 19 and Next.js-compatible routing via Vinext
• WebMCP tool registration through document.modelContext
• Babel's TypeScript-aware parser for deterministic AST inspection
• Node's built-in test runner for fixture, state, scanner, session, and comment-equivalence tests

The pull-request queue exposes two WebMCP tools:

1. review_pull_request accepts one validated pull-request number and starts its review.
2. set_pull_request_filter accepts a constrained (demo only) mode for showing all pull requests, reviews needing action, or pull requests from a known author.

Both tools update the same React state used by the visible interface, so agent actions and manual actions stay in sync.

Review requests go through server routes backed by Cloudflare D1. Review projects are deduplicated by repository, pull-request number, and head SHA.

The scanner parses JavaScript and TypeScript declarations, evaluates only added lines, and maps persisted findings back to the exact file and line in the diff.

The on-page Civium Companion uses the same underlying operations. It maps user's semantic requests to the same actions exposed through WebMCP.

Challenges we ran into

The hardest design question was deciding where the agent should stop.

Once an agent can inspect code and propose findings, it is tempting to let it publish those findings automatically. But that would weaken the human ownership Civium is designed to preserve.

We chose a strict boundary: the agent can organize and prepare the review, but the reviewer decides what gets published.

Another challenge was keeping the demo realistic without overstating what we built. We intentionally limited the review rule, constrained API inputs, and scoped GitHub publication to a small set of frozen example pull requests.

We also had to make agent actions feel like part of the product rather than a separate automation layer. Using the same application state for both WebMCP actions and manual interactions helped keep the experience consistent.

Accomplishments that we're proud of

• One natural-language request can start a structured review across the queue.
• The agent can narrow the queue to the pull requests that still need human attention.
• Findings persist across navigation and appear at the exact lines that triggered them.
• The scanner inspects parsed declarations rather than matching arbitrary text.
• Only added lines are evaluated.
• Repeated reviews of the same pull-request version do not create duplicate work.
• Agent and manual actions operate on the same application state.
• The workflow remains understandable and usable without WebMCP.

Most importantly, the agent can take on repetitive review work without taking ownership of the final decision away from the reviewer.

What we learned

WebMCP is most useful when an application exposes meaningful work rather than every individual UI control.

Civium gives the agent only two tools, but those tools are enough to review and organize an entire queue. The agent does not need to understand every button on the page to be useful.

We also learned that agent actions need visible consequences. Reviewers should be able to see when a pull request enters review, when results arrive, and which findings still need a decision.

That visibility matters because trust does not come from the agent simply saying that work was done. It comes from being able to see what it did and make the final judgment yourself.

What's next for Civium Systems for Code Review

The demo proves the workflow. The next step is turning it into something real engineering teams can use every day.

That means supporting real repositories and organizations, production-grade authentication and permissions, and reliable handling of changing pull requests.

The review engine also needs to grow beyond one fixed rule. It should understand more kinds of code issues, use repository and team context, and let teams decide what the agent should look for.

As the product scales, Civium will also need stronger infrastructure around security, reliability, auditability, and background processing.

The core idea stays the same: let agents do the repetitive review work, while people keep control of the decisions that matter.

Built With

• codex