Lubeno

A fresh take on pull-request iteration for the era of AI-generated code.

Role
Co-founder · Product Design · Frontend
Timeline
2025 – Present
Platform
Web application
Status
lubeno.dev
200+ users
Lubeno product screenshot
01

Problem and Context

Pull-request workflows haven't evolved to match how code is written today. Developers use AI-assisted coding more often than not, and the DevOps market keeps pouring resources into code generation efficiency. Code review tools haven't seen a significant change in 20 years. The human reviewer is still the one accountable for a larger volume of code they didn't write themselves. There is a high cost to this. Developers are frustrated, code quality suffers, and pull requests sit waiting while the work built on top of them can't move forward.

78%
say developers are writing and committing code faster since adopting AI
+91%
longer pull-request review time on teams with high AI adoption
31%
of developers don't trust the accuracy of AI output
02

Research and Discovery

We started from our own lived problem as developers working in teams, and then decided to validate it. We followed discussions on public developer forums, published articles that provoke reactions and pull feedback, and finally started direct conversations with real users. Each stage was validated enough to justify the next.

1 · The problem
My own daily frustration as hypothesis
2 · Forum research
Hacker News, X and Reddit on current tools
3 · Publishing
Articles that pull feedback from developers
4 · Direct feedback
Individual conversations with our users

"What I really want when I'm reading source code is to hover over a line and ask 'why was this done this way?' That reasoning almost never makes it into the docs but it's exactly what lives in the review discussion."

— Developer, from our user conversations
03

Design Decisions

An honest look at the structures and design shifts that transformed a complex set of developer workflows into an intuitive code-hosting experience.

3.1 Information Architecture

Before jumping into screens, I mapped out the product's page structure to have a clearer view of how the users would navigate. I organised flows for logged-out users, logged-in users, and repository settings. The page structure has grown since then, but this initial version already helped us understand how many steps a developer needs to start collaborating on the platform.

Lubeno sitemap
Lubeno sitemap · click to enlarge

3.2 Key Design Decisions

Pull Request Page

On my early designs I stacked conversation and code vertically, not so different than GitHub. I realised reviewers need discussion context visible alongside the code they're reviewing, without the need to switch tabs. This led to a two-column layout that mirrors how developers actually work. It's a simple decision, but it makes their work much more effective while reviewing code.

Stacked PRs
Before · click to enlarge
Code review flow
After · click to enlarge

Repository Page Navigation and Redesign

The sidebar navigation evolved from a feature-heavy list to a focused set of core actions. I decided to remove cognitive load and prioritize what developers access most frequently. We made it usable but wanted to delight users too! So we did a redesign few months ago keeping consistency with our brand, namely the light polkadot background.

Stacked PRs
Before · click to enlarge
Code review flow
After · click to enlarge

3.3 Core Features

Stacked pull requests
PRs build on top of each other, so users can keep working on new ones while previous ones are under review.
Code evolution tracking
The tool intelligently tracks what each reviewer has already seen, and comments never get lost in the noise of new changes. Reviewers can focus on what changed since their last review.
Git-compatible, Jujutsu-native
We offer backwards compatibility with Git, while Jujutsu users get its full velocity benefits through a visual tool.

"In every review tool I've used, I never know what order to review files in. As the author, I just want to float the important files to the top so reviewers look there first."

— Another developer we spoke with

3.4 Final Product

Key pivot: after testing the first prototype, we realized users needed a more linear flow rather than the branching model we initially designed.
Stacked PRs
How stacked PRs look · click to enlarge
Code review flow
The code review flow · click to enlarge

What shipped is live at lubeno.dev, where developers host and review code today. Git repositories work exactly as they always have, while Jujutsu users get the full velocity benefit through the same visual interface.

04

Outcome

200+
users hosting code with us
2025
from idea to a live, growing product
100%
hosted in Europe

What I learned

  • Design for emerging workflows rather than optimizing existing ones.
  • Knowing when to pivot on user feedback versus staying the course on the original vision.

What's next

  • Continuous Integration, protection rules and richer approval options.
  • IDE integrations and an AI agent that summarizes and pre-reviews pull requests with user-set rules.
Next case study
Restaurant Mobile App La Fermina
→