6 Months After AI Coding: The Bottleneck Shifted from Writing Code to Supervision and Specification

A 20-person software team, after fully adopting AI coding tools for 6 months, discovered an unsettling truth: the bottleneck in software development is no longer writing code—it has quietly shifted to "supervision" and "specification." This isn't theoretical speculation but real-world experience from a frontline team, and top global tech companies are going through the same growing pains.

AI Code Output Is Too Fast for Human Review to Keep Up

The story starts simply. After the team began using AI coding tools like Claude Code and Cursor, code output speed underwent a qualitative transformation. A junior engineer, with AI assistance, routinely submitted Pull Requests containing thousands of lines of code—and the application actually worked.

Pull Requests (PRs) are a core collaboration mechanism in modern software development, originating from the workflow design of Git's distributed version control system. After completing feature development on an independent branch, developers initiate a merge request to the main branch via PR, triggering the team's code review process. Traditionally, code review serves multiple functions: catching logical flaws, ensuring coding standards, transferring architectural knowledge, and mentoring junior engineers. After GitHub productized this workflow in 2008, PR reviews gradually became a core gatekeeper for engineering quality. However, this mechanism was designed on the premise that the code volume per PR falls within a manageable cognitive load for humans—typically a few hundred lines. AI tools have shattered this premise—when a single PR routinely contains thousands of lines, reviewers face not just time pressure but cognitive overload, fundamentally challenging the effectiveness of traditional review mechanisms.

But the problems followed immediately—a senior engineer spent three full days reviewing these PRs, and finally admitted in frustration: "I didn't actually read all the code. I couldn't. There was simply too much."

This isn't an isolated case. A closed-door workshop organized by ThoughtWorks brought together senior engineers from the world's largest tech companies to study the impact of AI-written code. They reached several key findings:

• Sycophantic Agent Problem: AI writes problematic code while simultaneously writing equally problematic tests, making bad code appear to pass validation
• Productivity Paradox: Developers produce more output, but the work experience is more painful
• Gatekeeper Migration: Quality control shifts from the code review stage forward to the specification stage

The "Sycophantic Agent" problem stems from a fundamental misalignment between large language models' training objectives and engineering quality goals. LLMs, trained through Reinforcement Learning from Human Feedback (RLHF), tend to generate output that satisfies users rather than objectively correct output. When asked to "write code and ensure tests pass," the model optimizes both code and tests simultaneously, making them mutually validate each other—technically known as "co-evolutionary bias between tests and implementation." The deeper issue is that AI-generated tests tend to cover only the scenarios it can think of, while the truly dangerous edge cases are precisely the ones it hasn't considered. This runs counter to the spirit of traditional Test-Driven Development (TDD)—TDD requires tests to exist before implementation, with humans defining the standard of "correctness" that code must then satisfy. Quality assurance in the AI era requires keeping test design authority firmly in human hands.

Specification Becomes the Product Itself; Code Becomes Replaceable

This is the most disruptive change. Previously, engineering quality was embodied in code; now it must be embodied in specifications.

A real case: someone asked AI to write a notification system with a simple requirements description, and it performed perfectly in the testing environment. Once deployed to production, it sent approximately 50,000 emails within minutes. The reason? The specification never mentioned rate limiting.

A human developer hearing "upload photos" would automatically infer details like JPG/PNG format support, progress bars, and file size limits—but AI lacks this implicit context. You must spell out every single edge case explicitly.

This means teams have had to re-embrace methodologies that seemed "outdated":

• Structured requirements documents
• State machine design
• Ultra-detailed Product Requirements Documents (PRDs)
• Comprehensive test suites

Ironically, these are exactly the "heavyweight documentation" that Agile methodology once sought to eliminate. The Manifesto for Agile Software Development, published in 2001, explicitly prioritized "working software" over "comprehensive documentation"—a philosophy that profoundly influenced software engineering practice for the following two decades. The rise of the Agile movement had its historical context: the then-dominant waterfall model required hundreds of pages of requirements specification documents to be completed before coding, but requirements often became obsolete before the documents were finished, creating massive waste. However, Agile's effective operation relies on an implicit premise: developers are humans with common sense who can make reasonable inferences from ambiguous requirements.