AI quality is software quality

Introduction

For most teams, the hard part of shipping an AI feature isn't getting a model to produce something plausible. It's getting it to produce the right thing, on the inputs that matter, every time — and knowing, before you ship, when it doesn't. That's not a research problem. That's a software quality problem, and we treat it like one.

A model behind an API is just another dependency. It has a contract, it has failure modes, and it drifts. The discipline that keeps a payments service honest — tests, regression checks, observability, rollback — is the same discipline that keeps an AI feature honest. We don't have a separate, looser bar for the parts of the system that happen to involve a model.

Evals before features

Before we wire a model into a product, we build the eval. A representative set of inputs, the outputs we'd accept, and a scoring method we can run on every change. It's unglamorous and it's the single highest-leverage thing you can do: it turns "this feels better" into a number you can defend, and it catches the regression a prompt tweak quietly introduced three deploys ago.

Software and tools

The tooling has caught up. Eval harnesses, tracing for prompt and token-level debugging, datasets versioned alongside code, CI that runs the suite on every pull request. We assemble these the way we'd assemble any test infrastructure — owned by the team, in the repo, runnable locally. No model change reaches production without going through the harness.

Other resources

If you measure it, you can improve it; if you can't measure it, you're guessing. We'd rather ship a narrower feature we can stand behind than a broad one we can only hope about. That's the whole philosophy: AI quality is software quality, and we don't ship what we can't test.