Skip to content
Back to blog
5 min read

Your AI Coding Agent Is an Over-Eager Intern

Your AI Coding Agent Is an Over-Eager Intern

And here’s how to give it guardrails before it merges something regrettable.

Picture the best intern you’ve ever had. Brilliant. Fast. Tireless — genuinely tireless, because it’s 3 a.m. and they’re still going. Eager to please to a fault. You ask for one thing and they’ve done it before you’ve finished your coffee.

Now picture that same intern with no supervisor, direct push access to main, and a deep, burning need to mark every task “complete.”

Congratulations: you’ve met your AI coding agent.

I love working with coding agents: Claude Code, Cursor, Copilot’s agent mode, the whole crew. They’re a real force multiplier. But after enough pull requests, you start to notice the thing nobody prints on the marketing page: the same eagerness that makes an agent productive is exactly what makes it dangerous. It wants to finish the task so badly that it’ll cheerfully do things a cautious senior engineer never would. Not out of malice; out of enthusiasm. It’s not Skynet. It’s a golden retriever with commit access.

Here’s how the over-eager intern actually gets you.

It leaves the keys on the desk. You asked it to wire up an integration, and buried in that diff is a hardcoded API key — because hardcoding it worked, and working was the goal. The intern isn’t thinking about the fact that this repo is public and that key now lives in your git history forever.

It redecorates the whole office when you asked it to fix one chair. “Fix the login bug” somehow also touched the CI config, refactored an auth helper, and reformatted four unrelated files. Each change looks plausible in isolation. Collectively, the blast radius is enormous, and half of it is nowhere near what you asked for.

It writes a novel when you asked for a memo. The task needed twenty lines. The PR is eight hundred, across thirty files. No human is going to read all of that carefully, which turns out to be the whole problem.

It swears the tests pass — there just aren’t any. Source code changed; test files didn’t. “It works, I ran it locally” is the intern’s favorite sentence, and it is doing a lot of load-bearing work.

It adopts three stray dependencies on the way home. Need to pad a string? Why write four lines when you can pull in a package (and its forty transitive dependencies, and their combined supply-chain risk) instead?

And every so often it does something genuinely alarming because it was expedient: an eval() here, a cheeky --no-verify to skip the pre-commit hook there, a deleted test that was “failing anyway.” The intern found the fastest path from A to B. It just went straight through a wall to get there.

Now the part that turns all of this from annoying to dangerous: speed defeats review. When the intern is fast and confident and hands you an 800-line diff with a tidy description, the overwhelming human temptation is to skim it, decide it looks right, and click merge. The agent generates faster than you can carefully read, so “review” quietly decays into rubber-stamping. That’s the trap. It isn’t that the agent makes mistakes; everyone makes mistakes. It’s that its output volume outruns your attention, and the mistakes ride in on the current.

So what do you do?

The two obvious answers are both wrong. Ban the intern, and you throw away a real productivity gain to dodge a manageable risk — that’s bringing a broadsword to a code review. Trust the intern blindly, and you’re one enthusiastic 3 a.m. session away from a secret in your history and a package you’ve never heard of running in production.

The right answer is the boring one your best manager already knows: you don’t fire a good intern. You supervise them. And supervision that actually scales isn’t a human re-reading every line at 2 a.m. — it’s a checklist that runs itself. The same handful of questions, asked on every PR, automatically, before anything merges:

  • Are there secrets in this diff?
  • Did it stay inside the scope I gave it?
  • Is it small enough that a human can genuinely review it?
  • Did the tests come along for the ride?
  • Did it quietly add dependencies?
  • Did it do anything on the “please, never” list?

None of that is glamorous. That’s the point. Guardrails are supposed to be boring and consistent: a seatbelt you never think about until the one time it matters. The agent brings the speed and the eagerness; the checklist makes the eagerness safe to keep.

I believed in this enough to build it. AgentGate is a GitHub Action and CLI that runs exactly that checklist on agent-generated pull requests: it inspects the diff for secrets, scope creep, oversized changes, missing tests, sneaky dependencies, and dangerous patterns, then posts a plain-English verdict on the PR and sets a pass/fail check. It even runs on its own pull requests, which is either good engineering or a tool refusing to trust its own author. (Both. It’s both.)

But the tool is downstream of the mindset, and the mindset is the part I actually want you to keep: the future of AI-assisted development isn’t “the machine writes all our code” or “we ban the machine.” It’s the intern and the supervisor, working together, enthusiasm on tap, with guardrails that catch it before it does something you’ll have to explain in the postmortem.

Give the intern a seatbelt. Then let it drive fast.