Using AI in real projects without the hype

There are two unhelpful positions on AI right now. One is that it will transform every product overnight, so you must bolt a chatbot onto everything immediately. The other is that it is all hype and best ignored. Neither survives contact with real projects. The useful question is narrower and far more practical: for this feature, for these users, does AI do the job better than the alternatives — and at what cost?

Here is how we think about it before we write a line of code.

Start with the job, not the technology

The fastest way to waste money on AI is to start from “we should use AI” and look for somewhere to put it. We start from the opposite end: what is the user actually trying to do, and where do they currently get stuck? Only then do we ask whether a language model, a classifier, or plain old deterministic code is the best tool for that specific job.

Very often the honest answer is that a well-designed form, a good search index, or a few lines of business logic beats an AI feature on every axis that matters — speed, cost, predictability, and the user’s trust. AI should win the job on merit, not because it is fashionable.

Where AI genuinely earns its place

There is a real category of problems where AI is not just viable but clearly the right tool — the messy, language-shaped tasks that traditional code handles badly:

• Turning unstructured text into structure — pulling fields out of emails, documents, or free-form notes that no regular expression could ever keep up with.
• Summarising and triaging — giving a human a fast, good-enough first pass over a large pile of content so they spend their attention where it counts.
• Natural-language interfaces — letting someone ask for what they want in plain words instead of learning a query syntax.
• Drafting and transformation — first drafts, rewrites, and translations that a person then reviews and approves.

The common thread is that a human stays in the loop, the cost of an occasional wrong answer is low, and the input is genuinely linguistic. That is AI’s home turf.

Where it quietly costs more than it saves

The flip side matters just as much. AI is a poor fit when the task demands exact, repeatable answers — totals that must reconcile, rules that must be enforced the same way every time, anything where “usually correct” is the same as “wrong.” It is also a poor fit when latency or cost per request is critical, or when a simpler approach would be easier to test, explain, and trust.

A model that is right 95% of the time sounds impressive until you realise the remaining 5% lands unpredictably on real users, with no error message to warn them. Designing for that long tail — verification, fallbacks, human review, sensible defaults when the model is unsure — is most of the actual engineering work. The demo is the easy part.

Build it so you can change your mind

The AI landscape moves monthly. Models improve, prices drop, and today’s best choice is rarely next year’s. So we build AI features behind a clean boundary: the rest of the application talks to a small, well-defined interface, and the specific model sits behind it. That way swapping providers, upgrading to a newer model, or falling back to a cheaper one is a contained change, not a rewrite.

We also keep the prompts, the evaluation cases, and the guardrails in version control alongside the code, because a prompt is just as much a part of the system as a function — and just as capable of breaking when something upstream changes.

The honest bottom line

AI is a genuinely powerful tool for a specific shape of problem, and a liability when forced onto the wrong one. The value is not in adding AI; it is in knowing where it belongs and engineering carefully around its weaknesses where it does.

If you have a problem that looks language-shaped and you are not sure whether AI is the right answer, that is exactly the conversation worth having before any budget is committed. We are happy to tell you when it is not.