Beyond that, if my MR/PR has two (or more) logical commits, will the tool support reviewing each in isolation? Often times, I will do a refactor in the first commit, and have a second commit with the new feature that makes use of the refactor. Reviewing it all together can result in muddying the water.
Another thought: if I edit a function to call a different function defined elsewhere in my codebase, is there a way to include that functions definition into the canvas (either by the author in preparation for a reviewer, or by the reviewer) to facilitate verifying the behavior across this new boundary?
I think the main benefit of Haystack is that it allows you to keep a model of how the pull request works on the canvas, rather than manually needing to gain an understanding of it in your head.
Even with goto definition/references, I need to understand what parts of the pull request are net new and work together (e.g. I created a new function A that relies on a new class B and calls a new function C) and what parts are linked with existing parts of the codebase.
Normally, this would require me to do some digging around, but with Haystack a lot of this work is done for me in a visual way, allowing me to understand a pull request significantly faster.
Beyond that, if my MR/PR has two (or more) logical commits, will the tool support reviewing each in isolation? Often times, I will do a refactor in the first commit, and have a second commit with the new feature that makes use of the refactor. Reviewing it all together can result in muddying the water.
Another thought: if I edit a function to call a different function defined elsewhere in my codebase, is there a way to include that functions definition into the canvas (either by the author in preparation for a reviewer, or by the reviewer) to facilitate verifying the behavior across this new boundary?
You might have seen our previous post at https://news.ycombinator.com/item?id=42935218. Since then, we've upgraded Haystack Code Reviewer to break down a pull request into logical chunks and lay them out on an infinite canvas. It walks you through the changes as a structured visual story, helping you focus on architecture, intent, and maintainability instead of chasing nits. We hope that this new version of Haystack Code Reviewer makes code reviews less of a last-minute, unwanted chore. And if it doesn’t, we would love to hear about it!
We built Haystack because code reviews today are fundamentally broken.
The typical line-by-line diff format forces reviewers to focus on individual changes to catch bugs, style issues, and bad variable names, rather than the bigger picture of what the code is doing and why.
However, we don’t think that’s what code reviews are for. Tests (and angry users) catch bugs. Linters catch style issues. And nitpicks almost always bog down the review and make it take longer for the code to merge.
I believe that the point of a code review is to help teammates understand how the author is trying to achieve their goal, whether that’s a bug fix, a new feature, or a refactor. A good review requires understanding the narrative behind a change, determining whether the structure of a pull request reasonably fulfills that narrative (interface changes, new data structures, etc.), and deciding whether the team is OK with maintaining this new shape of the codebase.
The current pull request interface makes this hard. It's just a wall of unordered diffs that you're left to piece together by jumping between files. When reviewing a pull request from a teammate, We found ourselves spending more time reconstructing the big picture of the changes than reviewing the code itself.
With Haystack, we're trying to fix that!
If you’re interested:
1. Take a look at the demo playground https://haystackeditor.com/playground
2. Watch a walkthrough https://youtu.be/K_qLwXFwr8I
3. Try it at https://haystackeditor.dev