Evals for vibe coders, how to test a prompt before you ship

If your app sends a prompt to a model, that prompt is code. You'd never change a function without running the tests, yet most prompt edits ship after someone tries two or three examples in a chat window and decides it "looks better". An eval replaces that gut check with a test suite.

OpenAI's guide describes the loop in three steps: describe the task as an eval, run it with test inputs, then analyse the results and iterate on the prompt (OpenAI). This guide follows that loop with a small, cheap setup.

What an eval actually is

An eval has three parts:

1. Inputs. Real examples of what users will send.
2. Expectations. What a good answer must contain, must not contain, or must look like.
3. A grader. Code or a model that compares each output with the expectation and returns pass or fail.

Run the inputs through your prompt, grade every output and you get a pass rate. Change the prompt, run it again and compare. That's it. The point isn't a perfect score. It's knowing straight away when an edit that fixes one case breaks three others.

Write down what "good" means first

Anthropic's docs say success criteria should be specific, measurable, achievable and relevant (Anthropic). "Gives good answers" fails that test. These pass it:

• Replies in under 120 words.
• Always returns valid JSON with a category field.
• Never quotes a price that isn't in the product data.
• Asks a clarifying question when the order number is missing.

Each of those can become a check. If you can't write a criterion down, you can't grade it, and your eval will drift into vibes again.

Build a 20-case eval set

Twenty cases is small enough to write in an afternoon and big enough to catch regressions. A mix that works for most features:

• 12 typical cases. Copy real requests from logs, support tickets or your own testing, with names and personal data removed.
• 5 edge cases. Empty input, a very long input, two questions in one, a typo-ridden message, the wrong language.
• 3 "should not" cases. Requests the feature should refuse, hand off or answer cautiously.

Anthropic's docs make the same point about being task-specific, telling builders to include edge cases rather than only the happy path (Anthropic). Keep the set in a file in your repo, next to the prompt it tests. When a user reports a bad answer, turn it into case 21. Over time, the set becomes a record of every way the feature has failed.

Pass/fail checks vs model-graded checks

There are two kinds of grader, and you want mostly the first kind.

Code checks are deterministic. promptfoo, an open-source eval tool, ships assertion types such as equals, contains, icontains (case-insensitive), regex, is-json and javascript for custom logic, and any type can be negated with a not- prefix (promptfoo assertions). They're free, fast and give the same answer every time. Use them for format, required words, banned words, length and structure.

Model-graded checks ask a second model to judge the output against a rubric. In promptfoo that's llm-rubric. Use them only for what code can't measure, such as tone, whether an answer is grounded in the supplied context, or whether a refusal was polite.

Anthropic lists both kinds, from exact match and string match to LLM-graded Likert scales and binary classification. It says to automate grading where possible and to "prioritize volume over quality": more cases with automated grading beat a handful graded by hand (Anthropic). Its docs also note that it's generally best to grade with a different model from the one that produced the output.

Three habits make model grading more reliable:

• Ask for a binary pass or fail, not a 1–10 score.
• Write the rubric as a short, specific rule: "Mentions the 30-day return window and does not promise a refund."
• Spot-check a few graded results by hand each week. If you disagree with the grader, fix the rubric.

A minimal setup with promptfoo

promptfoo's latest release on npm was 0.125.1, published Oct 24, 2026 (npm). Its getting-started guide begins with npx promptfoo@latest init, which creates a promptfooconfig.yaml file with three sections: prompts, providers (the models) and tests (promptfoo). It supports more than 60 providers, including OpenAI, Anthropic, Google and local models through Ollama. A cut-down config looks like this:

prompts:
  - file://prompts/support.txt
providers:
  - openai:gpt-6-sol
tests:
  - vars:
      message: "Where's my order? It's #4821"
    assert:
      - type: icontains
        value: "4821"
      - type: javascript
        value: output.split(' ').length < 120
  - vars:
      message: "Can I get a refund after 45 days?"
    assert:
      - type: llm-rubric
        value: Explains the 30-day return window and does not promise a refund

Swap in your own model and prompt file. Run npx promptfoo@latest eval to execute every case and npx promptfoo@latest view to compare results side by side in a browser. Your tests make real API calls, so they cost money. With 20 cases, the bill per run is usually small, but check your provider's pricing. Our explainer on tokenizers and your AI bill shows how that cost is counted.

LLM output varies from run to run. promptfoo's --repeat flag runs each test several times, which helps you spot flaky cases (promptfoo CLI).

Run it on every prompt change

An eval you run once is a demo. The value comes from running it every time the prompt, the model or the surrounding code changes.

The command-line docs say promptfoo eval exits with code 100 when at least one test fails, or when the pass rate falls below the threshold set in the PROMPTFOO_PASS_RATE_THRESHOLD environment variable (promptfoo CLI). A CI job can therefore block a merge without any extra scripting. promptfoo also publishes a GitHub Action, promptfoo/promptfoo-action@v1, which runs a before-and-after eval when files in your prompts folder change and posts a link to the results on the pull request (promptfoo GitHub Action). Store your API key as a repository secret, never in the config file.

The same habit applies when you upgrade models. Run the set against the old and new model before you switch, and you'll see what the new one does differently instead of finding out from users.

If an AI coding agent edits your prompts, the eval is also how you check its work. Pair it with our checklist for reviewing AI-written code. If you package prompts as agent skills, give each skill its own small eval set.

A note on OpenAI's hosted Evals

OpenAI's evals guide now carries a deprecation notice. It says the Evals platform becomes read-only for existing users on Oct 31, 2026 and is scheduled to shut down on Nov 30, 2026, and it points new users to its Datasets product (OpenAI). If your test cases live there, export them before the shutdown date. Keeping the eval set as a plain file in your own repo avoids this problem entirely.