When a tool needs code
Code appears when a tool needs moving parts.
A reusable prompt is enough for some work. A checklist is enough for some work. A tool card is enough for the first version.
But if the tool needs to handle a list, remember a value, make a decision, repeat a step, connect to another tool, or check itself, code becomes useful.
Take the weekly metrics email. A prompt can draft the wording. But "flag any metric that dropped more than 10% from its four-week average" is arithmetic across a list — a step a model will eyeball and sometimes get wrong, and a step three lines of code get right every time. Same with a runbook tool checking a server name against an approved list: that is a lookup, not a judgment call.
The weak ask is:
Read these numbers and tell me which metrics look off.
The builder ask is:
Compute which metrics dropped more than 10% from their four-week average, then draft the email around the flagged ones.
If you already ran a studio on this path, you already wrote some of those moving parts. This lesson is why they showed up.
If you are starting here, the next chapter reads small tools: names, values, simple outputs.
A variable is a name attached to a value so a tool can use it later.
Code is what tools need when they grow moving parts.
This matters because knowing which steps belong to the model and which belong to code is the difference between a tool you trust and one you babysit.
Next, look at your own tool card and mark the one step a model might fumble — that step is your first candidate for code.