AI, for real

Evals vs vibes: you probably don't have AI evals (yet). Here's your first real one

Most 'evals' are a glance at the output and a shrug. Air Canada and Cursor show what that costs. Your first real eval needs no framework: read real outputs, write down what good means.

This is the companion article to the AI, for real Short. Watch it on YouTube (@ai4real-chelvas).

Your team says you have evals. Be honest: for most teams an "eval" looks like this. You run a prompt, glance at the output, it looks fine, so you ship it.

That's not evaluation. That's a vibe. And vibes break in production.

What vibes cost: two real failures

Air Canada's chatbot invented a refund policy

A customer asked Air Canada's website chatbot about bereavement fares. The bot told him he could book now and apply for the discount retroactively. Another page of Air Canada's own site said the opposite. When he claimed the refund, the airline refused, and argued the chatbot was responsible for its own words.

The BC Civil Resolution Tribunal disagreed: the company is responsible for what its chatbot says. In Moffatt v. Air Canada (2024 BCCRT 149) the airline was ordered to pay $812.02 CAD in damages, interest and fees (American Bar Association summary).

The money was small. The lesson isn't: your AI's answers are your company's answers.

Cursor's support bot invented a rule

In April 2025, developers using the Cursor code editor were told by its AI support agent, signing as "Sam", that their subscription was limited to a single device. No such policy existed. Users cancelled before the company corrected it (The Register; AI Incident Database #1039).

In both cases, nobody was systematically reading what the AI told real users.

Your first real eval (no framework, no budget)

Every day, read what your AI actually told real users. Not test prompts; real conversations. Twenty is enough to start. You'll spot failure patterns within a week.
Write down, in plain words, what "good" means. "Never states a refund policy that isn't in the policy doc." "Always asks for the order number before promising anything." Short, checkable sentences.
Turn each sentence into a pass/fail check. Some are code (does the answer contain a price?); some need a human or an LLM judge. Start binary; nuance can come later.
Save the failures as test cases. That's the seed of the eval set you'll run on a schedule (EP 2).

Your first eval is a written-down definition of good.

What most people miss

Your criteria will change as you grade. Researchers studying LLM-assisted evaluation found that people refine what "good" means while looking at outputs, a phenomenon they call criteria drift (Shankar et al., 'Who Validates the Validators?'). That's normal. It's also why you read outputs before automating anything: automated checks built on unexamined criteria just automate the vibe.

Anthropic's engineering team makes a related point for agents: grade the outcome the agent actually produced, not the story it tells about how it got there (Anthropic, 'Demystifying evals for AI agents').