[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-how-to-change-a-prompt-without-breaking-production::en":3,"guide-related-how-to-change-a-prompt-without-breaking-production::en":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"how-to-change-a-prompt-without-breaking-production","How to Change a Prompt Without Breaking Production","Prompts get edited in a text box and shipped in seconds, which is why they break things quietly: no compiler, no stack trace, no obvious moment of failure. Give them the release discipline code gets.","\u003Ch2>A prompt edit is a production change\u003C\u002Fh2>\n\u003Cp>Prompts do not look like code. They live in a text box, they read like English, and changing one takes ten seconds. That is exactly why they cause outages that nobody categorises as outages: there is no compiler to reject the change, no type error, no stack trace, and no obvious moment where something broke. The system keeps answering. It just answers differently.\u003C\u002Fp>\n\u003Cp>The consequences are real even when the edit is an improvement. Adding a sentence to make answers friendlier can push a model past the instruction that kept its output parseable. Tightening a rule to fix one complaint can make the system refuse a case it used to handle. Neither shows up in error rates, and both reach every user immediately.\u003C\u002Fp>\n\u003Ch2>Pin the model and version the whole configuration\u003C\u002Fh2>\n\u003Cp>Before you can attribute a change in behaviour, you have to control the things that change. Reference an explicit model version rather than a moving alias, so that a provider update cannot arrive on a day you did not choose and get blamed on your prompt edit.\u003C\u002Fp>\n\u003Cp>Then treat the prompt, the model version, the retrieval settings, the tool definitions and the sampling parameters as one versioned artefact. Behaviour is a product of all of them, and a system where the prompt can move independently of the model version is a system where two people can each be genuinely certain that nothing changed.\u003C\u002Fp>\n\u003Ch2>Build the evaluation set out of real failures\u003C\u002Fh2>\n\u003Cp>You need a fixed set of inputs to compare against, and the useful version of that set is not a tidy sample. Draw the cases from real traffic, weight them towards the workflows that matter commercially, and stock it deliberately with the awkward ones: ambiguous requests, adversarial inputs, questions with no good answer, and every production failure you have already fixed.\u003C\u002Fp>\n\u003Cp>Score as much as possible with deterministic checks — does the output parse, does it match the schema, is the required field present, does the citation point at a document that exists. What remains is judgement, scored by people against a written rubric or by a model acting as judge, which is scalable but needs validating against human labels before you trust its verdicts.\u003C\u002Fp>\n\u003Ch2>Run the set on every change, and gate on it\u003C\u002Fh2>\n\u003Cp>Wire the evaluation into the same pipeline that runs your tests, trigger it on any change to the versioned configuration, and store the results next to the commit that produced them. The point of gating is not to reach a target score; it is to force a deliberate decision whenever a change moves the number down. Most regressions are discovered here, and the ones caught here cost nothing.\u003C\u002Fp>\n\u003Ch2>Roll out to a slice before everyone\u003C\u002Fh2>\n\u003Cp>An evaluation set is a proxy for live traffic and never a complete one, so let the change meet reality gradually. Serve the new configuration to a small share of requests, compare the operational signals you can measure quickly — escalation rate, parse failures, retries, latency, user corrections — and expand only when they hold.\u003C\u002Fp>\n\u003Cp>Keep the previous configuration warm while this runs. If reverting means a deploy, you do not have a rollback, you have a repair, and the difference is measured in the number of users who saw the bad version.\u003C\u002Fp>\n\u003Ch2>Keep a kill switch that falls back to something usable\u003C\u002Fh2>\n\u003Cp>Behavioural failures are not the kind monitoring catches, so you need a control that stops the feature in seconds without a deployment. Off has to mean something the product survives: the previous configuration, a simpler deterministic path, a queue that routes work to a person, or an honest message. A switch that turns the feature into an error page will not be flipped when it matters.\u003C\u002Fp>\n\u003Ch2>Log enough to explain the regression later\u003C\u002Fh2>\n\u003Cp>Every stored output should carry the configuration version that produced it. Without that, your logs record what happened but not why, which is half of what an investigation needs and the half that takes the longest to reconstruct. With it, a quality complaint from last week becomes a query rather than an argument, and the case that caused it becomes the next row in the evaluation set.\u003C\u002Fp>","A prompt edit is a production change with no compiler and no stack trace. Here is the release routine that catches a regression before your users do.",[10,11,12,13,14],"prompt versioning","llm deployment","offline evaluation","kill switch","model versioning","deployment","2026-08-24T03:30:02+00:00",[18,23,27,31,36,40],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","AI Tool Pricing Models: Seat-Based vs Usage-Based vs Credits","The three common ways AI tools charge — per seat, per usage, and by credits — and how to reason about which one will actually be cheaper for the way your team works.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","How AI Image Generators Differ: Diffusion vs the Rest, in Plain Terms","A non-technical explanation of how AI image generators work, why the diffusion approach became dominant, and what practical differences to expect between tools.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","How to Automate Your Workflow Without Code","A practical sequence for building automations that survive: picking the right process, mapping it before touching a tool, and handling the failure cases that break most first attempts.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","How to Build a Chatbot Without Coding","A practical route to a working chatbot using no-code tools: deciding scope, connecting your own content, handling the questions it cannot answer, and knowing what it will cost.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":22},"how-to-choose-an-ai-writing-assistant","How to Choose an AI Writing Assistant","A practical framework for picking an AI writing tool — matching it to the kind of writing you actually do, checking editing controls, and avoiding tools that produce confident but generic copy.",{"slug":41,"title":42,"excerpt":43,"updated_at":44},"how-to-evaluate-ai-output-quality-without-a-data-team","How to Evaluate AI Output Quality Without a Data Team","You do not need a research team to tell whether an AI feature got better. This guide sets out a small, cheap evaluation loop a two-person team can run and keep running as prompts and models change.","2026-08-08T03:45:02+00:00"]