How to Test and Improve Prompts Like an Engineer: Test Sets, Rubrics and Versioning

Most students improve prompts the way they debug code at 2 AM before a submission: change five things at once, run it, and hope. Sometimes the output gets better, but you never know why, and the next day it breaks again. Engineers who build reliable AI features work differently. They treat a prompt like code: they test it against known cases, measure the results, keep versions, and change one thing at a time. This guide shows you how to apply that discipline to your own prompts, whether you are building a college project, preparing for placements, or automating parts of your internship work.

Why "It Looked Good Once" Is Not Enough

Language models are probabilistic. The same prompt can give a great answer on one run and a mediocre one on the next. A prompt that works perfectly for one input can fail badly on a slightly different one.

If you test a prompt on a single example, you are not testing it. You are sampling it once. To know whether a prompt is good, you need to see how it behaves across a range of inputs, including the awkward ones. This is the same reason you do not submit a DSA solution after checking only the sample test case on LeetCode or Codeforces. Hidden test cases exist for a reason.

Step 1: Build a Small Test Set

A test set is simply a list of inputs you will run your prompt against every time you change it. You do not need hundreds. For most student projects, 10 to 20 well chosen inputs are enough to reveal real problems.

Include three kinds of cases:

• Typical cases: the inputs you expect most often.
• Edge cases: very short inputs, very long inputs, missing information, mixed Hindi and English text, unusual formatting.
• Hard cases: inputs where earlier versions of your prompt failed. Every bug you find becomes a permanent test case.

Suppose you are building a tool that turns a student's project description into resume bullet points. Your test set might include:

1. A detailed description of a full stack web app with clear metrics.
2. A vague two line description of a mini project.
3. A description written in casual Hinglish.
4. A machine learning project with lots of jargon but no outcome.
5. A group project where the student's own contribution is unclear.

Save these in a simple file, for example a JSON or CSV, so you can run them repeatedly.

[
  {"id": "t1", "input": "Built a MERN app for hostel complaints...", "notes": "typical, has metrics"},
  {"id": "t2", "input": "Made a weather app in college.", "notes": "vague, very short"},
  {"id": "t5", "input": "Our team of 4 built a chatbot...", "notes": "unclear ownership"}
]

Step 2: Define What "Good" Means With a Rubric

You cannot improve what you have not defined. A rubric turns a vague feeling ("this seems fine") into specific, checkable criteria.

For the resume bullet tool, a rubric could look like this:

• Action verb: each bullet starts with a strong verb.
• Specificity: mentions the actual tech stack or method.
• Honesty: adds no metrics or claims not present in the input.
• Length: each bullet fits in one or two lines.
• Ownership: describes the student's own contribution, or asks when unclear.
• Format: returns exactly 3 bullets, nothing else.

Score each output as pass or fail on each criterion, or use a simple 1 to 3 scale. Pass or fail is usually easier and more consistent when you are starting out.

Using a model as a grader

For larger test sets, you can ask a model to grade outputs against your rubric. Keep the grading prompt strict and specific:

You are grading resume bullets. Input description: [input]. Generated bullets: [output]. For each criterion below, answer PASS or FAIL with a one line reason. Criteria: 1) starts with an action verb, 2) mentions the tech stack, 3) adds no facts absent from the input, 4) exactly 3 bullets. Return JSON only.

Always spot check a few grades yourself. Model graders can be lenient or inconsistent, so treat them as an assistant, not a judge. For criteria like "exactly 3 bullets" or "valid JSON", write a small code check instead. Deterministic checks are cheaper and fully reliable.

Step 3: Version Your Prompts

If you edit a prompt directly inside your code and overwrite it, you lose history. When quality drops, you cannot tell what changed.

Simple habits that work:

• Store prompts in separate files, such as prompts/resume_bullets_v3.txt, or in a config file.
• Keep them in Git, with commit messages that explain the change, for example "v4: added instruction to never invent metrics".
• Record test results for each version in a small log or spreadsheet: version, date, pass rate per criterion, notes.

An illustrative log might read:

v1  baseline prompt                 honesty 12/20  format 15/20
v2  added "do not invent numbers"   honesty 18/20  format 15/20
v3  added one output example        honesty 18/20  format 20/20

Your own numbers will come from your own test runs, which is what makes them meaningful. A log like this is also excellent material for a project README or an interview discussion, because it shows a measured engineering process.

Step 4: Change One Thing at a Time

This is the most important rule, and the one students break most often. If you add a role, rewrite the instructions, add two examples and change the output format all at once, and the score improves, you do not know which change helped. Worse, one change may have helped while another quietly hurt.

Follow a simple loop:

1. Run the current version on the full test set and record scores.
2. Look at the failures. Find the most common pattern.
3. Form one hypothesis, for example "The model invents metrics because I asked for impactful bullets."
4. Make one change that tests that hypothesis.
5. Rerun the full test set, not just the failing case.
6. Keep the change if it helps without breaking other cases. Otherwise revert.

Here is what a focused change looks like.

Weak iteration:

Rewrite my whole prompt to be better and more professional.

Focused iteration:

My prompt generates resume bullets. On 8 of 20 test inputs, it adds percentages that are not in the input. Here is the current prompt: [prompt]. Suggest one minimal change to the instructions that stops invented numbers without making the bullets vague. Explain why it should work.

Running the full set after every change protects you from regressions, which is exactly why software teams run their whole test suite and not only the test they just fixed.

Prompting Reasoning Models and AI Agents

Everything above applies to every model, but reasoning models and AI agents change how you should write the prompt itself.

Reasoning models are designed to think through a problem internally before answering. AI agents can plan, use tools, read files and take several steps on their own. With both, micromanaging every step often makes results worse. A rigid script stops the model from using its own planning ability, and it breaks the moment reality does not match your script.

Instead, give them what a good senior would give a capable new joiner:

• The goal: what outcome you want and why it matters.
• The context: relevant background, constraints, what you have already tried.
• The success criteria: how you will judge the result.
• The boundaries: what not to do, and when to stop and ask.

Micromanaged prompt:

Step 1: open the file. Step 2: read line 1. Step 3: check if it has a bug. Step 4: go to line 2. Continue until the end. Then write a summary of exactly 5 points.

Goal and context prompt:

I am preparing my final year project, a Flask API for library management, for a demo next week. Review the code in this repository and find bugs or security issues that could break the demo, such as unhandled errors or missing input validation. Prioritise by severity. Do not rewrite working code for style. If something is ambiguous, list it as a question rather than guessing. Success means I get a short, prioritised list I can fix in two days.

The second prompt tells the agent what matters and leaves the "how" to it. It also sets clear limits, which matters for safety when an agent can edit files or run commands.

Testing agents

Agents are harder to evaluate because they take many steps. Keep your test set focused on outcomes: did it find the planted bug, did it stay within the files it was allowed to touch, did it stop and ask when information was missing? Review a few full transcripts by hand, since how the agent got there can reveal problems the final answer hides.

A Reusable Template for Your Prompt Experiments

PROMPT EXPERIMENT LOG
Prompt name: resume_bullets
Version: v4
Change from previous: Added one example of a vague input handled well
Hypothesis: Vague inputs will produce fewer generic bullets
Test set: tests/resume_bullets.json (20 cases)
Results: Specificity 17/20 (was 13/20), Honesty 18/20 (unchanged)
Decision: Keep
Next idea: Ask a clarifying question when ownership is unclear

Fill one of these for every meaningful change. It takes two minutes and saves hours of confusion later.

What to Do Next

Pick one prompt you use regularly, whether it is for a college project, your AI resume review workflow, or DSA practice explanations. Write 10 test inputs, define a rubric of four to six criteria, save the prompt as v1, and run it. Then improve it one change at a time and record the results.

This habit is what separates people who use AI from people who can build with it. It is also a skill you can demonstrate clearly in interviews. To build a stronger foundation in AI engineering, explore our courses, and when you are ready to apply, browse roles on the jobs board.