[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-what-to-do-when-an-ai-feature-gets-something-wrong::en":3,"guide-related-what-to-do-when-an-ai-feature-gets-something-wrong::en":18},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":8,"meta_description":9,"keywords":10,"category":16,"published_at":17,"updated_at":17},"what-to-do-when-an-ai-feature-gets-something-wrong","What to Do When an AI Feature Gets Something Wrong","AI features fail differently from ordinary software: confidently, plausibly and without an error. This guide covers designing for that in advance, and what to actually do when a wrong answer reaches a customer.","\u003Ch2>A different kind of failure\u003C\u002Fh2>\n\u003Cp>Ordinary software fails loudly. A request throws, a page errors, a monitor fires, and someone is paged. An AI feature fails quietly: it returns a fluent, well-formatted, entirely plausible answer that happens to be wrong. Nothing in the response distinguishes it from a correct one, no exception is raised, and the first signal is usually a customer who acted on it. Designing for that difference is the whole job, because you cannot prevent every wrong answer and you can decide what happens when one occurs.\u003C\u002Fp>\n\u003Ch2>Decide in advance what a wrong answer costs\u003C\u002Fh2>\n\u003Cp>Before anything else, classify the feature by consequence. Drafting a first version of a message a human will read and edit is low stakes — errors are caught by the person already in the loop. Summarising a document someone will act on without checking is higher. Sending a message, changing a record, issuing a refund, or answering a customer directly is higher still. The design that follows should differ sharply between those categories, and the most common product mistake is applying the same interaction pattern to all of them.\u003C\u002Fp>\n\u003Ch2>Design so the mistake is catchable\u003C\u002Fh2>\n\u003Cp>Several patterns make errors visible rather than absorbed. Show the source: if an answer came from retrieved documents, link them, so a reader can check the claim in one click rather than trusting the sentence. Keep a human in the loop where the action is irreversible — proposing an action for approval is a different product from taking it. Make the output structured where possible, because a schema lets you validate mechanically what prose lets you only hope. And say what the system does not know: a feature that declines to answer outside its scope is worth far more than one that always produces something.\u003C\u002Fp>\n\u003Cp>Expressing uncertainty deserves care. Vague hedging in every response trains people to ignore it. It is more useful to distinguish clearly between the cases the system is designed for and the ones it is not, and to fail visibly on the latter.\u003C\u002Fp>\n\u003Ch2>When one reaches a customer\u003C\u002Fh2>\n\u003Cp>Treat it as an incident, with the same steps you would use for any other. Capture the exact input, the exact output and the version of everything involved — prompt, model, retrieved context — before anything changes, because these are hard to reconstruct later and the same prompt may not reproduce the same answer. Tell the customer plainly what happened and what it affected; an AI feature getting something wrong is not surprising to anyone in 2026, but discovering that it was known and not mentioned is.\u003C\u002Fp>\n\u003Cp>Then find the actual cause before changing the prompt. The wrong answer might be missing context, retrieval that returned the wrong passage, an ambiguous instruction, an input the feature was never meant to handle, or genuinely stale source data. Each has a different fix, and prompt-editing as a reflex tends to move the failure rather than remove it.\u003C\u002Fp>\n\u003Ch2>Turn the incident into coverage\u003C\u002Fh2>\n\u003Cp>Every real failure should end up as a permanent test case: the exact input added to your evaluation set with the correct answer written down. This is the cheapest reliable source of test data you will ever have, because it is drawn from what actually went wrong rather than what you imagined might. Over a year this set becomes the thing that lets you change models and prompts without fear, and it accumulates only if adding to it is part of closing the incident.\u003C\u002Fp>\n\u003Ch2>What to tell users up front\u003C\u002Fh2>\n\u003Cp>Say the feature is AI-generated, say what it is good for, and say plainly that it can be wrong and should be checked where it matters. This is not a legal formality — it sets the expectation that determines whether a single bad answer is a shrug or a breach of trust. Give people an obvious way to report a bad output, and make sure those reports reach someone, because a feedback control that goes nowhere is worse than none: it collects the evidence you needed and throws it away.\u003C\u002Fp>","When an AI Feature Gets Something Wrong","AI features fail without an error message. How to design for wrong answers in advance, respond when one reaches a customer, and turn the incident into coverage.",[11,12,13,14,15],"ai reliability","hallucination","ai incident response","human in the loop","ai product design","fundamentals","2026-08-14T03:45:01+00:00",[19,24,28,32,37,42],{"slug":20,"title":21,"excerpt":22,"updated_at":23},"ai-tool-pricing-models-seat-vs-usage-vs-credits","AI Tool Pricing Models: Seat-Based vs Usage-Based vs Credits","The three common ways AI tools charge — per seat, per usage, and by credits — and how to reason about which one will actually be cheaper for the way your team works.","2026-08-05T14:32:26+00:00",{"slug":25,"title":26,"excerpt":27,"updated_at":23},"how-ai-image-generators-differ-diffusion-vs-the-rest","How AI Image Generators Differ: Diffusion vs the Rest, in Plain Terms","A non-technical explanation of how AI image generators work, why the diffusion approach became dominant, and what practical differences to expect between tools.",{"slug":29,"title":30,"excerpt":31,"updated_at":23},"how-to-automate-your-workflow-without-code","How to Automate Your Workflow Without Code","A practical sequence for building automations that survive: picking the right process, mapping it before touching a tool, and handling the failure cases that break most first attempts.",{"slug":33,"title":34,"excerpt":35,"updated_at":36},"how-to-build-a-chatbot-without-coding","How to Build a Chatbot Without Coding","A practical route to a working chatbot using no-code tools: deciding scope, connecting your own content, handling the questions it cannot answer, and knowing what it will cost.","2026-08-05T14:32:27+00:00",{"slug":38,"title":39,"excerpt":40,"updated_at":41},"how-to-change-a-prompt-without-breaking-production","How to Change a Prompt Without Breaking Production","Prompts get edited in a text box and shipped in seconds, which is why they break things quietly: no compiler, no stack trace, no obvious moment of failure. Give them the release discipline code gets.","2026-08-24T03:30:02+00:00",{"slug":43,"title":44,"excerpt":45,"updated_at":23},"how-to-choose-an-ai-writing-assistant","How to Choose an AI Writing Assistant","A practical framework for picking an AI writing tool — matching it to the kind of writing you actually do, checking editing controls, and avoiding tools that produce confident but generic copy."]