How to evaluate AI feature output quality on Mac: a practical guide for product managers

A normal feature has a right answer. A save button either saves the file or it does not. An AI feature can give a different answer to each input, and sometimes a different answer to the same input twice. A quick try in a demo rarely tells you how the feature behaves. You need many inputs, one scoring method, and a record you can compare over time.

What bad AI output costs your team

Bad output costs time before it costs anything else. BetterUp surveyed 1,150 full-time U.S. desk workers in September 2025. It found that 40% had received workslop in the last month. Workslop is AI-generated work that looks finished but does not move the task forward. The survey is self-reported, so read it as a signal, not a precise measure.

BetterUp puts the average fix at two hours per incident. It estimates $186 per employee per month, or about $9 million a year for a 10,000-person company. Those figures come from one vendor's research. Your team may see more or less. The more useful number is how many hours your own reviewers spend fixing AI output each week.

Put a rough number on it before you argue about model quality. Ask three questions about last week. How many AI drafts did reviewers rewrite? How many tickets quoted a wrong AI answer? How long did the last prompt change take to check? The answers give you a cost you can defend in a planning meeting.

Why AI output quality slips past reviewers

The fastest way to fool yourself is to trust how a tool feels. In a July 2025 randomized trial, METR tracked 16 experienced open-source developers on 246 real issues. With AI tools allowed, the developers took 19% longer to finish. Before the study, they expected a 24% speedup. Afterward, they still believed AI had made them 20% faster.

That gap is the lesson for product managers. A feeling that the feature is good is a hypothesis, not data. METR also warns that these results used early-2025 tools and do not generalize to most software work. Treat the study as a warning about self-assessment, not as a fact about your product.

Reviewers miss errors for a similar reason. KPMG's 2025 global study surveyed more than 48,000 people across 47 countries. In its press release, 66% said many people rely on AI output without evaluating its accuracy. Another 56% said they had made mistakes at work because of AI. These are self-reports, and regional pages show slightly different numbers.

Step 1: build a test set from real inputs

A test set is a list of inputs your feature should handle, plus notes on what a good answer looks like. Pull the inputs from real use. Support tickets, search logs, sales call notes and your own past requests all work. Demo prompts are too clean. They show the feature working on the examples you picked, which is not the same as working on your users' messy text.

Start with a few dozen inputs. Include easy cases, hard cases and awkward ones. Add long inputs, inputs with typos, inputs that mix two languages, and requests the feature should refuse. Put each input in its own row of a Google Sheets file, with columns for the input, the output and each score.

• Very short inputs, such as one or two words
• Very long inputs close to the length limit
• Typos, slang and text pasted with stray formatting
• Requests outside the feature's scope
• Inputs with names, account numbers or other sensitive details

Freeze the set once it is ready. If you swap inputs after you see results, the scores stop meaning anything. Add new failures as you find them, and keep the old cases too. Old cases show you when a fix in one area breaks another. You can filter the sheet by category with the Google Sheets filter steps.

Step 2: write a rubric before you read outputs

A rubric is a short list of criteria. Each criterion has a clear way to score it. Write the rubric before you read any outputs. If you write it afterward, you will grade toward what you already like. Keep it short enough that a reviewer can apply it in a minute or two per output.

Take a feature that summarizes support tickets for an internal triage team. A useful rubric might ask these questions. Does the summary include every customer request? Does it add any fact that is not in the ticket? Does it use the right product names? Is it short enough to scan quickly? Score each line on a 5-point scale, where 1 is unusable and 5 needs no edits.

Define the low end too. Write one sentence that says what a 1 looks like for each criterion. Without that, two reviewers can score the same output differently and both feel right. Score a handful of outputs together first, then fix any line that starts an argument.

Step 3: use a second model as the grader

Reading every output by hand does not scale. Many teams ask a language model to grade outputs against the rubric instead. Researchers call this LLM-as-a-judge. In the MT-bench and Chatbot Arena paper, strong judges such as GPT-4 reached over 80% agreement with human preferences. That matched the agreement between humans.

The same paper lists known weaknesses. Judges can favor the answer shown first, favor longer answers, and favor output from their own model family. They also reason imperfectly on some tasks. The benchmark tested chat answers, not product summaries, so the 80% figure does not carry over directly to your feature.

Anthropic's evaluation docs recommend using a different model from the one that generated the output, when you use an LLM for grading. If your feature runs on one model, grade with another. Then read a sample of the grader's scores yourself every week. Sampling is how you catch a grader that has drifted or has a blind spot.

How to run an AI evaluation with Promptfoo on Mac

Promptfoo is a command-line tool for running prompts against test cases. Its getting-started guide documents an install with Homebrew. Its config file, promptfooconfig.yaml, lists your prompts, inputs and checks. The steps below follow that guide. Check the current page before you run them, because commands and labels change.

1. Open Terminal with ⌘ Space, type Terminal, and press Return.
2. Run brew install promptfoo, then run promptfoo init --example getting-started.
3. Open promptfooconfig.yaml in a text editor. Replace the example prompt and inputs with your feature's.
4. Add an llm-rubric check for each criterion, written as a plain instruction, such as: The summary must not add facts absent from the ticket.
5. Run promptfoo eval, then run promptfoo view to open the results in your browser.

The llm-rubric check is a model-graded test of free-form instructions. The Promptfoo page uses the example 'Do not apologize.' Your rubric lines work the same way. Keep one criterion per check, so a failure tells you what went wrong. A check that covers four things at once tells you almost nothing.

Save each results file with the date in its name, and keep the first run as your baseline. A saved baseline lets you compare the feature before and after a prompt change. That comparison matters more than any single score.

Side-by-side checks in Anthropic's Console

If your feature runs on Claude, Anthropic's Console has an Evaluate feature for prompts. The July 2024 launch post describes a Generate Test Case button, CSV import and side-by-side comparison of prompts. Subject matter experts score responses on a 5-point scale. Labels may have changed since then, so match the post's steps to what your Console shows.

Side-by-side comparison suits product managers well. Show two prompt versions to a domain expert and ask which answer is better. Record the choice and the reason. Then sort the reasons by how often they come up. The most common reason usually points to the real problem.

Mistakes that make AI quality scores meaningless

• Testing only the demo prompts, which were picked because they work.
• Running each input once, then treating one answer as the feature's behavior.
• Changing the prompt, the model and the rubric in the same week.
• Letting the generating model grade its own output.
• Scoring without a baseline, so every number looks like progress or failure.
• Reporting an average and hiding the failures users will notice.
• Reading the summary score but never opening a failed output.

The last mistake is the most common. A feature can average well and still fail on one customer type. Sort failures by input category. Keep a short list of must-pass cases, such as a refusal that must happen or a fact that must be right. One failed must-pass case should block the release, whatever the average says.

Where Lazur fits in your evaluation work

Lazur is a voice assistant for the Mac. Hold ⌥ ⌘ to ask about anything on your screen, and Lazur answers out loud. Ask where a control is, and Lazur draws a circle and a label around it. Ask how to do something, and Lazur guides you one click at a time, waiting for each click.

Lazur does not run Promptfoo, click buttons in the Console or grade outputs for you. It does not operate your spreadsheet. Use it to explain a rubric line, draft test inputs in your product's voice, or dictate reviewer notes. Hold fn to dictate clean text at the cursor in any app. You still choose the criteria and read the failures.

Research jobs run in Lazur's own Chrome tabs, through the Lazur for Chrome extension. They return a summary and a report. That helps when you want to see how other teams grade AI output. Check each claim against its original source before it goes into a spec.

Lazur listens and looks at the screen only while you hold the shortcut. Audio and the screenshot go to AI providers to answer, and they are not stored. Content is never used to train AI models. Still, follow your employer's rules before you hold the shortcut over client or patient data.

Edge cases: long outputs, unstable answers and small teams

Long outputs, such as reports or generated code, need more than one score. Split them into sections and grade each section. Check the parts that matter most, such as numbers, names and links. A reviewer who skims a long answer can miss a made-up figure in the middle.

Some outputs change from run to run. If the feature samples its answers, run each input more than once. An input that passes one run and fails the next is a finding. Record it as unstable, not as a pass. Unstable cases often point to a prompt that leaves too much open.

Small teams can start with one reviewer. Ask a second person to score a sample each week. When two people disagree, write down the reason and update the rubric. That habit turns disagreement into a better test.

What to do next

Pick the feature that causes the most rework this month. Build the input set first, then the rubric, then the baseline. Do not change the prompt until the baseline is saved. Every later score depends on that first file meaning something.