The productivity gain is real, but there's a question running alongside it: how good is that code, and what will it cost you in maintenance later? Scientific research paints a sobering picture. AI-generated code is longer, more often duplicated, and harder to maintain, with 1.7 times as many problems as human-written code. Peter Verrykt, Business Unit Lead Data & AI at Xylos, dives into the causes and asks the question few dare to ask out loud: is verbose AI code a technical necessity or a commercial model?

Before we get to the causes, let's lay the groundwork. Over the past two years, several large-scale studies have appeared that systematically compare AI code with human work. What they show together:

1. Matching patterns, not understanding them

The architecture of a language model always predicts the most likely next piece of code, based on statistics over its training data. There's no native instinct for optimization in there, nor any sense of what's too much or what the codebase already contains.

A senior developer writing a sort function knows the existing util library already has an implementation. The model doesn't know that, unless that information is explicitly present 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 isn't a curated library of best practices. It's a collection of everything: lengthy 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 internet developer, rarely the most elegant coder. Models therefore learn the statistically average style, not the optimal one. What internet code overrepresents:

• 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 used to be common but are now unnecessary.

• Copied code without adaptation to the local context.

3. Defensive programming as the default

CodeRabbit research showed that AI-generated code contains almost twice as many null checks, early returns, and defensive patterns as human code. In web development, that's often the right approach. In data engineering, it can turn out disastrous.

A concrete example of the perverse side of defensive programming in Claude Code (Medium, November 2025). The request to the AI: write a simple transformation for transformuserrecord(record).

AI output (simplified):

The problem: in a data pipeline, this pattern hides corrupt records. A missing user_id becomes -1, a value that's valid on its own but has unintended effects downstream. The model chose robustness that would be correct in another context, but here it pollutes the pipeline. The code does what was asked and is still semantically wrong for the use case.

4. No context of the existing codebase

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

GitClear's longitudinal study of 211 million lines of code shows this concretely: copy-paste code climbed to 12.3% of all changed lines, up from 8.3% in 2021 — nearly half again as much. At the same time, refactoring (reusing and moving code) dropped to below 10%, compared to 25% before. AI duplicates where a human reuses.

5. RLHF: rewarded for elaborate answers

This is the most controversial point. Models are refined through Reinforcement Learning from Human Feedback (RLHF). Human raters have historically tended to favor more elaborate answers that feel complete, even when a shorter answer is technically more correct. That creates a structural preference for verbosity.

That doesn't mean models were deliberately designed to bill more tokens. The outcome remains the same, though: models rewarded for elaborate answers produce longer code, and under token-based billing, that works directly in the provider's favor.

To make it concrete, we compare what a typical task looks like in human style versus AI style. Pay attention to the number of lines and the implicit assumptions. The task: validate an email address and save it to a database.

The AI version is correct in its own right. 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 produces thousands of extra lines that need to be maintained, understood, and debugged, while the business logic stays identical.

The incentive structure

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

That doesn't mean models were deliberately designed to be verbose in order to make money. It remains a structural problem of misaligned incentives that the industry could honestly acknowledge:

• RLHF training rewards elaborate, complete answers, including in code.

• Users, especially non-technical ones, often judge more elaborate code as 'more work' and 'more value'.

• Providers measure quality through benchmarks (correctness, test pass rate), rarely through 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 turns out longer:

The conclusion is nuanced. Part of the extra code has real value. Another part is an artifact of the training process and the incentive structure. The problem is that the industry lumps both together, with concrete financial and technical consequences.

Verbose AI code has a direct effect on your token cost, but the indirect cost weighs heavier: technical debt that piles up as AI writes a larger share of the codebase.

The 80% problem

Augment Code (April 2026) documented what it calls the 80% problem: AI agents deliver code that functionally works but remains structurally incomplete. A typically generated dashboard component fetches 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 sting is in the tail: adding the missing 20% afterward costs more than building it correctly from the start. Every fix first requires understanding the intent behind the generated code, while agents rarely document their architectural choices.

Four mechanisms of debt accumulation

• Comprehension debt: for every fix, an engineer has to reconstruct the intent of the generated code.

• Duplication debt: copied code requires synchronized updates in multiple places with every bug fix.

• Testing debt: generated code optimizes for the tests that exist, rarely for the edge cases that should exist.

• Architecture debt: code generated without system insight doesn't fit into the existing abstraction layers.

To understand AI's coding behavior at its core, we need to look at the sources. The major code models are trained on heavily overlapping datasets.

• GitHub public repositories: the largest source. Contains outstanding code alongside first-year student projects, abandoned projects, and code full of quick fixes.

• Stack Overflow: answers under a CC-BY-SA license. Popular answers aren't necessarily the best ones — they're the most upvoted, and upvotes are partly determined by accessibility.

• Technical blogs and tutorials: educational by design, so extensive and step-by-step with maximum explanation.

• Official documentation and API references.

• CodeSearchNet, The Pile, and similar aggregated datasets with varying quality standards.

Research from Cracks in The Stack (arXiv 2025) analyzed the Stack v2 dataset and found incorrect file-provenance attributions. These lead to code with incompatible licenses and, more importantly, to buggy code wrongly marked as valid. Models trained on buggy data learn buggy patterns. Hubinger et al. also showed that LLMs can introduce vulnerabilities and that this behavior is particularly difficult to remove through fine-tuning. Once a pattern is learned, it stays present in the model.

A language model learns the statistical distribution of its training data. So it writes code that resembles the GitHub average, not the best 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 — make up a small minority of the data. Instruction tuning and RLHF correct that partially, never completely. The model never reaches beyond its training data, and that data reflects the average internet developer, rarely the very best.

The message is clear: keep using AI, because the productivity gain is real. Just do it with your eyes open, with clear guidelines and technical counterweights.

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

2. Define a coding style guide for AI.
Write explicitly in your prompt or system instruction: 'Use existing utility functions from /utils, follow our naming from CONVENTIONS.md, don't write inline logging unless asked.' AI follows instructions better than it extrapolates them.

3. Deliberately ask for concise code.
Add to your prompt: 'Write as few lines of code as possible that fully solve the task.' Models respond well to explicit instructions to be concise. Without that instruction, they default to completeness.

4. Review generated code structurally, not just functionally. Test coverage doesn't guarantee the code makes the right architectural choices. Also assess: does this fit the existing structure, are there duplicates, does the error handling suit this context?

5. Use linting and static analysis as a gatekeeper. Tools like Pylint, SonarQube, or ESLint automatically detect duplication, code smell, 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 climbed to 7.9% exposes a problem that stays invisible without measurement. Add churn metrics to your engineering dashboard, since a high churn rate is an early signal of quality problems.

7. Adjust model-specific expectations. Haiku writes faster but with less nuance, Opus writes slower but with more architectural awareness. Know which model performs which task, and calibrate your review intensity to the model that generated the code.

8. Treat AI code as external code. The industry best practice: treat AI-generated code like code from an external library. Don't trust it blindly, understand what it does, test it explicitly, and document its origin for future maintenance.

AI writes code faster. That much is certain. Speed and quality simply remain two different things, and more lines of code doesn't equal more value. The figures are sobering: 1.7 times more problems, 4 times more duplication, refactoring activity that halved, and a churn rate that doubled.

Some of that verbosity delivers real value: better type annotations, more robust error handling, explicit documentation. A substantial part is an artifact of how models learn — namely from the average of the internet, rewarded for completeness and without insight into the codebase they're building on.

Whether tokens are being deliberately burned has no simple answer. 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 responsible use of a powerful instrument that has its limits.

The key message

• AI code has 1.7x more problems than human code (CodeRabbit, 2025), largely due to structural shortcomings in training and incentives.

• Verbosity partly has legitimate causes (robustness, type safety), but is also reinforced by RLHF training that rewards completeness.

• Technical debt piles up fast: 4x more duplication, refactoring cut in half, 7.9% churn within 2 weeks.

• The solution: explicit instructions for conciseness, codebase context, structural review, and CI/CD-driven quality metrics.

Peter Verrykt is Business Unit Lead Data & AI at Xylos and helps organizations turn data into concrete business value. Want to keep AI code in your team under control? I'm happy to talk about it.

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: the code examples are illustratively simplified. The studies referenced are peer-reviewed or published by recognized institutions and are cited accurately in substance, not reproduced verbatim.