Google says 75% of all new code is AI-generated and engineer-approved. We unpack the workflow, metrics, and strategy behind it today. Read now.
What “75% AI-generated and engineer-approved” actually means
Google’s claim that roughly three-quarters of new code is AI-generated is less about replacement and more about where human judgment sits in the loop. The important half of the phrase is “engineer-approved”: models draft, complete, refactor, and propose, but ownership stays with people who merge, review, and defend the change. That distinction separates a productivity story from a quality story. Volume of generated lines is easy to inflate; trust that those lines ship without silent defects is not.
Treat the milestone as a workflow maturity signal, not a scoreboard. Teams that reach high AI share usually already have strong review norms, clear ownership of modules, and tests that catch the classes of mistakes models make often—wrong APIs, partial refactors, insecure defaults, and plausible but outdated patterns. Without that substrate, a high generation rate just moves bugs from keystrokes into pull requests.
The workflow that makes high generation rates safe
High AI code share tends to follow a repeatable path rather than ad-hoc chat in an editor. Engineers start from a tight task: a failing test, a ticket with acceptance criteria, or a narrow interface change. The model proposes a patch; the engineer edits for intent, naming, and edge cases; automated checks run; then human review focuses on design, security, and operability instead of typing syntax. The human step is not rubber-stamping—it is where “approved” earns its meaning.
- Scope first: give the model a bounded change surface so it cannot rewrite half the system by accident.
- Generate, then own: treat every suggestion as untrusted until you can explain why it is correct.
- Review for risk, not style alone: prioritize auth boundaries, data handling, error paths, and rollback behavior.
- Close the loop: when a generated change fails in review or production, feed the lesson back into prompts, templates, or shared examples.
Metrics that make the number useful
A single share-of-code metric is a headline, not a management system. Useful measurement pairs generation rate with outcomes that matter to shipping software: review time, defect rate after merge, rollback frequency, time-to-fix for small changes, and how often engineers discard or heavily rewrite model output. If generation climbs while rework and incidents climb with it, the workflow is accelerating the wrong thing.
Instrument at the pull-request level when you can. Track whether AI-assisted changes need more rounds of review, whether they concentrate in low-risk areas (tests, boilerplate, migrations) or touch critical paths, and whether approval quality stays stable as volume grows. Strategy starts when leaders use those signals to decide where automation is welcome and where human-authored code remains the default.
Strategy: where to push generation—and where not to
Apply AI generation hardest where correctness is checkable and blast radius is limited: scaffolding, repetitive adapters, documentation aligned to code, test expansions, and mechanical migrations. Slow down or forbid unsupervised generation where ambiguity is high: threat models, distributed consistency, compliance-sensitive logic, and anything that encodes product policy in subtle edge cases. The goal is not maximum percentage; it is maximum safe throughput of changes an engineer can still stand behind.
For teams outside Google, the practical playbook is the same shape at smaller scale. Codify review checklists for AI-assisted diffs, invest in tests and type systems that make bad generations fail fast, and train engineers to prompt with constraints instead of vague wishes. The milestone is less a finish line than proof that, with strong approval discipline, generation can become the default first draft—and human judgment the permanent last word.