Shipping an AI Feature You Can Defend

Language models have made the demo phase of a project almost free. A week of work produces something that answers questions about your data, drafts the reply, or reads the document — and everyone in the room can see the point immediately.

That prototype is genuinely valuable, because it settles the question of whether the idea works at all. What it does not tell you is whether you can operate it. Those are separate questions, and the second one is where the cost lives.

Decide what happens when it is wrong

This is the whole design problem, and it is a product question rather than a technical one. A model that drafts a reply for a person to approve can be wrong regularly and still be extremely useful. A model that sends the reply cannot.

So the first thing to establish is not accuracy but consequence. If a wrong output costs a moment of a user's attention, you can ship early and improve in the open. If a wrong output moves money, files a claim, or tells a patient something about their care, you need a person in the loop and you need it from the first release.

Constrain the surface

A general assistant with access to everything is hard to evaluate and harder to defend, because failure can look like anything. A feature with a narrow job — classify this into one of six categories, extract these eight fields, summarise this thread for someone who has been away — has a failure mode you can describe, test, and explain to a customer.

Narrow features are also the ones that survive contact with the roadmap. The broad assistant tends to be impressive in the demo and quietly unused by the third month.

The parts that are ordinary engineering

Most of the work of putting a model in production has nothing to do with the model:

• An evaluation set of real examples with known-good answers, so a prompt change can be measured rather than argued about.
• Cost and latency budgets per request, monitored — usage grows, and a feature that is cheap at launch may not be at scale.
• Graceful degradation. The provider will have an outage; decide now whether the feature disappears, queues, or falls back to something simpler.
• Logging that captures the input, the output and the version of the prompt, so a complaint from six weeks ago can be reconstructed.
• A written position on what customer data is sent where, because someone in procurement will ask and the answer must not be improvised.

Ship the boring version

The version that draws a clear line around what it will attempt, asks a person to confirm anything consequential, and says plainly when it does not know is less exciting than the demo. It is also the one still switched on a year later, which is the only version that ever produced any value.