Choosing a cloud architecture you will not regret in two years
Most cloud regret is not a technology problem. It is a sizing problem, teams adopting the architecture of a company ten times their size.
Read article →Building an impressive AI demo has never been easier. Building an AI feature that still works in month six, on inputs nobody anticipated, is a different discipline entirely, and it looks much more like ordinary software engineering than most teams expect.
Define failure before you define success
For any AI feature, answer three questions before writing code. What does a wrong answer cost? How will a user notice it is wrong? What can they do about it? A feature where wrong answers are cheap and visible (draft generation, say) can ship early. One where wrong answers are expensive and invisible needs a fundamentally more careful design.
Evaluation is the product
Without an evaluation set you are not engineering, you are decorating. Start small: fifty to a hundred real examples with known-good outputs, kept in version control and run in CI. It feels crude next to published benchmarks. It will catch far more regressions, because it is made of your data.
- Draw examples from real usage, including the ones that went badly.
- Cover the boring middle, not just the interesting edges.
- Re-run on every prompt change, model change and retrieval change.
- Track the numbers over time. A single score tells you nothing; a trend tells you a lot.
Retrieval beats fine-tuning more often than people expect
When the goal is to make a model aware of your organisation's knowledge, retrieval is usually the better first move. It is cheaper, updates instantly when a document changes, and, critically, lets you show the user where an answer came from. Fine-tuning earns its place when you need a consistent format or behaviour, not when you need facts.
Design the fallback path first
Models time out. Providers have incidents. Rate limits arrive at the worst moment. Every AI call needs an answer to "and if this does not return?", a cached response, a simpler deterministic path, or an honest message. Deciding this during the incident is how a degraded feature becomes a broken product.
Keep a human in the loop where it counts
The most durable pattern remains the least glamorous: the model drafts, a person approves. It is not a failure to reach full autonomy. It is a design that acknowledges the cost of being wrong, and it is usually the version that actually ships.