Engineering brief
Testing AI Agents: Plant the Defect, Then Find It
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- Now
- Warnings
- None
Air Canada's AI team had no benchmark for contract review, so it generated 275 contracts with planted violations and graded them in code. Evaluation went from one expert session a week to dozens a day.
Agent quality hinges on evaluation speed; teams without a grading loop cannot improve or safely ship AI agents.
Watch if you are building agents in a domain with no benchmark, scarce experts, or slow evaluation cycles.
Summary
The bottleneck. Nathanael Weill, who runs AI delivery at Air Canada, starts with the problem most enterprise teams hit: no public benchmark exists, and only busy domain experts can grade the agent. On an earlier telecom RAG project, his team got one expert evaluation per week, and the grading sessions were contradictory. Without a fast loop, the team could not tell whether added reasoning steps helped or broke retrieval. The result was a complex pipeline that was not measurably better.
The inversion. The fix was simple: start with a known document, have an LLM write a question about it, run the agent, and check whether the agent retrieves the same page. Weill did not invent this for RAG, but he turned it into a general principle: plant a known defect or answer, then test whether the agent finds it. That removes expert opinions from the grading loop and makes success checkable in code.
The impact. That shift took his team from one expert evaluation per week to dozens per day. Removing pipeline components mattered as much as adding techniques from papers, and accuracy climbed over weeks. His working rule: if you cannot grade the agent, you cannot improve it.
The contract case. At Air Canada, the agent analyzes supplier contracts: spot clauses, find supporting documents, write amendments, and classify them. The team wanted to diff old and new contracts, but the company did not keep original versions. So they generated tests instead. Using known rules, like a cap above one million dollars, they built 275 contracts with planted violations. Taking signed contracts and deleting clauses was the strongest method, exposing that the agent missed most removed clauses.
Code before judges. Weill's team avoided LLM-as-a-judge whenever possible. The noise from an LLM judge was nearly as hard to control as the agent itself, and tuning the judge consumed effort without a stable signal. Code checks handled consistency: change supplier names, reorder clauses, rerun the same contract, and verify the flag count stays stable.
The real loop. Expert templates with blanks became a generator: fill blanks with values that do or do not break rules, and expected flags are known without model grading. Generated tests are a starting point, not a go/no-go decision. Weill uses expert feedback to improve the tests and prompts, not just the agent. Sometimes the solution must be re-engineered so it can be evaluated, a tradeoff teams should accept.
My take
I like the inversion because it solves a real enterprise problem: experts are expensive, and their opinions are noisy. But I'd push back on the phrase 'code can grade it.' That only works when you can define the defect in advance, which is exactly what is missing in many new AI use cases. The 275 contract tests were possible because Air Canada had explicit rules and templates. Teams without that foundation will still need a hybrid loop: synthetic tests for what is known, structured expert sampling for what is not.
The deeper point is organizational. Evaluation harnesses should be planned and budgeted like infrastructure, not bolted on after the agent works. That is the part most engineering leaders underestimate.
What to do with this
- Map known rules and templates for your highest-value agent into a synthetic test generator.
- Run an experiment: replace one weekly expert grading session with code-checked planted-defect tests.
- Ask each AI project to define expected outputs in code before the agent is built.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Model Choice Barely Matters: Fix Engineering Culture, Not AI Tools
AI model choice explains under 1% of developer output variance, per Jellyfish's 50,000-engineer dataset. The levers leaders control matter more.
Stop evaluating models. Start evaluating the risk around them.
1,368 AI failures later: deployment controls, not model quality, determine real-world harm. Failure-driven evals follow. No production proof yet.
Make legacy code AI-queryable: Vanguard's 7-day research loop became 15 minutes.
Vanguard cut legacy research from 7 days to 15 minutes by making its mainframe code queryable through MCP. The real lesson is governance.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.