Perspective · Diffraction
A code diff is only part of the picture.
Why we’re building a review layer for the experience on the other side of a pull request.
The other side of the diff
A pull request is a precise account of what changed in the code. It is a less direct account of what changed for the person using the application. A few lines of CSS can move a critical button out of reach. A shared component can quietly change a flow far from the file being reviewed.
That gap is where Diffraction starts. We want the experience produced by a change to receive the same attention as the code that produced it.
Look at the change in context
A page is more than its first screenshot. People open menus, enter information, follow links, encounter errors, and try again. Reviewing a UI means following those actions and understanding what they make possible—or prevent.
The useful question is specific: can someone still complete the task affected by this change, in the browser and at the screen size that matter? That question gives the review a scope and makes its answer something a developer can investigate.
Make the evidence part of the review
A finding is more useful when it shows its work. What action led to the problem? What did the browser display? Which revision was running? A recorded sequence gives the reviewer a place to start and a way to check the observation.
We call these findings aberrations. The name is a reminder to look for departures from the expected experience, grounded in the project’s own rules and the user’s task.
A clearer picture includes its limits
A review that cannot reach a flow should say so. A recording from one viewport should not stand in for another. Evidence becomes less useful when its boundaries are hidden.
The aim is a review that helps people make a better decision about a change: what was inspected, what happened, and where to look next. That is the picture we’re building Diffraction to provide.