Learn this for free

Pick one and stay there for a month. Seriously — that's the whole answer.

The gap between the top models is much smaller than the gap between someone who knows one tool deeply and someone who bounces between five. Every model has its own habits: how it handles vague instructions, how it pushes back, where it quietly guesses instead of asking. You only learn those by staying put long enough to get burned a few times.

If you want a starting point: use whatever has a free tier, and use it for real work, not test questions. "Write me a poem" teaches you nothing. "Rewrite this email I actually have to send" teaches you everything.

Switch later, once you can name a specific thing your current one keeps getting wrong. Not before.

(Current as of August 2026. Models ship changes weekly — check the provider's own docs before you commit money to anything.)

No — and yes, in a way nobody warns you about.

You don't need to write code. You do need to read it well enough to tell when something looks wrong. That's a much lower bar, and it's the bar that actually decides whether you ship anything.

Here's the trap: the model will hand you something that runs. Running is not the same as correct. If you can't read it at all, your only quality check is "did it crash," and that check misses almost everything that matters — wrong logic, a leaked key, a database call that works fine on ten rows and dies on ten thousand.

So the honest sequence is: start building immediately, and let the reading skill grow out of the building. Not the other way around. You will not finish a course first. Nobody does.

(This is my own path, not a universal rule. I came from ten years of retail, zero technical background.)

Nobody's an idiot. The only thing that writes a flawless, textbook prompt is a language model itself — and even those, 99% of the time, come stuffed with so much information that half of it gets lost somewhere in the context anyway.

Here's where the real differences actually sit:

• "Make me a nice website" vs. "build section X with content X" — that's context, and how much freedom you're handing over.
• "Don't add extra spacing" vs. a hard, specific list of constraints — that's control over the output.
• Asking for one option vs. asking for 3, 5, 10 on a creative task — that's giving yourself room to actually choose instead of accepting the first draft.
• An abstract request vs. a reference — that's whether the result is something you can check against anything at all.

That's the whole principle behind prompting. More freedom, messier result. One giant prompt trying to cover a huge task in one shot, more errors.

I go iterative. Every big task gets cut into small ones first. Task and context go in the prompt every single time, no exceptions. Examples, output format, hard constraints — those go in when the situation actually calls for them, not by default just because they're available.

(Current as of August 2026 — this is my process, not a universal rule. Test it against your own workflow before you copy it.)

I'm not going to quote you a number, because the number moves and anyone quoting one is guessing. What doesn't move is the shape of the bill, and that's the part worth understanding before you spend anything.

Three ways you pay:

• Free tier. Enough to learn on. You will hit the ceiling mid-task and it will be annoying, and that annoyance is genuinely useful information about how much you're actually using this.
• Flat subscription. Predictable. Caps are generous until you start running long agent sessions, then they aren't.
• API, metered. You pay per token. No ceiling, which is either freedom or a bad surprise depending on how carefully you're watching.

The real cost trap isn't the plan — it's leaving an agent running unattended on a metered key. Set a hard spend limit on day one, before you need it.

(Current as of August 2026. Every provider changes pricing without much notice — go read their pricing page yourself, don't take mine.)

Confidence is not a signal. It reads the same whether the answer is solid or invented, and that never fully goes away no matter how good the model gets.

What actually helps:

• Give it something to check against. A pasted doc, a file, a search result. An answer grounded in a source you handed it is a different category of reliable than an answer pulled from training data.
• Ask for the source, then open the source. Not the summary of the source. The source.
• Watch for specifics you didn't provide. Version numbers, exact prices, API parameters, dates, names. That's where invention lives. Vague-and-correct is common; precise-and-wrong is the dangerous one.
• Don't ask it to grade its own work. "Are you sure?" gets you a confident yes either way. Checking only means something when the signal comes from outside — a test that runs, a page that loads, a doc you read.

Assume anything specific is wrong until you've seen it somewhere else. That habit costs you thirty seconds and saves you entire afternoons.

A few of you asked, so here's mine. Drop your own sources in the comments, I'll take more.

First — the source itself. Docs at code.claude.com/docs and developers.openai.com/codex. For changelogs: Claude Code keeps a CHANGELOG.md right in the anthropics/claude-code repo on GitHub, Codex has a Releases tab.

Second — Reddit. r/ClaudeAI, r/ClaudeCode, r/codex. This is where the actual tricks show up first — people's workflows, their tests, what broke and what didn't.

Third — YouTube. But 90% of it is someone reading last week's changelog out loud. I only pull workflow ideas from there. Every fact still gets checked against the docs before it's real.

One rule, no exceptions: primary source first, someone's opinion about it second. Never the other way around.

(Current as of August 2026 — these tools ship changes weekly, so treat anything specific above as a starting point, not gospel. Go check it yourself.)

Nothing unusual. This happens to everyone, and it happens for a boring reason: the model can't see the consequences of an edit the way you can't see them either — it just moves faster than you.

Four things that fix most of it:

• Commit before every request. Not after. Before. Then a bad edit costs you one command to undo instead of an evening of forensics.
• Ask for the smallest possible change. "Fix the login button" beats "clean up the auth flow." Big asks get big, confident, sprawling rewrites.
• Say what must not change. Constraints are the cheapest thing you can add to a prompt and the most consistently skipped. "Don't touch anything outside this file" works.
• Give it a way to check itself. A test that runs, a page it can load. Without an external signal, "done" just means it stopped typing.

If you're doing all four and it still sprawls, the task is too big. Cut it in half and go again.