Skip to main content

Intent-Based Review - Abstracting Code Changes for Human Verification

· 3 min read
Calvin Cheng
Calvin Cheng
Shape what gets built and the value it creates.

When agents generate code, the volume of changes can overwhelm human reviewers. Line-by-line diff review doesn't scale - and for many changes, it's the wrong level of abstraction. What reviewers often need is: what did this change accomplish, logically? Intent-based review surfaces that instead of (or in addition to) the raw diff.

The Review Bottleneck​

A human might spend 20 minutes reviewing a 200-line diff. An agent can produce several such diffs in an hour. If the review process expects line-by-line scrutiny of every change, the human becomes the bottleneck. Worse, line-level review may miss the forest for the trees - the reviewer focuses on syntax and style while the real question is: does this change do what we intended?

Abstraction Levels for Review​

Raw diff: Exact code changes. Necessary for some checks, but often too granular.

Intent summary: "Changed sorting for user_list from bubble sort to quicksort to improve performance. Test coverage maintained." One sentence; the reviewer can verify conceptual correctness.

Pseudocode / logical diff: Representation of control flow or data flow changes. "Added retry loop around API call; on failure, log and fall back to cached value."

Visualization: Diagrams of structural changes - new modules, dependency shifts, flow alterations. Useful when the change affects architecture.

The key: the abstracted representation must have strong guarantees (or high confidence) that it accurately maps to the actual code. Otherwise the reviewer is verifying a summary that might not match reality.

Design Requirements​

Faithful mapping: The intent summary must be derived from the actual changes, not from a separate agent "description" that could drift. Tooling that generates summaries from diffs, or that requires the agent to produce both code and summary in a single structured output, reduces this risk.

Auditability: When the reviewer approves the intent, there should be a traceable link to the code. "Approved: intent X → implementation in files A, B, C."

Configurable depth: Some changes warrant full diff review. Others - routine refactors, well-scoped fixes - can be verified at intent level. Let teams choose.

Integration with existing workflows: PRs, code review tools, CI. Intent-based review should slot into current processes, not replace them entirely. It's an additional layer, not a fork.

When It Shines​

  • Agent-generated code where the agent's reasoning is more important than manual style
  • Large refactors where structural intent matters more than line counts
  • Repetitive changes (e.g., API migrations) where the pattern is clear and the review is "did we apply it correctly?"

When to Keep Line-Level Review​

  • Security-sensitive changes
  • Critical paths where subtle bugs have high cost
  • First-time agent outputs from a new system (trust is still being established)

Intent-based review is a design choice: optimize for the common case (conceptual verification) while preserving the ability to go deep when it matters.