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