akshaysg

If you see my reply, I would absolutely love it if you could email akshaysg@haystackeditor.com with some details about your desired use cases!

Thank you for the kind words!

RE Pricing: Because of the high volume of our customers, this is quite necessary unfortunately. We can definitely shift down costs as existing intelligence becomes cheaper though.

I think that AI coding is only going to grow in usage. I also think that AI more-or-less writes working code that is faithful to the user's prompt.

At the same time, AI does not write code that's easy for humans to review, as it writes very verbosely and with the goal of getting the job done vs producing readable code.

I really don't think humans should be reviewing the absolute mountains of LLM-produced code; doing so would only exhaust someone's cognitive budget.

Therefore, I think that bug finding should be left to AI to review, while architectural decisions should be reviewed by humans.

Yeah I agree it's a shame. Unfortunately coding has changed fast and I was not confident that the editor was in the correct direction with AI coding becoming so prevalent.

I think there is a lot of value with "reconnecting" with your codebase, so I do have some plans to bring the core concept of Haystack back in one form or another.

I think Haystack offers:

1. A centralized review mechanism for a team or org that operates on coding agent conversations in addition to diffs (and the codebase). It evaluates multiple different variables (e.g. how sensitive are the changes, how much did the author do to derisk, and what did the author's coding agent gloss over) and helps enforce your team's guidelines moreso than just an individual's prompt

2. Adversarial review that operates in addition to other AI review agents (e.g. BugBot, or Greptile) and filters any comments to only the things the author cares about. This helps cut down on the "AI reviewer battleground" that is present in pull requests

3. A review interface that allows human reviewers to quickly understand what the author did to verify their changes and focus on the author's design decisions

We actually jury-rigged all of this together before building Haystack, but found that it doesn't scale to the team level (since every individual has their own ideas/opinions of what constitutes a human review).

We also found that reviewing through purely Claude Code/Codex was slow and difficult because stuff like author traces are not pre-processed and you have to get your agent to specifically explore/understand them.

I've been thinking a lot about this!

Redoing the work as smaller PRs might help with readability, but then you get the opposite problem: it becomes hard to hold all the PRs in your head at once and keep track of the overall purpose of the change (at least for me).

IMO the real solution is figuring out which subset of changes actually needs human review and focusing attention there. And even then, not necessarily through diffs. For larger agent-generated changes, more useful review artifacts may be things like design decisions or risky areas that were changed.

Will add this then!

We use a mixture of LLMs (e.g. to identify the important variables to trace), language servers (to understand where a variable is originally defined and where it's used).

We may go back to code visualization for editors, but after testing it with a lot of engineers, we found that it was too confusing for code reviews. The main issue was just how alien the interface is!

> 1. Allow me to step through the code execution paths that have been modified in the pull request, based on the tests that have been modified.

Not sure if I fully grasp this! We tried to kind of do this in previous iterations (show call graphs all at once) and it gets messy very fast. Could you elaborate on this point in particular?

Ahah! Thanks for the feedback.

Yes! I personally iterate without understanding the code too much (since it'll change), and fully assess what Claude Code (in my case) has done after I finished a piece of work.

Thanks for the feedback!

Not sure if I fully grasp what you mean by dog whistling, but at the end of the day, like another commenter said, Haystack is also pretty helpful for when you're done experimenting with a piece of work and need to see what an AI has generated.

Yes! We haven't wholly given up on that idea by the way ;)

>If AI writes all of the code, we will need to max out humans’ ability to do architecture and systems design.

Strongly agree with this. There are demos that you're able to try, by the way!

Yeah I did this too as an engineer!

I think this is a valid part of the "crafting PR" skill that's under appreciated, and part of the goal of Haystack here is to make that part of PR craft effortless.

Interesting. At my previous company there was a debate about smaller PRs vs bigger PRs and the end conclusion was that there are tradeoffs in being able to deal with 2-5 bite-sized PRs vs one large PR. The largest one being that it's hard to grasp the totality of the pull request and how the different PRs work together.

> companies don't want to invest in slowing down, only going faster.

I do think this is the way things are going to go moving forward, for better or for worse!

Sorry to clarify: you hit "back" after traversing from the summary but it doesn't go back? If so, that's a bug!

Or do you mean that doing the browser navigation of "back" should bring you to the summary (initial page)?

> you likely have a bigger organizational issue

Could you expound on this? In my experience as a software engineer, a pull request could fall into one of two buckets (assuming it's not trivial):

1. The PR is not organized by the author so it's skimmed and not fully understood because it's so hard to follow along

2. The PR author puts a lot of time into organizing the pull request (crafting each commit, trying to build a narrative, etc.) and the review is thorough, but still not easy

I think organization helps the 1st case and obviates the need for the author to spend so much time crafting the PR in the 2nd case (and eliminates messy updates that need to be carefully slotted in).

Curious to hear how y'all handle pull requests!

Thanks for the opinion! That makes a lot of sense and I like the concept of being an extension of a user's own analysis vs hosing them with information.

Yeah originally I thought of using yellow/brown or yellow/black but for some reason I didn't like the color. Plenty of time to go back though!

Trying to fix/find this! Could you email me the repo details? Very sorry for the error here.

In terms of auth: you should get an "unauthenticated" if you're looking at a repo without authentication (or a non-existent repo).

1. Pricing would be $20 per person and we'd spin up an analysis for every PR you create/are assigned to review 2. We don't train or retain anything related to your codebase. We do send all the diffs to Open AI and/or Anthropic (and we have agentic grepping so it can see other parts of the codebase as well) 3. Do you mean the ability to run this on your own servers (or even on your own computer with local LLMs)? We do have plans for the former, but I don't know how big the lift on the latter will be so I'm not sure!

There's a GitHub app that you can install on your repo.

If you install and subscribe to the product, we create a link for you every time you make a pull request. We're working (literally right now!) on making it create a link every time you're assigned a review as well.

We'll also speed up the time in the future (it's pretty slow)!

That's fair! If there were a "minimal" mode where you could still access callers, data flows, and dependencies with no AI text, would it be helpful for your reviews?

Hi HN!

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

Ruby is now supported on Haystack and it should have a graph connected correctly!

Ruby is now supported on Haystack!

> If I had jump-to-definition and find-references in the line-by-line code review UI

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.

I'll let you know when we have this up!

You can review each commit in isolation! Also, you can CMD+Click on that new function and it should create a view of that function on the canvas, along with a connector.