Md Mohosin Ali Shah

Posted on Mar 29

RepoLens Version 2 Ranked #7 on Product Hunt — Building AI for Code Change Intelligence

#ai #productivity #webdev #opensource

RepoLens Version 2 ranked #7 on Product Hunt this week.

That number was exciting, but what mattered more to me was what it represented.

It felt like a signal that this problem resonates with more people than just me.

Because RepoLens started from a frustration I kept running into again and again:

understanding a codebase takes too long.

When I opened a new repository, I would usually go through the same cycle:

open random folders
search for routes
trace imports manually
guess how modules fit together
try to understand the architecture from scattered files and tribal knowledge

That process was slow, repetitive, and mentally expensive.

So I built RepoLens Version 1 to solve that.

Version 1 was about helping developers understand a repository faster.

It could analyze repositories, detect stack and structure, map modules and dependencies, extract API endpoints, generate docs, support grounded repository chat, compare branches, and turn a codebase into something much more explorable.

That solved an important problem.

But while building it, I realized I had only solved the first half of the real pain.

Understanding a Repository Once Is Not Enough

A repository is not static.

It keeps moving.

Pull requests change behavior.

Endpoints shift.

Dependencies evolve.

Architecture drifts.

And teams are constantly trying to answer a harder question:

what changed, what was affected, and what actually matters?

That is where RepoLens Version 2 came from.

Version 2 is not just about repository understanding.

It is about change intelligence.

That shift changed how I thought about the product.

Instead of only helping someone understand a repository once, I wanted RepoLens to become useful inside the real engineering loop:

when a pull request opens
when a branch changes
when APIs move
when architecture starts drifting
when a team needs clarity before review or release

What Changed in Version 2

RepoLens Version 2 now focuses on helping teams understand change with more structure and more trust.

It can now:

analyze pull requests and generate engineering summaries
detect affected modules
detect changed endpoints
highlight likely review hotspots
support branch-aware and PR-aware repository chat
show exact code snippet references and confidence signals
run incremental analysis instead of full rebuilds every time
sync automatically from GitHub events
detect architecture drift
send alerts for important changes and failed analysis runs
track workspace usage and operational health

The product story became much clearer through this work:

Version 1: Know any repo fast
Version 2: Know what changed and what matters

That clarity was one of the biggest wins for me as a builder.

What I Learned Building It

One of the biggest lessons from building RepoLens is that generic AI output is not enough for engineering workflows.

It is easy to generate a summary.

It is much harder to generate something that engineers can actually trust.

That means the system has to do more than just “talk about code.”

It has to first build a structured understanding of the repository and its changes, then use AI on top of that structure to make the output more useful, grounded, and verifiable.

That has shaped almost every product decision in RepoLens so far.

I do not want RepoLens to be another tool that gives impressive-sounding answers without enough proof behind them.

I want it to help teams see:

where an answer came from
what changed
what was affected
what deserves attention

The Product Hunt Launch

Launching RepoLens Version 2 on Product Hunt and seeing it reach #7 was encouraging not just because of visibility, but because of the kinds of conversations it created.

The most interesting feedback was not about “AI” in the abstract.

It was about very practical engineering questions:

How do you handle overlapping PRs?
How reliable is changed endpoint detection?
Can this work beyond a single framework?
Which signals are actually useful in day-to-day development?

That is exactly the kind of feedback I hoped for.

It means the product is starting to move from “interesting demo” territory into “could this fit real engineering workflows?” territory.

That is the transition I care about most.

Where RepoLens Is Going

RepoLens started as a way to understand repositories faster.

Now it is becoming a way to understand change faster.

That feels like the more important problem.

Because teams do not just need help reading code.

They need help reasoning about evolving systems.

That is what I want RepoLens to keep getting better at.

DEV Community