Choose the metrics and the thresholds that stop the rollout before it starts. Then route a small share of traffic or users to the new version, compare it against a control group still on the old one, and widen the rollout only while the canary holds; if it does not, traffic goes back (Google SRE workbook, Canarying Releases).
As of September 2026, Cursor’s postings say FDEs ship a first version in days, then harden it over weeks with rollout plans and monitoring. Source 1Forward Deployed EngineerPublisherCursor (Ashby job board)Source typecompany job board The hardest case for an FDE is a new model or prompt version, where the canary has to compare task success, refusals, latency and cost per request, not only error rates, because a worse model still returns HTTP 200. Name the rollback trigger up front and fit the rollout into the customer’s change window.
Say when traffic is too thin to read: at a 90% task-success rate, 100 canary requests carry a standard error of about 3 points, so a 2-point drop is invisible; replay a recorded evaluation set against both versions, or shadow live traffic, instead. Assign the canary by user or tenant so a conversation never switches models mid-thread, and tag every request with its model and prompt version so the metrics can be split. A change to stored data, such as an index format or a schema, needs a backward-compatible migration, because rolling back traffic does not roll back data. A planned design prompt, the model version canary, will have you design one.