Building Pattern-Aware Code Review with Cloudflare and Claude

Here’s a cleaned‑up version of the markdown, preserving the original content and formatting:

[![Jonescodes](https://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F755962%2Ff42b6499-fbed-449c-8164-435553c8c6cb.png)](https://dev.to/codejonesw)

Nobody loves code review. You open a PR, scan the diff, catch a typo, approve it, move on. The deeper stuff like pattern consistency and architectural alignment takes real time and real focus. Most of us don't have enough of either.

I wanted to build something that catches pattern drift. **Not a linter. Not static analysis.** Something that understands how your codebase handles a problem and tells you when new code does it differently.

> **Source:** [Dev.to – Building pattern‑aware code review with Cloudflare and Claude](https://dev.to/codejonesw/building-pattern-aware-code-review-with-cloudflare-and-claude-352c)

Why Existing AI Reviewers Fall Short

Most AI code‑review tools only see the diff. They often give generic advice such as “consider adding error handling,” even when your project already provides a handleApiError() wrapper that is used in every API method. The feedback sounds smart but isn’t grounded in the actual codebase.

Generic vs. Useful Suggestions

The second suggestion is only possible when the reviewer has visibility into the whole codebase.

Starting as an MCP Tool

The first version of DiffPrism was a Claude Code MCP tool. MCP (Model Context Protocol) lets you build tools that AI agents can call. DiffPrism gave Claude Code a browser UI for reviewing diffs: you could open a review, see the changes, and Claude would post inline comments.

Why It Fell Short

• Session‑bound – You had to be in a Claude Code session.
• Manual prompting – You had to prompt Claude to start the review.
• Server requirement – The MCP server had to be running.

Each step was manual, creating too much friction.

The Pivot

Real code review happens on GitHub: PRs, discussions, and merges all live there. A separate tool would always be an extra step, so I pivoted to a GitHub‑centric workflow.

Moving to a GitHub App

A GitHub App receives webhooks whenever something happens on a repository (e.g., a PR is opened, code is pushed, or a comment is posted). No manual triggering is required.

The new DiffPrism is a Cloudflare Worker that listens for these GitHub webhooks. When a user comments /review on a pull request, DiffPrism:

1. Fetches the diff.
2. Gathers code‑base context.
3. Sends everything to Claude.
4. Posts inline comments on the PR.

The developer never leaves GitHub.

Architecture

GitHub webhook
   → DiffPrism Worker (receives event, queues review job)
   → Queue consumer (fetches diff, gets context, calls Claude, posts comments)
   → Repo Context Service (semantic search, related files, conventions)

• Service bindings allow workers to call each other directly without traversing the public internet.
• The Repo Context Service remains private, while the GitHub App can still reach it.

The repo‑context service

This is where I spent the most time. The service indexes your entire repository and makes it searchable, enabling pattern‑aware review.

• When you install DiffPrism on a repo, it triggers indexing.
• The service walks the repo tree, splits code into semantic chunks at function and class boundaries, generates vector embeddings with Workers AI, and stores everything in Cloudflare Vectorize.
• It also tracks imports and exports to build an import graph.

When a review happens, DiffPrism asks the context service two questions:

1. What code is semantically similar to what changed?
2. What files connect to the changed files through imports?

These answers are fed to Claude alongside the diff, allowing Claude to reference actual patterns instead of guessing.

The whole stack runs on Cloudflare:

$5/month covers everything at my current scale.

Quality Problems I Had to Solve

1. Combined Query Problem

Embedding an entire PR diff as a single search query diluted the embedding. A diff that touched routing, auth, and tests often matched nothing well.

Solution
Added a batch‑search endpoint that accepts multiple queries—one per changed file. This produces focused, relevant results.

2. Path‑Only Embeddings

The related‑files tool was embedding a string like

File: src/router/index.js

which contains hardly any semantic content.

Solution
Look up the file’s exports and the first chunk of its content. After the change, related‑file scores jumped from 0.6 to 0.91 (e.g., lib/request.js now finds lib/response.js as highly related).

3. Missing Conventions

DiffPrism could find related files but couldn’t answer questions about naming conventions, test patterns, or import style.

Solution
Exposed architecture‑ and conventions‑detection as JSON API endpoints so the review prompt can include project standards.

4. Indexing Timeouts

Indexing a 200‑file repository timed out because the pipeline ran synchronously; the embedding step alone took minutes for hundreds of chunks.

Solution
Split indexing into two phases:

1. The HTTP request stores pre‑walked data in R2 and queues a job.
2. The queue consumer reads from R2 and runs the pipeline asynchronously.

Result: express.js (209 files, 308 chunks) indexed without issues.

Testing at scale

I indexed express.js to validate beyond small repos:

• Files: 209
• Chunks: 308
• Processing: Fully async through the queue.

Search examples

• "middleware error handling" → returned the error‑handling example file with 0.78 relevance.
• "routing and route matching" → returned router files.
• Architecture detection correctly identified JavaScript as the primary language and lib/ & test/ as the main directories.

DiffPrism now provides pattern‑aware, context‑rich code reviews directly inside GitHub, turning AI from a generic suggestion engine into a true project‑specific reviewer.

Sure, `index.js` as the entry point, ESLint and Prettier as tooling.  
Conventions detected kebab‑case naming and CommonJS imports. All correct.

What’s Next

The core review loop works: comment /review and get inline comments that reference your codebase in about 10 seconds.

Next steps for production‑ready release

• Real multi‑tenant authentication
• Stripe billing integration
• Upgrade from Haiku to Sonnet for better review quality

The end goal is a code‑review tool that knows your codebase well enough to catch what humans miss when reviewing at speed. It’s not a replacement for human review—just a way to make it better.

Try it out

DiffPrism is free for up to 10 reviews per month.

Install the GitHub App and comment /review on any PR.