RepoLens
Know what changed and what matters across your codebase
125 followers
Know what changed and what matters across your codebase
125 followers
RepoLens Version Two helps engineering teams understand what changed and what matters across repositories, branches, and pull requests. It analyzes PRs, detects affected modules and changed endpoints, highlights review hotspots, powers branch-aware chat with grounded code references, compares branches structurally, and sends alerts for important changes so teams can understand evolving codebases faster with more trust.
This is the 2nd launch from RepoLens. View more
RepoLens
Launched this week
RepoLens Version Two helps engineering teams understand what changed and what matters across repositories, branches, and pull requests. It analyzes PRs, detects affected modules and changed endpoints, highlights review hotspots, powers branch-aware chat with grounded code references, compares branches structurally, and sends alerts for important changes so teams can understand evolving codebases faster with more trust.
Free
Launch Team / Built With
Clipboard Canvas v2.0
Love the focus on structured understanding, but how do you plan to handle situations where multiple PRs touch overlapping modules? That could muddy the waters for teams relying on clear insights.
RepoLens
@trydoff That’s a really good point, and it’s exactly one of the problems I want RepoLens to get better at over time.
Right now the model is to keep analysis scoped to each PR’s actual diff and commit context, so even if multiple PRs touch the same module, the insight stays grounded in that PR’s changed files, affected modules, endpoints, and review signals, rather than mixing everything together.
But you’re right that overlapping PRs can still create ambiguity for teams. The direction I’m exploring next is cross-PR overlap detection: flagging shared modules, shared endpoints, and potential review/conflict hotspots across open PRs so teams can see not just “what this PR changes,” but also “what else is changing around it.”
That would make the insight much more useful in fast-moving teams where multiple changes are landing at once.
RepoLens
Knowing what changed and what actually matters across a codebase is a different problem from just reading diffs, and I don't think existing code review tools really solve it. The "what matters" part is doing the heavy lifting in that tagline. How does RepoLens decide something is worth surfacing versus noise?
RepoLens
@sourav_sheth1 That’s exactly the hard part.
RepoLens doesn’t treat “what matters” as a single AI guess. It combines structured signals like change scope, affected modules, dependency impact, endpoint changes, review hotspot heuristics, and branch/PR context, then grounds the output in extracted repository evidence.
So the goal is to surface impact, not just summarize diffs. Right now it’s essentially a ranking problem over repository and change signals, and that ranking layer is something I’m continuing to improve.
@mohosin2126 I tried signing up using GitHub and keep being redirected to the home page. I also tried signing up using an email address, it seems like the account was created, but when I try logging in with that account, I get a database error. Is anyone else encountering this issue or did I do something wrong?
RepoLens
@andrewdavidj Thank you for flagging this, and you didn’t do anything wrong.
The auth flow appears to be working normally for other users, so this looks more like a case specific issue rather than a general signup problem. It may be something related to how your session was created, completed, or stored in that particular attempt.
I’m sorry you ran into it. If you’re open to it, please try again in incognito mode or from another browser, since it may be related to a cached session or browser state. If it still happens, feel free to send me the email you used or a bit more detail, and I’ll look into your case directly.
jared.so
When multiple PRs touch overlapping modules, how does the analysis stay clear and avoid conflicting signals for reviewers? Really solid concept, congrats on shipping V2!
RepoLens
@mcarmonas Thank you, I really appreciate that.
Right now, the analysis stays scoped to each PR’s own diff, commit context, affected files, modules, endpoints, and review signals, so the goal is to keep the output grounded in that specific PR rather than blending multiple open changes together.
That said, overlapping PRs are definitely one of the more important edge cases, because they can create ambiguity for reviewers even if each PR is analyzed correctly in isolation. The direction I’m interested in pushing next is cross-PR overlap awareness, so RepoLens can flag when multiple open PRs are touching the same modules, endpoints, or architectural areas and surface that as an additional review signal instead of leaving reviewers to discover it manually.
I think that’s where this becomes much more useful for fast-moving teams.
Does it also give code recommendations? What to improve?
RepoLens
@natalia_iankovychnot as a primary feature yet, but the product is being built on top of the exact analysis foundation that would make those recommendations much more useful and trustworthy over time.
Congrats on the launch @mohosin2126 , I think a feature that could help get more client is just like stripe has a screenshot feature to for people to share MRR achievement on social media, you could have something similar where solo SAAS builders can share the timeline there product being built. If you can do that with a good UI/UX I think it work get traction
RepoLens
@talal_bazerbachi2 Thank you, I really like that idea.
A shareable “repository evolution” or “build timeline” view could be a strong way to make RepoLens more useful and more visible at the same time, especially for solo builders shipping in public.
Because RepoLens already tracks repository analysis history, branch changes, pull requests, and architecture signals, there’s a good foundation for turning that into a clean, social-friendly snapshot of how a product is evolving over time.
I think the key would be exactly what you mentioned: making it feel polished enough from a UI/UX perspective that people would actually want to share it.
That’s a really interesting direction. I can see it working both as a growth feature and as a useful product surface for builders.