No More Code Reviews, Only Spec Reviews: Where the Agent Pipeline Gets Stuck First

Someone on X relayed the latest development process at a frontier lab. There are six points in total, and this is secondhand information. The gist is: most code is written by agents according to specs, and humans no longer review code, only specs; agents assign a risk score to each PR, low-risk ones are auto-merged, and only high-risk ones bring in a human; if CI fails, agents automatically fix it in the background; most PRs will not be merged, and agents continuously weed out bad code and bad tests; the code volume has grown so large that Git/GitHub cannot handle it, so the team simply built their own system.

First, some background. A spec is a specification, a PR is a code merge request, and CI is continuous integration. For readers who do not write code, you can think of a spec as a construction blueprint, a PR as a construction section awaiting acceptance, and CI as the automated check after each submission. The original poster’s judgment is that software development will become an assembly line like manufacturing, and what is scarce will no longer be the ability to write code, but the ability to write system design and design evaluation systems. This judgment is appealing, and it pushes the question one step further: for the assembly line to run, who writes the quality-control standards?

The replies are closer to the reality than the main post. User Gabe mentioned that reviewing only specs sounds elegant, but in practice the ambiguity rate of specs and missing edge cases are the new bottleneck; bad code written by agents from vague specs still requires humans to go back and clean up the mess. User byteswim asked more directly: when the production system has a major bug, an outage, or a security vulnerability, who is responsible, and how do you find the person? User viest focused on the risk score: who calibrates this step, and the proportion of low-risk auto-merged PRs that later turn out to have bugs is exactly the number this process should watch most. User Jack Ma questioned agents automatically eliminating bad tests: who sets the elimination standard? Another user, A_shen, asked where programmers will train their taste in the future. These replies do not deny efficiency; they point to the same thing: the point at which errors are discovered has moved later.

The picture is not hard to imagine. CI is showing red, and agents are queued in the background to fix it; there are so many PRs that the GitHub page spins, and the team builds its own code hosting; risk scores act like turnstiles, letting low risk through and pulling in humans for high risk. What is saved is the time of reviewing code line by line; what is put at stake is spec quality and the evaluation system. If low-risk auto-merge is misjudged, the bill will not show up at merge time; it will show up in the incident group chat. At that point, the risk score will not take the blame; the person who signed off will. The original post says agents continuously weed out bad code and bad tests, which sounds like automated dredging, but the elimination standard itself also needs to be evaluated. One commenter joked that it does not matter if you write a pile of crap code; just wait for the next-generation frontier model to fix it. That line is funny, and it also exposes the boundary of the assembly line: models can fix code, but responsibility cannot be auto-merged.

So what is truly scarce in this process may not only be people who can write system design and evaluation systems, but also people who can calibrate the evaluation system. Only when specs are written clearly can risk scores be targeted; only when risk scores are calibrated can auto-merge not be gambling; only when incident accountability is clear can the assembly line dare to run fast. Software development is indeed moving closer to manufacturing, but a factory is not without quality control, and quality control is not just the phrase low-risk auto-merge. The original post link is here: original post.