Design before the agent codes

An agent is fast at the part that looks like typing. It is casual about the part that looks like a blank page. If you hand it the blank page, you will get a shape, and the shape will be whatever the model has seen most often. That is a default, not a design.

The useful order is the other way around. Draw the boxes. Name the boundary that is not allowed to leak. Decide who may write the response, who may call the tool, who may open the port. Then ask for an implementation of a box you can already point at.

A test of whether you did this: you can reject a plausible diff. If every suggestion sounds fine, you did not have a design. You had a mood. The agent will fill a mood with libraries.

I keep the picture small enough to redraw. Five boxes, the arrows, and the failure I am designing against. A step budget. A tool list. A response that only one owner is allowed to finish. When the implementation argues with the picture, the argument is the work. Updating the picture on purpose is fine. Discovering the picture inside a pull request is how the default wins.

None of this requires disliking the tools. It requires noticing what they are quick at. Implementation is a good place to be quick. The boundary is a bad place to be surprised.

This is a sample of how I want the notes to sound. It is not a case study of a particular system at a particular company.