Using BoardSnap for code review sketches.

Code review is typically a text-on-screen activity: you read a diff, leave comments, suggest changes. But the most consequential code review conversations often leave the screen and move to a whiteboard — when the change is large enough that a diagram clarifies the architecture, when the reviewer needs to sketch an alternative approach, or when the two engineers are talking through a data model change that's hard to convey in PR comments.

That whiteboard content — the proposed refactor diagram, the alternative API surface sketch, the data flow before and after — is exactly what belongs in the PR description or the Architecture Decision Record. But it usually doesn't get there, because no one wants to re-type a diagram.

The code review sketch workflow with BoardSnap

1. Work through the review at the whiteboard as normal.
2. At the end of the discussion, snap the board. BoardSnap AI reads the diagram, labels, code pseudocode notes, and margin annotations.
3. The summary becomes the "how we decided this" context in the PR description, Confluence ADR, or Linear task.

Pinned context works well here: pin the system architecture or the relevant service contracts once, and when you ask the AI "Does this approach contradict our stated API design principles?" — it uses that context.

Limitations: BoardSnap doesn't read code diffs or syntax-highlight code. If pseudocode or short code snippets are written on the board, it reads them as text. For code-heavy boards, write larger and more legibly than you might otherwise — the camera resolves text, not semantic meaning from small characters.

For related use cases, see the system design and architecture sketching pages.