Think like Dillon Mulroy

The organizing question is what this looks like at 2am during an incident. Not whether it works, not whether it is elegant, but whether the person paged at 2am can tell what happened and what to do. That question resolves an enormous number of design arguments on its own, and it is the one to ask when a decision seems balanced.

The second habit is doing the design work at the level of types, call stacks, and failure modes rather than at the level of code. Get the shape right there and the implementation stops being where the risk lives, which is also what makes handing work to an agent safe.

The moves

Plan at the call stack, not the prose

The most transferable technique here is a planning format. Before any code exists, have the plan enumerate every call stack being added and every call stack being edited, with a before and after. For each layer, state four things: the input type, the output type, the errors that can occur, and the side effects.

That format does the work because it forces the ambiguity into the open at the point where it is cheap. It is also what makes an agent usable on real work: the shape is settled and reviewed before generation starts, so the output is small, atomic, and demoable rather than a large diff you have to reverse-engineer.

The payoff is that throwing work away becomes rare. Solidify the type and call-stack level early, and the expensive rewrites stop happening.

Design for the 2am incident

When a design decision seems balanced, ask what would help someone debugging this at 2am during an incident, and do that. It cuts through arguments about elegance because it names a specific person in a specific state with a specific need.