AI accuracy by field · Software

Is AI accurate for coding?

Useful, but not to be trusted blind. AI writes code that compiles, reads well, and looks idiomatic, which is exactly what makes its mistakes hard to catch. It hallucinates software packages that do not exist in nearly 20 percent of dependency suggestions, 45 percent of the code it writes fails security testing, and controlled studies show it makes developers more confident while their code gets less secure. Run it, test it, and security-review it before you ship it.

Try the free claim checker

It compiles, it looks right, and it is often wrong

Across 16 code-generating models and 576,000 samples, AI suggested a software package that does not exist in 19.7 percent of all dependency references, more than 205,000 unique hallucinated package names. Separately, security firm Veracode found that 45 percent of AI-generated code that compiled still contained a known OWASP Top 10 vulnerability, and that newer, larger models were no more secure than older ones.

AI code failure is dangerous precisely because it does not look like failure. The output is not full of obvious typos; it is confident, fluent, idiomatic code with a subtly wrong line of logic, an insecure default, a deprecated API, or an import for a library that was never real. It passes the eye test and often the smoke test, which is why the most damaging bugs are the ones that compile.

19.7%

of the software packages AI code generators suggested do not exist: over 205,000 hallucinated package names across the models tested.

USENIX Security Symposium, 2025

Why AI fails at coding specifically

A model invents an import, a method, or a parameter because the shape of the name is statistically plausible, not because it exists. That produces the headline package-hallucination rate, but the sharper risk is that these hallucinations are repeatable: 43 percent of fabricated package names reappeared in every one of ten repeated runs. A repeatable hallucination is a predictable target. This is the basis of slopsquatting, where an attacker asks a model which fake package names it reliably suggests, registers a real malicious package under that exact name, and waits for developers to copy the AI's install command.

The rest of the failure surface is quieter and just as real: off-by-one errors and mishandled edge cases that pass a happy-path test, insecure-by-default patterns like string-built SQL and missing output encoding, weak or placeholder cryptography, hardcoded secrets, and API calls that were removed after the model's training cutoff. Worst of all is the confidence gap. In a controlled Stanford study, developers using an AI assistant wrote less secure code while believing it was more secure, an inverse relationship between how safe their code was and how much they trusted the tool.

Documented failures

The huggingface-cli slopsquatting proof of concept (2024)

A researcher noticed models kept hallucinating a Python package called huggingface-cli. He registered an empty, harmless package under that exact name. In about three months it drew more than 15,000 real downloads, and companies including Alibaba referenced it in real install instructions. Had the package been malicious, that was live code execution across thousands of machines.

More confident, less secure (Stanford, 2023)

In a controlled study, participants using an AI assistant produced more security vulnerabilities than a control group, for example writing SQL-injection-prone code far more often, yet were more likely to believe their code was secure. Confidence in the tool rose as the actual security of the output fell.

205,000 registerable fake names (USENIX Security, 2025)

The academic study that measured the 19.7 percent hallucination rate catalogued more than 205,000 unique non-existent package names, most of them repeatable, that an attacker could register today. The researchers deliberately registered none of them, so it is a demonstrated attack surface, not yet a breach.

The numbers behind it

45%

of AI-generated code that compiled still contained a known OWASP Top 10 security vulnerability, with larger models no safer than smaller ones.

Veracode GenAI Code Security Report, 2025

~5% vs ~22%

package-hallucination rate for the best commercial models versus open-source models: even the best still invents a package roughly 1 in 20 suggestions.

USENIX Security Symposium, 2025

The reason AI code slips through review is the same reason it slips through your own eyes: it looks like something a competent developer wrote. Checking it against several models is a fast way to surface the parts that are not what they seem. Paste the snippet into TrueStandard and, in about a minute, the models flag the invented package, the insecure pattern, or the deprecated call as a disagreement, so you know exactly what to test before it reaches your codebase.

How to verify AI-generated code

Never ship AI code on the basis that it compiles. Before it reaches your repo, run this check.

  1. 01

    Verify every imported package actually exists and belongs to the real maintainer. Check it on PyPI or npm directly: publish date, downloads, maintainer, repository. A brand-new, low-download package matching an AI suggestion is a slopsquatting red flag. Never blind-run an install command an AI gave you.

  2. 02

    Run it and write tests. It compiling and looking right is not evidence. Cover the edge cases models tend to skip: nulls, empties, boundaries, concurrency, and error paths.

  3. 03

    Security-review the output specifically. Assume insecure by default: check for SQL built by string concatenation, missing output encoding, weak crypto, and unsafe deserialization. Run static analysis and dependency scanning as a rule, not an exception.

  4. 04

    Confirm every API call and function signature against the official docs. Models invent parameters and emit deprecated or removed calls from before their training cutoff.

  5. 05

    Scan the diff for hardcoded secrets and injected credentials before committing.

  6. 06

    Check the logic against the actual requirement, not the AI's explanation. The natural-language rationale is as confidently wrong as the code, so re-derive the tricky parts yourself.

  7. 07

    Pin and lock dependencies, and review the lockfile diff. A verified package today can be a hijacked one tomorrow.

How to make AI output reliable: check it across models

The fix is not to hunt for a single more accurate model. Every large language model predicts fluent, plausible text, so each one can be confidently wrong on its own. What changes the odds is agreement. When several independent models are asked the same thing and all land on the same answer, the chance they share the exact same hallucination drops sharply. When they disagree, you have found the precise claim to check by hand before it ships.

That is what TrueStandard does: it runs your draft through four to five frontier models at once and surfaces every disagreement in about a minute, with sources. See the AI fact checker for how the method works, or read why AI cites studies that do not exist for the mechanism behind the failures on this page.

Common questions

Can I trust AI-generated code if it compiles and runs?

No. Compiling and passing a quick test only rules out the most obvious errors. The dangerous failures in AI code are subtle wrong logic, insecure defaults, deprecated APIs, and hallucinated dependencies that pass the happy path. Veracode found 45 percent of compiling AI code still contained a serious security flaw.

What is slopsquatting?

It is a supply-chain attack that exploits AI's habit of hallucinating package names. Because a model reliably suggests the same fake package names, an attacker can register a real malicious package under one of those names and wait for developers to copy the AI's install command. A benign proof of concept using the name huggingface-cli drew over 15,000 downloads in three months.

Does using a better or newer model fix this?

It helps with package hallucination, where the best commercial models are around 5 percent versus roughly 22 percent for open models, but it does not fix security. Veracode found newer and larger models were no more secure than older ones. The fix is verification, not a better model.

What is the safest way to use AI for coding?

Use it to draft and scaffold, then treat every line as unreviewed until you have tested it, security-scanned it, and confirmed its dependencies and APIs are real. Checking the output across several models quickly surfaces the invented packages and insecure patterns that a single model will produce with full confidence.

Do not publish AI output on trust

Paste your draft. Four to five models check every claim in about 60 seconds, and you see exactly where they disagree before your name is on it.

See pricing
No Training on Your Data · 60-Second Checks · Full Verification Reports