Two ways to lose hours: ignore AI and forgo the gain your competitors are already banking, or use it badly and disappear down a rabbit hole of prompts, rewrites and answers you cannot trust.
By Dev Lakhani & Xenia Gleissner | Co-founders, Cloud & Culture
There are two ways to lose hours to AI right now. The first is to sit it out. The reconciliation still gets done by hand on a Friday afternoon, the 40-page supplier contract still gets read line by line, the proposal still starts from a blank page. Meanwhile the firm down the road has quietly handed that work to a model, checks the result in ten minutes, and spends the rest of the day on something that earns money.
The second is to jump in badly. A vague prompt, no context, twenty attempts at the same task, generic output that sounds plausible, and a result nobody verified before it went to a client. That is the rabbit hole, and it can eat more time than the manual job ever did.
The rabbit hole: twenty prompts in, and still nothing you can trust.
We are giving a 40-minute talk on this in October, and this is the argument in written form: how to start an AI project properly, the small set of skills you actually need, why sensible people hesitate, and why so many of them end up unable to tell whether the output is true.
Start with a task, not a tool
Most failed AI projects begin with the wrong question: “What can we do with AI?” That question has no edges. It produces demos, not savings. The better question is “Which task costs us time we resent spending?” Pick one. It should be repetitive, so you do it weekly or monthly in roughly the same shape; text- or data-heavy, meaning reading, summarising, drafting, categorising or cross-checking; and reviewable, so you could look at a finished version and tell in minutes whether it is right.
Bank reconciliation, first-pass contract review, drafting engagement letters, turning meeting notes into action lists, classifying inbound enquiries. These are the tasks where the gain sits, because a model does the bulk in minutes and you keep the judgement.
Write down what “done” looks like before you open a chat window. If you can’t describe the output you want, the model certainly can’t produce it.
Once you have that, you can measure the project: how long the task took before, how long it takes now including your review, and how often the review catches something. If you can’t answer those three, you don’t have a productivity gain. You have a feeling.
The basic skills (there are only four)
None of them are technical. Nobody in the room needs to know what a token is.
Specifying the task. The single biggest skill. A good spec says who the output is for, what format it should take, what to include, what to leave out, and what a bad answer would look like. “Summarise this contract” gets you a book report. “List every clause that creates an obligation on us, with the clause number, the deadline and the penalty for missing it, as a table” gets you something you can act on.
Providing context. A model knows nothing about your business unless you tell it: your terminology, your house style, the previous version of the document, the policy it should follow, the client’s history. People who get generic output are almost always people who gave generic input. Most of the effort in a well-run AI project goes into assembling context once, so it can be reused every time.
Decomposing work. Big tasks fail; small ones succeed. “Prepare the quarterly board pack” is a project. “Extract the five KPIs from these three reports into this template” is a step. Break the work into steps where each has a checkable output, and chain them.
Reviewing. Not proofreading. Reviewing means knowing where this kind of output tends to go wrong and looking there first. More on this below, because it is where the trouble is.
Why people hesitate
We hear the same reasons in every conversation, and most of them are reasonable.
“I tried it and the answer was rubbish.” Almost always a specification and context problem, not a capability problem. The tool was asked a vague question and gave a vague answer.
“I can’t trust it with client data.” A fair concern, and one with an answer. Business-tier tools have data-handling terms that differ sharply from free consumer ones. Read them. Decide which categories of data are in scope and which never are. That is a policy decision, not a reason to do nothing.
“I don’t have time to learn it.” The learning curve is front-loaded. The first properly specified task takes an afternoon. The tenth takes fifteen minutes.
“It’ll make my work look like everyone else’s.” Only if you let it. AI slop, that flat, over-hedged, vaguely enthusiastic prose you now see everywhere, is what you get when you accept the first draft. Your voice comes from the context you provide and the edits you make. The model is the junior; you are still the author.
Underneath all of these is a quieter worry: if I hand this over, how will I know it’s right? That is the real question, and it deserves a proper answer.
The pitfall: outputs that sound true
A model’s output is fluent, confident, well-structured and instantly available. Every one of those properties makes it feel reliable. None of them makes it be reliable. People get trapped in one of two ways.
The rabbit hole. The output isn’t quite right, so they prompt again. And again. Each version is slightly different, none is clearly better, and an hour later they have lost track of which draft had the correct figure. They never wrote down what “right” looked like, so they can’t recognise it when it appears. The fix is upstream: define the acceptance criteria first, then judge every output against them rather than against the previous output.
The false sense of truth. The output looks finished, so it ships. The figure that was subtly wrong, the clause the model didn’t flag, the confident claim that was invented. Nobody checked because it read like something a competent person had checked already. This is the failure that costs clients.
Both come from the same missing piece: no verification step built into the process. Verification isn’t a vibe. It’s a step you design in.
How to build a sense of truth
This is the part people most want an answer to, and it is what most of the talk is about. Trust in AI output is not a feeling you arrive at after enough good results. It is a small set of habits you design into the process: how you ask the model to show its working, where you look first when checking, how you use the model to catch its own mistakes, and which decisions you never hand over at all.
Each of those has a specific, teachable technique behind it, and none of them takes more than a few minutes per task once you know it. We will walk through all of them live on 22 October, on real work brought by the room. If you want to know how to tell whether the thing you just generated is true, that is where to find out.
Which tasks to keep
Not everything should be handed over, and knowing the line is part of the skill. Keep the work where a wrong answer is expensive and hard to detect, where the value is in the relationship or the judgement rather than the text, and where you can’t describe what “right” looks like well enough to check it. Everything else is a candidate.
If you have read this far you probably have a task in mind. Bring it.
