Wink Pings

From 126 comments to 0: a developer turned off review for AI code

Martin Gratzer removed human code review from the process, and the agent now merges low-risk PRs on its own. People moved from the middle to both ends: define the problem clearly up front, then build the system robustly afterward. He brought in a civil engineer who doesn't know how to code to run an experiment: 85 PRs in five weeks.

In January, Martin Gratzer wrote 126 inline comments on 25 PRs in Colorburst. In September and October, there were 159 PRs and zero comments. His new project Tandler has only three handwritten comments in total, all on the earliest PR.

These numbers come from his own tracking. It is not that the agent no longer makes mistakes; it is that the problems he could catch are largely caught first by the agent and the systems around it.

He gave two examples. In the Colorburst quota change, reviewers in two fresh contexts found that a test fixture used a pricing tier that did not exist; the tests were all green, but the free tier was not tested at all. In another dependency update, an adversarial review hit the SVG sanitizer with 30 crafted payloads and found three bypass paths. Both problems were fixed within the PR before a human had even looked at the diff.

二月和十月的工作流对比:左边人处在中间,右边人处在两端

In the diagram, the left side is the February process: a human plans the issue, the agent implements, the human self-checks, and the human reviews the diff line by line. The right side is October: the human first shapes the problem, the agent implements and runs it in a fresh context, guard pushes CI and review feedback forward, and land makes a risk determination for green PRs, automatically merging low-risk ones. The human moved to both ends.

To make the evidence not come only from himself, he brought in a friend for an experiment. Andreas is a civil engineer who shares an office with him and had an idea in the industry that had been sitting around for a long time. Martin showed him Claude, and he built a prototype with Claude Cowork. The functionality worked, the interface was presentable, and potential customers were excited when they saw it.

But underneath was a classic vibe-coding disaster: at first there was no git, no CI, one giant index.html stuffed with inline JavaScript, and every query read nearly 1GB of data because no one had told him that geospatial data should use PostGIS.

Martin rebuilt it from the prototype and wrapped it in the structure of his own projects: linting, dead-code and duplicate-code detection, import boundaries, migration checks, high coverage requirements, and a pipeline that deploys to a VPS on every commit. Then he handed it over to Andreas and Forge. Andreas does not look at the code, and would not understand it anyway.

In the first five weeks, Andreas opened 85 PRs, each about a thousand lines. In September, Martin approved 45 of his 48 PRs. He admits that many details relied on Claude's /code-review, with the results pasted under his own name and then a fix PR opened. Simon Willison calls this meat proxy review, a human proxy review. What was truly useful was finding patterns across PRs and then turning those patterns into guardrails.

Forge's changes grew out of this. Three steps:

/forge-setup-project   # 每个仓库一次:生成 AGENTS.md 和 agent 工作用的文档
/forge-ship 42         # 实现 Issue #42,跑一遍,在新上下文里 review,开 PR
/forge-ship --guard 42 # 继续推进:CI、review 反馈,最后给风险判定

ship implements the issue, then actually runs the application, and writes what it saw into the PR's Exercised section. The reviewer is another context, not the session that wrote the code. guard pushes the PR to a reviewable state unattended, but it never merges, because a loop that can fix its own PRs should not also have approval authority. land is the newest; it judges risk on the head commit: mechanical checks run first—size, migrations, CI changes, security-sensitive paths, weakened tests. Only if none of these hit can the verdict be low risk, and only if the reviewer can say what the checks would miss. Otherwise the PR gets a where-to-look list, each item a file plus a question.

He turned on auto-merge for a few days on Colorburst, Tandler, and Andreas's project; it is too early to tell whether land judges accurately. Of Andreas's first six PRs, two were judged low risk. Of the four that needed a human, one asked whether the code correctly understood a clause in the building code, and only Andreas could answer.

What finally made him decide to change Forge was seeing others arrive at the same place within a few weeks. Anthropic's Claude Code team optimizes for the least human review time without increasing rollbacks and incidents; low-risk changes with all checks green need no human approval, on the grounds that the change sets the tier, not the author. Will Larson's team at Imprint built small-change, where CI decides whether a PR qualifies, and the review skill can only approve or ignore—letting one mistake through counts as a system failure. Gergely Orosz calls what remains in many places zombie code reviews. The Amp team simply does away with PRs. The risk profiles are very different, but the direction is the same: take people off the default path and spend their attention on risk.

There is a counterexample worth remembering. After swapping the image model, Colorburst's new templates had no title and tags for five consecutive weeks, and CI stayed green because the tests hard-coded the model response. Reading those PRs would not catch it either; the fix was to add another guardrail: run a live contract test against the real model. Structure makes trust possible, but structure itself can also deceive.

The limitations are also stated clearly. These are all single-person projects, with no team and no compliance. Gergely found that other fully automated review cases were also side projects, one-person companies, and very early-stage startups. Work involves compliance, and also knowledge sharing: if no one reads what ships, no one understands what ships.

Martin's framing is that the human is still in the loop and still in control. They just spend less time reading diffs and more time at both ends: shaping the issue, sparring with the agent, asking dumb questions, puncturing both sides' assumptions until what should be covered is covered. At the other end is tending the system: wherever it drifts, wherever something could have been avoided, that is where you add guardrails.

In February he wrote that planning is the step where humans add the most value. That still looks true. No one is in the middle; people are at both ends.

发布时间: 2026-10-27 21:32