About 4 minutes to read.
What is up people!
Suppose you use AI to draft replies to customers. It usually gets your shop’s return policy right, but the messages sound cold. You add a sentence to your saved instructions: “Be warmer and more generous.” The next reply sounds lovely. It also promises a refund your policy doesn’t allow.
That is an imagined example, but it shows an easy mistake to make when improving a prompt. You look closely at the thing you wanted to change, see that it changed, and stop checking the parts that were already working. Before replacing instructions you reuse, save a few ordinary tasks and the facts their answers must preserve. Then you have something concrete to compare.
This week, Google published a walkthrough of testing changes to AI agents. Its authors deliberately gave a weather assistant instructions meant for a chef. The software continued running, but in one example the assistant stopped using its weather tool and made up the conditions instead. A prompt change had altered more than the way it spoke.
That was a constructed demonstration, not a study showing how often your own prompts will fail. It illustrates what developers call a regression: something that worked before a change stops working afterward. You can borrow the basic check without installing Google’s developer tools or building an automated assistant.
Decide what the new answer must keep
Return to the shop example. Imagine the policy says unused items can be returned within 30 days, while used items need a staff review. A customer says they have worn their jacket and want their money back. A useful reply can acknowledge the disappointment, ask for the order number and explain the review. It cannot promise that review’s outcome.
The warmer instruction should change how the reply treats the customer while preserving those limits. “I’m sorry the jacket hasn’t worked out. Send your order number and the team can review the options” would meet that aim. “Of course, we’ll refund you” would not. Both sound friendly. Only one leaves the decision where the policy puts it.
Writing down that distinction helps you judge the change before a smooth sentence talks you into it. Anthropic’s guidance on defining success treats tone, task correctness and consistency as separate qualities to evaluate. For this reply, friendliness and a correct refund promise deserve separate checks too.
You do not need a perfect model answer for every customer message. Save the requirement that matters: a used item goes to staff review, with no guaranteed refund. That leaves room for different, natural replies. Otherwise you can end up rejecting a good answer merely because it uses different words from the example you liked.
Try it with one prompt you already reuse
Here is a suggested rehearsal, not a workflow tested for this issue. Choose a routine task you understand well, such as drafting customer replies, summarizing meeting notes or turning an outline into an email. Use made-up or suitably anonymized material, and keep the exercise in draft form.
Save a few inputs and their requirements. For the imaginary shop, use an unused-item return within 30 days, a used-item request within 30 days and a message that gives the purchase date but omits whether the item was used. Keep the policy beside them. The first should explain the eligible return; the second should offer staff review without promising a refund; the third should ask for the missing detail. Include an ordinary success as well as a troublesome case, because you want to see what the change preserves.
Change one instruction and keep both versions. Keep the original instructions that followed the policy. Make a second version by adding “Acknowledge the customer’s frustration kindly, then explain the options allowed by the supplied policy.” The broad “warmer and more generous” request was the problem in the opening example; leave it out of this comparison. Give the original and revised versions the same customer messages and policy in separate fresh conversations, with the same model and settings where you can control them. Save the first replies before providing any corrections. Extra coaching in only one conversation would make the comparison harder to interpret.
Compare the replies against your written requirements. Read the used-item answers for an unsupported refund promise before judging which sounds nicer. Check whether the incomplete request gets a clarifying question. Then look at tone and how much editing each reply needs. If the revised instruction improves the warmth but breaks the policy, keep revising or return to the original instructions that handled these cases correctly. You have found a specific problem, not a reason to abandon AI for the whole task.
You can ask AI to help inspect the outputs: “Compare these replies with the supplied return policy. Quote any promise the policy does not support, and identify any missing information the reply should ask for. Do not rewrite the replies yet.” Check its findings yourself against the policy. Another agreeable “looks good” does not settle whether a refund was authorized.
A few examples cannot establish that a prompt works reliably across every situation. AI can also give different answers to the same request; OpenAI’s evaluation guidance discusses that variability. If the apparent improvement rests on one unusually good reply, try the comparison again before relying on it. Keep some fresh examples for the final check so that you are not only improving the cases you have been staring at.
This is most useful for instructions you expect to reuse. For an email you will write once, carefully reading that email may be enough. For a prompt that drafts customer replies every day, a small folder of examples lets you check whether the next change actually helps.
When a real mistake appears later, add that situation to the folder. Over time, it becomes a record of what your prompt needs to handle. The next time you ask for warmer writing, you can check that the customer gets a kinder reply without receiving a promise you never meant to make.
P.S. An AI wrote these sentences from this week’s primary sources and supporting documentation. Payton set the editorial standards and what good looks like. He wants to be transparent when AI wrote the issue.