AI Wrote 800 Lines. How Much Should Actually Ship?

An AI agent wrote 800 lines of code. How much of it should actually ship?

Only the code that is needed to meet a written requirement, is covered by tests that would fail if it broke, and that a reviewer on your team understands line by line. Everything else, including speculative helpers, duplicated logic and unused branches, should be deleted before merge. There is no fixed percentage; the right amount is whatever the requirement needs and no more. An 800-line diff is also a signal that the task was too big for one pull request.

More code is a cost, not an output

AI coding agents make writing code cheap. They do not make reading, reviewing, testing, securing or maintaining it cheap. Every line that ships is a line someone has to understand during the next incident, the next upgrade and the next feature. That is why we treat the size of an AI-generated diff as a cost to be justified, not as a measure of progress.

The best evidence on this comes from DORA, Google Cloud's long-running software delivery research programme: its 2024 report found that AI adoption improved individual productivity, flow and job satisfaction, but negatively affected software delivery throughput and stability, and it concluded that fundamentals such as small batch sizes and robust testing remain crucial.

Why agents overproduce

• They solve the problem they imagine, not the one you have. Without a precise requirement, an agent fills gaps with plausible features: extra configuration options, retry logic, caching or admin screens nobody requested.
• They don't know what already exists. An agent that hasn't found your existing date helper or permission check will often write a new one, so the codebase ends up with two slightly different versions of the same rule.
• They stop when the work looks done. Anthropic's Claude Code documentation makes this point directly: without a check it can run, looking done is the only signal the agent has. Plausible-looking code that misses edge cases is the result.
• Review prompts can make it worse. The same documentation warns that a reviewer asked to find gaps will usually find some, and that chasing every finding leads to extra abstraction layers, defensive code and tests for cases that can't happen.

Step 1: requirements first, then code

Most of the 800 lines that shouldn't ship were never asked for. The cheapest place to remove them is before they exist. Before an agent writes anything, write down in plain language what the change must do, who is allowed to do it, what is explicitly out of scope, and how you will know it works. Anthropic's guidance recommends a similar sequence: explore the code, agree a plan, then implement, and it notes that the most useful specs state what is out of scope and end with a verification step.

Step 2: tests are the definition of done

Turn each acceptance criterion into a test before or alongside the implementation, and include the unhappy paths: the wrong user, the empty list, the oversized input, the expired session. Then the question "how much should ship?" has a concrete answer: the least code that makes those tests pass and keeps the rest of the suite green. Code that no test exercises and no requirement explains is the first candidate for deletion.

Google's published code review guidance adds a useful test of the tests: check that they would actually fail if the code broke, and don't accept complexity in tests just because they aren't production code. AI agents can generate hundreds of shallow tests quickly. A smaller set that pins down the real behaviour is worth more. Where each test should sit (unit, integration or end-to-end) is covered in our modern web development workflow guide.

Step 3: keep pull requests small

Google's engineering practices recommend small, self-contained changes because they are reviewed faster and more thoroughly, are less likely to hide bugs and are easier to roll back. The guide suggests that 100 lines is usually a reasonable size and 1,000 lines is usually too large, while leaving the final call to the reviewer, and notes that a change spread across many files can be too large even when the line count is modest. By that standard, an 800-line AI diff should normally be split.

Splitting also makes the agent better. A narrow task with its own tests gives the agent a clear finish line and gives the reviewer a diff they can hold in their head.

Step 4: measure code health, not lines of code

If a team celebrates lines written or pull requests opened, AI agents will make those numbers rise while the product gets harder to change. Measure outcomes instead. DORA's software delivery metrics are a good default because they balance speed against stability:

Alongside these, we watch a few code-level signals in review: net lines added per feature, how often the same logic appears twice, how many new dependencies arrive, and whether each change leaves the area it touched easier or harder to understand. Google's review standard is a good north star: approve a change once it definitely improves the overall code health of the system, even if it isn't perfect.