Skip to content
CutplaneJoin the private beta

Understand what your AI agent changed.

  • Public and private repos
  • TypeScript
  • JavaScript
  • Python

Pull requests, or any two commits.

acme/api#482Add password reset flowclaude-code
  • Password resets are issued and confirmed by a component of their own
  • Reset tokens reach the user database through a new store
  • Email delivery now sits on the account recovery path
  • Two public routes and one migration ship with this change
files changed
11
in a component
8
lines in components
412
components
5
public routes changed
2
schema statement
1
new dependencies
2
excluded by role
3
Based on 8 of 8 eligible changed files

Password reset

Added
Before
A forgotten password needed an operator to clear it
After
Users request a reset link and set a new password themselves

Auth Service hands recovery to Password Reset, which issues a single-use token through Token Store and sends the link with Email Delivery. Tokens expire after an hour and are consumed the first time they are used.

In favour

  • In favour: Reset tokens have one home and one expiry rule

Against

  • Against: The recovery path now depends on an external mail provider
Files changed in 5 components. Dependencies shown: 4 new, 1 unchanged
unchanged · 1new · 42 components added

AI can write more code than humans can comfortably understand.

What the diff shows

GitHub tells you what lines changed.

  • 18 files changed
  • 1,700 lines
  • 4 modules touched
  • 2 API endpoints
  • 1 schema migration
  • 1 new dependency

What you actually need

Cutplane tells you what changed in the system.

  • Session handling moved out of Auth into a new component
  • Checkout now depends on authentication at request time
  • A new external dependency sits in the login path
  • A second token abstraction appeared next to the existing one

See the PR as a system change.

Architecture Diff

Compare the architecture before and after the pull request, as one drawing rather than two panels to diff by eye. Components and dependencies that were introduced or removed are obvious at a glance, and only the affected part of the system is drawn.

How did this PR change how this repository works?

Illustration: an architecture diagram from an example report, drawing the components before and after a pull request as one graph, with the added component and the dependencies this change introduced and removed marked.
new · 2removed · 11 component added

New File Integration

Agents create files very easily. For every meaningful new file, see the component it belongs to, the responsibility it introduces, who calls it, what it calls, and which existing flow it became part of.

Why does this file exist and how does it integrate into the architecture?

Illustration: a card from an example report describing one new file, naming the component it joined, what calls it, and what it calls.
token-cache.tsNew file
Belongs to
Authentication domain
Used by
AuthServiceSessionManager
Calls
RedisClient
Introduces
A new caching responsibility

Change Impact

Not “37 imports found”. Impact is grouped at the architectural level first: the components that may behave differently, how many of their files are involved, and whether they import the change themselves or only sit downstream of something that does. Every reach opens onto the path it travelled.

What existing parts of my application could this change affect?

Illustration: the reached components table from an example report, each row naming a component, how many of its files the change reaches, and how far the reach travelled, with one row opened onto the shortest path from the changed symbol.
ComponentFilesReached by
Checkoutsrc/checkout/32 direct · 1 at two steps
Billingsrc/billing/1none direct · 1 at two steps

Shortest component path from the changed symbol:

  1. Session Manager
  2. Auth Service
  3. Billing
Admin APIsrc/admin/21 direct · 1 at two steps

Start at the system. Drill down only when you need to.

You should never be forced to start from raw code. The report opens on the components this change touched; the file, the function and the diff are each one tab away, and you stop as soon as you understand the change.

Illustration: the component tab of an example report, a rail of cards, one per component this change touched, each with its path, its size and why it ranked where it did, above the file, function and diff tabs one step further down.
Session ManagerAdded
src/auth/session/

3 files · 116 lines

exports, 2 dependents

Session creation and expiry moved out of Auth Service into a component of its own.
src/auth/session/manager.ts:1-88
Auth ServiceModified
src/auth/

2 files · 41 lines

exports, 4 dependents

Auth Service delegates session lookup instead of reading the session table itself.
src/auth/service.ts:112-153

Show me what matters. Hide what doesn’t.

Changed components, new components, direct dependencies and important downstream effects come first. Everything else stays hidden until you ask for it: counted on a tab, folded under a ranking, never deleted.

Pick any sentence. Here is the source.

A report makes a small number of claims about what your change did to the rest of the app. Each one arrives with the exact lines in your repository that made it true.

Illustration: claims from an example report, each one carrying the file, the lines and the diff behind it.

Example report

Every claim

Session handling moved out of Auth into a component of its own.

manager.ts:1-6
added +export class SessionManager {added +  async validate(session: Session) {added +    const record = await this.store.get(session.id);added +    if (!record) throw new SessionExpired(session.id);added +    return record;added +  }

Checkout now depends on SessionManager.

checkout-service.ts:82-86
 export async function createOrder(req: Request) {   const session = req.session;removed -  if (!session.valid) throw new Unauthorized();added +  await sessionManager.validate(session);   const cart = await cartStore.load(session.userId);   return checkout.begin(cart);

Computed by static analysis

imports · exports · function calls · API routes · database access · schema changes · dependency changes · grouping and ranking

Interpreted by the agent, from your request

naming the concepts · explaining the relationships · judging what fell outside your request

Run the analysis before the commit, not after the pull request.

Point Cutplane at what you have changed right now, including staged, unstaged and new files, and it prints the components, routes, migrations, packages and database tables they reach. Published on npm: no pull request, no account, no model call.

$ npm install --global cutplaneinstall the CLI
$ cutplane explaincurrent working files compared with HEAD; no API key
$ cutplane setup claudeinstall /cutplane, then invoke it in Claude Code

Published on npm as cutplane, MIT licensed.

Example: the terminal output of cutplane explain, run on uncommitted changes. It shows two API routes added, two schema statements with the migration line behind each, one new package, and the database tables the change reaches with the components that read or write them.
Cutplane — what else does this affect?
"acme-billing" · current working tree compared with 4979f34

2 connections added / 0 removed between components · 2 route changes · 3 schema statements · 1 packages added

ROUTES
  + /api/invoices [GET, POST]   app/api/invoices/route.ts
  + /api/invoices/[id] [GET]    app/api/invoices/[id]/route.ts

SCHEMA
  + create table invoices (id, org_id, total_cents)   0012_invoices.sql:1
  + alter table orgs (billing_email)                  0012_invoices.sql:24
  NOT READ  supabase/seed.sql — not a migration

DEPENDENCIES ADDED
  stripe@^14.4.0  first used at src/billing/checkout.ts:12

DATA ACCESS
  3 component(s) reach a database
  invoices                     2 components, 4 read / 2 write
    src/billing/, src/admin/
  orgs                         3 components, 6 read / 1 write
    src/billing/, src/admin/, src/auth/
  2 access site(s) added or removed by this change
  + invoices [select,insert]   src/billing/invoice.ts:44

GRAPH
  412 literal edges, 18 through barrels (2 ambiguous)

Before shipping: inspect the changed components and exercise the callers reached above.
Evidence describes this snapshot; rerun after editing. No model calls were made.

Or let the agent explain it

cutplane setup claude installs an explicit /cutplane command. Run it once the agent has finished: Cutplane computes the structure locally, and the session already holding your original request relates the findings back to what you asked for. Nothing runs on its own.

Your repository is untouched

Snapshots are written to a temporary Git object database, so your index, branches and working files are unchanged. Nothing is installed, run or evaluated from the repository being analysed.

The same engine as the report

cutplane.dev runs this engine on a server and gives each run a link you can send. In your terminal, --json is the whole report and the thing to hand another program.

Common questions about reviewing AI-generated code.

Something not covered here? hello@cutplane.dev

How do I review a pull request from Claude Code?

Point Cutplane at the pull request. It reads the two commits, groups the changed files into the components they belong to, and tells you which parts of the system changed and what those changes reach, all before you open a single file. Every sentence links to the line of code it was computed from.

My agent changed 60 files. Where do I start?

At the top, with the two or three things that actually changed in the system. Cutplane collapses the repository until only the change is left standing, taking thousands of files down to the handful of components this change affects, and ranks what to read first. You open a file once you have decided it matters, not to find out whether it does.

I vibe-coded a whole feature and never read the diff. Can I still ship it?

That is the case this was built for. You get the shape of what the agent did in a page you can read in a minute: the new components it introduced, where each new file landed, what existing behaviour it could affect, and any new route, migration or dependency. Whether the code is correct is still your call, since this is not a linter or a test runner. But you stop shipping things you cannot describe.

Does this work with Cursor and Codex?

Yes. Cutplane reads the code, not the agent, so a pull request from Cursor, Codex, Claude Code, a teammate or you is analysed identically. Which agent wrote it changes nothing.

Does it work on commits, or only pull requests?

Both. Give it a pull request number, or any two refs: a base and a head. With no base it uses the merge base with your default branch, and the report says that is what it did.

Does it work with private repositories?

Yes, public and private, on GitHub. Reading code comes from a GitHub App you install on the repositories you choose, not from your login: signing in asks GitHub for your name and email address and nothing else. On an organisation an owner approves the install, and you can remove it at any time. The CLI needs none of this. It runs against the clone you already have, with no account and no model call.

Does Cutplane track architecture drift across pull requests?

Not yet. Cutplane analyses one change at a time, this pull request against its base, and everything it tells you is computed from those two commits. Watching structure degrade across a year of merged PRs is a different product with a different data model, and until it exists the honest answer is that this tool reads one pull request, not a history. There is a page under Concepts explaining what architecture drift is and why agents accelerate it.

Is this a code review tool or a diagram generator?

A code review tool that draws. Structure comes from real static analysis: imports, function calls, API routes, database access, schema and dependency changes. The model only names and explains what the analysis found. When it is uncertain it shows less rather than something plausible, and there is a section whose whole job is naming what it chose not to claim.

Your AI already writes the code. Make sure your team still understands it.

Built initially for GitHub repositories, public and private, using TypeScript, JavaScript and Python.

One email when the beta opens. No newsletter, no sharing.