How I use coding agents without shipping their bugs

I use coding agents every day, and they make me faster. But only because I never let one work without a spec, tests and a review before anything merges.

That's the whole trick. Coding agents are very good at typing and not reliable at judgement. So I keep the judgement and hand over the typing, with checks in between that catch the agent when it's confidently wrong.

What's the difference between a coding agent and autocomplete?

Autocomplete suggests the next line while you type. A coding agent takes a whole task. It reads the files it needs, plans a change, edits several files, runs the tests and tries again when they fail.

That's a big jump in what it can do, and in what it can get wrong. Autocomplete makes a bad suggestion you can see. An agent can make twenty changes across a codebase, and one of them quietly removes a permission check.

Why does AI-written code need extra checking?

Because it looks right. It's tidy, well named and often passes a quick glance. That's exactly what makes it risky.

One large Veracode study found 45% of AI-generated code failed security tests. The mistakes aren't random. Agents tend to skip what wasn't asked for: the permission check, the input check, the error case. They sometimes pull in a package that's out of date, or one that doesn't exist at all. None of that shows up in a demo.

How do I set up a task for an agent?

The same way I'd set one up for a sharp new engineer who doesn't know the codebase yet.

1. 01Write the specWhat changes, what doesn't, how we'll know
2. ↓→
   02Tests firstThey fail now and should pass after
3. ↓→
   03Agent worksSmall change, in a branch
4. ↓→
   04Checks runTests, types, security scan
5. ↓→
   05I reviewEvery line, before it merges

The spec is short, a few lines. But it's the most important step. A vague task gets a confident guess, and the guess is usually 80% right in a way that takes longer to untangle than writing it from scratch.

What goes in the repo so the agent stops guessing?

A file of instructions that every agent reads first. Claude Code reads CLAUDE.md. Other tools read AGENTS.md. I write one for every repo I work in, and for client teams it's the first thing I set up.

Question	What it says	What it prevents
How to build and test	The exact commands, and which tests to run	Changes that were never actually tested
How the code is organised	Where things live, and the patterns to follow	A second, slightly different way of doing the same thing
Security rules	How permissions, secrets and inputs are handled	Skipped checks and keys written into code
Hands off	Files and folders the agent may not change	Edits to payments, migrations or generated code
Style	Naming, comments and formatting, matching the code around it	Code that works but reads like a stranger wrote it

A good instructions file is the cheapest improvement you can make. It turns "the agent keeps doing it wrong" into "the agent does it our way".

What do I never let an agent do on its own?

A short list that doesn't change, whatever the tool:

• Run migrations or anything against production. It writes them. A person runs them.
• Change payment, sign-in or permission code without a review. These get a line-by-line read, every time.
• Read or write secrets. Keys live in settings the agent can't see.
• Merge its own work. Nothing reaches the main branch without a person approving it.

These rules matter more as the agents get better, not less. A more capable agent makes bigger changes, faster, and a mistake in a big change costs more to find.

Is your team ready for coding agents?

1. Does every engineer use AI tools in their own way, with nothing written down?Yes →Start with an instructions file in each repo and a shared set of rules.No ↓
2. Can AI-written code merge without someone reading it?Yes →Add a required review before merging. It's the single biggest safeguard.No ↓
3. Do your checks run without a security scan?Yes →Add one to every pull request. It catches the mistakes agents make most.No ↓
4. Could an agent touch payments, migrations or secrets without anyone noticing?Yes →Mark those areas as hands-off in the repo instructions and in code review rules.No ↓
5. Are reviews falling behind because there's more code than people to read it?Yes →Make the tasks smaller. Small diffs get real reviews. Big ones get a nod.
6. Still no →You're in good shape. Review the setup every few months, because the tools change that often.

Coding agents are worth using. They just need the same discipline you'd give any new engineer, written down so it holds. If you'd like help setting that up for your team, that's my agentic coding setup. Or send me a note about how your team works today.