Using AI Tools Daily

9:07 on a Tuesday

Maya is a product engineer at a fifty-person company. She has Claude open in one tab, ChatGPT in another, and Copilot quietly suggesting things in her editor. She pays for two of the three. By any reasonable measure she has plenty of AI.

And yet, if you asked her at the end of the week whether AI made her faster, she'd hesitate. Some days it feels like a superpower. Other days she spends twenty minutes wrestling a chatbot into producing something she could have written herself in five.

That gap is the subject of this lesson. It isn't a model problem — the models are fine. It's that Maya, like most people, is using AI ad hoc: reaching for whatever tab is open, accepting whatever comes back, and never quite building a routine she can rely on.

Most people plateau not because the tools are weak, but because they never turn scattered use into a system.

So let's follow one ordinary workday. Five moments, five decisions. Click any stop below to see what Maya is up against — we'll unpack each one as the lesson goes.

Three tools, three shapes

The usual way to compare AI tools is a feature table — context window, price, benchmark scores. It's the wrong lens for daily work, because by the time you're deciding what to open, the differences that matter aren't about model quality at all.

The thing that actually decides which tool you should reach for is where the tool sits relative to your work.

Once you see it this way, most "which tool is better" arguments dissolve. Asking a browser chat to refactor across twelve files is painful not because the model is weak, but because you'd have to paste twelve files in and copy twelve results back out. Asking an inline completer to help you choose a database is equally awkward — it only sees the file you're in.

Try it. Pick where your work lives and what you need, and see which shape fits.

Where it plugs in

Here's the unglamorous truth about daily AI use: the tool you actually use is the one that's already open. Friction decides everything. If reaching for AI means finding a tab, logging in, and re-explaining your project, you'll skip it exactly when you're busiest — which is when it would have helped most.

So the setup goal isn't "install everything." It's to make sure that at any moment, help is at most one keystroke away, in whichever of the three shapes fits.

Tick these off as you go — the ones you've already got count.

The loop that does the work

Back to Maya at 10:30, staring at an empty spec document. She types "write a spec for a notification preferences feature", gets 600 words of confident, generic prose, skims it, sighs, and closes the tab. Nothing about it is wrong. Nothing about it is hers.

This is the most common failure in daily AI use, and it has nothing to do with prompting technique. It's that she treated a first draft as a final answer.

The first output is not the deliverable. It's the raw material.

Everyone who gets consistently good results is running some version of the same four-stage loop — and crucially, going round it more than once.

The stage almost everyone skips is Critique — and it's the one that changes the output most. You can ask the model to evaluate what it just produced, and it will find real problems, because judging text against criteria is an easier task than generating it perfectly the first time.

09:10 — the inbox

Maya's 28 unread aren't a writing problem, they're a triage problem. The wrong move is asking AI to draft 28 replies. The right move is asking it to tell her which ones actually need her.

Note the last line. Without it you get 28 drafts you didn't ask for and have to read anyway. Telling the model what not to do is doing real work here — the technique from Step 02, applied to a Tuesday.

10:30 — the spec document

This is where the loop earns its keep. Three prompts, not one.

That third prompt is what makes the document Maya's rather than the model's. She's the one deciding which criticisms are real. The AI widened the option space; the judgement stayed with her.

16:45 — meeting notes

Messy notes into action items is close to the perfect AI task: tedious, structured, and you can instantly tell when it's wrong because you were in the room.

Trust, but verify — and know which

"Always check AI output" is advice everyone repeats and nobody follows, because it's unaffordable. If verifying costs as much as doing the work yourself, the tool is pointless, and after a week of dutiful checking most people quietly stop.

The workable version is to spend verification where being wrong is expensive. Ask two questions: would I notice if this were wrong? and what does it cost me if I don't?

The dangerous zone is that third row, because fluent writing feels verified. A confident sentence and a correct sentence are produced by the same mechanism, and they read identically.

Four situations. Which tier?

How to push back

When something looks off, "that's wrong, try again" is the weakest possible response — you've given it nothing to work with. These four questions do far more:

The paste test

At 13:00 Maya hits an unfamiliar service and wants to paste a stack trace into a chat window. It's a reasonable instinct. The trace also contains a database connection string.

You need a check that takes one second, because a rule that takes longer than the paste itself won't survive contact with a deadline. Here's the one:

If this text showed up in a screenshot on a public forum tomorrow, what happens?

That question resolves most cases instantly. Where it doesn't, the engineering detail matters:

• Tiers differ. Consumer, business and enterprise plans of the same product often have different rules on retention and whether your input trains future models. Check what your organisation signed — don't infer it from the logo.
• Secrets are absolute. API keys, passwords, connection strings, tokens: never, on any tier. And if one does get pasted, the fix isn't regret, it's rotation — treat it as leaked, because it is.
• Customer data usually isn't yours to decide about. Contracts and regulation govern it, not your comfort level.
• Sanitising beats abstaining. Replace real values with representative fakes. A stack trace with postgres://user:pass@prod-db swapped for postgres://user:pass@localhost debugs exactly the same — the model was never going to use the real host anyway.

That last point is the practical one. The goal isn't to use AI less; it's to strip what doesn't affect the answer.

Run the test. For each item — safe as-is, sanitise first, or never?

Maya's Tuesday, rerun

Same day, same tools, different system. The inbox got triaged instead of drafted. The spec went round the loop three times and came out sounding like her. The unfamiliar codebase got explored with a tool that could actually see it. The queue decision got argued against before it got made. The meeting notes took ninety seconds. The connection string never left her laptop.

None of that required a better model. It required knowing which shape to reach for, refusing to accept first drafts, spending verification where it counts, and having one fast rule about what to paste.

Up to now you've been using tools other people built. Next you'll build with the models directly — which is where you stop being limited by what a product happens to expose.