AI-generated code is source code that a large language model produces and engineers then review, edit and merge into a product. It is now a routine part of enterprise delivery rather than a pilot project. On Alphabet’s Q3 2025 earnings call, Google CEO Sundar Pichai said that more than 75% of new code at Google is generated by AI and then approved by engineers. That figure is worth reading carefully, because it tells you as much about Google’s review process as it does about the models.
What the 75% figure actually measures
The statement describes the share of new code written with model assistance and then approved by engineers. It does not mean three quarters of production code ships with no human in the loop. Google reviews changes through a mature monorepo, extensive automated testing and a strong code review culture, and those controls are what make a high generation rate tolerable.
Two things transfer to other organisations and one does not. What transfers is the shift in where effort sits: less time typing, more time verifying. What also transfers is the risk that review becomes a bottleneck and turns into rubber-stamping. What does not transfer is the assumption that approval equals quality, because approval quality depends entirely on the reviewer’s capacity and context.
The ratio also depends on what you count as code. Boilerplate, tests, configuration and framework glue generate easily. Novel algorithms, concurrency-sensitive logic and domain rules that live only in a senior engineer’s head do not.
Quality: where AI-written code holds up and where it fails
Output that is usually solid
Teams get reliable results on adapters, CRUD scaffolding, test scaffolding, data migrations, language or framework translation, and documentation drafts. These tasks have many correct examples in public code, which is exactly what a model has learned from. Reviewing them is fast because the patterns are familiar.
Output that needs scrutiny
Generated code tends to be plausible rather than correct. It handles the happy path well and quietly skips edge cases: empty collections, timezone boundaries, retries, partial failures, permission checks on the second endpoint. It also invents library methods, uses deprecated APIs and picks dependency versions that no longer match your lockfile.
There is a second-order cost that rarely appears in pilots. Verifying unfamiliar code can take longer than writing it, especially when the reviewer did not write the prompt. Reviewers who cannot see the intent behind a diff tend to approve it or rewrite it, and both outcomes waste the gain.
AI code security: process beats trust
Security is where the gap between “works” and “safe” is widest. The recurring problems in AI code security are consistent across teams: outdated or vulnerable dependency versions, packages that do not exist at all (an attacker can register a hallucinated name, a pattern now called slopsquatting), secrets pasted into examples, missing authorisation checks, over-broad cloud permissions in generated infrastructure files, and verbose error messages that leak internals.
None of these are solved by better prompting alone. They are solved by gates that run on every change:
- Static analysis and software composition analysis in CI, failing the build rather than warning.
- Secret scanning plus an internal package allowlist so invented dependencies cannot be installed.
- A threat model supplied as context for any code touching authentication, payments or personal data.
- Mandatory human security review for identity, data access and infrastructure changes, regardless of who or what wrote them.
Maintainability: the bill that arrives six months later
The maintainability of AI-generated code is rarely a problem in week one and almost always one in month six. Models optimise for local correctness, so you get duplicated helpers, three ways to call the same service and abstractions that exist only because the prompt asked for them. Tests often assert what the implementation does instead of what the business requires, which makes them resistant to refactoring rather than protective.
Countermeasures are unglamorous and effective: linters and formatters that make style non-negotiable, a short internal guide describing approved patterns and libraries, module ownership so someone is accountable for each area, and a habit of asking the author to explain the diff in the pull request description.
| Adoption model | What it looks like | Main risk | Best fit |
|---|---|---|---|
| IDE assistant | Autocomplete and chat inside the editor, developer merges manually | Inconsistent patterns, silent dependency drift | Teams starting out with AI coding assistants |
| Agentic pull requests | Agent generates a branch and PR from an issue | Reviewer overload, shallow tests | Well-tested codebases with strong CI |
| Custom internal workflow | Models grounded in your codebase, policies and evaluation set | Build and maintenance cost | Organisations with specific compliance or domain needs |
A review process that scales with AI-generated code
- Classify the change by risk before review: cosmetic, business logic, or security and data sensitive. Route each to the right depth of scrutiny.
- Require the prompt or task description alongside the diff so reviewers can judge intent, not just syntax.
- Run automated gates first: build, unit tests, static analysis, dependency and secret scanning. Never spend human time on what a machine can reject.
- Focus human review on design fit, edge cases, error handling and tests, which are the areas models handle least reliably.
- Track outcomes rather than output: revert rate, defect density per merged change, review turnaround time and incidents traced to generated code.
Ready-made AI coding tools versus a custom workflow
Buying an off-the-shelf assistant is the fastest path and usually the right first step. You get autocomplete, chat and increasingly agentic features with no infrastructure work, and the main costs are licences, data handling review and a short enablement period. The limits appear when you need the model grounded in private code, internal design standards or regulated data flows.
Building a custom workflow costs more and is worth it when the value is in context rather than completion: retrieval over your own repositories, evaluation sets that catch regressions when a model changes, and policy checks wired into the pipeline. That is the kind of work Zodinet’s AI development services cover, from model integration and data pipelines to evaluation and deployment. Choose build only if you can also fund its ongoing maintenance.
Frequently asked questions
Is AI-generated code less secure than human-written code?
Not inherently, but it fails differently. Models reproduce insecure patterns from public code, suggest outdated dependencies and sometimes invent packages. Human code tends to fail through missing checks on known paths, which reviewers catch more easily. The practical answer is identical for both: automated scanning, dependency allowlists and mandatory security review for authentication, payments and personal data.
How much enterprise code is actually AI-generated?
There is no reliable cross-industry figure, and reported numbers measure different things: accepted completions, lines touched, or changes approved after generation. Google’s 75% figure reflects its own tooling and review capacity. Treat any single percentage as a signal of direction rather than a benchmark, and measure your own ratio if you want it to mean something.
Does AI-generated code pass code review?
Usually, and that is the risk. Generated diffs are readable, well-formatted and look conventional, so reviewers skim them. Defects concentrate in edge cases, error handling and tests, which skim-reading misses. Reviewers need the task description, a risk classification and automated gates doing the mechanical checks before human attention is spent.
How do you keep AI-generated code maintainable?
Make conventions enforced rather than suggested. Use linters and formatters, publish a short guide of approved patterns and libraries, assign module ownership, and require tests that describe business behaviour. Ask authors to explain the diff in the pull request. These practices matter more as generation volume rises, because inconsistency compounds faster than it is cleaned up.
Conclusion
A high generation ratio is a productivity signal only when the surrounding process can absorb it. The teams that benefit most treat AI output as a draft from a fast but junior contributor: useful, cheap to produce and always reviewed against explicit standards. Invest in gates, conventions and measurement before you chase a percentage, and the quality, security and maintenance questions mostly answer themselves.
Planning a similar project? Zodinet Technology has built software for businesses since 2016. See our AI development services or talk to an engineer.
