Best Practices.

The frame

There is no shortage of "AI best practices" lists on the internet. Most of them are for one tool, written by that tool's vendor. They're useful but partial. The thing that becomes obvious after using two or three of these tools seriously is that most of the practices that actually matter are not tool-specific. They're cognitive and ergonomic. They're about how a careful human gets useful work out of any plausible-talking system.

This guide collects those. It is intentionally short on prompt-engineering tricks and long on stance: how to set up your relationship with the tool, when to escalate, when to walk away, when to trust output, when to verify it.

The format that worked for me is a small set of habits. Each is a sentence, usually with a "do this" and a "because if you don't" clause. Read them once; come back to whichever ones you keep tripping over.

Pick the right surface

Every AI tool has at least three or four surfaces: a web app, a desktop app, a mobile app, sometimes a CLI, sometimes a browser. They are not equivalent. They reward different working patterns.

The trap is using whichever surface opened first because that's where you started yesterday. The recovery is recognizing that switching is cheap, and that the ergonomic mismatch costs more than the switch.

The shape of the rule

• Desktop apps are for tasks that touch local files, system apps, or your wider workflow. Voice is fine but not the killer feature. The global hotkey is.
• Mobile apps are for ambient interactions and voice. Walking, driving, in line at the coffee shop. Trying to write a long structured doc on a phone is fighting the tool.
• Web apps are for tasks where you want canonical behavior and the latest features. Anything new lands here first, and most product weirdness is on the wrappers, not the web.
• CLIs and IDE extensions are for tasks where you want the AI inside the loop you're already in (a terminal, a repo, an editor). Don't pull a CLI into a workflow that's fundamentally a chat.
• Browser-integrated agents (Atlas, Operator-style) are for tasks that are the web. Comparing across tabs, summarizing while reading, taking actions. Don't make them the chat you'd otherwise have on the web app proper.

The general principle: where does this task already live, and which surface is closest to it? Pick that. The wrong-surface tax is small per-task and compounds.

Verify, don't trust plausibility

The single most expensive failure mode in working with AI is not being lied to. It's being told something plausible that turns out to be wrong, and noticing two days later because you didn't check.

Plausible-but-wrong is the canonical AI output. It's fluent, structured, confident, and superficially right. It is more dangerous than obvious-wrong because it doesn't trigger your skepticism.

The defense

Set up verification mechanisms that don't depend on you noticing. The strongest ones are mechanical, not vigilant.

• For code: tests. A failing test before the agent runs, a passing test after. The test is the contract; the agent's job is to make it pass without breaking siblings.
• For research and citations: links, opened. Not the link the model says exists, the link you actually click and read.
• For numbers: a sanity check against the source. The model's reasoning doesn't matter if the input row was misread.
• For drafts: read it cold, the next day, with a pencil. Models polish; they don't fact-check.
• For agent actions: an undo button you've actually tested. Not "I assume this is reversible."

The pattern: your verification mechanism should be cheaper to run than the cost of the mistake it catches. Tests are cheap; reading a citation is cheap; sleeping on a draft is cheap. The mistakes they catch are not.

Branch instead of restart

Every chat product on the market lets you edit a message you previously sent and re-send from that point, creating a branch. Almost no one uses this feature. Most people delete the chat and start over, losing all the context they laid down.

Branching preserves the context up to the fork point. Starting over throws it away. If you've been working through a problem for ten turns and the eleventh went sideways, branching from turn ten is dramatically better than starting fresh.

Where to find it

• Web: hover over a message; the edit pencil appears.
• Desktop apps: same as web.
• Mobile: long-press on the message.
• After branching: a small arrow above the input switches between branches. The original is still there if you want it.

This is the most underused feature in every chat product. Five minutes of practice and it changes how you use AI.

Scope your context tight

Modern AI products give you two ways to maintain context across conversations: memory (implicit, global, the model "remembers" you) and projects (explicit, scoped, you tell it what's in scope).

Memory is at its best for low-stakes personalization ("I'm vegetarian, I'm in California"). It's at its worst for substantive work, because its surprises (recalling a detail from a totally different topic at exactly the wrong moment) outweigh its conveniences.

Projects beat memory for almost everything that isn't trivia. A project's context is on rails: the agent has the documents you uploaded, the conversations within the project, the rules you set, and nothing else. That's a feature.

The hygiene

• Turn off global memory in your settings. Re-enable it later if you miss it. (You won't.)
• Use a project per workflow, not per topic. "Weekly competitive brief" is a project. "Marketing" is a category that contains many.
• Be explicit about scope: in the project's instructions, say what's in scope and what isn't. The model honors hard "this is off-topic" lines surprisingly well.
• Don't reuse a project for a meaningfully different purpose. Make a new one. The cost is near zero.

Watch for silent model fallback

Most AI products will quietly demote you to a smaller model when you exceed soft caps in the current usage window. The conversation keeps going. Nothing tells you. The answers just get worse.

This is the most annoying class of failure mode in modern AI products, and it's invisible if you're not looking. The signal: a chat that was nailing the topic suddenly missing things, repeating itself, or producing less crisp output. The cause: probably not the model getting "tired." Probably you got fallen back.

What to do

• Pin your model explicitly when it matters. The auto-router optimizes for cost, not for your task quality.
• Watch the model badge near the picker. It's small. Sometimes it's hidden. It's the truth.
• Start a new chat if you suspect fallback. Once the usage window cycles, you'll be back on your normal model.
• Voice mode is the worst offender. Voice consumes budget faster than text and silently drops you. If voice answers feel weak, end the call and check the model.

Specific beats vague

The single most counterintuitive thing about prompting is that constraints help. New users assume that giving the model more freedom produces better output. The opposite is closer to true. A prompt that names its audience, its format, its length, its tone, and its acceptance criteria produces dramatically better output than an open-ended one.

The reason: a vague prompt gets a generic response. A generic response is, by definition, the average of the corpus. The average is not what you want. You want the specific thing that fits your task, and getting there means saying enough about your task that the model can find it.

The shape of a useful prompt

• Audience: who reads this. ("Senior engineer who hasn't seen this codebase.")
• Format: prose vs bullets vs table vs code. ("Three bullet points and a code block.")
• Length: words or paragraphs. ("Under 200 words.")
• Tone: formal, neutral, blunt, friendly. ("Direct, no hedging.")
• Acceptance criteria: how you'll know it's right. ("Must reference the X function and not the deprecated Y one.")
• Out of scope: what to ignore. ("Don't touch the imports.")

You don't need all six every time. But the more high-stakes the task, the more of them help.

Vague in, generic out. Specific in, useful out. — Practitioner adage

Pace your iteration

People new to AI tend to write mega-prompts: big multi-paragraph blocks that try to specify everything in one shot. Experienced practitioners decompose. Many short prompts almost always beat one mega-prompt.

Why: each turn is an opportunity to course-correct. A mega-prompt commits you to a single trajectory; if it's wrong, you've burned time and the model has anchored on a bad framing. A series of smaller prompts lets you steer in flight.

A rough cadence

1. Frame: tell the model what you're trying to do at a high level.
2. Draft: ask for a first attempt, knowing you'll iterate.
3. Critique: read the draft and ask for one specific change.
4. Iterate: another targeted change.
5. Polish: final read-through.

This is slower per-step than a mega-prompt, but faster end-to-end because you spend less time recovering from misframings.

Voice mode follows the same logic. Voice is for exploration: you talk through a problem, the model responds, you redirect. It's bad for precise output because dictation hates precision. Use voice for thinking, text for output.

Trust agents like junior staff

The fastest-growing category in AI is the agent: a model that takes actions on your behalf. Edits files. Sends email. Books appointments. Opens pull requests. Operates your computer. Each of these has tools today and more are coming.

The instinct that helps the most: treat agents the way you'd treat a smart, eager, capable junior employee on day one. They will produce work that's genuinely useful and occasionally surprising. They will also do unexpected things that you'd want a senior person to catch.

The three constraints

• Verifiable: every action they take should be auditable. Read the activity log. Skim the diff. Check the email before it sends.
• Scoped: give them the narrowest permission set that lets them do the work. Working-directory access only. This connector only. This branch only. Expand from there.
• Reversible: prefer actions you can undo. Drafts over sends. Branches over master pushes. "Always allow" the small stuff, never the destructive stuff.

Agents that take irreversible actions are dramatically more dangerous than agents that take reversible ones. Don't blur the line.

The supervision pattern

For the first month with any new agent: read every activity log. Spot-check every action. Calibrate your trust. After a month you'll know which actions are reliable and which aren't, and you can let your guard down on the reliable ones. Skipping the calibration period is the single most common mistake.

Privacy posture, by default

Every AI product has its own privacy story. They differ. They change. The defaults change. The defaults are not always opt-out; sometimes they're opt-in. Don't assume your data is private; check.

The questions to ask, of any tool

• Is my conversation used to train future models? By default, yes on most consumer tiers. By default, no on enterprise. Pro is sometimes the cheapest tier with the no-train default; sometimes it isn't.
• Is my conversation logged for the company's review? Almost always, for some retention period. Length varies.
• Are uploaded files retained? Usually yes, for the lifetime of the conversation or the project.
• Can I purge? Almost always, but the path varies. Settings → Data → Delete is your friend.
• Are voice recordings stored? Usually transcripts only, not audio. Verify per tool.

Posture

• Use a temporary or "incognito" chat when you're sharing something you don't want logged. Every major tool has this surface.
• Default-deny on training opt-ins. The convenience is small; the data cost is real.
• For sensitive work: use the enterprise tier, where the contract changes the defaults. If you don't have one, do the work locally or use a tool that runs locally.
• For stuff you're not sure about: ask yourself "would I be comfortable if this were public next month?" If the answer is hesitant, find a different surface.

Multi-tool workflows

Most serious users settle into using more than one AI tool. Claude for some things, ChatGPT for others, Codex or Claude Code for code, Cowork or Copilot for office work. The product strategists wish you'd pick one. You won't, and shouldn't.

The corollary: invest a little in conventions that work across tools.

Cross-tool conventions

• AGENTS.md is an emerging cross-tool convention for project-level instructions to coding agents. Codex, Cursor, Aider, and an increasing number of others read it. Write your project conventions there, not in a tool-specific file.
• Per-tool config files (like CLAUDE.md) should be small and tool-specific. Anything that applies broadly belongs in AGENTS.md.
• Document the toolchain: a one-page note saying which tool you reach for when. Saves you twenty seconds every time you start a task and prevents drift over time.
• Don't fight a tool to do another tool's job. If the workflow keeps wanting Claude Code's hooks but you're in Codex CLI, switch to Claude Code for that workflow. The cost of switching is a tab; the cost of fighting is steady.

When to switch mid-task

Some workflows have natural handoff points where switching tools pays off:

• Brainstorm in the consumer app, build in the IDE. The consumer chat is great for "what should this look like?" The IDE is great for the actual edits.
• Dispatch in the cloud, review locally. Send a long-running task to a cloud agent. Review the PR with your local tools.
• Draft on mobile, polish on desktop. Voice on the walk, edit at the laptop.

Cross-check between models

The single strongest verification mechanism for an AI answer is another AI's answer to the same question. Different models trained by different labs have different blind spots. When two of them give you the same answer, your confidence should rise. When they disagree, you have learned something more useful than either answer alone.

This is the practice that separates careful users from confident-but-wrong ones. Plausibility is not truth. A second model is a cheap, fast skeptic.

When to do it

• Anything you'll cite or repeat to someone else. Names, dates, statistics, technical claims. The cost of being wrong publicly is high. The cost of pasting the same question into a second tool is thirty seconds.
• Decisions with money on the line. A second opinion is standard for medical and legal questions. Treat financial questions the same way.
• Technical answers you can't fact-check yourself. If you don't know enough to spot a wrong answer, you need the structural defense of a second source.
• Anytime an answer feels too neat. Suspiciously clean answers are often wrong in ways that take a second model to notice.

How to do it well

The mechanics are simple. Copy the question. Paste it into a second tool. Read both answers side by side. Three patterns to watch for:

1. They agree on substance, differ on style. Strong signal the substance is right. Use whichever phrasing you prefer.
2. They agree on a specific detail you can't verify, but the overall answers diverge. Trust the shared detail more than the surrounding reasoning. The shared part likely has training-data support; the divergent reasoning is each model improvising.
3. They disagree on a key fact. Stop. Neither answer is reliable until you check a third source outside both models. The disagreement is a flag, not an invitation to pick the more confident one.

The pairings that work

• Claude and ChatGPT are the most common pair. Different training data, different reinforcement, different blind spots. Free tiers cover most casual cross-checks.
• Add a third tool when stakes are higher. Gemini, Le Chat, or Grok each bring a different lab's perspective. Three sources catch agreement that two might fake.
• An open-weight model (the Mistral lineup, or local Llama variants) is useful as a third because it's trained from a different starting point than the major closed labs.

The trap to avoid

If both models agree, your answer is more likely right. More likely, not certainly. Two models can confidently agree on a hallucinated citation, a wrong middle name, a misremembered date. Unanimity is reassurance, not proof.

For anything load-bearing, the model agreement is the second-to-last step. The last step is still checking against a non-AI source: a publication, a primary document, the actual person, the actual receipt.

When you're stuck

Sometimes a chat just goes sideways. The model is missing context, repeating itself, hallucinating, ignoring stipulations you set turns ago. The instinct is to keep correcting it. The instinct is wrong.

The escalation ladder

1. New conversation. Bring forward only the load-bearing parts. Most "stuck" chats are fixed by this single move. Conversations are cheap.
2. Smaller scope. If the new chat also goes sideways, the prompt is too ambitious. Cut it in half. Solve one piece, then the next.
3. Different model. If the smaller scope still doesn't land, switch to a stronger reasoning mode (extended thinking, GPT-5 Pro, Opus). The cost is rate; the value is correctness.
4. Different tool. If the strongest mode still doesn't land, the tool may not be the right one. Try another. The cost of switching is small.
5. Re-read the docs. Sometimes the answer is "the feature you're trying to use doesn't work the way you think." This is more often the case than ego allows.

The general principle: don't escalate by rescuing a bad chat. Restart with a sharper prompt. The minutes you spend rescuing are minutes you spend better starting over.

Closing thought

None of these practices are about prompting. They're about stance: how you set up your relationship with a tool that's fluent, fast, and sometimes wrong. The prompts come and go; the stance persists.

The model changes faster than your habits do. Build habits that survive the next model. — TWD

If you've read this guide and one or two of the ideas felt like things you've been trying to articulate, that's what to take with you. Don't try to install all twelve at once. Pick the one that maps to your current frustration. Notice when it helps. The next one will reveal itself.

Then read whichever tool guide is relevant: Claude Code, Claude App, ChatGPT, Codex, Claude Cowork, or Microsoft Copilot. The tool guides are about the differences. This one is about the constants.