After a while of working with agents in our team, we started noticing a pattern: the higher someone’s seniority, the better the result they got. Especially clean with experienced tech leads. They weren’t fixing the agent’s code — they were just structuring their thoughts correctly.
I’d be experimenting with increasingly complex tasks, selling these ideas to the whole team with excitement, and then they’d come back disappointed — that I’d tricked them, that the same approach hadn’t worked for them. So why?
The answer is simple: I’d been writing “prompts” for the last five years of my life — just not for agents. First for developers, then for tech leads. You know what information to provide to get the right result, because you’ve already stepped on the rake of someone lacking context and shipping the wrong thing.
Any engineering leader will recognize the type: senior on the hard skills, junior on the awareness. Technically strong, writes good code, but doesn’t ask questions, doesn’t push back on the spec, doesn’t check in along the way, doesn’t surface risks. Does exactly what they were asked — even if what they were asked was wrong.
Agents are very similar to those folks. And they need to be worked with the same way.
Imagine you’re handing such a developer a task on a new project.
Before the task, you usually walk them through a bunch of stuff: how things are structured, what to pay attention to, where you’ve already burned yourself. With an agent, all of that has to go into the prompt. It won’t re-ask, won’t come back to clarify — it’ll do what it sees.
Next, they need something to read. That’s the project’s docs. If there are none or they’re stale — that’s an old debt that never made it to the top of the list. Now there’s a reason to deal with it: for an agent, docs are continuously-applied rules of the game.
Backstopping you is the same routine we already keep around live developers: tests, linters, CI. With an agent they’re doubly necessary: they catch errors before you do and save hours of line-by-line manual review.
When the agent gets it wrong, the important thing is not to patch it manually but to understand what it was missing — context, a rule, a test — and add that for next time. Same as with a team: blame the process, not the person. Sort it out once and the same story won’t repeat.
If you’re good at giving tasks to developers of that type — you already know how to work with agents. Same skill, just a different recipient.