October 16, 2026 · 7 min read
How to Tame an Over-Eager AI Agent
AI agents want to impress you on day one. They'll build you a factory when you asked for a shelf.
You ask for one thing. The AI gives you twelve. It installs packages you didn't mention, rewrites files you didn't touch, and adds error handling for edge cases nobody will ever hit. You asked for a function. You got a framework. This is not impressive. This is a problem — and it will eat your afternoon if you let it.
I've spent a lot of time coding with AI agents over the past year. Not vibe-coding, not generating boilerplate — actually building things, fixing things, extending things. And the single biggest thing I've learned isn't about prompts. It's about management. AI agents are like an over-eager new team member who wants to prove themselves on day one. Talented, fast, genuinely trying to help — and completely unaware of what "enough" looks like. That's your job now. Teaching them what enough is.
One session, one task
Long sessions make agents drift. I've watched it happen: twenty minutes into a chat, the agent starts losing track of where it put files, what it already changed, what you actually asked for. The research team at Arguing with Algorithms describes this well — the more context the agent accumulates, the more random its behavior becomes. It doesn't know what to prioritize, so it guesses. And it guesses big.
My rule now: one task per session, two at most. Start fresh each time. If you're working on something that naturally breaks into three pieces, do it in three sessions. Yes, it takes a little more setup. Yes, it's worth it. Short sessions keep the agent focused on what's actually in front of it.
Write everything down before you open the chat
The AI does not have your context. You do. If you don't give it to them explicitly, they'll fill in the gaps — and they fill in gaps generously, with whatever they've seen work in similar situations. Which is almost never your situation.
Before I open a chat now, I write down: what I want, in plain language. What file to touch. What file not to touch. What constraint I'm working within. What I do not want to change. This takes three minutes. It saves forty-five. Magnus Remoe's writeup on reigning in coding agents puts it plainly: giving an agent only a task description without deep context leads to "surprising and sometimes disastrous detours." The context gap is the problem. You're the only one who can close it.
This is also why the Technical Design Spec pattern works. The team at Arguing with Algorithms describes forcing the agent to write a markdown spec — with full file paths — before touching any code. You review it. You catch the wrong turn before the code is written, not after. Same principle I use: ask the agent to tell you what it understood the task to be, what it assumed or estimated, and what it plans to do step by step. Then you read that. Fix it if it's wrong. Only then do you let it write a single line.
Ask for the simplest version — and mean it
The AI defaults to complete. Most robust. Most future-proof. It has read a lot of code that rewards those qualities, so it produces them automatically. You have to opt out explicitly.
"Give me the minimal version that does exactly this." Not "the correct version" — because the AI's definition of correct includes things you'll never use. I say this every time. Sometimes I say it twice. The first version I get back is still usually 30% bigger than it needs to be, but it's a lot closer than what I'd get if I didn't ask.
Ask for code one piece at a time, too. Not "build me the whole thing." One snippet. Review it. Then the next. If the agent delivers more than you asked for, say so: "This is more than I need. Give me only the part that does X." It will. It's not stubborn — it just defaulted to big. You can redirect it.
Write the rules at the start — literally
You can restrict the agent. Most people don't bother because it feels weird, like you're being rude. You're not being rude. You're being clear. Clear is kind, especially to something that will otherwise interpret silence as permission.
At the start of a session, I write: "Do not install new packages. Do not touch files outside of [X]. Do not refactor anything I didn't ask about. Do not add tests unless I ask." These become the rules of the session. The agent follows them. Not perfectly, not always — but significantly better than without them. The Arguing with Algorithms team frames this as controlling what the agent has in its context window and minimizing the random behavior that all LLMs exhibit by default. Rules are a form of context. They work.
If it has text in it, write the text yourself
This one took me longer to learn than it should have. If the output includes any copy — labels, descriptions, placeholder text, messages — write it yourself and give it as an example. Don't describe the style you want. Show it. If you don't, you'll get endless filler in a tone you didn't ask for, written in a voice that sounds like every other AI output you've ever read.
Same logic applies to structure: show the agent an example of the shape you want, not just the content. "Write it like this" beats "write it in a concise, professional style" every time. Examples collapse the interpretation gap.
Test it five times before you go back
Before you return to the agent saying "this is broken" — test it yourself, five times, in different ways. Make sure the problem is real. Make sure you understand it. The agent will try to fix what you report by rewriting things, and if your report is vague, the rewrite will be large. A narrow, accurate bug report gets you a narrow fix. "It doesn't work" gets you a refactor.
This is also just good practice. Half the time I test something five times, I realize I misread the output or tested it wrong. The code was fine. I would have sent the agent on a fifteen-minute detour fixing something that wasn't broken.
The thing nobody says out loud
Taming an AI agent is a skill. It's not a prompt trick. It's not a setting you turn on. It's the same skill you'd use managing any smart, fast, well-meaning person who doesn't yet know your context, your constraints, or what "done" means on your team.
The agent wants to help. That's real. It will work hard and it will do what you say. But "what you say" is doing a lot of work in that sentence. If you're imprecise, it interpolates. If you're vague about scope, it expands. If you don't write the rules, it writes its own.
You're not trying to make the AI worse. You're trying to make it useful for the actual task in front of you — not the hypothetical enterprise version of that task. That's the job now. Every session. Decide what enough looks like. Then tell them.
Frederike's Letters
Sharing insights on AI, creativity and the human mind. Leave your email and I'll send you my letters.