The cost has shifted: writing code is almost free; checking it is not. Throughput is now set by how much a person can honestly verify, so changes are shaped for the reviewer, not for the generator.
What we know about review predates code generation and is mostly observational. Bacchelli and Bird (“Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013) found at Microsoft that finding defects was the top stated motive for review, but that comments were more often about understandability and design, and that understanding the change was the reviewers’ main difficulty. Sadowski et al. (“Modern Code Review: A Case Study at Google”, ICSE-SEIP 2018) describe a culture of small changes with quick turnaround. A Cisco study published by SmartBear reported that defect discovery fell off when a review covered more than a few hundred lines or went faster than roughly 500 lines an hour; it is a single vendor-run study, so read the numbers as an order of magnitude. Together they say the scarce resource is a reader’s understanding, and generation increases the supply of text against it.
Consequences: small diffs (reviewability matters more than generation speed), a ban on PRs larger than a reviewer can honestly read, and the author’s responsibility cannot be delegated — “the model wrote it” is no excuse in a postmortem. In practice: mechanical changes (a rename across 200 files) go in their own PR, produced by a script that is itself reviewed; behavioral changes go in stacked, separately reviewable steps; the description says what was verified and how. A schema migration, its backfill and the code that reads the new column are three reviews, not one.
Trade-offs. Not every line deserves equal reading: shift checking to machines where they are reliable — types and tests (60), linters, property tests (9) — and keep human attention for intent and design. Splitting too finely has its own cost: ten trivial PRs can hide one decision that only shows when they are read together.