explain the consequence
“Missing null check” is a label. “Throws on checkout when a shopper removes their last item” is a reason. Comments carry the reason or they do not get posted.
About Rubberduckly
get your review hour back, and spend it on the decisions that matter.
Rubberduckly reads every pull request on GitHub and GitLab and talks you through what could break, line by line. You walk into review with the edge cases already named, so the conversation can be about design.
named after the oldest debugging trick there is: explain it out loud and the bug shows itself.
The problem
review time kept going to the wrong things
Open any busy review queue and the same comments repeat: a missing null check, a TODO without a ticket, a float where cents belong, a style rule everyone knows and nobody remembers. Each one is small. Together they eat the hour a reviewer had for the question that actually needs a human: is this the right shape for the change?
Linters catch the mechanical stuff but cannot say why something is dangerous. Human reviewers can, but they run out of attention first. The result is the worst kind of queue: slow, and still missing the bug that costs you a weekend.
Rubberduckly was built for that gap. It explains the consequence in plain sentences, with the line number, the reason and a fix you can commit.
BeforeReviewers hunt for typos, then run out of time for design.
AfterThe nitpicks are already answered. Reviewers start at the hard question.
Principles
four rules every comment has to pass
point at the line
Every finding names the file and line it is about, and shows the exact change that would resolve it. You should never have to hunt for what a comment means.
stay in the thread
Disagree? Reply. Rubberduckly answers with more context instead of repeating itself, and your team’s rules decide what blocks a merge and what only nudges.
respect the reviewer’s attention
Ranking matters as much as finding. Risky diffs rise to the top, trivial ones stay quiet, and a clean pull request gets a short, calm review.
How it is built and supported
plugged into the tools you already merge with
- Native to GitHub and GitLab
Rubberduckly joins the pull request or merge request thread, so comments, suggestions and checks live where your team already works.
- Reads your history
It learns from your repository’s past changes, so it knows which modules are fragile and which files change every week.
- One payment, then it is yours
Plans are paid once. No seat meter ticking up as your team grows.
- Answers from a human inbox
Questions go to help@rubberduckly.com and get a real reply from the people who maintain the product.
Where it is going
sharper reviews, then faster ones
deeper context
Comments that weigh a change against how the surrounding modules have behaved, so the explanation gets more specific over time.
reviewer load
A clearer view of which pull requests are waiting, on whom, and why, so bottlenecks show up before they become the retro topic.
fewer, better comments
Every release is judged by a simple test: did the review get quieter and more useful? If not, it does not ship.
Direction, not a promise of dates. We build in the open with the people who use it.
Your next pull request
give your reviewers the hour back.
Pick a plan, connect GitHub or GitLab, and open your next pull request with the explanation already waiting in the thread.