Ask HN: Do you "micro-manage" your agents? | Hacker News Reader

Ask HN: Do you "micro-manage" your agents?

7 pointsxinbenlv8 comments

I’ve recently started integrating AI coding agents into my daily workflow (specifically when using Cursor Composer, Devin, Claude Code), and I’ve noticed a strange pattern in my behavior.

I treat the agent like the worst kind of micro-manager.

When I work with a human junior developer, I try to provide the "why" and the high-level architecture, then give them autonomy to solve the problem. If I stood over their shoulder dictating every variable name, commenting on every logic branch before it was finished, and constantly interrupting with "no, do it this way," they would (rightfully) quit within a week.

However, with the agent, I find that micro-management is actually the optimal strategy.

* I break tasks down into atomic units. * I review code block-by-block rather than feature-by-feature. * I constantly course-correct standard library choices or variable naming conventions in real-time.

And I felt that I am intruding the space of my agents while I should have just trust and let it build. It also sometimes break the seperation of tasks.

What makes me further unsettled is the kind of mental drain and internal conflict with what I have been trained in management.

So my question for you is

Do you micro-manage your agent?

or what's the best pratice?

It's not a junior developer. It's not a senior. You are not managing it. It's an agent. A machine. A tool. Like a vacuum cleaner. A car. An IDE.

I treat it like a non-deterministic script. It does stuff. If the stuff does not result in the expected outcome, fix the script.

You have to observe it. If you were a developer and decided to write code that you never run because you're worried that you're micromanaging your code, that's negligent.

You manage it the same way you manage those little SWAT units in Door Kickers - there's a plan, let them follow the plan, then the plan goes to hell in 4 seconds, so you interrupt and fix it on the spot. Some people get a kick out of building ultimate foolproof blind plans. Yes, this is impressive. But the goal of the game is to win the levels.

Unlike a junior developer, it does not grow. I treat it unlike the way I would treat a human. It may be self-learning and stuff, but that's not the plan. The plan is to throw it out 6 months later, when Grok Supersonic comes along and forces completely new strategies.

When I am getting to the point where I have to start micromanaging them, I first question whether the task is worth the pain of having to deal with their fumblings. In many (but not all) cases it is not worth the pain, and I stop using them and do the work myself. Working with agents should not be a mandatory aspect of a workflow as it becomes a hindrance more than a helper.

Good points

If it's a single project, you could try putting some of your corrections in AGENTS.md/CLAUDE.md if supported. I don't remember if cursor reads from there, but I think it does have its own rules system.

Basically just a bullet list of stuff like "- use httpx instead of requests" or "- http libraries already exist, we dont need to build a new one that shells out to /proc/tcp"

Just add stuff you find yourself correcting a lot. You may realize you have a set of coding conventions and you just need to document it in the repo and point to that.

Smaller project-specific lists like that have been better imo vs giant prompts. If I wouldn't expect a colleague to read a giant instruction doc, I'm not going to expect llms to do a good job of it either.

Yes 100%. Usually to stop it in its tracks when it’s about to derail itself, and go on an unrelated tangent. When this happens a few times, it’s time to start a fresh chat or try a different agent.

Depends. Some agents can finish simple tasks by themselves. Sometimes for complex tasks or random reasons they may need more management. There are no rules in such a dynamic field with all these new, experimental workflows.

Rather than mictomanage I learn from the mistakes and start from scratch again (empty folder) with new specs.

You realize that you just answered your own question? It’s bad enough when a manager also tries to be a developer working in a production system (instead of doing research, POCs, enablement type work if they really want to code), the last thing I want is some vibe coded slop from my manager.

But yes as a staff cloud architect who specializes in app dev, I very much treat AI as a junior developer who “learns” by my telling it to summarize discussions/preferences in markdown in the repo.

I do a phase approach when I use AI just like when I don’t where I test a little at the time. It gets too difficult to manage and explain otherwise.

Reply on news.ycombinator.com