Where to start with AI

The advice everyone gives, and why it does not help

Ask how to get started and you get a version of this. Learn the fundamentals. Get good at prompt engineering. Try different tools. Stay curious and keep up with the field. Every word of that is defensible.

It is also empty. It does not survive contact with a Tuesday. You have a full inbox, four listings to write, a call at eleven, and no idea which of those an AI is supposed to touch. Stay curious is not a task.

The rest of this is the boring version. It is less impressive to read and it survives Tuesday.

Learning AI is three skills, not one

Most of the confusion comes from one phrase covering three jobs with three different payoffs and three different maintenance costs.

• Using models. One conversation, one task. You describe a job, you read what comes back, you decide whether it is right. The payoff lands the same day. Almost everyone should live here for the first month.
• Orchestrating workflows. The same job, the same steps, every time, without you starting it. Anthropic's engineering write-up on agents draws the line at predefined code paths: a workflow follows a route you laid out in advance. The payoff is time, and it compounds quietly.
• Building agents. The model directs its own steps and picks its own tools inside a loop you handed it. Highest ceiling, highest maintenance. The same Anthropic write-up tells developers to find the simplest solution that works and add complexity only when it demonstrably improves the outcome, which sometimes means not building an agent at all.

Those are not three rungs of a ladder you have to climb. They are three answers to three different problems. Most of the value most people get sits in the first one, and the second one is where it starts running without you. When you are ready for that, set up your first AI workflow. When a fixed route genuinely is not enough, build an agent that does real work. Not before.

How to start learning AI: what to learn first

Two skills, and neither of them is a tool.

1. 1Describing a job precisely enough that a stranger could do it. Anthropic's prompting guide gives a test you can run in ten seconds: hand your prompt to a colleague who does not know the task, and if they would be confused, the model will be too. It also suggests explaining why you want something, not just what, because the reason lets the model generalise to cases you did not spell out.
2. 2Judging whether what came back is right. This is the skill nobody teaches and everybody needs. It gets its own section below, because it is the difference between using AI and being quietly wrong faster.

Alongside those, there are four mechanical facts worth knowing. They are the ones that explain most of the weird behaviour beginners run into.

• It is not looking things up unless you give it something to look at. Every model has a training cutoff date. Google's Gemini docs describe search grounding as connecting the model to live web content so it can answer about recent events, and returning citations that link specific spans of the answer back to a source URL. If there is no search and no document, you are getting recall, not research.
• The conversation is working memory, and it is finite. Anthropic's context window docs describe the context window as everything the model can reference while answering, separate from what it was trained on, and warn that as the token count grows, accuracy and recall degrade. They call that context rot. The practical translation: a long, messy chat gets worse, not wiser. Start a fresh one more often than feels natural.
• You can hand it your own material. When you attach a PDF, Anthropic's docs describe the system converting each page into an image and extracting the text alongside it, so the model can be asked about charts and tables and not only the text layer. Your own documents are the cheapest accuracy upgrade available.
• It does not run anything by itself. In tool use, the model returns a structured request to call a function, and your application is what actually executes it and hands the result back. Worth knowing early, because it tells you exactly where the responsibility sits when something goes wrong.

What to skip, at least for now

You are drowning in this stuff, so here is my opinion, stated as opinion.

• Model release news. You do not need to know which model topped which benchmark this month. If your work falls apart when the leaderboard changes, the work was the problem.
• Prompt libraries with five hundred prompts. Two of them fit your job, and you cannot tell which two until you have done the job.
• Transformers, fine-tuning, and anything that opens with a neuron diagram. Real subjects. Wrong ones for you right now. You do not study engine thermodynamics before you drive to work.
• Vector databases and RAG. Genuinely useful once you have a pile of documents that is too big to paste. Before that, it is vocabulary.
• Tool collecting. Pick one general assistant and stay with it for a month. Capability differences between the big ones move constantly. Your judgment does not transfer between tabs.

I have watched people spend a month evaluating AI tools and end up with nothing to show except fourteen open tabs. The evaluation was very thorough.

Your first 30 days, mapped to work you already do

One rule: never invent a project. Every project below is something already sitting on your plate, which means you already know what a good answer looks like. That is the whole trick. You cannot learn to judge output on a task where you have no opinion.

One row a week is four projects in a month, which is plenty. If the last row is the one that matches your week, there is a longer version of it in turn one idea into a week of content.

A prompt worth copying, and why each line is there

This is the one I would hand a beginner first. It is deliberately unglamorous. Replace the document and the two things you care about, and it works on a contract, a brochure, a policy, a long email thread.

I have to act on the document below, so I need to be able to check your work.

<document>
PASTE OR ATTACH THE DOCUMENT HERE
</document>

Do this in two steps.

Step 1. Find every sentence in the document that involves money or a deadline.
Copy them out word for word and number them.
If there are none, write: No relevant sentences found.

Step 2. Using only the sentences from step 1, give me a table with three columns:
- the quoted sentence and its number
- what it commits me to, in plain English
- the question I should ask before I agree to it

Rules:
- Use nothing outside the document. Not general knowledge, not assumptions.
- If something is unclear or missing, write: not stated in the document.
- Flag anything a professional should look at before I sign.

Every line is doing a job.

• The first sentence gives the reason, not just the order. Anthropic's prompting guide notes that explaining why you want a behaviour produces more targeted results than stating the rule alone. I need to check your work is the why.
• The tags fence the document off. Wrapping the input in its own tag keeps the model from reading the document as more instructions. Anthropic's guide recommends tags exactly for prompts that mix instructions with pasted content.
• Quotes come before analysis. Anthropic's guidance on reducing hallucinations suggests pulling word-for-word quotes out of a long document first, so the answer sits on the real text instead of a summary of it.
• Two escape hatches are written in. No relevant sentences found and not stated in the document are permission to admit there is nothing there. The same guidance is blunt about this: explicitly allowing the model to say it does not know cuts down invented answers.
• The output is a table, not a paragraph. Three columns, one row per quote, source attached. You can audit it without rereading the document.

How do I know if the AI answer is any good?

This is the skill beginners skip, and it is the only one that actually protects you. A model can produce a confident, well-formatted, professionally-toned answer that is wrong, and nothing in the formatting will tell you which one you got.

Three questions, in order.

1. 1Can I trace it? Every factual claim should be attached to something: a quoted sentence, a row, a file, a link. If a claim floats free, treat it as a draft, not a finding.
2. 2Would I have caught it if it were wrong? If the answer is no, the format is the problem, not the model. Ask for the output in a shape you can check. A table with sources beats a paragraph with confidence.
3. 3Did it ever refuse? If a model never says it does not know, never flags a gap, and never comes back short, that is a signal about your prompt, not proof of its competence. Build the permission to say nothing into the instruction.

Then the harder version, which almost nobody does and which is worth more than the rest combined. Keep about ten cases where you already know the right answer. OpenAI's evals guide describes this as test cases with a known correct label, and a loop: describe the task as an eval, run it on real inputs, look at where it failed, change the prompt, run it again. You do not need their tooling. A spreadsheet with ten rows and a column for what it should have said is the entire idea.

What to do when it goes wrong

It will go wrong in week one. That is the curriculum, not a setback. Five moves, roughly in order of how often they work.

1. 1Do not argue with it. Rewriting the same request in a slightly annoyed tone almost never helps. Fix the input instead.
2. 2Start a new conversation. Long threads accumulate every earlier mistake as context, and Anthropic's own docs warn that recall degrades as that context grows. A fresh chat with a clean brief often fixes what twenty follow-ups could not.
3. 3Give it the material, not the memory. If it is guessing about your business, it is because you asked it to. Paste the actual pricing sheet, the actual policy, the actual five replies.
4. 4Make it show the source. Ask for the quote behind each claim, and ask it to delete any claim it cannot support. That single instruction removes most invented detail.
5. 5Cut the job in half. Extraction and judgment in one prompt is where quality falls apart. Pull the facts in one step, reason about them in the next.

Why a boring table beats an impressive summary

Here is the fact: a summary compresses, and compression hides where a claim came from. Here is my reading of it, which is mine and not something the docs say. A summary is optimised for being read. A table is optimised for being checked. Early on you need the second one far more than the first, because you have no calibration yet for when this thing is bluffing.

There is a second reason, and it is the practical one. A table survives being partly wrong. One bad row gets deleted and the other eleven still work. A subtly wrong summary has to be thrown out whole, because you cannot tell which sentence broke it. That is why the artifact from your first project keeps its value even if your first idea about the project turns out to be off.

What actually changes after 30 days

Honestly: less than the internet promises and more than you expect. You will not be an AI expert. Nobody is thirty days in, and anyone selling you that timeline is selling you the timeline.

What you will have is specific. One prompt you trust enough to reuse without rereading it. Two jobs that now take a third of the time they used to. A real sense of which tasks this thing is bad at, which is knowledge you cannot get from a course. And the habit of looking at a confident paragraph and asking where it came from, which is the part that keeps paying after the tools change.

So pick the one row from the table that matches a job you were going to do this week anyway. Run it once. Then answer the only question that matters at the end of the month: what did you have to fix by hand every single time? That list is your actual curriculum, and nobody else can write it for you.