DEV Community: michael smith

5 code smells I keep finding in AI written codebases

michael smith — Fri, 25 Sep 2026 06:08:22 +0000

I spend most of my days thinking about code health. Lately, a growing share of the code I look at was written by an AI and approved by a human who skimmed it at best. After enough repos, the same problems show up so often that I can spot them within seconds. Here are the five I see most, why each one happens, and the practical fix I reach for every time.

1. The same helper, written three times

Ask your AI for a date formatter on Monday and a slightly different one on Tuesday, and you will get two near identical functions living in two different files. Models are lazy about abstraction. They would rather paste a fresh copy than hunt down the existing one and reuse it. Studies of enterprise repos have reported duplication climbing sharply since AI assistance went mainstream, with one analysis putting the increase at nearly eight times.

The cost shows up later. A bug in the logic now lives in three places. A behavior change means three edits. Nobody remembers all three exist.

The fix is boring and it works. The moment you spot the second copy, stop and extract the shared version. Give it a clear name, put it where the whole codebase can reach it, and delete the copies. Ten minutes now saves a week of archaeology later.

2. Three ways to do the same thing

One module validates input with a library. Another hand rolls its own checks with regex. A third skips validation entirely because the demo never sends bad input. Same story with error handling, logging, and state management. Small differences in how you phrase a prompt produce different solutions to identical problems, and over weeks the codebase fills with parallel approaches to the same concerns.

This is the one that hurts teams the most, because every new contributor has to learn three systems instead of one.

The fix: pick one approach per concern and write it down. A short conventions note in your repo, even just a paragraph per topic, beats a thousand lines of drift. Then tell the AI about it. Paste the conventions into your prompt or your agent instructions. Models follow written standards surprisingly well when you actually give them some.

3. The happy path, and nothing else

AI generated code adores the sunny day scenario. The form submits. The API returns 200. The payment succeeds. Everyone claps. Now ask what happens when the network drops halfway through the request, the API returns a shape nobody expected, or the user double clicks the submit button. Silence. The unhappy paths are where production incidents live, and they are exactly what the model skips when you do not ask.

The fix: for every AI written function that touches the outside world, meaning networks, files, payments, or user input, ask one more question before you merge. What breaks here, and what should happen then? If the answer is not in the code, send it back. This single habit catches more real bugs than any linter I know.

4. Secrets in the frontend, auth as an afterthought

This is the scary one. Reports on AI built apps keep finding API keys sitting in frontend bundles and routes with no protection at all. One 2026 report that scanned thousands of AI built applications found nearly half exposed secrets in frontend code. The model will happily hardcode a key to make the demo work, because making the demo work is what you asked for.

Worse, auth logic is where AI confidence most exceeds AI competence. The code looks right. The login works. But the authorization check you assumed is there might not be, and you will not find out from the demo.

The fix has two parts. First, every secret lives in environment variables, never in committed code, no exceptions. Second, treat any AI generated auth code as guilty until proven innocent. Read it line by line. This is the one file you do not skim. If you only review one thing this week, make it this.

5. No tests, just vibes

Only a small fraction of AI built apps ship with meaningful test coverage. The demo works, so nobody writes the test. Then month three arrives, something breaks, and nobody understands the system well enough to fix it quickly. A fix that should take an afternoon turns into weeks of digging through code nobody wrote and nobody read.

The fix: make the AI write the tests too, but put the same care into the test prompt as the feature prompt. Tell it the edge cases you care about. Name the sad paths explicitly. A test you never read is better than no test at all, but a test written from your spec is better still. Future you, debugging at midnight, will be grateful.

Why I am building a score for this

None of this means AI coding is bad. It means the review step matters more than ever. The teams getting the most out of these tools treat the AI as an acceleration layer on top of real engineering habits, not a replacement for them. Speed plus judgment beats speed alone, every time.

I am building Code Sonar because I wanted a simple answer to one question: how healthy is this codebase, really? You connect a GitHub repo and run a scan. You get a code health score from 300 to 850, plus plain English findings that point to the exact file and line, tell you how severe each issue is, and estimate how long a fix should take. Free scans are coming soon. If you want in early, here is the waitlist: https://muse.ai/s/waitlist-page-zxc6q7xbxii91n

The 10-minute code health check I run on every AI-generated PR

michael smith — Fri, 25 Sep 2026 05:07:39 +0000

A preprint that hit arXiv in August (Michels et al.) put a number on something every senior dev already felt: code-review time is up 441% under vibe coding. Generation got fast. Verification didn't.

I'm building Code Sonar, a tool that scans GitHub repos and scores code health from 300 to 850, with plain-English findings that include the file, line, severity, and a fix-time estimate. Free scans are coming — there's a waitlist at the end of this post. But regardless of what tooling you use, here's the 10-minute health check I run on every AI-generated pull request before it gets near main.

1. Read the diff, not the summary

The PR summary the agent wrote is marketing copy. The diff is the product. I scroll the actual changes top to bottom, and I specifically look at files I didn't expect the change to touch. AI-generated PRs have a habit of "helpfully" refactoring adjacent code or touching config nobody asked about.

2. Hunt for duplicated utilities

This is the single most common thing I find. GitClear's analysis of 211 million lines of code found copy-paste patterns rose 48% after AI adoption while refactoring dropped 60%. The model doesn't know your codebase has a formatCurrency helper three files over — it just writes another one. Search for the function name and its obvious synonyms before approving.

3. Interrogate the unhappy paths

AI-generated code is relentlessly optimistic. It handles the happy path beautifully and waves vaguely at everything else. My mental checklist: What happens when the API returns an error? When the token expires? When the input is empty, malformed, or enormous? A password-reset flow I once reviewed worked perfectly in testing — and quietly never invalidated old reset tokens, so every link stayed valid forever. The code looked like a tutorial because it basically was one.

4. Ask "where are the tests?"

Researchers at Missouri S&T gave this a name in 2026: GIST, GenAI-induced self-admitted technical debt. When they combed GitHub for AI-related TODO/FIXME comments, developers most often flagged AI code for incomplete implementation and deferred testing — not design flaws. The structure usually looks fine. The verification is what's missing. If a PR adds behavior without tests, that's the review, not a footnote.

5. Get a second pair of eyes that isn't you

You're tired, the diff is 400 lines, and it "looks right." That's exactly the moment bugs slip through — an Anthropic study found AI-assisted engineers scored 17% lower on code comprehension quizzes, not because of the tool but because of the posture: passive "just make it work" delegation. Run your linter, your type checker, your security scanner. Whatever you run, run it on AI-generated code with more suspicion, not less.

The uncomfortable math

None of this is anti-AI. I use these tools every day — the velocity is real. But output volume got conflated with productivity, and the verification bill always comes due. Ten minutes of structured skepticism per PR is the cheapest insurance in software right now.

I'm building Code Sonar to automate the boring parts of this checklist: point it at a GitHub repo, get a 300–850 code-health score and plain-English findings with file, line, severity, and fix-time estimates. Free scans are on the way — join the waitlist here: https://muse.ai/s/waitlist-page-zxc6q7xbxii91n

What's the worst thing you've caught in an AI-generated PR? I want the horror stories.

I'm building a credit score for code health — starting with vibe coders

michael smith — Thu, 24 Sep 2026 23:20:59 +0000

The fastest-growing codebase in the world right now is code nobody fully read. AI writes it, humans ship it, users depend on it. I think "did the AI write good code?" is about to become a real question teams ask.

Code Sonar is my answer: deterministic scoring (same repo, same score, every time — no vibes in the scoring), 8 checks, results in seconds, findings written for humans. Free scans coming while I build in public.

If you've shipped AI-written code, I'd genuinely like to know what score it gets — and whether you trust the number.

(I built this.)