Show HN: Stage – Putting humans back in control of code review

Original Article ↗ Hacker News Discussion ↗

AI-powered code review tool Stage, which groups pull request diffs into narrative “chapters,” is prompting debate over how best to manage increasingly large, AI-generated code changes. Supporters like the way it auto-structures messy PRs and could help juniors, non-technical stakeholders, or high-volume teams focus their attention, while critics argue that better commit hygiene, specs, and processes would address many of the same problems without adding another proprietary SaaS layer. Many commenters also question whether AI summaries risk distancing engineers from real understanding, how to incorporate intent and “why” into reviews, and whether such features should be built locally or directly into GitHub/GitLab instead.

Chapters and PR Workflow

  • Many reviewers like “chapters” that auto-split large PRs into logical groups, often matching what should have been several smaller PRs.
  • Some see chapters as complementary to stacked PRs and good commits; others argue this just compensates for bad practice and misbehaving teammates.
  • Users want manual control (editing chapter splits, CHAPTERS.md config), and chapter-level actions (mark as viewed, comment on chapter).

Context, Intent, and “Why”

  • Several commenters say the core problem in review is understanding intent, requirements, and acceptance criteria, not just “what changed.”
  • Suggestions: pull context from tickets (GitHub issues, Linear), embed agent context into git, map changes to specs/ACs/tests, and ensure PRs explain why and how to verify.
  • Some tools and workflows mentioned try to distill review learnings back into agents and docs (LESSONS.md, BUGBOT.md, agents.md).

Human vs AI Review

  • Product positions itself as “human-in-the-loop,” using AI to guide attention, not replace review.
  • Skeptics counter: if AI can reliably summarize and flag focus areas, why not let it just do the review? Others fear humans will only read AI’s “what to review” list.
  • Some see human review as essential for design tradeoffs, knowledge sharing, and onboarding, even if AI can mechanically check correctness.

Commits, Git, and Abstraction Level

  • Debate over whether chapters duplicate what good commits should already provide.
  • Critics argue tools like this discourage disciplined commit hygiene, which hurts bisect/blame/history.
  • Others say topic-grouped commits are hard and costly to maintain, especially for teams and AI-generated code; PR-level grouping is seen as more practical.

Trust, Deception, and AI Framing

  • Strong concern that AI narratives “spin” changes, making slop look polished and discouraging deep scrutiny.
  • Question whether a separate “narration” agent can truly be trusted not to mislead when operating on AI-generated PRs already optimized to appear good.

Business Model, Local vs Cloud, and OSS

  • Some want this as OSS or a local-first tool; distrust long-term SaaS for core dev workflows.
  • Pricing is criticized as high relative to general LLM subscriptions, and lack of upfront pricing info is a turnoff.
  • Others note incumbents (GitHub/GitLab) could integrate similar features; moat is questioned.