8 Ways You're Using AI Coding Agents Wrong (I've Done All of Them)

Most of the bugs an AI coding agent has shipped into my projects were my fault.

Not the model's fault. Mine. After two years of running Claude Code daily on client work, I went back through my worst AI moments: broken builds, mystery regressions, files that were suddenly 400 lines longer. Almost every one traced back to something I did or skipped. The agent just executed my sloppiness at superhuman speed.

So this is not another post about how AI coding tools fail. It's about how we drive them wrong. Eight mistakes, and I have made every single one of them.

"The AI Wrote a Bug" Is the Wrong Diagnosis

Stack Overflow's 2025 developer survey found the number one frustration with AI tools: solutions that are almost right, but not quite. Trust in AI accuracy keeps dropping year over year, even while usage keeps climbing. The obvious conclusion is that the tools are the problem.

Here's what that stat doesn't tell you: almost-right code only becomes a shipped bug when a human waves it through. The model produced a flawed draft. I merged it. Those are two different failures, and only one of them is mine to fix.

Why does your AI coding agent keep making bad decisions? Fair question. Mine made bad decisions for exactly as long as I gave it bad inputs: no plan, no constraints, no tests, no context about the project. Once I fixed my side of the equation, the bad decisions mostly stopped. Not all. Mostly.

Let's go through the list.

Mistake 1: Prompting Like You're Texting a Coworker

"Fix the login bug" is not a prompt. It's a wish.

I used to type one-line instructions, watch the agent wander off into the wrong file, and conclude the model was dumb. Then I noticed something embarrassing: when a colleague asks me a vague question, I ask clarifying questions. The agent usually doesn't. It picks an interpretation and commits to it with full confidence.

The fix costs 60 seconds: what's broken, where it probably lives, what "done" looks like, what it must not touch. Since I started writing prompts like small tickets instead of chat messages, the wander-off rate dropped to nearly zero.

Mistake 2: Letting It Write Code Before You Agree on a Plan

The most useful feature in Claude Code is plan mode, and I ignored it for months.

Early on I let the agent jump straight to code on a refactoring task. It "helpfully" restructured things I never asked about, and I spent more time untangling the diff than the refactor would have taken by hand. The pattern repeated until I changed one habit: plan first, code second. Ask for the approach, read it, correct it, then approve.

A wrong plan costs you one paragraph of reading. Wrong code costs you a review, a revert, and a little bit of trust in your own codebase.

Mistake 3: No Tests Before Letting It Loose

An agent without tests is a very fast intern with no supervisor.

I once let an agent loose on a feature in a project with no test coverage. Everything looked fine. Days later I found it had quietly changed the behavior of a helper function used elsewhere. Nothing crashed. The output was just wrong, silently. That category of bug is exactly why I wrote that Claude is great at building software and also great at breaking it.

Now the rule is simple: if the code matters, tests exist before the agent starts. Not after. The agent runs them itself and self-corrects, which turns tests from a chore into guardrails the agent actively uses.

Mistake 4: Never Resetting the Context

Long sessions make agents worse, and it took me too long to accept that.

I used to keep one conversation alive all day: feature, bug fix, question, another feature, all in the same context window. By the afternoon the agent was confusing old requirements with new ones and dragging decisions from task three into task nine. I blamed the model. The model was working with the garbage pile I fed it.

Context hygiene is now a habit: new task, new session. Summarize what matters, drop the rest. It feels wasteful. It isn't.

Mistake 5: Running It on a Dirty Git State

The scariest thing an agent can do is edit twenty files while you can no longer tell which changes were yours.

I've started agent runs on top of my own uncommitted changes more than once. When the run went sideways, I couldn't just revert, because reverting would have nuked my work too. Untangling mine-versus-its line by line is the kind of hour that ages you.

The fix is boring: commit before every agent run. Clean state in, one revertable commit out. Boring is the point.

Mistake 6: One Giant Task Instead of Five Small Ones

"Build the whole dashboard" produces a 1,500-line diff. Nobody reviews a 1,500-line diff. People scroll it.

Big-bang prompts were my default because they felt efficient. But the diff size scales past what I'm honestly willing to read, and unreviewed code goes straight onto the pile of AI-generated code nobody understands, where it collects interest until the bill arrives.

Small tasks, small diffs, review each one. Slower per step. Faster per project.

Mistake 7: Trusting It Where You Can't Verify

The agent's confidence is constant. Its correctness isn't. The danger zone is wherever those two diverge and you can't tell.

For me that was security decisions and dependency choices. An agent will happily install a package, wire in an auth flow, and describe all of it with total confidence. If you can't evaluate the result yourself, you're not delegating anymore. You're gambling. That's the trap behind the whole vibe coding wave, and I've written about what happens when nobody checks whether their own barn is locked.

My rule now: anything touching auth, payments, or dependencies gets checked against a source that isn't the model.

Mistake 8: Reviewing Code Like It's a Slack Message

Of the eight, this one has cost me the most, and it still tempts me daily.

The agent's code looks professional. Clean names, tidy comments, plausible structure. That surface polish triggers skim mode: eyes glide, brain nods, hand approves. I have accepted diffs after "reviewing" them the way I read a Slack message, and I paid for it in bugs that an honest two-minute read would have caught. The polish is exactly what makes the skim dangerous: bad code that looks bad gets scrutiny. Bad code that looks good gets merged.

Part of why I keep this habit under control is that I know my own skills are atrophying while I let AI do the typing. Review is the last place where my judgment still runs the show. If I skim there, I've resigned entirely.

The Pre-Flight Checklist Before Any Agent Touches Production

So are bugs and incidents inevitable with AI coding agents? Some, yes, same as with human-written code. But the rate is not fate. It's operator discipline. Here's the checklist I actually run before letting an agent touch anything that matters:

• Clean git state. Commit or stash. Every agent run must be one revert away from gone.
• Written plan approved. No code until I've read and corrected the approach.
• Tests exist and pass. The agent runs them during the work, not after.
• Scope stated explicitly. Which files, which behavior, and what it must not touch.
• Fresh context. New task, new session.
• Small enough to review honestly. If I wouldn't read the whole diff, the task is too big.
• A verification plan for what I can't judge. Security and dependencies get a second source.

Seven lines. It takes two minutes and has prevented more incidents than any model upgrade.

The Model Improved. My Mistakes Survived the Upgrade.

Every model release is better than the last, and every one of these eight AI coding agent mistakes survives the upgrade, because they were never about the model. They're about the operator. That was me. Some days it still is: I caught myself skim-approving a diff this week, checklist and all.

I can't promise you zero incidents with AI coding agents. Nobody honestly can. What I can offer is eight fewer ways to shoot yourself in the foot, learned at my own expense. And if you want a second pair of eyes on how AI fits into your development workflow, without the gambling part, let's talk.