You ship on Friday, things look fine, and on Monday morning a feature is suddenly broken. The clock starts ticking, and your only certainty is that the regression is hiding somewhere in the recent commit history. Staring at git log and guessing rarely ends well — especially when the wrong guess costs you forty minutes of fruitless build-and-click cycles.
After moving my bisect workflow into Antigravity and letting the AI ride shotgun, I have started closing these investigations much faster. This article describes that workflow, framed as a clear split between what to delegate to the AI and what to keep firmly in human hands.
Why git bisect alone tends to stall
Mechanically, git bisect is just a binary search through commits. The reason it stalls in real projects is rarely the search itself; it is the cost of judging "good or bad" at each step.
- Switching commits often means a fresh install of dependencies and a full rebuild
- Reproducing the issue requires the same UI clicks, API calls, or test runs every time
- A commit can look fine while subtly breaking something else you did not check
That repetitive judging step is exactly where AI assistance pays off. The judgment itself, however, is something I want to keep on the human side. Settling that division up front is what keeps a bisect session from drifting.
The "3 + 1" division of labor with Antigravity
Here is the split I keep coming back to:
- Delegate to the AI: running the reproduction at each step, primary triage of logs and stack traces, and summarizing the diff of each candidate commit
- AI drafts, I approve: a one-line note explaining why a step was good or bad
- Human-only: the final
good/badmark, the bisect range, and the eventual fix commit
The note-taking part matters more than it looks. Halfway through a bisect, you will eventually wonder, "wait, did I really see the failure on the last commit?" Asking Antigravity's Inline Chat to draft those notes in place gives you both an audit trail and useful raw material for the eventual PR description.
A 30-minute walkthrough — chasing a frontend regression
Imagine a Next.js app where, after login, the dashboard chart silently fails to render. Here is how I would attack it.
1. Bound the search
Recall the last point at which you remember the feature working. A rough memory is fine — the AI can help sharpen it.
# List the last two weeks of commits that might be relevant
git log --since='14 days ago' --pretty=format:'%h %ad %s' --date=shortPaste that list into Antigravity's Inline Chat with a prompt like:
"From this list, pick the commits most likely to affect the dashboard chart. Explain your reasoning."
Filenames and commit messages are usually enough to surface a starting point. That gives you a defensible good anchor — for example, "the release tag from two weeks ago."
2. Start the bisect
git bisect start
git bisect bad # current HEAD is broken
git bisect good v3.4.0 # last known good releaseAntigravity's terminal preserves the bisect state across other operations, which means you can fan out to logs or PR diffs without losing your place. This is more important than it sounds — half the reason bisect feels heavy in practice is that the moment you switch context to read a commit message, you forget which step you were on. Keeping the state and the workspace in the same place removes that friction entirely.
3. Have the AI run each reproduction
Each time the bisect checks out a new commit, hand the AI a single short instruction:
Build the currently checked-out commit, open http://localhost:3000/dashboard,
and confirm whether the chart renders. If it does not render, capture the error
and propose three hypotheses for the cause.The AI watches both the build output and the browser console, freeing you to think about strategy. I only step in to type git bisect bad when it confirms the failure.
4. Inspect the last 1–3 commits manually
Let bisect do the mechanical narrowing, then take over with git show for the final couple of candidates. With a small diff in front of you, the offending line is usually obvious within seconds. I usually open the candidate commit in Antigravity's diff view and ask, "what could this change break that is two layers away from the lines it touches?" Almost every regression I have hunted in the last six months has had its root cause one or two indirect calls away from the actual diff — a state shape change, a default value swap, an event order shift. The AI is good at surfacing those second-order effects when you ask explicitly.
Three prompts that pay for themselves during a bisect
These are the prompts I lean on most often. Copy them as-is.
Prompt 1: Translate the diff into user-visible behavior
Read the diff of this commit and summarize, in three bullets max,
how the user-visible behavior changes. Skip implementation details
and focus on outcomes.When the diff is large, this lets you triage where to look first.
Prompt 2: Distrust "looks fine"
The dashboard appears to render. Before I mark this commit as good,
please double-check:
- Is the chart element inserted into the DOM within 1 second?
- Are there any console errors?
- Does /api/metrics return 200 in the network tab?
If any of these is suspicious, lean toward "bad".A wrong good mark wastes thirty minutes of bisect. Wiring scepticism into the AI's checklist saves backtracking.
Prompt 3: Pre-rank the hypotheses before you confirm
Once the bisect range collapses, but before you commit to a final answer:
Assuming HEAD is the offending commit, give me three hypotheses for why
the chart fails to render, ranked by likelihood. I will verify the most
likely one first.Having the hypotheses in writing before you start the fix dramatically reduces aimless trial and error. As a small bonus, the same hypotheses tend to make excellent material for the eventual PR description and post-mortem — you already wrote them down.
If the surrounding git operations get tangled — merge commits, rebases, cherry-picks — you may want to read Resolving git conflicts with Antigravity's AI and Running parallel workspaces with git worktree in Antigravity. I usually keep the bisect and the eventual fix in two separate worktrees.
A small ritual that compounds over time
Before closing the bisect session, ask the AI to draft a one-paragraph "regression recap" with three fields: the commit hash, the change in user-visible behavior, and the smallest reproduction. Drop that paragraph into your repository's docs/regressions.md (creating the file the first time). After a year, this file becomes a quiet but powerful asset: when a similar symptom shows up later, you can grep for the keywords and skip half the bisect on day one. Antigravity's project-wide search makes this lookup trivial, and the file pays compound interest the longer you maintain it.
Failure modes worth knowing
A few traps I have walked into so you do not have to.
1. Old commits expect old environment variables or schemas.
Stepping back two weeks may mean stepping back to a different .env file or a pre-migration database. Before starting, ask Antigravity to summarize the diffs in .env.example and migrations/ across the bisect range, and prepare a temporary .env.bisect if needed.
2. git bisect run can be misled by flaky E2E tests.
Automated bisect is tempting, but a single flaky end-to-end test will mismark a commit and ruin the run. Verify the first few steps by hand, harden the reproduction script, and only then switch to bisect run. For more on E2E reliability, see Writing E2E tests with Antigravity's Browser Agent.
3. Do not auto-merge the AI's "I fixed it" patch. Once the offending commit is identified, Antigravity often offers a fix in the same breath. Convenient, but always cross-check that the file the patch touches matches the commit the bisect found, and that the original author did not write the original code that way for a reason. Skipping that step is how you trade one regression for another.
What to do next
The next time a regression lands in your repo, resist the urge to scroll through git log by hand. Instead, paste the last two weeks of commits into Antigravity's Inline Chat and ask which ones are most likely to touch the broken feature. That single move will compress the bisect's search range to something you can actually finish before lunch.
Keep the good / bad decision for yourself, hand the reproduction and triage to the AI, and the late-night bug hunts get noticeably shorter — that is the trade I would not give up.