Give an AI feature a fixed evaluation before changing its prompt
A small evaluation set makes AI acceptance concrete. Agree on real examples, failure rules and a pass bar before comparing prompts or changing the model.
By 
Paul. AI and agentic engineering
An AI feature needs repeatable evidence that it handles the work you intend to give it. A pleasing demonstration cannot provide that evidence on its own. My recommendation is to agree on a small, fixed evaluation set and a pass bar before tuning the prompt. Fifty well-chosen examples can be a useful starting point for a narrow task; fifty is a planning suggestion, not a statistically sufficient number for every product.
This does not mean software without such a set has never received any testing. It means its AI behavior lacks a repeatable acceptance check for the intended task. That is a gap a buyer can ask a supplier to close without becoming a machine-learning specialist.
What the console announcement changed
On 9 July 2024, Anthropic announced prompt evaluation features in its developer console. Users could supply or generate test cases, import cases from CSV and compare outputs from prompt versions. The announcement also described expert grading on a five-point scale. It made a practical evaluation loop easier to access; it did not invent evaluation or certify any application’s quality.
The date matters. This announcement belongs at the end of the editorial period beginning 3 July, not its first day. Looking back from November 2026, its value as an example is that testing was presented as part of the prompt-development workflow. This article does not assume that the current console interface is identical or report any use of that console.
Generated cases can help explore variations. They cannot establish that the examples represent your actual customers, documents or failure costs. A tool can run the comparison while leaving the hardest question untouched: what outcome should count as acceptable?
Write the acceptance rule before the answer
Consider an illustrative assistant that drafts replies to incoming support messages. It may need to identify the issue, refer to an approved policy and prepare a reply for a person to approve. A good-looking paragraph is insufficient if it promises a refund outside the policy or includes another customer’s information.
Before comparing prompts, decide what each case requires and forbids. For a refund question, record the applicable policy passage and the facts that determine eligibility. If essential information is missing, define an acceptable request for clarification. If the material cannot support an answer, define when the assistant should decline to guess.
Separate checks that can be determined directly from judgments that need a reader. Required fields and valid identifiers may be checked mechanically. Whether the reply accurately reflects the policy needs semantic assessment. Do not let a valid output format stand in for a correct decision. If an AI grader helps with that assessment, compare some of its judgments with qualified human judgments before relying on its score.
The example is a proposed workflow, not a claim about an AL+ deployment or a tested model. No prompt comparison or model evaluation was executed for this article.
Choose cases that can disagree with the demonstration
Start with real inputs you are permitted to use, suitably protected or de-identified. Include ordinary cases as well as cases where the assistant should ask for help. A set made entirely of edge cases can misrepresent normal work; a set made entirely of tidy examples can miss the reason human supervision is needed.
Add synthetic cases to probe known risks, but label their origin. Keep them distinguishable from real examples so that apparent breadth is not mistaken for observed coverage. Record why each case matters and who supplied the expected outcome.
Keep an unchanged set for comparisons, and reserve some examples from repeated prompt tuning. Otherwise you can gradually teach the prompt to satisfy the visible examples without improving its behavior elsewhere. When policy changes make an expected answer obsolete, version the set and explain the change. Fixed means stable enough to compare, not frozen against reality.
A pass bar should reflect consequence. A general percentage can conceal an unacceptable failure if harmless stylistic misses and unauthorized actions share one total. State which failures prevent release regardless of the average. For a human-approved drafting tool, also define what the reviewer must verify and how much correction the workflow can tolerate.
A later Figma explanation shows the boundary
Figma’s Make Designs episode offers a useful contrast, but it needs careful dating and attribution. In its 17 July 2024 retrospective, Figma said it had temporarily disabled the feature after outputs resembled existing apps. It attributed the problem to underlying design-system assets and said late additions had not been vetted carefully enough. That account appeared after the period discussed here.
This does not prove that Figma had no evaluation process; its account describes reviews and a private beta. It also does not prove that fifty examples would have caught the issue. The inference is narrower and more useful: evaluation should cover the complete system, including contextual assets that can change near release. Checking the prompt alone can miss behavior introduced elsewhere.
For the illustrative support assistant, the analogous change could be a replacement policy document. Even with the same prompt and model, a different reference input can change the answer. Rerun relevant cases when the system’s effective inputs change, not only when someone edits the visible instruction.
Keep the evaluation proportionate
The strongest objection is that maintaining expected answers takes time, particularly while a product is still exploratory. A disposable prototype may not justify a formal release gate. But once a feature handles real work, somebody pays for its mistakes. A small acceptance set makes that cost discussable before customers discover it.
An evaluation set remains a sample. It cannot prove the absence of all harmful outputs, replace access controls or establish regulatory compliance. Higher-consequence applications need a wider assurance argument than the small starting set proposed here.
When commissioning an AI feature, ask for the cases, the acceptance rules and the comparison record for the proposed change. Include model, prompt and relevant input versions. The useful deliverable is a reason to accept or reject this version for this task, with the remaining uncertainty stated plainly.