↓ Skip to main content
sdd.sh
sdd.sh
  1. Articles/

Google's 75% Threshold: When AI Became the Primary Author of Production Code

·1254 words·6 mins·
Table of Contents

At Google Cloud Next 2026, Sundar Pichai announced a number that quietly rewrites a decade of assumptions about software engineering: 75% of all new code at Google is now AI-generated and approved by engineers.

Not assisted. Not suggested. Generated — then reviewed, then shipped.

That figure was 25% in October 2024. It hit 50% by fall 2025. Now, eighteen months after the first credible automation milestone, AI has become the primary author of production code at one of the most sophisticated engineering organizations on earth.

Engineers didn’t disappear. But their job description just changed.

The Number in Context
#

Three data points define the trajectory:

PeriodAI-generated code at Google
October 2024~25%
Fall 2025~50%
April 202675%

The velocity matters as much as the current figure. That’s not incremental adoption — it’s geometric. The first 25% took years of careful AI tooling integration. The next 25% took roughly twelve months. The last 25% took six months. If the curve continues, asking “what percentage is human-written?” becomes the more interesting question faster than anyone planned.

Pichai was precise about what the number means: this is code that AI generates and that engineers approve. It goes through review. It doesn’t bypass human judgment. But the role of that human judgment has inverted: the engineer is now verifying and directing rather than producing and reviewing.

That’s not a semantic distinction. It’s an architectural one.

Engineers as Directors
#

The productivity data Pichai shared is specific enough to be credible. A recent complex code migration — the kind of project that historically consumes entire quarters of senior engineering time — was completed six times faster than the equivalent project one year prior, with agents and engineers working in tandem.

The Gemini app on macOS was built using Google’s internal agentic development platform, called Antigravity, to go from concept to working native app prototype in a few days.

Google has also formalized the transition in its management systems: internal AI adoption goals now factor into engineer performance reviews. That’s the clearest possible signal that this isn’t a lab experiment or an executive vanity metric — it’s operational reality baked into how careers are evaluated.

The shift in role has a clean description: engineers are becoming reviewers and orchestrators rather than line-by-line authors. That’s not a downgrade. An engineer who can review 10x more code per hour and direct 5 parallel agent workstreams produces more value than one who types faster. But it requires a genuinely different skill set — less syntax, more architecture; less typing, more judgment; less execution, more specification.

This is what Spec-Driven Development looked like in theory two years ago. It’s what Google looks like in practice today.

The Tooling Reality
#

Google uses its own Gemini models as the primary engine for this automation. The Antigravity platform — their internal agentic development stack — orchestrates agents across tasks that would previously require handoffs between teams.

But there’s a detail buried in the announcements: some Google DeepMind employees have been permitted to use Claude Code. At a company that builds its own frontier models and operates at Google’s scale, that’s a notable carve-out. It signals that even inside the world’s most capable AI-first engineering organization, there are contexts where Anthropic’s tooling is the better choice for autonomous development workflows.

Claude Code’s terminal-native architecture — where the agent operates in your environment, uses your tools, and integrates with your existing CLI workflows — is a different class of tool than an IDE-embedded assistant, even one powered by Gemini.

What This Means for Software Teams That Aren’t Google
#

The temptation is to read Google’s numbers as exceptional — the output of a uniquely well-resourced organization with proprietary models and billions of dollars in infrastructure. That’s partially true. But the trajectory matters more than the absolute figure.

Google was at 25% eighteen months ago. If your team is at 10% today, you’re not behind where Google was in late 2024 — you’re behind where Google was in 2023. The curve that took Google from 25% to 75% is the same curve your team is on. It’s just shifted.

The practical implications:

Code review changes first. When 75% of the diff is AI-generated, the review process can’t operate the same way it did for human-authored code. Reviewers need to evaluate correctness, architecture, and intent at a higher level of abstraction. Spotting a bug in a function you wrote yourself is different from evaluating whether an agent’s 300-line solution to your spec is the right solution.

Specification quality becomes the constraint. If AI writes three-quarters of the code, the quality of what gets written is bounded by the quality of what got specified. Sloppy requirements produce sloppy-but-functional code — and automated tests pass it. The weakest link in the pipeline moves upstream.

Hiring signals shift. The engineers who will be most productive at 75% AI-generated codebases are the ones who can write precise technical specifications, evaluate AI output at speed, architect systems that agents can navigate without constant correction, and debug the failure modes of AI-generated code specifically. These are different skills than the ones that made a great engineer in 2022.

The Productivity Ceiling Question
#

There’s a critique that sits underneath the productivity numbers: if 75% of code is AI-generated, is the resulting software better or just faster? Faster is real value — shipping in days instead of months has compounding effects. But the security data from this same week offers a counterpoint.

Sherlock Forensics found critical vulnerabilities in 92% of AI-generated codebases. ProjectDiscovery’s 2026 report shows 62% of security teams say keeping up with AI code velocity is harder than ever. The productivity gains are real; so is the quality debt they introduce if the review layer is too shallow.

Google’s answer to this is to keep humans in the review loop with explicit performance accountability. That’s the right answer. But it means the review skill is as load-bearing as the generation skill — and most teams are investing more in generation tooling than in review quality.

Agentic review loops, pre-commit security hooks, CLAUDE.md invariants that codify security and architecture invariants — these aren’t overhead. At 75% AI-generated code, they’re the actual engineering work.

The Asymmetry That Matters
#

One thing the 75% number doesn’t say: which 75%? Routine, well-specified, well-tested code that follows established patterns is much easier for AI to generate correctly than novel architectural decisions, security-sensitive logic, or code at system boundaries where implicit assumptions live.

If AI is writing the boilerplate and the straightforward implementations while engineers spend their time on the hard, novel, consequential parts — that’s a genuine productivity multiplier, and arguably the ideal division of labor. If AI is writing the security-sensitive authentication code and engineers are approving it at speed because 75% of their review queue is AI-generated, that’s a different situation.

Google’s framing suggests they’re aware of this distinction. Building Antigravity with domain-specific guardrails for their internal codebases implies the hard cases are still getting appropriate attention.

The 75% threshold isn’t a finish line. It’s the point where being thoughtful about which 75% becomes the most important engineering decision your organization makes.

Sources:

Related