Learning AI: The People Who Learn Fastest Expect It to Fail

*Part 3 of 6 in a series on the habits that make AI useful. Previously: [AI Problem Definition: If You Can't Explain the Problem, AI Can't Solve It](/insights/ai-problem-definition-explain-the-problem/). Next: [AI Time Investment: Spend Time on AI Before It Saves You Time](/insights/ai-time-investment-before-it-saves-time/).* Learning AI is mostly learning how and where it fails. A director once told me AI was "not accurate enough for our business". I asked what had happened. He'd asked it to summarise a contract, it had got a date wrong, and that was that. One attempt, one error, case closed. He would not have applied that standard to anything else. A new starter who got a date wrong in week one would have been corrected, not dismissed. A new report that came out slightly off would have been adjusted. Only AI gets judged on a single first attempt. The people who learn this stuff fastest have the opposite expectation. They assume the first go will be partly wrong, and they treat that as information rather than a verdict. ## It isn't deterministic software, and that's the bit people miss Business software is predictable. The same input gives the same output, and if it doesn't, something is broken. Decades of that has trained us all to treat variation as failure. AI produces likely output rather than fixed output. Ask the same question twice and you may get two different answers, both reasonable. That is how it works, not a fault, and no amount of complaining will make it behave like a spreadsheet formula. Once a team internalises that, the whole approach changes. You stop expecting a perfect answer on demand and start designing a way of working that gets you to a reliable result: better inputs, a defined format, a human check where it matters. ## Treat the first attempt as an experiment The useful question after a first attempt is not *"is this perfect?"* It's *"is there anything worth having here?"* Often the answer is: the structure is right but the tone is wrong, or the summary is accurate but has missed the one clause that matters. That is a long way from nothing. It tells you what to change. This is the difference between consuming AI output and working with it. Consumers judge. Experimenters iterate. ## A weak result is a diagnosis When something comes back poorly, it usually means one of six things: - context was missing - the objective wasn't clear - the task was too broad and needs breaking up - the information you gave it isn't good enough - human judgement is genuinely required here - AI isn't the right tool for this job Every one of those is useful to know, and none of them is "AI doesn't work". The last two in particular are wins: finding out early that a task needs a person saves you from automating something you shouldn't. ## The bigger risk is not failure, it's paralysis Failure is cheap. Twenty minutes and a poor first draft. Paralysis is expensive, and it's far more common. It looks like productivity: courses, webinars, LinkedIn threads, prompt libraries, tool comparison spreadsheets, another vendor demo. Months pass. The business has learned a lot about AI in general and nothing about AI in its own operation. Training has real value — we run [workshops](/workshops/) for clients on request — but it works when it's attached to real work. The people who come with a task from their own week leave with something they use. The people who come to "find out about AI" leave with notes. ## Learn just in time, not just in case Rather than learning everything first, start with an objective and pick up what you need as you hit it. *"I want to get the key figures out of these supplier PDFs and into a sheet without rekeying them."* Try it. You'll hit a specific wall — the layout varies, or the totals don't reconcile, or the output format won't hold. Now go and learn about that one thing. That knowledge sticks, because it's attached to a problem you actually have. ## Know where failure isn't acceptable None of this means being reckless. Experimentation is for low-risk work, and the boundary needs to be explicit. Anything touching legal advice, financial reporting, safety, HR decisions, clinical or care judgements, regulated advice or communications going straight to customers needs controls: human review before anything leaves the building, a record of what was checked, and clarity about who is accountable for the outcome. "The AI wrote it" has never been a defence and won't become one. Write the line down. People experiment far more freely when they know exactly where it is — see [using AI without putting your business at risk](/insights/using-ai-without-putting-your-business-at-risk/) and our note on [meaningful human oversight](/insights/ai-human-oversight-meaningful/). ## Turn a working experiment into a process Experiments that work should stop being experiments. The loop: **Try → review → learn → adjust → test → standardise.** Standardising is the step people skip. If a colleague found a way to turn messy meeting notes into decent client updates, that shouldn't live in their head or their chat history. Write down the steps, the instructions that worked, the checks required and who's responsible. Otherwise you've created another [process that lives in one person's head](/insights/process-documentation-out-of-one-head/). ## Fail cheaply, learn quickly The goal was never to avoid failure. It's to make failure small, fast and safe — a spoiled draft rather than a spoiled client relationship — and to actually learn from it. Businesses that manage that quietly build real capability over a few months. Businesses waiting for AI to be reliable enough to try are still waiting, and are now a year behind on the learning rather than the technology. ## FAQs ### Why does AI sometimes give different answers to the same question? Because it generates likely responses rather than looking up fixed ones. Some variation is normal. Where consistency matters, supply the same context every time, specify the output format, and check the result rather than assuming it will repeat. ### How many times should I try before giving up? Three or four genuine attempts, changing something meaningful each time — more context, a narrower task, an example of a good result. If it still isn't working, the task may be a poor fit, and that's a legitimate finding to record. ### How do I know whether the problem is my prompt or the AI? Test with a simpler version of the same task. If a narrower, well-briefed version works, the issue was scope or context. If even a clean, simple version fails, you're at a real limitation of the tool for that job. ### When should AI output always be checked by a person? Whenever it affects money, legal position, safety, employment decisions, personal data or anything a customer receives directly. In those areas, name who checks it and what they're checking against, and keep a record. ### Is learning through experimentation safe? Yes, within boundaries. Set out approved tools, what information must never be pasted into public services, and which decisions require sign-off. Inside those limits, experimentation is far safer than the shadow AI that grows when there's no guidance at all. ### When should I turn an AI experiment into a formal process? Once it produces a good result reliably across several real cases. At that point, document the steps, the instructions, the checks and the owner, and train whoever else needs it. Until it's written down, it isn't a process.

This article was written by Peter Lowe. The ideas and opinions are his own; AI was used to assist with drafting and editing.