2 min lesson
Spec the metric as a code-linked, reviewable doc
Tell someone how to act on this idea: "The old way to spec a metric change was a design doc in Notion or Drive, disconnected from the code it described."
Step 1 of 2
Spec the metric as a code-linked, reviewable docthe workflow, not just the definition
The old way to spec a metric change was a design doc in Notion or Drive, disconnected from the code it described. Cursor's plan mode loads the plan beside the code, so a step can point at the exact file and snippet it will touch. You edit the plan directly - delete a chart step and the agent drops it, add a step to ask for a test or a different cut. Check the plan into git and it becomes a reviewable paper trail your team can argue over before any query runs.
You can run several plans at once through separate non-conflicting agents - a notebook and a web app drawing from the same DB - without them stepping on each other.
“I would always have the technical design doc in Notion or Google drive and I wouldn't be able to actually be like here's the code I want to change. With plan mode you'll have everything in one place.”
The same surface handles the messy front end of metric work. It is strong at pulling a sprawling Excel sheet into a notebook: point it at the raw data and ask for a Jupyter notebook that queries it, so the metric work starts in code instead of a spreadsheet.
A metric the org distrusts is worse than no metric, because every meeting devolves into arguing about the number instead of the problem. Data-quality checks, clear ownership and a single source of truth are not hygiene - they are what make the metric usable as a decision input at all.