AI 智能體寫程式時，審查變更邊界而非逐行檢查

When agents write most of the code, review becomes the slow step. Certify each change with the test suite, and place the human where a failure is expensive: what enters and leaves the working enclosure. A passing suite is the gate. The diff is the record of what shipped.

Greg Foster, co-founder of Graphite, described the shift from Copilot tab completion through sidebar director mode to headless background agents in September 2025 (episode 40). You message one on Slack or GitHub, wait, and a pull request comes back. Anush Elangovan, Corporate VP of AI Software at AMD, described shipping that volume once CI is green in April 2026 (episode 56). He had just checked a week at 6.5 billion tokens.

How do you review code when agents write most of it?

Approve with checks you can rerun, because a person can no longer assume they are re-reading a teammate's work. Greg used to trust that a colleague had written the change and that review was a second look. He now allows that the author may have held tab while looking at a phone, or that no human has read the code at all. He cites Facebook being quoted as doubling internal code changes per engineer over the past year, with another doubling expected soon. Graphite, which syncs and manages code changes for many companies, sees volume "strictly up into the right." He sketches the merge load as a jump from 20 changes a day to 50, or 100 once bots are in the mix, with conflicts and skew behind it. Longer changes draw fewer comments per line, a pattern he thinks a Google study found, and that he also sees in Graphite's data. A 10-line pull request gets something like five comments. Longer changes are where reviewers glaze over and reach for an LGTM. A 2,000-line change is where finding the bug means searching the whole diff.

Maybe like no human has ever read this code before. There's like a bot that just generated it. And now I'm the first person ever reading it.

Greg Foster, co-founder of Graphite, on Chain of Thought ep 40

After Code Gen: What Graphite … - Chain of Thought | AI Agents, Infrastructure & Engineering - Apple Podcasts

Podcast Episode · Chain of Thought | AI Agents, Infrastructure & Engineering · September 24, 2025 · 55m

podcasts.apple.com

What does the test suite replace in the review loop?

It replaces line-by-line inspection as the check that decides. Anush gave this advice before agents: 80% of your time should go to tests, and the test framework should exist before the first line of code. His issue agent requires a test for every fix before committing. It watches one tracker, writes a test for the fix, and only then commits. If CI is green, it can ship. He will not hold that ship for a person to read every line. When he disagrees with the result, he does not argue the diff. He adds a requirement the suite can fail. In his virtual GPU simulator, that requirement is a dispatch budget of 50 microseconds in simulator time. A miss sends the agent back to refactor on its own. He does not want to be the one who decides when a refactor is due.

Testing is the code review and testing is kind of the gate of your sandbox. If you have a complaint about anything in the box, fix the sandbox, right?

Anush Elangovan, Corporate VP of AI Software at AMD, on Chain of Thought ep 56

80% of your time should be spent on tests and writing tests. Even before you write your first line of code, you should have a test framework.

Anush Elangovan, Corporate VP of AI Software at AMD, on Chain of Thought ep 56

Where should the human sign off when volume makes line-by-line review impossible?

Sign off at the enclosure wall, and keep each change small enough to review. Anush's agents run inside a geo-distributed rig on a Tailscale network he controls, with redundant power and different AMD hardware variants. The rig can log into machines, exercise Windows or Linux, and continue the work. He reviews what goes in and what comes out. He also keeps the jobs narrow. He would rather schedule a focused agent than let agents spawn their own thread pool. The tracker agent wakes, fixes what it can, and hands back anything it cannot resolve. His hours go to the plan and the tests. On a demand-paging task he stopped an agent that wanted to implement everything, asked for 100 tests of corner cases, and then read them. Some were repetitive parameter tweaks, and he judged that if the set passed, the feature was good. The scope he gives up front is narrow: name the layer, name the cases, then implement.

Stacking is Greg's way to keep that review possible. He attributes it to Facebook and traces it to commit-by-commit Git: one small change, then another on top of it, reviewed and tested one at a time. CI runs at that grain, so a failure points at one diff. He says AI "really likes" stacking. Agents start to apply chain-of-thought across the stack, creating the function, then the unit test, then the endpoint, and they build that better than a single large change. A reviewer can take the first diff while the agent writes the second, and can bring in a subject-matter expert per layer. His picture of the job is a person on the input and a person on the output, with the agent in the middle. On the input, strong engineers write a markdown design doc and only then ask the agent to implement it. On the output, review is where security and codebase context still get absorbed. If the team did not absorb that context while writing, review is the remaining place it can land.

A minimal sketch to adapt, not a drop-in library.

def boundary_review(plan_doc, test_suite, change, human_sign_off):
    if not test_suite.run(plan_doc.tests):
        return "fix the sandbox"
    if change.crosses_enclosure() and not human_sign_off("entry or exit"):
        return "wait"
    return "suite passed; keep the diff as evidence"

FAQ

Does this mean humans stop reading code entirely?
No. Reading moves to the plan, the tests, and the enclosure boundary. Greg still wants a person on the way in and the way out, including for security and for context the team would otherwise lose. Anush still reads the test cases. He treats generated lines as lower priority once those cases pass.

What if the tests themselves are wrong?
Fix the suite before you blame the agent. Anush treats a complaint about anything in the box as a missing check. State the requirement so a test can fail it, then let the agent iterate.

Can a team use this without many agents in parallel?
Yes. Anush says developers do not need multi-agent flows for agents to make their life easier. Decide what the tests must prove, keep each diff small, and spend your time on the plan and the suite. The human sign-off stays where a bad change would be expensive to undo.

Takeaway

• Put a test framework in place before the first line of agent-written code.
• Require a test with each fix, and treat a green suite as the ship gate.
• Review what enters and leaves the enclosure, including security-sensitive paths.
• Scope each mission in writing, and read the generated tests before the agent implements.
• Stack small diffs so review, CI, and the agent all work one change at a time.

The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.

Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.

Drafted with AI assistance from the episode transcripts.