AI 程式碼審查應該閲讀哪些程式碼？

Originally published on anton.qa.

A reader asked whether more files change a review's verdict. Or do they mostly increase confidence in the same finding?

Relevant code can reveal a problem the edited lines cannot explain alone. Start with the behavior the change should preserve. Then read the code that depends on it.

An AI review asks a model to inspect code. This fictional example explains what useful context can add. It is not an AI review experiment.

Two parts need different orders

A queue is a waiting list. Our fictional program receives jobs in arrival order.
The runner chooses the next job. It must choose the earliest ready job.

The screen has a different requirement. It should show ready jobs from shortest to longest.

These are the exact example inputs:

const queue = [
  { id: "J1", ready: false, minutes: 1 },
  { id: "J2", ready: true, minutes: 10 },
  { id: "J3", ready: true, minutes: 2 },
];

J1 arrived first, but it is not ready. J2 arrived before J3, so the runner needs J2.
The screen should show J3 before J2 because J3 has the shorter estimate.

The example uses unique job IDs and distinct, positive minute estimates. Invalid inputs are outside this small illustration. No job runs here.

Start with the shared function

A function holds reusable code. A shared function serves several parts of a program.
A caller is code that uses that function.

Our three fictional files are ready-jobs.js, queue-screen.js, and runner.js.
The snippets show their relevant parts, without installation or a downloadable project.

The shared function in ready-jobs.js keeps ready jobs:

function readyJobs(jobs) {
  return jobs.filter(job => job.ready);
}

Here, filter keeps matching items in their existing order. It returns a new array, meaning a separate list.
The ready-job order is J2, then J3. The original queue stays unchanged.

The screen currently uses that order in queue-screen.js:

function visibleJobIds(jobs) {
  return readyJobs(jobs).map(job => job.id);
}

Here, map turns each job into its ID. The screen therefore lists J2 before J3.
It needs the opposite order for this input.

A small shared edit changes the order

The requested change is simple: show shorter ready jobs first on the screen.
One possible edit adds sorting to the shared function:

 function readyJobs(jobs) {
-  return jobs.filter(job => job.ready);
+  return jobs.filter(job => job.ready)
+    .sort((a, b) => a.minutes - b.minutes);
 }

The comparison puts smaller minute estimates first. The function still returns both ready jobs.
Its new order is J3, then J2.

That satisfies the screen's requirement. The edited lines alone leave other callers unverified.
We still need to know whether another caller depends on the old order.

Read the caller that chooses a job

The relevant code in runner.js chooses the first item:

// jobs arrive in queue order.
// Choose the earliest ready job.
function nextJobId(jobs) {
  return readyJobs(jobs)[0]?.id ?? null;
}

The [0] reads the first item. The remaining expression returns its ID, or null when no item exists.

Before the edit, this caller returns J2. After shared sorting, it returns J3.
J2 arrived earlier and was ready. Choosing J3 violates the runner's stated rule.

The caller makes the ordering change meaningful. We can now name the defect and its consequence.
A list with the same items can still produce different behavior.

Keep sorting in the screen

Leave the original shared function unchanged. Sort its returned list inside the screen's caller:

function visibleJobIds(jobs) {
  return readyJobs(jobs)
    .sort((a, b) => a.minutes - b.minutes)
    .map(job => job.id);
}

The screen gets J3, then J2. The runner still gets J2.
Sorting this separate filtered list leaves the input queue unchanged.

This correction meets both stated requirements for the supplied input.
Empty input and a list without ready jobs return no selected job.
One ready job remains the runner's choice.
These simple cases do not establish behavior for every possible input.

Ask what the extra file explains

The useful question here is whether another caller depends on order.
The runner answers it. Its requirement explains why that dependency matters.

Relevant context can therefore change a finding. Other context might confirm an assumption and strengthen confidence.
This example cannot tell us how often either happens. It supplies no measured verdict-flip rate.

There was no earlier AI approval or later AI rejection. The example follows the code's stated behavior.
Reading unrelated files adds no demonstrated benefit here.

For your next review, pair the changed code with its intended behavior.
Find the callers that use the changed result. Include a focused test when it demonstrates that dependency.

If a file answers no relevant question, explain why you want it included.
More input alone does not establish a better review.

One supporting example comes from Robin, my code-review project. Version 2.12.2 omits encoded binary payloads, meaning non-text file contents.
This applies only to native fallback patches, Robin's backup lists of file changes.
The later v2.12.3 keeps the model's private reasoning details when reusing earlier conversation messages.
That is a different correction. These release notes provide no measurements of speed, cost or review quality.

Give the reviewer a specific question

Ask what behavior could change, then read the code that depends on it.
For this example, the question is whether sorting changes the runner's next choice.
The caller provides the missing connection.

The original reader discussion is on LinkedIn.

I'm Anton. I build AI tools and measure how fast they really run. Former Apple engineer. I make ollamatps.com and write about building and measuring AI at anton.qa.