Building Pattern-Aware Code Review with Cloudflare and Claude

Published: (March 9, 2026 at 12:27 AM EDT)
6 min read
Source: Dev.to

Source: Dev.to

[![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.

---

## Why existing AI reviewers fall short

Most AI code review tools see only the diff. They give generic advice like “consider adding error handling” without knowing that your project already has a `handleApiError()` wrapper used in every API method. The feedback sounds smart but isn’t grounded in your codebase.

**The difference between a generic suggestion and a useful one:**

```text
Generic: "Consider adding error handling"

Pattern‑aware: "This bypasses the handleApiError() wrapper
used in every other API method. See src/utils/errors.ts:12"

The second one is only possible if the reviewer has seen your code.


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.

It worked, but it had too much friction:

  • You had to be in a Claude Code session.
  • You had to prompt it.
  • You had to have the MCP server running.

Every step was manual.

Real code review happens on GitHub. PRs live there. Discussions live there. Merges live there. A separate tool will always be an extra step, so I pivoted.


Moving to a GitHub App

A GitHub App receives webhooks when things happen on a repo (PR opened, code pushed, comment posted). No manual triggering is needed.

The new DiffPrism is a Cloudflare Worker that listens for GitHub webhooks. When someone comments /review on a PR, 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 let workers call each other directly without going through the public internet. The context service stays 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:

ComponentPurpose
D1Database
R2Storage
VectorizeVector search
Workers AIEmbeddings
QueuesAsync processing

$5/month covers everything at my current scale.


Quality problems I had to solve

Combined query problem

Embedding the entire PR diff as a single search query diluted the embedding. A diff that touches routing, auth, and tests matched nothing well.
Solution: Added a batch‑search endpoint that accepts multiple queries—one per changed file. This produced focused, relevant results.

Path‑only embeddings

The related‑files tool was embedding a string like "File: src/router/index.js"—hardly any semantic content.
Solution: Look up the file’s exports and the first chunk of its content. Related‑file scores jumped from 0.6 to 0.91 (e.g., lib/request.js now finds lib/response.js as highly related).

Missing conventions

DiffPrism could find related files but couldn’t ask 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.

Indexing timeouts

Indexing a 200‑file repo timed out because the pipeline ran synchronously; the embedding step alone took minutes for hundreds of chunks.
Solution: Split indexing into two phases: the HTTP request stores pre‑walked data in R2 and queues a job; the queue consumer reads from R2 and runs the pipeline asynchronously. 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.

ure, `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`, get inline comments that reference your codebase in about 10 seconds.  

Next is making it production‑ready:

- Real multi‑tenant auth  
- Stripe billing  
- Upgrading 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** replacing human review—just making it better.

If you want to try it, DiffPrism is free for up to **10 reviews per month**.  
[Install the GitHub App](https://github.com/apps/diffprism) and comment `/review` on any PR.
0 views
Back to Blog

Related posts

Read more »

Your Agent Is a Small, Low-Stakes HAL

Overview I work with multi‑agent systems that review code, plan architecture, find faults, and critique designs. These systems fail in ways that are quiet and...