Most advice starts with a tool and looks for a use. Start with the task instead, and put it through three questions. Two of them are about checking, and that is the point.
Most guides to using AI at work open with a product and then hunt for something to do with it. That is the wrong direction, and it is why so many enthusiastic starts fade out after a few weeks. The tool arrives, everybody tries it on whatever is in front of them, the results are uneven, and the habit dies without anyone deciding to kill it.
A better starting point is a task you already do and already understand. Put it through three questions.
This is the question that decides most cases, and it is the one people skip.
Writing a first draft of a summary of a meeting you attended passes easily. You were there. A summary that misses the point is obvious to you within seconds, because you are checking against something you already hold in your head.
Calculating what to invoice a client fails just as clearly. To know whether the number is right you have to work out the number, at which point the machine has saved you nothing and added a step. Anything where verification costs as much as production is not a candidate, however impressive the output looks.
The useful version of this question is not can I check it but can I check it quickly. Almost anything can be checked eventually. If checking takes as long as doing, the arithmetic is already negative.
Some mistakes are cheap. A clumsy first draft costs you the minute it takes to rewrite the sentence. A badly worded internal note gets corrected in the reply.
Other mistakes are expensive, and worse, they are expensive later. A wrong figure that goes into a document nobody re-reads, a commitment made to a client in a tone you did not intend, a piece of code that works on the cases you tried and fails on the one you did not: these do not announce themselves. They surface weeks later, attached to someone else's problem.
Where the cost of an error is low and the error is visible immediately, speed is a real gain. Where the cost is high or the error hides, the time you appear to save is borrowed against a bill that arrives later, with interest.
This one is not about quality at all, and it is the one that gets people into genuine trouble.
Personal data about other people, material covered by a confidentiality clause, credentials, client documents that arrived under an agreement about who would see them: none of these become shareable because pasting them into a text box is convenient. Convenience is not consent, and the fact that a tool has a text box does not mean you have the right to fill it.
The practical form of this question is simple. If you would not forward this document to an outside contractor without asking anyone, do not paste it into an outside service without asking anyone.
The tasks that clear all three are consistent, and they are unglamorous.
Turning rough notes into a structured first draft, where you know what the notes meant. Rewriting something you already understand for a different audience, where you can tell immediately whether the meaning survived. Producing the boring variants of a sentence so you can pick one. Explaining an unfamiliar document or an unfamiliar piece of code well enough that you can ask a better question about it, treating the explanation as a starting point rather than an answer.
Notice what these have in common. In every one, you are the person who already knows the answer, and the machine is doing the typing. That is the shape of the reliable win.
Anything that requires a fact the model has no dependable access to. Anything where a confident tone can hide an absence of knowledge, which is most factual questions. Anything you cannot check faster than you could have done it. And anything you are not entitled to share.
If you want a first week that teaches you something, pick one recurring task that passes all three questions and use the tool on it every day. Keep the outputs you rejected, not the ones you kept.
The rejects are where the learning is. They show you where this particular tool drifts on this particular kind of work, and that is knowledge no general prompt guide can give you, because it depends on your task and your standards. After a week you will have a much better instinct for when to reach for it, which is worth more than any list of prompts.
All three questions are versions of one idea: the machine is good at producing shapes and bad at guaranteeing content. Where a well shaped output is what you need, and you are the one holding the content, it works. Where the content is what you need and you have no way to supply or check it, it does not, and no amount of rephrasing the request will change that.
Ordinary software breaks loudly. A language model does something stranger: it produces a confident, well formed answer whether or not it has one. Here is where that bites, and what catches it.
Read the articleOne email when a new article is published. No tool of the week, no affiliate list, no forwarding of your address to anyone.
