7 Things You're Probably Doing Wrong With AI

None of these are about the tool you use. They're habits. Most people pick them up in their first week with AI and never revisit them, because the results look fine — they just have no idea how much better they could be.

Each one below has a small fix you can make today, and a complete, deliberate method behind it that the course builds step by step.

1. You ask without a goal you can check

"Make this better" produces a typical answer, not yours. The deeper problem: you can't even tell whether the answer you got back is good, because you never defined what good means. So you judge it by feel — and feel is exactly what a confident-sounding paragraph is designed to satisfy.

Compare two ways of asking for help with a client email:

• "Improve this email." — You get a smoother version of a mediocre email. Is it better? Unclear.
• "Improve this email. A good version gets a busy CFO to reply within a day, stays under 150 words, and never sounds like a template." — Now the model is aiming at something, and you can check the result against three concrete tests.

In real work: the goal line is also where domain knowledge enters. A project manager writes "A good version lets the steering committee decide without a follow-up meeting, and it names every open risk in one line each." Their professional judgment lives in that sentence — and once it's written down, it can be reused on every future update.

Small fix: before your next request, write one line stating what must be true of a good answer. Put it in the request. You'll notice the answers change immediately — because the model finally knows what it's aiming at, and you finally know how to grade it.

2. You accept the first answer

The first answer is the average of everything the model has ever seen on the topic. Averages are safe, generic, and rarely yours. The good versions live one or two exchanges deeper — after you've pushed on what's weak, added a constraint, or shown it a better example.

Professionals who get great results aren't better at writing first requests. They're ruthless about the second one. A simple pattern that costs thirty seconds:

1. Read the answer once, and name one thing that's wrong or missing.
2. Say it plainly: "The tone is too formal for my audience — rewrite it the way a colleague would say it over coffee."
3. Compare. The second answer is usually yours. Sometimes the third is.

In real work: the push-back is also where the model learns your world mid-conversation. Watch what happens to everything after that correction: the vocabulary, the assumptions, the level of detail all shift toward your situation. One honest sentence of feedback is worth five carefully polished original requests.

Small fix: never use a first answer that matters without one deliberate push-back. Not because the model failed — because the second pass is where your context actually enters.

3. You assume it knows your situation

It doesn't. Where your request has gaps, it fills them with plausible specifics — and they sound exactly like facts. Ask it to "write a plan for my team" and it will quietly decide your team is five people in a generic mid-size company with standard problems. If your team is actually two people with one impossible deadline, the plan is fiction — confident, well-formatted fiction.

This is the single biggest gap between casual users and skilled ones. Casual users describe their situation. Skilled users show their material: the actual notes, the real customer message, the genuine numbers, the messy draft.

In real work: notice the difference in output when you paste the raw material instead of describing it. A described meeting produces a plan for meetings in general. The pasted notes produce a plan for that meeting — including the awkward part where two departments disagree, which a description would never have captured, because descriptions smooth things over and raw material doesn't.

Small fix: give it your actual material, not a description of your memory of it. The difference in quality is not incremental — it's a different category of answer.

4. You let it add what you didn't ask for

A helpful extra here, an invented rule there. You asked for a summary; it added recommendations. You asked for three options; it gave you five. You asked it to rewrite a paragraph; it reorganized your whole document.

Silent additions are the quietest way a good answer goes wrong, because each one looks reasonable in isolation. The real cost appears later: you spend your review time auditing everything it added instead of checking the thing you asked for — or worse, an invented detail survives into your finished work because it arrived inside a competent-looking answer.

In real work: this is why "just read it once before using it" fails for busy people. Reading a summary for accuracy takes a minute. Auditing a summary that also added three "suggestions," reorganized your numbering, and "clarified" a date is a different task entirely — and it's the reason people stop checking at all, right when the stakes go up.

Small fix: end important requests with a boundary: "Deliver only what I asked for. If you notice something important I didn't ask about, mention it in one line at the end instead of adding it." Then read every answer once for what was never requested.

5. You start from scratch every time

A prompt that worked on Tuesday is gone by Thursday. So every task begins at zero: you re-explain your audience, your constraints, your preferred format — and get inconsistent results you can't reproduce.

People who build with AI treat instructions as assets. The instructions that worked get kept, with the parts that change turned into blanks:

You are helping me write weekly updates for my [AUDIENCE]. Rules: keep it under [LENGTH], lead with what changed, no marketing language. This week's material: [PASTE NOTES]

Now the quality lives in the instructions — which compound every week — instead of in the luck of each request.

In real work: a kept instruction is also a documentation habit. Open it three months later and you can see exactly how you wanted that work done: the length, the priorities, the things you banned. Most teams have never written down their standards this precisely, even once. The file quietly becomes the training document for whoever works with you next.

Small fix: the next time a request works well, don't move on. Save the instructions with the variable parts as blanks. That one file is the seed of everything the course builds later.

6. You treat every tool as the same tool

A chat assistant, a workflow and an agent are different animals with different jobs. A chat is for one answer you'll judge. A workflow is a fixed process that runs the same steps every time. An agent is something that acts on its own within limits. Using a chat for a job that needs a process means redoing the same request forever; using an agent where a chat would do means giving up control for no reason.

Mismatched tools aren't a small inefficiency — they're why people conclude "AI can't do this" when the tool was simply the wrong shape for the job.

In real work: three quick tests, from inside the course. If you'll do this work once, a chat is right. If you'll do it every week in the same shape, it wants to be a workflow. If it needs to react — notice something, decide within limits, act — that's an agent territory, and it also means you owe it explicit authority limits and a way to stop. Most disappointments with "AI agents" come from skipping that last sentence.

Small fix: before picking a tool, name what kind of help the job needs: one answer, a repeatable process, or something that acts. That single question resolves most tool confusion.

7. You don't say what you want back

The same request can return a paragraph, a table, a set of steps, or a finished draft. If you don't name the shape, the model guesses — and its guess is tuned to what most people expect, not to what fits into your day.

Describe the shape you want, or better, show one example of it. "Give me the answer as a three-row table" or "match the format of this sample" turns an answer you must reformat into an answer you can use directly. This costs ten seconds and is the fastest quality jump most people ever make.

In real work: the strongest version of this fix is showing, not telling. Paste a piece of output you already liked — a status line, a summary, an email — and say "match this." You stop describing your taste in words and hand over a sample of it. The model calibrates to the sample in a way no adjective list ever matches.

Small fix: in your next request, add one line describing what you want back — the format, the length, the shape.

---

A checklist you can keep

Seven lines, one per habit, in the order you'd use them:

1. Goal written down before asking.
2. One deliberate push-back on any answer that matters.
3. Real material pasted, not described.
4. Boundary stated: only what I asked for.
5. Good instructions saved as reusable assets.
6. Tool chosen by the shape of the job.
7. Output format named, or a sample shown.

Seven habits, seven lines. Print it, or rewrite it in your own words — writing it your way is the point.

---

Each of these fixes has a full method behind it. What you just read is the tip of each one, on purpose — enough to change your results this week, not enough to make you dangerous.

These are only the foundations. Praxaria AI takes you from using AI → directing it → building with it → delegating to it, with a build at every level to prove you're there.