How to Find Which AI-Generated Change Broke Your App Using Git Bisect

Quick answer

• git bisect binary-searches your commit history to find the exact commit that introduced a bug.
• You only need a yes/no test for the bug — no code reading required.
• Perfect for AI workflows: the AI made 15 commits, you don’t know which broke it, bisect finds it in log₂(15) ≈ 4 steps.
• Full system: How to Debug AI-Generated Code: A Complete System

The scenario: AI made commits, now something’s broken

You worked with an AI assistant for two hours. It made commits. The app worked. You went to sleep. Next morning, something’s broken. You don’t know which commit introduced the bug because you accepted the AI’s changes without reviewing every one.

Git bisect solves this. It’s a binary search through your commit history. Instead of reading 15 commits, you test 4.

Step-by-step walkthrough

1. Start bisect

git bisect start

2. Mark current commit as bad

git bisect bad HEAD

The bug exists right now. Mark it.

3. Find a known-good commit

git log --oneline -20

Find a commit from before the bug appeared. The commit message might help — look for “refactor,” “add feature that’s now broken,” or pick a commit from yesterday when things worked.

git bisect good a1b2c3d   # use the commit hash from when things worked

4. Git checks out a midpoint commit

# Git automatically checks out a commit halfway between good and bad.
# Terminal shows: "Bisecting: 7 revisions left to test after this"

5. Test for the bug

Run your app and trigger the bug. Does it happen?

# Start your app
python app.py

# Or run a specific test
python -m pytest tests/test_broken_feature.py

# Or hit the API
curl http://localhost:5000/api/broken-endpoint

# If the bug exists on this commit:
git bisect bad

# If the bug does NOT exist on this commit:
git bisect good

6. Repeat until Git identifies the commit

Bisecting: 7 revisions left to test after this
Bisecting: 3 revisions left to test after this
Bisecting: 1 revision left to test after this
Bisecting: 0 revisions left to test after this
a3f5e7d is the first bad commit

7. Examine the commit

git show a3f5e7d

# Or just the diff for the file you care about:
git diff a3f5e7d^ a3f5e7d -- src/broken_module.py

Now you know exactly which change caused the bug. Read that diff. It’s one commit’s worth of changes — manageable.

8. End bisect

git bisect reset

This returns you to your original branch.

Writing an automated bisect test

If you can script the bug detection, Git will run bisect automatically:

#!/bin/bash
# test-for-bug.sh — exits 0 if good, 1 if bad

# Start the app in background
python app.py &
APP_PID=$!
sleep 2  # wait for startup

# Trigger the bug
RESPONSE=$(curl -s http://localhost:5000/api/users/42/orders)
kill $APP_PID

# Check if the response contains the bug symptom
if echo "$RESPONSE" | grep -q '"orders":\[\]'; then
    # Bug exists — orders should not be empty
    exit 1  # bad
else
    exit 0  # good
fi

Then run:

git bisect start
git bisect bad HEAD
git bisect good a1b2c3d
git bisect run ./test-for-bug.sh

Git runs the script on each commit and finds the exact commit automatically.

When the AI-generated commit is a giant blob

AI assistants sometimes commit “add feature X” with 500 lines across 12 files. That’s not a helpful commit — but bisect still works. It tells you which 500-line blob introduced the bug. Then you compare the broken and working states:

# Show the diff for just the file containing the broken function
git diff a3f5e7d^ a3f5e7d -- src/orders.py

# Or interactively explore changes
git difftool a3f5e7d^ a3f5e7d -- src/orders.py

If even the single-file diff is too large, git bisect has done its job — it’s narrowed a 15-commit history to one. Now use the isolation technique from the main debugging guide to narrow within that commit.

What bisect can’t find

Bisect finds the commit that introduced the bug. It cannot:

• Fix the bug (that’s the debugging guide)
• Find bugs that existed before any commit in your history
• Find infrastructure or configuration issues (database schema change, env var change, dependency upgrade)

If bisect says “all commits are bad,” the bug predates your git history, or it’s not in the code — check environment, database schema, and dependencies.

Where this bites vibecoders

The AI made changes. Something broke. The vibecoder stares at 15 commits with messages like “update” and “fix.” Instead of reading them all — or worse, asking the AI to “fix everything” and creating more chaos — bisect finds the commit in 4 tests. Then the vibecoder reads one diff, understands the change, and fixes surgically.

Related topics

• How to Debug AI-Generated Code: A Complete System
• How to Debug AI-Generated API Logic
• How to Debug AI-Generated Database Queries
• What Is Version Control (and Why Do You Need It)?
• How to Resolve a Git Merge Conflict
• How to Write a Good Git Commit Message