A copy change and a database migration can arrive as the same thing: a short message to a coding agent. The effort of asking tells you almost nothing about the consequences of getting it wrong.
That is the decision I want to make before the agent starts. How much structure does this particular piece of work need? Too little, and the agent fills the gaps with assumptions. Too much, and I spend the afternoon maintaining a process for a change I could have checked in the browser.
Start with the cost of a mistake
The size of a diff is a poor measure of risk. A one-line permission change can expose customer data. A large visual refactor might be straightforward to inspect and easy to undo. I care more about what the change touches, who it affects and how we would recover.
For a small interface adjustment, a clear request and a visual check may be enough. I want to see the actual result, including the state or screen size that prompted the change. A passing build cannot tell me whether a label is centred.
A booking flow needs more. What happens when a slot is taken while someone is completing the form? Can a retry create a second booking? Those questions belong in the brief and the checks, while the implementation is still cheap to change.
A migration or billing change needs a recovery plan as well as a success case. I want the affected data understood, the failure paths exercised and the authority to make the production change explicit.
Keep the brief close to the work
My starting point is usually small: the problem, the expected behaviour, what is out of scope and how I will check the result. I add detail when there is a decision to preserve or a risk to control.
That last condition matters. A document earns its place when it prevents someone from having to guess. If a page of process merely repeats the task in more formal language, it adds another thing to keep up to date.
I also want the agent to read the existing implementation before proposing a new one. Many apparently difficult architecture decisions become ordinary changes once you understand the conventions already in the codebase.
Make the next step reviewable
Working alone does not remove the need for review. It makes it easier to skip. I prefer changes small enough that I can explain what they do and inspect the important parts without reconstructing an entire project.
For a larger feature, that often means starting with a narrow path through the real system. It exposes missing assumptions earlier than building every layer separately and hoping the pieces fit at the end.
The check at the end should answer the question we started with. A screenshot can settle a spacing change. A permission change needs evidence about who can access what. The amount of ceremony can vary; the connection between the problem and the evidence should stay clear.
The process is doing its job when I can make the next decision with less uncertainty. That is what I am trying to buy with it.