arrow_backBack to field notes
AI Published 30 Jul 2026

What Mistakes Do Devs Make Coding With AI Assistants?

A practical look at the most common ways developers misuse AI coding assistants, and how to avoid shipping bugs and vulnerabilities.

AI assistants like Copilot, Claude, and Cursor's built-in models have changed how fast code gets written. They haven't changed how carefully it needs to be reviewed. Most of the damage I've seen from AI-assisted coding comes from a handful of repeatable habits, not from the models themselves.

Accepting suggestions without reading them

The biggest one is tab-accepting a completion because it looks plausible and compiles. Plausible isn't correct. I've watched a suggested SQL query silently drop a WHERE clause during a refactor, and the person accepted it because the variable names matched. If you're not reading every line an assistant hands you at the same speed you'd read a coworker's pull request, you're going to ship something you don't understand. Treat every suggestion as a first draft from a junior dev who is fast but has no memory of your codebase's conventions.

Trusting it with security-sensitive code

AI assistants are trained on huge piles of public code, and a lot of that code has security problems baked in. Ask for a quick file upload handler and you'll often get something with no extension check, no size limit, and a path built by string concatenation instead of os.path.join or a safe library call. Same story with auth: assistants love to suggest storing JWTs in localStorage, or comparing secrets with == instead of a constant-time comparison. None of this is malicious, it's just statistically common in training data. For anything touching authentication, file I/O, deserialization, or SQL, write the logic yourself or run the AI's output through the same threat-modeling questions you'd ask of any new code: what happens with hostile input, what happens if this call fails, who else can reach this endpoint.

Letting it invent dependencies and APIs

Models hallucinate package names and function signatures with total confidence. This is the "slopsquatting" problem — attackers register the fake package names that models frequently suggest, so an unverified pip install or npm install can pull down something that isn't your logging library at all. Before adding any dependency an assistant recommends, check that it actually exists on PyPI or npm, check its download count and last publish date, and skim the source if it's small enough. The same caution applies to API calls: if the assistant references a method you don't recognize, check the actual docs before assuming it exists.

Losing the mental model of your own code

When you write code yourself, you build a mental map of why each piece exists. When you accept large blocks of AI-generated code across a session, that map gets thin fast. Then a bug shows up three weeks later and you're debugging code you never really wrote and don't fully remember. The fix isn't to avoid AI-generated code, it's to slow down enough to explain each chunk back to yourself, or to a teammate, before merging it. If you can't explain what a function does and why it does it that way, don't merge it yet.

Skipping tests because the code

Written with AI assistance, reviewed and published by Michal Pilch (CISSP), Korra Studio.

Ready to go further?

This is one note from the Korra Studio knowledge base — the platform pairs every topic with 1-to-1 mentoring.

Get started freearrow_forward