Reinventing the Pull Request

Source: lubeno.dev | Author: Unknown (Lubeno team) | Published: ~2026-03-27 Category: vendor-analysis | Credibility: low

Executive Summary

Lubeno, an early-stage code hosting platform built natively on Jujutsu (jj), argues that traditional pull requests are broken and proposes stacked diffs as the solution, with their platform as the enabler.
The article frames code review as a tool for reducing “comprehension debt” (a concept coined by Addy Osmani in March 2026), not just catching bugs, and advocates for small, atomic, stackable PRs reviewed independently.
Key workflow claims: developers should break large changes into small sequential diffs, reviewers can evaluate individual commits, and jj’s native change management makes rebasing stacks painless compared to Git.
This is fundamentally a vendor blog post promoting Lubeno’s differentiators (jj-native hosting, stacked PRs) against GitHub and GitLab.

Evidence quality: anecdotal (references a recently coined concept)
Assessment: This is a reasonable reframing, but it appropriates Addy Osmani’s “comprehension debt” concept — originally about AI-generated code that passes review without being understood — and applies it to general code review. The mapping is imprecise. Osmani’s point was about the gap between code existence and human understanding in the AI era; using it to justify stacked diffs is a stretch.
Counter-argument: Comprehension debt as Osmani defined it is primarily about AI-generated code volume. Smaller PRs help reviewers understand changes, yes, but the core comprehension debt problem (code nobody understands is accumulating) is not solved by PR sizing — it requires architectural discipline, documentation, and team knowledge sharing regardless of PR workflow.
References:
- Addy Osmani - Comprehension Debt
- Comprehension Debt discussion on HN

Evidence quality: vendor-sponsored (claimed by the platform selling this feature)
Assessment: The velocity benefit of stacked diffs is real and well-documented independently. Graphite reports Shopify saw 33% more PRs merged per developer after adoption. However, velocity gains must be weighed against the complexity cost: cascading rebases, merge conflicts in dependent branches, and the cognitive overhead of managing stacks.
Counter-argument: Alex Jukes argues stacked diffs “solve the problems of branching with more branching” and that the existence of entire SaaS businesses (Graphite, Lubeno) built to manage this complexity is itself evidence that the pattern introduces significant cost. For smaller teams, trunk-based development with short-lived branches may be simpler and equally effective.
References:

Evidence quality: anecdotal (no benchmarks comparing jj vs Git stacking ergonomics)
Assessment: This is directionally accurate. jj’s first-class change tracking and automatic rebase propagation does simplify stacked workflows compared to vanilla Git. However, jj adoption remains early-stage (27k GitHub stars, mostly individual experimentation). The claim that this makes Lubeno superior to GitHub + Graphite is unverified — Graphite has production deployments at Shopify and Asana, while Lubeno’s production usage is undocumented.
Counter-argument: jj uses Git’s on-disk format, so the ergonomic advantage is at the CLI layer, not the hosting layer. A developer can use jj locally with GitHub + Graphite and get most of the same benefits without switching code hosts. Lubeno’s value proposition shrinks to “native jj hosting” which is a niche play.
References:

Evidence quality: anecdotal
Assessment: Per-commit review and routing is a valid workflow improvement. Google’s internal code review tool (Critique) has supported this for years. However, the article implies this is novel or unique to Lubeno — it is not. Graphite, Gerrit, and Phabricator all support commit-level or change-level review. The innovation here is bundling this with jj-native hosting, not the review model itself.
Counter-argument: Commit-level review routing requires discipline and consistent commit hygiene from developers. In practice, many developers create messy intermediate commits and clean up later. The HN discussion itself surfaced suggestions that LLMs could auto-reorganize commits into clean stacks, implying that manual commit discipline is a real friction point.
References:
- SmartBear - Code Review Best Practices (200-400 LOC optimal)
- Google Engineering Productivity - review turnaround research

Author background: Unknown. The HN account “bkolobara” posted an earlier Lubeno submission (37 days prior). No public profile, company page, or LinkedIn found. The blog has no author byline.
Publication bias: This is a vendor blog from Lubeno, a pre-revenue early-stage startup with no documented production customers. The article exists to promote Lubeno’s stacked-PR and jj-native features. It borrows credibility from the “comprehension debt” concept (Addy Osmani / Google) and from the broader stacked-diffs movement (Meta’s Phabricator, Google’s Critique) without establishing independent evidence for Lubeno specifically.
Verdict: low — Vendor marketing from an unproven startup with no independent validation, no public customers, and UI described as “rough” by early HN commenters. The underlying ideas about stacked diffs have merit but are not novel to Lubeno.