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?
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.