Before and After Changes, Manually Verify the DIFF: The Hidden Costs of Minor Changes

Specific Scenarios

You ask an AI to modify a configuration file, or you manually tweak an `if` branch. The moment you hit "Save," three things happen:

1. That specific line is indeed changed as expected.

2. Two adjacent lines you didn't notice had formatting errors, which have now subtly changed.

3. An extra blank line is added at the end of the file, causing a false positive for "new additions" in the next diff.

The code passes, and the logic is correct, but during the next code review, someone asks, "What is this blank line for?" and you can't answer. **Verifying the DIFF before and after changes is precisely how you catch these issues.**

When to Use It

- **The change is small** (within the same file or adjacent files, ranging from a few lines to dozens), but involves shared resources.

- **You are unsure if your OS or AI tool will inadvertently modify lines you didn't intend to change** (formatters, automatic line wrapping, BOM handling).

- **The code is about to be committed**, and you want to do a self-check before others review it.

- **After letting an AI modify code**, you claim to have reviewed it line-by-line but haven't used a diff tool for final confirmation.

- **The file has undergone multiple rounds of modifications**, and you are finally merging, but want to ensure all historical changes are still intact.

When You Can Skip It

- You clearly know what you are changing; the modification is pinpointed and does not involve shared state.

- Your automated CI already has a diff stage, and its rules align perfectly with your expectations.

- You only modified pure documentation, comments, or blank lines, without affecting logic.

- You have full manual control over the file's fixer/formatter, and the CI does not block based on diffs.

How to Do It (3 Steps)

Step 1: Take a Snapshot Before Changing

Before making any changes, use a command to freeze the current state of the file:

cp path/to/file.yaml /tmp/file-before.yaml

Step 2: Unified DIFF After Changing

Once the changes are complete, run a diff and visually inspect it:

diff --unified=3 /tmp/file-before.yaml path/to/file.yaml

Focus on answering these questions:

- [ ] Are the added lines exactly what I intended to add?

- [ ] Are the deleted lines exactly what I intended to delete?

- [ ] For modified lines, is the change minimal?

- [ ] Are there any changes in lines I didn't touch at all? (Formatting, blank lines, BOM)

- [ ] Does the file end correctly? (No extra blank lines / proper ending)

Step 3: Fix Based on DIFF, Then DIFF Again

After discovering unintended changes, fix them to match your expectations, save, and run the diff again.

The goal this time is: **To confirm that your final changes match your intended changes exactly—no more, no less.**

Checklist (Review Before Committing)

- [ ] I have listed every line (or group of lines) expected to be touched by this change.

- [ ] Every line change in the actual diff is included in my expectation list.

- [ ] No lines that I completely untouched appear in the diff.

- [ ] The file ending format is correct (no extra blank lines, BOM status matches the original file).

- [ ] If the file has a formatter (or lint rules), I haven't passively allowed content formatting changes after committing.

- [ ] If this change involves multiple files, I have performed the same 3 steps for each file.

Common Pitfalls

| Pitfall | Symptom | Fix |

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

| Accidental deletion of blank lines | Diff shows changes in blank lines, and you can't see why | Align before/after snapshots and verify byte-by-byte |

| BOM changes | Some editors/CI add/remove UTF-8 BOM; differences are only visible in hex | Use `xxd path/file \| head -1` to compare the first 3 bytes before and after |

| Line ending changes | LF vs. CRLF differences; standard diff won't flag this as an error | Use `file path/file` to check line ending types and ensure consistency with the original |

| Passive formatter triggering | Saving triggers auto-formatting, resulting in unexpected format changes | Disable editor auto-formatting, or run diff again after formatting |

| AI making incidental changes | While modifying code, the AI also "tidies up" comments, blank lines, or code order | Explicitly instruct the AI to only modify specified lines, then verify with diff |

An Example

# Before change: /tmp/file-before.yaml
server:
  host: 127.0.0.1
  port: 8080
  # Cache configuration
  cache_enabled: true

# Intended change: Only change port to 8081
# After change (done by AI):
server:
  host: 127.0.0.1
  port: 8081
  cache_enabled: true
deleted_key: something_unused

# Diff result:
#   @@ -2,5 +2,5 @@
# -    port: 8080
# -    # Cache configuration
# -    cache_enabled: true
# +    port: 8081
# +    cache_enabled: true
# +deleted_key: something_unused

The intended change was only 1 line (port 8080 → 8081), but the actual diff shows 3 changes: the comment was deleted, and `deleted_key` was added. **If this file reaches reviewers in CI, you will be asked, "Why is this comment missing?"**

Spending 5 minutes to manually verify and fix it is much better than being questioned during a review later.