You Can Only Ship as Fast as Your QA Process

Short answer: AI coding agents removed writing code as our constraint, and the constraint immediately moved to QA. Manual review couldn't keep pace, and naive LLM-as-a-Judge scores didn't correlate with our human expert scores — so they were worse than useless. We built an annotation tool called Anchor, paired it with an evaluation platform, and validated the judge against human scores until it was trustworthy. Now we ship as fast as we build.

Every team member here is a power user of the AI tools in their arsenal. We let them go all out.

And it revealed something uncomfortable: even if you build 100x faster with AI coding agents, you can only ship as fast as your QA process.

That's the reality for teams shipping reliable software under real data security and compliance requirements — as opposed to toy projects, where the QA process is "it ran."

Speed just moves the bottleneck

Here's the thing nobody tells you about adopting AI coding agents.

They don't make you ship faster. They make you build faster. Those are different, and the gap between them is entirely QA.

If code generation was 60% of your cycle time and review was 40%, and you make generation nearly free, you haven't gained 60%. You've gained until you hit review — and review is now handling a much larger volume of changes, produced faster, by a process nobody on the team fully inspected line by line.

I've written about how agentic coding is turning everyone into a builder. This is the other half of that story. Broadening who can build raises throughput into the review stage. If review is manual, you've built a faster machine feeding the same queue.

If it itches you to see suboptimal systems — and it does me — this is unbearable to watch.

Why the bar is different in legal AI

Our users are lawyers. They can lose trust over a single wrong citation.

That is not a figure of speech. In Mata v. Avianca, lawyers submitted a brief containing case citations that ChatGPT had fabricated; the Southern District of New York sanctioned them $5,000 in June 2023, and the episode became the profession's reference point for what AI can cost you.

And the problem isn't confined to people misusing a general chatbot. Stanford RegLab researchers assessed the leading purpose-built AI legal research tools — Lexis+ AI, Westlaw AI-Assisted Research and Ask Practical Law AI — and found they hallucinate between 17% and 33% of the time (Magesh et al., Journal of Empirical Legal Studies, 2025). Per tool, that came out at roughly 17% for Lexis+ AI and roughly 33% for Westlaw AI-Assisted Research — better than general-purpose models, and nowhere near the "hallucination-free" marketing.

That's the environment. A one-in-three error rate is a product that cannot be used for the thing it's sold for. Which means the acceptance criteria have to be extremely high, and we make no compromises on them.

So when your QA process is the constraint, you can't solve it by lowering the bar. You have to make the QA itself faster without making it worse. That is a much harder problem, and it's the one worth writing about.

Why we didn't just trust LLM-as-a-Judge

The obvious move is to automate evaluation with an LLM judge. We tried exactly that.

The first time we automated our QA with LLM-as-a-Judge, the scores did not correlate with our human expert scores.

Not "correlated weakly." Did not correlate. Which means every number it produced was noise wearing the costume of a metric — and that is strictly worse than having no automated metric at all, because a dashboard full of confident numbers will get trusted.

I've met plenty of people who trust LLM-as-a-Judge blindly. Here's the test I'd suggest: run a correlation analysis against human expert scores on a statistically significant sample. Or check how the judge behaves on a 1% difference — can it reliably distinguish two outputs that differ marginally? You will quickly see how biased and overconfident these models are.

This isn't a fringe concern, and the literature is unambiguous. The original Judging LLM-as-a-Judge work (Zheng et al., NeurIPS 2023 Datasets and Benchmarks track) that popularised the technique also documented its failure modes: position bias (favouring whichever answer came first), verbosity bias (favouring longer answers regardless of quality), and self-enhancement bias (favouring the judge's own outputs). Later work found judges agree with expert annotators far less than teams assume, and are least reliable on precisely the hardest questions — because a judge that can't answer a question itself can't grade the answer.

For a general chatbot, that error bar is survivable. For specialist legal research, where every query is the hard tail, an unvalidated judge will confidently report that a regression is an improvement.

So we chose strict quality standards over automated testing we couldn't trust. Slow and correct beat fast and fictional.

The metrics we defined

Rather than accept a generic eval suite, we defined the dimensions that actually matter for legal AI:

Three things about this list are worth stealing even if you're nowhere near legal AI.

Retrieval is measured separately from generation. Paragraph and document retrieval recall are their own metrics. Without that split, a retrieval regression and a generation regression look identical from the outside, and you'll debug the wrong half of your system. This is what made the work in Drop 1 on our custom embedding model measurable at all.

Citation precision is separate from faithfulness. An answer can be faithful to its sources overall while pointing at the wrong paragraph. In law that distinction is the whole ballgame — a citation that doesn't support the proposition is the thing that ends careers.

Speed and tokens per query sit alongside correctness. Not in a separate performance dashboard someone checks quarterly. If cost and latency aren't in the same table as quality, they get traded away silently, one PR at a time.

What we actually built

Two pieces:

Anchor — our internal tool for data annotation and labelling. This is the foundation, and it's the part teams skip. You cannot validate a judge without a trustworthy human-labelled ground truth, and you cannot produce that ground truth at any useful scale without tooling built for your domain and your annotators.

An evaluation platform on top of it — we use Scorecard — to generate LLM-as-a-Judge scores against those metrics.

The pairing is the point. The judge isn't trusted because it's an LLM; it's trusted because its scores were validated against human expert labels produced in Anchor, and we keep correlating them to catch drift.

Was it time-consuming? Yes. Was it necessary? Absolutely.

Now we ship as fast as we build using AI coding agents.

How to do this on your own team

You don't need our domain to need this. If AI coding agents have increased your build throughput, your QA process is already the constraint — you just may not have named it yet.

1. Find the real bottleneck before optimising anything. If generation is free and review is manual, adding more generation capacity does nothing. Measure cycle time by stage.

2. Define metrics specific to your failure modes. Generic eval suites measure generic things. What does wrong look like in your product, precisely? That's your metric list.

3. Split retrieval from generation. If you use RAG and measure only end-to-end quality, you cannot tell which half broke.

4. Build the annotation layer first. Ground truth is the prerequisite. Everything downstream depends on it.

5. Validate the judge before you trust it. Correlate against human expert scores on a statistically significant sample. If it doesn't correlate, you don't have a metric — you have a number.

6. Keep correlating. Models change, your product changes, your data changes. A judge validated once is a judge validated once.

7. Put cost and latency in the same table as quality. Otherwise they get traded away silently.

Step five is where most teams stop, because steps one to four are work and step five risks telling you the previous four were wasted. Do it anyway. That's the whole value.

If you're earlier on and want a lighter starting point, five ways to test your AI readiness without coding or maths is a better first step than this post.

Frequently asked questions

Why doesn't AI coding assistance make teams ship faster? Because it accelerates building, not shipping. Removing code generation as a constraint moves the constraint downstream to review, testing and QA — which now handle a larger volume of changes, produced faster. Teams that don't also automate quality assurance see build throughput rise while shipping velocity stays flat.

Can you trust LLM-as-a-Judge for evaluating AI products? Not without validating it first. The research that popularised the technique also documented position bias, verbosity bias and self-enhancement bias, and later work found judges are least reliable on the hardest questions in a benchmark. The practical test is to run a correlation analysis against human expert scores on a statistically significant sample. If the scores don't correlate, the judge is producing noise that looks like signal.

How do you make LLM-as-a-Judge scores trustworthy? Build a human annotation and labelling layer first to establish ground truth, then correlate judge scores against those human expert scores. Validate on a statistically significant sample, check the judge can distinguish small quality differences, and keep re-correlating over time as models and data drift.

What metrics should you use to evaluate a legal AI or RAG system? Measure retrieval separately from generation — document retrieval recall and paragraph retrieval recall alongside correctness, faithfulness to sources, answer relevance and source relevance. For citation-heavy domains, track paragraph citation precision separately from faithfulness, since an answer can be broadly faithful while citing the wrong paragraph. Include speed and tokens per query so cost and latency aren't traded away silently.

How often do AI legal research tools hallucinate? Stanford RegLab researchers assessed leading purpose-built tools — Lexis+ AI, Westlaw AI-Assisted Research and Ask Practical Law AI — and found hallucination rates between 17% and 33% — roughly 17% for Lexis+ AI and roughly 33% for Westlaw AI-Assisted Research. That is better than general-purpose models but well short of the "hallucination-free" claims made in marketing. The study was published in the Journal of Empirical Legal Studies in 2025.

The series

• Drop 1 — We trained our own embedding model for legal RAG

• Drop 2 — You're reading it

Keep reading

• The reality of agentic coding: how we are turning everyone into a builder

• How my team reduced our LLM inference cost by about 50%

• Every AI team hits a wall — ours had RAG written all over it

• 70% of leading companies are struggling with AI