After AI Modifies Code, Read the DIFF Line by Line: 30 Seconds of Slow Work Saves Half a Day of Firefighting

Last time, AI helped me clean up a batch of cron scripts. It claimed, "All changes made, logic is equivalent." I trusted it and let it commit directly. That night, production alerts fired: two log lines in three scripts were silently swallowed—it had "unified" away the stderr redirections that included `-f`. Rolling back, investigating, and correcting took forty minutes in total. Since then, I’ve adopted a fixed habit: **After AI modifies code, read the DIFF line by line before taking any next steps.**

When You Must Read Line by Line

In four scenarios, the larger the DIFF, the less you should skim—not because bigger changes require carelessness, but because they demand *more* caution:

- Letting AI refactor or clean up "unused code" on the fly. Deleted lines are often more dangerous than added ones, especially `except: pass`, defensive `mkdir -p`, or variables that look unused but are actually kept for downstream compatibility.

- AI performs a "style unification" pass. Comment formats, log levels, environment variable prefixes—these "aesthetic changes" love to tangle with real logic changes, making it hard at first glance to distinguish which lines involved actual reasoning and which just got a new skin.

- Changes involving permissions, password paths, shell expansion, concurrency locks, and cross-file contracts. The probability that these changes "look fine" isn't zero; rather, ignoring them leads to trouble on the scale of "mismatches in forms requiring you to dig through billing records later."

- You need to hand off the changes for someone else’s review, or merge them into a shared repository. In this case, the DIFF mixes AI’s judgments with yours, making it hard for readers to identify which parts need focused attention.

When You Don’t Need to Read This Way

- Formatting only: You ran `prettier` or `black`, order hasn’t changed, and a quick scan confirms nothing was added or removed.

- Adding only one test file: If existing logic is untouched, a few clicks are enough to verify.

- AI only fills templates: Changes involve deterministic items like filenames, casing, or strings, which can be visually confirmed in ten seconds.

These scenarios deserve time savings, but the way to save time isn’t "not reading," but rather "quick scanning + line count reconciliation."

How to Spend Those 30 Seconds Wisely

1. First, run `git status` to confirm the file list matches what AI claimed it changed. Extra files are more suspicious than missing ones—the file list itself is the first layer of DIFF.

2. Run `git diff --stat` to scan the overall volume. For "net deletion" changes like "added 5 lines, modified 80 lines," focus heavily on what was deleted.

3. Read line by line, prioritizing by suspicion level: Permissions and sensitive fields > Control flow (if/else/loops) > Edge cases (empty inputs, empty arrays, out-of-bounds) > Strings and logs > Remaining context.

4. After reading, check critical integration points: Did the change connect properly with upstream/downstream components? The caller’s line wasn’t changed, but the modified function signature did. **AI excels at fixing the immediate line while forgetting the previous step.**

5. Run the local CI checklist: lint → tests → start service. If resources are tight, at least run `npm test`, but remember that "compilation success" and "local green" are two different things.

6. Only then commit. In the commit message, clearly state "what was done + why." Messages in typical AI style like "updated code" should be rejected outright.

Checklist (Pin to Your Terminal Sidebar)

- [ ] Changed file list = AI’s claimed list, no extras or omissions

- [ ] Every deleted line has a clear explanation for why it can be removed

- [ ] Silent fallbacks in `except` / `||` / `??` haven’t been "optimized" away

- [ ] Permissions, paths, and environment variables haven’t been renamed or moved

- [ ] Mixed Chinese/English text and encoding remain unchanged (don’t trap yourself with `BOM`)

- [ ] Local lint + tests are green; re-check after CI runs

- [ ] Commit message explains the rationale, not just `update` / `fix bug` / `chore`

Quick Notes on Common Pitfalls

| Pitfall | How You Step Into It | How to Avoid It |

|---|---|---|

| "Wait, I still need to install a package" | Didn’t run `npm install` locally; CI passes but local fails | Run `npm ci && npm test` before committing; don’t trust the editor’s little green dot |

| Leaving `useEffect` dependencies to AI | Added three `eslint-disable` comments, creating hidden pitfalls for a year | Auto-fix what `eslint --fix` can handle; manually review the rest |

| Pushing after only half-reading `git diff` | Changes hit `.gitignore` in workspace; AI quietly moved paths | Run `git status` + `git diff --stat` again before committing |

| AI merges if/else branches for "optimization" | Fewer visual lines, but network ordering changes, causing retry logic to jump erratically | Pause for a second when you see "looks more compact": Is it truly equivalent? |

Why Not Automate This Process?

Automation prevents syntax and type errors, not semantic ones. Among the pitfalls above, only linting catches one or two items; the rest rely on human reading. Spending thirty seconds is cheap—what’s expensive is the subsequent two hours spent patching bugs while cursing, "Who told you to touch that?" amidst the collateral fire.

In One Sentence

After AI modifies code, read the DIFF line by line; most accidents that thirty seconds can prevent don’t require you to invent any new processes.