How Efficient Is Your AI Model’s Code? A Critical Look at AI-Generated Code

The Numbers at a Glance

Before we get into the causes, let’s lay the groundwork. Over the past two years, several large-scale studies have been published that systematically compare AI code with human work. What they show collectively:

Why AI Writes More Code Than Humans

The model has no memory of what works. It has statistics on what is written.

1. Matching Patterns, Not Understanding

Them
The architecture of a language model consistently predicts the most likely next piece of code based on statistics from its training data. It has no innate instinct for optimization, nor any sense of what constitutes too much or of what the codebase already contains.

A senior developer writing a sorting function knows that the existing util library already has an implementation. The model doesn’t know that, unless that information is explicitly included in the context. So it writes a new implementation, complete with edge case handling, logging, and documentation.

2. Trained on the Internet: Quantity Over Quality

All major code models are trained on public code: GitHub repositories, Stack Overflow, technical blogs, and documentation. That sounds good, but the Internet is not a curated library of best practices. It’s a hodgepodge of everything: in-depth tutorials that explain every step, copied Stack Overflow answers, old enterprise code full of historical workarounds, and beginner projects with unnecessary structure.

Most of that data reflects the average web developer, rarely the most elegant coder. As a result, models learn the statistically average style, not the optimal one. What is overrepresented in web code:

• Educational code that explains things step by step (tutorials, courses).
• Defensive programming with extensive try-catch and error handling.
• Boilerplate and template-based structures.
• Outdated patterns that were common at the time but are now obsolete.
• Copied code that hasn’t been adapted to the local context.

3. Defensive Programming as the Standard

A CodeRabbit study showed that AI-generated code contains nearly twice as many null checks, early returns, and defensive patterns as human-written code. In web development, that’s often the right approach. In data engineering, it can have disastrous consequences.

A concrete example of the downside of defensive programming in *Claude Code* (Medium, November 2025). The question posed to the AI: Write a simple transformation for `transform_user_record(record)`.

AI output (simplified):

def transform_user_record(record):
    try:
        user_id = record.get('user_id', -1)          # default -1 als ontbreekt
        email = record.get('email', '').lower()      # lege string als ontbreekt
        created = record.get('created_at', datetime.now())  # nu als ontbreekt
        return {'user_id': user_id, 'email': email, 'created_at': created}
    except Exception as e:
        logger.error(f'transform_user_record failed: {e}')
        return None                                   # stil falen

The problem: in a data pipeline, this pattern hides corrupted records. A missing `user_id` becomes -1, a value that is valid in and of itself but has unintended effects downstream. The model prioritized robustness, which would be correct in a different context but here contaminates the pipeline. The code does what was asked of it but is still semantically incorrect for this use case.

4. No context of the existing codebase

An agent writing code without full codebase context starts every function as if it were the first piece of code for this project. Existing utility functions are rewritten, constants are hardcoded instead of imported, and the team’s naming conventions are disregarded.

GitClear’s longitudinal study of 211 million lines of code illustrates this clearly: copy-paste code rose to 12.3% of all modified lines, up from 8.3% in 2021—an increase of nearly half. At the same time, refactoring (reusing and moving code) dropped to less than 10%, down from 25% previously. AI duplicates code where a human would reuse it.

5. RLHF: Rewarded for Detailed Answers

This is the most controversial point. Models are refined using Reinforcement Learning from Human Feedback (RLHF). Historically, human evaluators have tended to prefer more detailed answers that feel complete, even when a shorter answer is technically more correct. This creates a structural bias toward detail.

That doesn’t mean that models are deliberately designed to charge more tokens. However, the result remains the same: models that are rewarded for detailed answers produce longer code, and under token-based billing, that directly benefits the provider.

Human Code vs. AI Code: A Comparison

To illustrate this, let’s compare what a typical task looks like in human-style and AI-style code. Note the number of lines and the implicit assumptions. The task: validate an email address and store it in a database.

def save_email(email, db):
    if '@' not in email:
        raise ValueError('Invalid email')
    email = email.strip().lower()
    db.execute(
        'INSERT INTO users (email)'
        ' VALUES (?)', [email]
    )
    return True

import re, logging
from typing import Optional
logger = logging.getLogger(__name__)
EMAIL_REGEX = re.compile(
    r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]'
    r'+\.[a-zA-Z]{2,}$')
def save_email(email: Optional[str], db: DatabaseConnection) -> dict[str, any]:
    """Save email with validation."""
    if not email or not isinstance(email, str):
        logger.warning('Email is None/empty')
        return {'success': False, 'error': 'Email required'}
    email = email.strip().lower()
    if not EMAIL_REGEX.match(email):
        logger.warning(f'Invalid: {email}')
        return {'success': False, 'error': 'Invalid format'}
    try:
        db.execute(...)
        logger.info(f'Saved: {email}')
        return {'success': True, 'email': email}
    except Exception as e:
        logger.error(f'DB error: {e}')
        return {'success': False, 'error': str(e)}

The AI version is correct in and of itself. In certain contexts, it’s even better: stricter email validation, type hints, logging, and an explicit return object. If this pattern is repeated across an entire codebase for every utility function, it results in thousands of extra lines of code that need to be maintained, understood, and debugged, while the business logic remains identical.

Burn tokens or deliver value?

AI companies are paid per output token. More extensive code generates more output tokens. The incentives are structurally misaligned.

The incentive structure

Current token pricing is asymmetric: output tokens cost five times more than input tokens. Every extra line of code a model writes generates more output tokens, and more output tokens mean a higher bill. In the short term, the provider has little financial incentive to be concise.

That’s not to say that models are deliberately designed to be verbose in order to make money. It remains, however, a structural problem of misaligned incentives that the industry should honestly acknowledge:

• RLHF training rewards comprehensive, complete answers, even when it comes to code.
• Users, especially non-technical ones, often perceive more extensive code as “more work” and “more value.”
• Providers measure quality using benchmarks (correctness, test coverage), rarely based on code length or maintainability.
• A standardized “efficiency score” for generated code is missing from public benchmarks.

The counterargument

The other side deserves just as much attention. There are indeed good reasons why AI code experiences longer outages:

The conclusion is nuanced. Some of the extra code has real value. Other parts are artifacts of the training process and the incentive structure. The problem is that the industry lumps both together, with concrete financial and technical consequences.

The Hidden Cost: Technical Debt at Scale

Extensive AI code has a direct impact on your token cost, but the indirect cost carries more weight: technical debt that accumulates as AI writes a larger portion of the codebase.

The 80% Problem

Augment Code (April 2026) documented what it calls the 80% problem: AI agents produce code that works functionally but remains structurally incomplete. A typical generated dashboard component retrieves data and renders a grid. What’s missing: error state handling, a loading skeleton, data refresh logic, accessibility attributes, ARIA labels, and an authentication check.

The devil is in the details: adding the missing 20% later costs more than building it correctly from the start. Every fix first requires an understanding of the intent behind the generated code, while agents rarely document their architectural choices.

Four Mechanisms of Debt Accumulation

• Conceptual debt: For every fix, an engineer must reconstruct the intent of the generated code.
• Duplication debt: Copied code requires synchronized updates in multiple places with every bug fix.
• Test debt: Generated code optimizes for the existing tests, rarely for the edge cases that should be covered.
• Architectural debt: Code generated without an understanding of the system does not fit into the existing abstraction layers.

Where does the model get its inspiration? The training data question

To thoroughly understand AI’s coding behavior, we look at the sources. The large code models are trained on highly overlapping datasets.

• GitHub public repositories: the largest source. Contains excellent code alongside freshman student projects, abandoned projects, and code full of quick fixes.
• Stack Overflow: Answers licensed under CC-BY-SA. Popular answers aren’t necessarily the best—they’re the most upvoted—and upvotes are partly determined by accessibility.
• Technical blogs and tutorials: by definition, they’re designed to be educational, so they’re comprehensive and step-by-step with thorough explanations.
• Official documentation and API references.
• CodeSearchNet, The Pile, and similar aggregated datasets with varying quality standards.

Research by Cracks in The Stack (arXiv 2025) analyzed The Stack v2 dataset and found incorrect file origin attributions. These lead to code with incompatible licenses and, more seriously, to buggy code that is incorrectly marked as valid. Models trained on buggy data learn buggy patterns. Hubinger et al. also demonstrated that LLMs can introduce vulnerabilities and that this behavior is particularly difficult to eliminate through fine-tuning. Once learned, a pattern remains in the model.

A language model learns the statistical distribution of its training data. So it writes code that resembles the average on GitHub, not the top 5% of it. The top engineers known for elegant, minimal code—think of a one-liner by Linus Torvalds or a Rust contributor who avoids `unsafe` blocks—are a small minority in the data. Instruction tuning and RLHF correct this to some extent, but never completely. The model never goes beyond its training data, and that data reflects the average internet developer, rarely the very best.

How Can You Get the Most Out of It? Practical Recommendations

The message is clear: keep using AI, because the productivity gains are real. Do so with an open mind, clear guidelines, and technical safeguards.

1. Always provide context for the codebase.
Make sure the agent has access to the relevant existing modules, conventions, and style guides before the code is generated. Without that context, the agent will reinvent the wheel—and add extra spokes and reflectors that nobody asked for.

2. Define a coding style guide for AI.
Explicitly state in your prompt or system instruction: “Use existing utility functions from /utils, follow our naming conventions from CONVENTIONS.md, and do not write inline logging unless asked.” AI follows instructions better than it extrapolates them.

3. Make a point of asking for concise code.
Add the following to your prompt: “Write as few lines of code as possible to fully solve the task.” Models respond well to explicit instructions to be concise. Without that instruction, they prioritize completeness.

4. Review generated code structurally, not just functionally.
Test coverage does not guarantee that the code makes the right architectural choices. Also evaluate: Does this fit into the existing structure? Are there any duplicates? Is the error handling appropriate for this context?

5. Use linting and static analysis as a gatekeeper.
Tools such as Pylint, SonarQube, or ESLint automatically detect duplication, code smells, and style deviations in generated code. Integrate them as a mandatory step in your CI/CD pipeline before merging.

6. Measure your code churn per developer and per AI tool.
GitClear’s finding that churn rose to 7.9% exposes a problem that remains hidden without measurement. Add churn metrics to your engineering dashboard, because a high churn rate is an early warning sign of quality issues.

7. Adjust your expectations based on the model.
Haiku writes faster but with less nuance; Opus writes more slowly but with a better sense of architecture. Know which model performs which task, and tailor the intensity of your review to the model that generated the code.

8. Treat AI-generated code as third-party code.
Industry best practice: Treat AI-generated code as if it were code from an external library. Don’t trust it blindly; understand what it does, test it explicitly, and document its origin for future maintenance.

Conclusion: Productivity and quality are two different things

AI writes code faster. That much is certain. However, speed and quality remain two distinct matters, and more lines of code do not necessarily equate to more value. The figures are sobering: 1.7 times more issues, 4 times more duplication, refactoring activity that was cut in half, and a churn rate that doubled.

Some of that verbosity provides real value: better type annotations, more robust error handling, and explicit documentation. A substantial portion, however, is an artifact of how models learn—namely, on the average web, where they are rewarded for completeness and have no insight into the codebase they are building.

There is no simple answer to whether tokens are intentionally burned. The incentives are structurally misaligned, and that calls for deliberate countermeasures: clear instructions, codebase context, peer review, linting, and churn monitoring. Think of it as handling a powerful tool responsibly—one that has its limits.

About the author

Peter Verrykt is the Business Unit Lead for Data & AI at Xylos and helps organizations turn data into tangible business value. Want to keep AI code under control in your team? I’d be happy to discuss it.

Sources

CodeRabbit: State of AI vs. Human Code Generation (Dec. 2025) | GitClear: AI Copilot Code Quality 2025 (211M lines) | Cotroneo et al. arXiv 2508.21634 (Aug. 2025) | Monash/Otago: Comparing Human and LLM-Generated Code (Jan. 2025) | Augment Code: The 80% Problem (Apr. 2026) | METR: AI Tooling Slowed Developers Down (Jul. 2025) | Stack Overflow: Bugs and Incidents with AI Coding Agents (Jan. 2026) | Cracks in The Stack arXiv 2501.02628

Disclaimer: Code examples have been simplified for illustrative purposes. The studies cited have been peer-reviewed or published by recognized institutions and are cited accurately in spirit, not reproduced verbatim.