QualityLogic logo, Click to navigate to Home
QualityLogic logo, Click to navigate to Home

The Top 10 AI Coding Quality Risks and What to Do About Them

Home » Blogs/Events » The Top 10 AI Coding Quality Risks and What to Do About Them

Over the past year, the story has shifted from “can AI write code” to “can we trust the code that AI writes.” There is near-universal adoption of AI as a coding tool, although paradoxically trust is declining as usage rises. The top complaint is that AI-coded solutions are almost right, but not quite. And yet, figuring out that “not quite right” component is not so easy.

Buggy code is just one of the risks. I’ve spent the past year digging deeply into what does and does not work in AI coding, and in this article, I’ll share the top 10 quality risks along with the top three things you can do to mitigate each of them.

1. Insecure Code by Default

By default, AI tends to write code that works but isn’t secure. Typical problems include missing input validation, injection-prone database queries, weak cryptography, and hard-coded secrets. A 2025 Veracode study found that 45% of AI-generated samples introduced a known OWASP Top 10 vulnerability, and that rate hasn’t improved as the models have gotten larger. Studies also show that developers who use AI tend to write less secure code while believing the opposite.

To avoid this, coders should:

  • Gate it automatically. Run security scanning in the build pipeline, including static code analysis (SAST) and dependency scanning (SCA), so no AI change merges without being checked.
  • Review for security, not style. Apply extra scrutiny to authentication, cryptography, and anything that handles sensitive data.
  • Add an independent security pass. Have someone who didn’t write or prompt the code check it before release.

2. Package Hallucination and Supply-Chain Exposure (“Slopsquatting”)

AI assistants will sometimes recommend installing software packages that don’t exist. Attackers have learned to register those invented names in public repositories and load them with malware, so a developer who trusts the suggestion pulls the attack straight into the build. The industry has taken to calling this “slopsquatting.” A 2025 USENIX study found that 5% to 22% of suggested packages were fictional, covering more than 205,000 unique fake names, and that the same fake names come up again and again.

Instead of falling prey to this risk, you should:

  • Verify before you install. Confirm that every new dependency actually exists and is reputable and treat adding one as a supply-chain decision rather than a convenience.
  • Lock down the pipeline. Enforce approved package lists, a private registry, lockfiles, and dependency scanning in the build.
  • Keep an inventory. Maintain a software bill of materials (SBOM) so you can trace and fix exposure the moment a bad package is disclosed.

3. Silent Correctness Bugs (“Plausible but Wrong”)

AI produces the most plausible-looking code, but that is not always the correct code. The result is defects that hide in edge cases, rest on wrong assumptions, or misuse an interface, all while reading cleanly enough to survive a quick look. This is the number one developer complaint in the 2025 Stack Overflow survey, cited by 66% of respondents, and 45% say that debugging AI-generated code takes longer than writing it themselves would.

A better way to go is to:

  • Start with testable requirements. Let the model write the implementation, but don’t let it decide what “correct” means.
  • Test behavior, not appearance. Use edge-case testing, property-based testing, and comparison against a known-good implementation to expose subtle logic errors.
  • Review for logic and requirements. Require reproducible test evidence before a change is accepted, not just a passing build.

4. Maintainability Erosion and Technical Debt

AI optimizes for a working answer right now, not for fitting the system that already exists. Over time that produces duplicated code and a codebase that fragments into pieces nobody wants to touch. GitClear’s analysis of 623 million code changes found duplication up to 81% and refactoring down sharply as AI authorship rose. The trouble is that each individual change looks reasonable, so the erosion is hard to notice until it has already added up.

To prevent this from happening, teams should:

  • Set automatic quality gates. Enforce duplication, complexity, and style limits with formatters and linters, so debt can’t build up unnoticed.
  • Keep changes small and reviewed. Require code-owner review for shared components and give the tool your architecture and conventions up front.
  • Protect refactoring with tests. Track post-commit rework and maintain a strong regression suite so that refactoring stays at low risk instead of something the team avoids.

5. Misleading Test Coverage

Ask AI for tests and you’ll get plenty of them, but many assert very little, cover only the happy path, or just restate what the code already does, so they pass even when the code is wrong. When the same model writes both the code and its tests, whatever it misunderstood gets baked into both. That makes a high coverage number on weak tests more dangerous than no number at all, because it reports a safety that isn’t really there.

Three ways around this include:

  • Measure effectiveness, not coverage. Use mutation testing, which checks whether the suite actually catches injected faults, instead of trusting a line-coverage percentage.
  • Break the self-validation loop. Generate tests from requirements rather than from the code and have a human or a separate model review them.
  • Test at the integration level. Require integration and end-to-end tests so that downstream regressions surface before release.

6. The Productivity Illusion and Automation Bias

Teams often feel much faster with AI even when they aren’t, and that feeling of speed leads people to check the output less. In a 2025 METR trial, experienced developers were actually 19% slower with AI while believing they were 20% faster. Polished, confident-looking output encourages rubber-stamping, and it arrives in larger volumes than before, so reviewers have more to get through and less inclination to dig in.

To avoid this bias, coders should:

  • Measure outcomes, not output. Track defects, escapes, rework, and change-failure rate rather than lines of code or self-reported speed.
  • Keep reviewers skeptical. Cap pull-request size so no one is asked to meaningfully review more code than a person can hold in mind.
  • Fix accountability. Put one named person on the hook for every merge, so that “the AI wrote it” is never a defense.

7. Skill Erosion and Over-Reliance

When AI does the thinking, developers build and maintain less of the understanding they need to judge whether the output is any good, and a team can drift into depending on code it can no longer really review. An Anthropic trial found that developers using AI scored about 17 points lower on code comprehension, with the biggest gap in debugging, which is exactly the skill you need in order to supervise AI in the first place. Because human review is what every other safeguard on this list rests on, that loss of understanding undercuts all of them.

Instead, developers should:

  • Use AI as a tutor, not a crutch. Ask it to explain its code and expect developers to understand what they submit.
  • Make review real. Give AI-generated code the same scrutiny you’d give a junior developer’s work, and watch whether review time matches the size of the change.
  • Sustain expertise. Keep mentorship, pairing, and debugging practice going so that in-house skill doesn’t atrophy.

8. Prompt Injection and the Agentic Attack Surface

AI agents do more than autocomplete. They read files, issues, and connected tools, and then take actions based on what they find. That opens a new problem: hidden instructions planted in a file, a README, or a connected tool can hijack an agent into leaking secrets or running commands you never intended. (The technique is called indirect prompt injection.) OWASP now ranks prompt injection as the leading cause of agentic-AI failures in production, and an agent set to approve its own actions can do about as much damage as a compromised developer workstation.

To combat this:

  • Give agents least privilege. Run them sandboxed, without production credentials, and with limited network access.
  • Keep a human at the point of action. Require approval before an agent installs packages, runs commands, or opens a pull request.
  • Vet the agent’s configuration. Pin its rules, files, and connected tools and keep secrets out of anything it can read.

9. Governance, Provenance, and Accountability (“Shadow AI”)

Most organizations can’t say which code was AI-authored, which tool produced it, or whether anyone reviewed it. That matters because when one kind of defect turns up, there’s no record to help you find the rest of it. The same blind spot works in reverse, too, as proprietary code, secrets, and customer data get pasted into prompts and leave the company’s boundary without anyone tracking it. It’s hard to manage or fix a problem you can’t even see.

Teams would do better if they:

  • Set an AI-use policy. Define approved tools, require disclosure of AI-assisted changes, and ban secrets or regulated data in prompts.
  • Capture provenance. Tag AI-assisted commits and require review, so that any finding can be traced across the codebase.
  • Add data-leak controls. Run secret detection on prompts and code and audit AI usage periodically.

10. Poor Performance, Scalability, and Resilience

Code can be functionally correct and still perform badly in production, whether through inefficient algorithms, redundant database calls, resource leaks, or failures under load. This happens because the models learn mostly from happy-path examples rather than from how software behaves under real traffic. Passing your functional tests, in other words, tells you very little about how the code will hold up at scale.

Instead, developers should:

  • Set performance targets. Put explicit latency and resource requirements in the prompt, then measure against them, and against the previous version, afterward.
  • Test under real conditions. Run load, stress, and concurrency tests, and watch for excessive database or service calls.
  • Prove resilience. Use fault injection to confirm that the code degrades gracefully and retries safely.

The Bottom Line

If AI is already writing a meaningful share of your code, and for most teams it is, the highest-leverage move is building a real verification layer: independent testing and review that doesn’t share the code author’s blind spots. Get that layer right, and AI’s speed becomes a genuine advantage instead of growing your backlog of verification debt.

If you’re coding with AI and running into these challenges yourselves, you will find our monthly quality newsletter useful. Subscribe here.  

Key Sources:

Author:

Jim Zuber, Chief Technology Officer

Over the past three decades, Jim Zuber, co-founder and Chief Technology Officer at QualityLogic, has established himself as a leading innovator in developing testing standards and methodologies for industries such as smart energy, imaging, telecommunications, and software technology.

Jim’s career in technology began with his role as co-founder and CTO at Blue Chip Software, where he developed the official simulation software for the American Stock Exchange, co-branded with the Amex itself. The company was successfully acquired by Compton’s New Media in 1986. Following this, Jim co-founded and served as president of Genoa Technology, guiding it to prominence as a trusted provider of test solutions within the computer and telecommunications sectors. The merger of Genoa Technology with Revision Labs Inc. laid the foundation for what would become QualityLogic.

At QualityLogic, Jim has been instrumental in architecting innovative testing products and solutions that have set industry benchmarks. His expertise in creating practical and effective testing methodologies continues to shape QualityLogic’s reputation as a leader in QA and software testing standards.

Jim remains actively engaged in advancing QualityLogic’s technology initiatives, regularly contributing insights and thought leadership in AI technologies, software testing, and industry standards.