In the previous post, I talked about how "you can only direct others once you've done it yourself." The next question remains: so how exactly do you give directions?
When I delegate work to an agent, the results often don't match my expectations. Looking back, it was rarely a technical limitation. Most of the time, the problem was on my end. What ultimately determines the outcome is whether I'm in a state to evaluate the result. Without judgment criteria of my own, I either accept whatever the agent produces or feel vaguely dissatisfied. Building those criteria is, in the end, the process of structuring my own intent.
Structuring intent requires raw material first. I run enough research and planning. Sometimes I have the agent analyze the current code structure so I can verify its understanding. Sometimes I push into suspected gaps in the spec myself to expose them. Sometimes I have the agent enumerate edge cases first, then align with the PM or designer. The method varies by situation, but the goal is the same: securing a state where I can verify the result.
Once I have judgment criteria, I decide what to specify and what to leave to the agent. Say we've agreed to build a card UI. Details like text overflow handling or hover states often exist only in my head. The agent fills in what I don't say, using its own judgment. The odds of its defaults matching the picture in my head are low. But specifying everything means the cost of writing the prompt exceeds the cost of just building it myself.
So I start by putting everything in the prompt. When I notice I'm repeating the same instructions, that's when I elevate them to rules. In intent engineering, directional guidance is called a steering constraint, while absolute limits are called hard constraints. Prompts lean toward steering; rules lean toward hard.
Rules don't need to be front-loaded. Models keep getting stronger—what required explicit specification six months ago may be unnecessary now. It's better to build up incrementally and keep only what's needed.
That's what you can do before execution. Once preparation is done, I hand off execution in units I can review. But I keep reviewing the results. No matter how thorough the preparation, unexpected things surface during implementation. Specs aren't documents you write once and finish—they're documents you keep revising as you see implementation results.
As I review, recurring patterns emerge. When the same kind of mistake keeps appearing, that's a signal it can be elevated to a rule. This task's prompt ends with this task, but rules carry over to the next.
Designing delegation means structuring your intent and redrawing the boundaries each time. The more you repeat, the more rules accumulate, and the lighter the boundary-drawing becomes.