Git Bisect for Mobile is Dead

I love git bisect

If you don’t know it, git bisect is basically a binary search for bugs. You have an issue that did not exist before, so you grab two commit hashes, one good and one bad, and build, repro, build, repro until you find the exact commit that introduced the bug.

git bisect Hates Mobile

Constant building and shifting of your dependency graph is a HUGE pain for mobile devs. Our builds can take multiple minutes, especially if we have to go to a previous release and we don’t have recent build caches. Git bisect requires a lot of builds. This can take a TON of time.

I was investigating an issue between two releases (release_8 and release_9) which had 1300 commits between them. This is about 11 bisect steps or:

• 22 minutes of build time with 2 minute builds

• 55 minutes with 5 minute builds

The reality is going to be some mix of these build times depending on which way the bisect goes. Regardless, this is a large amount of time to simply wait.

AI to the Rescue?

For this issue, we couldn’t reproduce it locally and didn’t have clear steps. Doing 10+ builds would’ve been a waste of time.

So instead, I grabbed a big diff.
We knew the bug appeared in the recent release but not the previous one:

git diff release_8 release_9

This command produced 413,032 lines changed.

Instead of bisecting I asked an AI Agent to look at this diff with relevant information from our issue. This only took a few minutes!

The AI analyzed the diff, grouped related changes, and surfaced a few areas that might be tied to the behavior we were seeing:

• Code paths that touched relevant data

• New conditions around feature flags

• etc.

No builds. No waiting. Just instant context.

Why This Works So Well

Bisecting exists because it’s impossible to reason about that much change at once. It helps us narrow the scope so we can test smaller chunks and confirm behavior step by step. That’s how we make the problem manageable.

This is exactly what large language models are good at. They can take in the full context of a change and reason about the entire picture at once.

Instead of checking each commit, I tell the agent to get the diff between good and bad commits and ask, “Given these changes and this bug, what looks connected?” and it points me towards areas of interest.

I’m still debugging, just with more context than I can hold in my head, and without having to wait for the compiler.

Try It Yourself

Next time you hit a tricky regression, grab an AI agent and look at a diff between the good and bad commits. Let it scan the changes and tell you what stands out.

git bisect still matters. When you can reproduce the issue cleanly and builds are quick, it’s the right tool. When the bug is vague or builds take forever, this approach can save a lot of time.