GitHub 新增空白字元偏好設定：如何分兩輪審查 AI 生成程式碼

A cleaner diff can help you understand a change. Before you merge, check what your review settings left out.

You ask AI to fix one bug. It returns a change that also reformats half the file.

Now you have two problems: understanding the fix and finding everything else that moved.

On October 22, GitHub announced saved whitespace preferences for pull-request reviews. You can keep whitespace visible, hide it across reviews, or hide it for one diff. The update also gives new and deleted files the full width in split view.

That is a useful change for anyone reviewing AI-generated code. A noisy diff can bury a tiny behavioral edit. But a quieter view is still a view you selected.

My practical lesson: use one pass to understand the change and a second pass to check its completeness. Your review settings belong in that process.

First, write down the intended change

Before opening the diff, describe the behavior in one sentence.

For a fictional appointment app, that might be: “Reject an end time that comes before the start time, and keep the user's entered values visible.”

You now have something to compare against the patch. A rewritten navigation menu or a new analytics dependency needs an explanation, even if the assistant calls it cleanup.

If you want help turning a feature request into a bounded task, my $3 AI App Builder Starter Prompts give you a guided starting point. The immediate job here is small enough to practice on your next change: state the intended behavior before judging the implementation.

I would also ask the assistant to separate formatting from behavior where practical. That makes review easier, but it does not prove that either change is safe.

Pass one: understand the behavior

Open the changed files and look for the part that implements your sentence.

If whitespace churn makes that difficult, hide whitespace temporarily. Read the conditions, the values being compared, and the error path. Ask yourself what happens when the user corrects the time and tries again.

GitHub's new preference can save you from choosing the same setting repeatedly. Its active filter also gives you a way to restore whitespace for the current review without replacing your saved preference. The announcement says displayed file counts and diff statistics follow the filtered view.

That last detail is why I would avoid using the visible change count as a completeness check while a filter is active.

Write a short behavior note instead: “The validation runs before saving; invalid input keeps the form open; correcting the input allows a save.” If you cannot explain the path, ask for clarification before approving it.

Pass two: restore the missing context

Show whitespace again. Clear any file filters you used, and inspect the complete set of changed files, including additions and deletions.

This is where you look for changes that were easy to overlook during the focused pass: a configuration edit, a deleted test, an altered text template, or an unrelated file that was reformatted.

Whitespace is not universally cosmetic. Python's language reference explains that leading whitespace determines statement grouping. Moving an operation outside a conditional can change when it runs while leaving the operation's words intact.

For the appointment example, imagine a save operation that should run only after validation succeeds. An indentation change could move it outside that condition. Inspect the complete function, then test an invalid appointment and confirm that nothing was saved.

I am not claiming that GitHub's filter necessarily conceals that exact example. The broader engineering point is that a whitespace option does not understand every consequence of your program. You still need to reason about the resulting file.

Keep review coverage separate from proof

GitHub's review guide recommends examining files individually and supports marking them as viewed. I would use that progress tracking after the relevant inspection, rather than treating a collapsed file as evidence that its behavior works.

For our fictional fix, a useful review record would name three things:

• Intent: invalid time ranges cannot be saved.
• Coverage: the complete diff was inspected with whitespace visible after the focused pass.
• Behavior: invalid input failed safely, corrected input saved, and the saved record contained the expected times.

Those statements answer different questions. Reading the patch helps explain it. Running the app checks a path through it. Neither guarantees that every possible failure has been found.

When two passes cost too much

A second pass adds attention and time. That tradeoff matters when the patch is large.

My response would be to shrink the change before asking a beginner to review it. Request a separate formatting change, a narrower bug fix, or an explanation for unrelated edits. Splitting work has its own coordination cost, so use judgment for tiny changes that are already easy to inspect.

The rule I want to keep is simple: a convenient review view should not silently become the boundary of what you checked.

On your next AI-generated patch, write the intended behavior, use a focused view to understand the edit, restore the full diff, and run one concrete failure path. Record anything you could not verify before deciding whether to merge.

A guided next step

The $3 Starter Prompts help you frame the next task. The $9 AI App Builder From Zero e-book provides an organized path from an app idea to publication. The $10 learning bundle includes both complete resources.

Bootcamp Bundle (Review Radar) is coming soon; checkout is closed. See the preview and manually request waitlist updates by email.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim