Review the pull requests that actually need human attention
Haystack helps engineering teams manage the growing volume of AI-generated pull requests. It sits on top of GitHub, analyzes each PR’s diff, codebase context, agent trace, intent, and verification evidence, then routes it: safe to move forward, needs fixes, or needs human review. Teams use Haystack to keep code moving without rubber-stamping, focusing human attention where judgment actually matters.
Hey PH! We’re building Haystack to help teams deal with the explosion in the number of pull requests that need to be reviewed due to the rise of coding agents.
Haystack replaces the GitHub PR review system with a queue that triages each PR before a human has to read any diffs. It looks at the diffs, the codebase, and the coding-agent conversation that produced the PR. Haystack then routes it into one of three buckets:
1. Safe to merge. This means the PR has enough evidence behind it that the team can merge it without another human’s review.
Some examples:
A small UI copy change that includes a screenshot showing the final state
A backend change where the author clearly tested the important paths and ran the changes in a real environment
2. Needs fixes. This means that the PR has bugs or violates a rule in your codebase and therefore the PR needs to be fixed by the author.
Some examples:
The agent was asked to make loading a large table faster by adding pagination, but the PR still loads every result at once and “implements” pagination in the UI
The PR silently catches an error instead of logging, surfacing, or handling it. This violates the team’s “no silent error swallowing” rule
3. Needs human review. This means that the PR could not be sufficiently verified by the author or is touching a sensitive part of the codebase (determined by user-input guidelines) and thus requires human review.
Some examples:
The PR changes a significant amount of logic in billing
The PR changes an important user flow like onboarding, but the author only ran unit tests and never opened the app to check the flow end-to-end. That violates the team’s rule that high-impact user-facing changes need manual verification.
Instead of starting with line-by-line diffs, Haystack immediately tells the reviewer the goal behind the PR, what design decisions the author made (informed by their coding-agent conversation), and how much the author did to verify that the pull request works (e.g. run scripts, checked the frontend, etc.).
In this way, review shifts from “what changed?” to “is this the right behavior and is there evidence that it works?”.
We previously launched Haystack as a tool for understanding large PRs (https://news.ycombinator.com/ite...). As many of you can probably relate to, the release of Opus 4.5 completely shattered our conception of how fast an engineer could craft a PR.
And as coding agents got even better from 4.5, we realized that pull requests did not scale along with our coding velocity. With each member of our team being able to pump out more than 20 pull requests a day, code review quickly became cognitively exhausting and less helpful.
After talking with other folks, we learned many feel similarly, and currently face the binary option of either not doing review at all or trying to keep up with a fire hose of pull requests.
Haystack is our attempt at a third path. We still believe in code review, but as coding agents produce more code, human reviewer attention becomes more valuable and more expensive.
Haystack helps teams spend that attention on the PRs where a human can meaningfully change the outcome of that PR. And for such PRs, Haystack shows the reviewer what the PR intended to do, whether the author showed that it works, and what design decisions need a second pair of eyes.
We’re still quite early and are figuring out whether Haystack truly makes code review better. We would love any and all feedback!
About Haystack on Product Hunt
“Review the pull requests that actually need human attention”
Haystack launched on Product Hunt on May 19th, 2026 and earned 104 upvotes and 12 comments, placing #12 on the daily leaderboard. Haystack helps engineering teams manage the growing volume of AI-generated pull requests. It sits on top of GitHub, analyzes each PR’s diff, codebase context, agent trace, intent, and verification evidence, then routes it: safe to move forward, needs fixes, or needs human review. Teams use Haystack to keep code moving without rubber-stamping, focusing human attention where judgment actually matters.
On the analytics side, Haystack competes within Developer Tools, Artificial Intelligence and GitHub — topics that collectively have 1M followers on Product Hunt. The dashboard above tracks how Haystack performed against the three products that launched closest to it on the same day.
Who hunted Haystack?
Haystack was hunted by Akshay Subramaniam. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
For a complete overview of Haystack including community comment highlights and product details, visit the product overview.
Akshay Subramaniam
Hey PH! We’re building Haystack to help teams deal with the explosion in the number of pull requests that need to be reviewed due to the rise of coding agents.
Haystack replaces the GitHub PR review system with a queue that triages each PR before a human has to read any diffs. It looks at the diffs, the codebase, and the coding-agent conversation that produced the PR. Haystack then routes it into one of three buckets:
1. Safe to merge. This means the PR has enough evidence behind it that the team can merge it without another human’s review.
Some examples:
A small UI copy change that includes a screenshot showing the final state
A backend change where the author clearly tested the important paths and ran the changes in a real environment
2. Needs fixes. This means that the PR has bugs or violates a rule in your codebase and therefore the PR needs to be fixed by the author.
Some examples:
The agent was asked to make loading a large table faster by adding pagination, but the PR still loads every result at once and “implements” pagination in the UI
The PR silently catches an error instead of logging, surfacing, or handling it. This violates the team’s “no silent error swallowing” rule
3. Needs human review. This means that the PR could not be sufficiently verified by the author or is touching a sensitive part of the codebase (determined by user-input guidelines) and thus requires human review.
Some examples:
The PR changes a significant amount of logic in billing
The PR changes an important user flow like onboarding, but the author only ran unit tests and never opened the app to check the flow end-to-end. That violates the team’s rule that high-impact user-facing changes need manual verification.
Instead of starting with line-by-line diffs, Haystack immediately tells the reviewer the goal behind the PR, what design decisions the author made (informed by their coding-agent conversation), and how much the author did to verify that the pull request works (e.g. run scripts, checked the frontend, etc.).
In this way, review shifts from “what changed?” to “is this the right behavior and is there evidence that it works?”.
Here’s a quick demo: https://www.tella.tv/video/strea...
We previously launched Haystack as a tool for understanding large PRs (https://news.ycombinator.com/ite...). As many of you can probably relate to, the release of Opus 4.5 completely shattered our conception of how fast an engineer could craft a PR.
And as coding agents got even better from 4.5, we realized that pull requests did not scale along with our coding velocity. With each member of our team being able to pump out more than 20 pull requests a day, code review quickly became cognitively exhausting and less helpful.
After talking with other folks, we learned many feel similarly, and currently face the binary option of either not doing review at all or trying to keep up with a fire hose of pull requests.
Haystack is our attempt at a third path. We still believe in code review, but as coding agents produce more code, human reviewer attention becomes more valuable and more expensive.
Haystack helps teams spend that attention on the PRs where a human can meaningfully change the outcome of that PR. And for such PRs, Haystack shows the reviewer what the PR intended to do, whether the author showed that it works, and what design decisions need a second pair of eyes.
We’re still quite early and are figuring out whether Haystack truly makes code review better. We would love any and all feedback!