AI with a scoreboard: which projects pay for themselves

We have been in enough of these projects now to notice that the outcome is largely determined before any modeling begins. Three conditions predict success, and when a project is missing one, it fails in a recognizable way.

Adoption is not the constraint any more, and the survey data makes the actual constraint clear. In Stack Overflow’s 2025 developer survey, 84% of respondents said they use or plan to use AI tools, up from 76% the year before. In the same survey, 46% actively distrust the accuracy of what those tools produce against 33% who trust it, and just 3% trust it highly. The single most-cited frustration, at 66%, was output that is almost right but not quite; 45% said debugging AI-generated code took longer than expected.

That is the whole problem in one dataset. The generation step is solved well enough that nearly everyone uses it. The value, and the cost, has moved entirely into verification, which is why the conditions below are all about measurement rather than about models.

The three conditions¶

• A repetitive, expensive, judgement-light task. Someone is doing the same structured thing hundreds of times a week. If the task requires genuine expert judgement on every instance, you are automating the wrong step.
• Enough historical examples to evaluate against. Not to train on necessarily (modern models need less of that than they used to) but to measure against. Without an evaluation set you cannot tell improvement from confident nonsense.
• A tolerable cost of being wrong, or a place to put a human. Either the error is cheap, or the workflow has a review point where uncertainty can be routed to a person.

That last condition is the one that gets waved away, and it is the one that determines whether the system survives contact with production.

Build the evaluation set before the model¶

The single highest-leverage day in an applied AI project is the one where your domain experts label real examples. Not synthetic examples, not the clean ones: the smudged fax, the handwritten amendment, the form somebody filled in wrong.

This does three things at once. It defines correct, which is harder than it sounds and frequently surfaces genuine internal disagreement. It gives you a number, so 'it seems better' becomes a measurement. And it belongs to you: when a vendor’s benchmark says 94% and your evaluation says 71%, you have the only figure that matters.

Confidence beats coverage¶

The instinct is to maximize the share of cases handled automatically. The better objective is a calibrated confidence score per output, with a threshold tuned to your actual tolerance for error, and everything below it routed to a person with the uncertain parts highlighted.

A system that handles 78% of documents at 99.6% accuracy and hands the rest to a human is worth far more than one that handles 95% at 91% accuracy, because the second one has scattered errors into your data with no way to find them, and someone will eventually have to audit all of it.

Design for the fallback¶

Model providers have outages, deprecate versions, change pricing and adjust behavior between releases. Any AI feature on a critical path needs a defined degraded mode: a secondary provider, a simpler local model, or an honest queue that tells users the assist is unavailable. Decide this at design time, because you will not enjoy deciding it at 2am.

The projects that fail¶

• The chatbot with no defined task. Its scope is 'answer questions', so it can never be evaluated and can never be finished.
• The project with no baseline. Nobody knows what the current process costs or how often it errs, so no improvement can be demonstrated.
• The one where accuracy is a feeling. No evaluation set, no monitoring, and a demo that impressed everyone in March.
• The one where a rules engine would have won. Deterministic logic is cheaper, faster, more accurate and defensible in an audit. If the task is genuinely rule-shaped, use rules.

Roughly a third of the feasibility sprints we run end with a recommendation not to build. We charge for those, we write up why, and clients tend to regard them as the most useful money they spent that quarter.