First steps with AI: teaching notes

"There are fourteen ideas here, one per screen. We start with what the machine actually is, then what you can trust it with, then how to work with it so it earns its keep. You don't need to remember all of it today. What matters is that you leave knowing what this thing is and what you'd point it at on Monday."

"This is the plan. First, what the machine actually is, which takes two screens and explains almost everything else. Then what to trust it with and where to check. Then the working habits, which is the biggest part. And last, how to make it stick past this session. If you get lost, we come back to this screen."

"The single most useful thing to understand is that it isn't searching. There's no database of answers behind it. It looks at everything so far and picks a likely next word, then does that again, and again, until there's an answer. Your phone keyboard has done a tiny version of this for years. This is the same idea at enormous scale. Almost everything that surprises people later comes back to this one fact." (Pairs with framings.md, the prediction framing.)

"Two stages made this thing. First it read an enormous amount and learned to predict text. That alone gives you something fluent with no idea how to be useful. Then people rated its answers, over and over, until it behaved like an assistant. So the politeness and the caution aren't magic, they were trained in. That same training left two habits you should know about: it leans towards agreeing with you, and it leans towards writing too much. Both are fixable by asking. 'Push back on this' and 'half the length' both work."

"Here's the trade. Because it's predicting what sounds right, it's genuinely strong on work that's been done a million times: summarising, drafting, explaining, rewording. And it can tell you something false with total confidence. People call that a hallucination. You don't need to be frightened of it, you need one habit: the more precise the claim, the more it deserves a look. Names, dates, numbers, quotes, links. Be most careful outside your own field, because that's where you can't spot the miss."

"Everything it's paying attention to sits in one container: your messages, its replies, anything you've uploaded. What's in the container it can use. When the container fills, the older parts drop out, and it won't tell you they have. So two habits. In a long conversation, restate what matters instead of trusting that page one survived. And don't assume it remembers last week: a correction you made in one chat does not carry into the next unless you've put it somewhere it can see. The container is big, roughly five hundred pages, but it isn't infinite."

"There's no special syntax to learn, and there are no magic words. Talk to it the way you'd brief a capable colleague. The change that matters isn't how you type, it's what you bring. Most people bring it questions they could have looked up: what does this acronym mean, write me a haiku. Small in, small out. Bring it the work you'd normally sit down and do yourself, and it becomes a different tool. Same Claude on the web, on your desktop and on your phone, and it stays signed in across them." (Pairs with framings.md, the colleague framing.)

"If you take one thing out of today, take this. A good ask does three things. It sets the scene: who you are, what's going on. It states the task: the thing you want produced. And it gives the rules: tone, length, format. Look at the difference on the screen. 'Write an email about the project delay' gets you something generic, and then you blame the tool. The version with the scene and the rules gets you something you could almost send. Same request. The gap is entirely in the brief."

"The first answer is a draft. That's it. People read the first reply, decide it's not right, and close the tab. That's like reading a colleague's first draft and firing them. Say what to change and go again, as many rounds as it takes. Two things make the loop work. Specific beats vague: 'cut the first two paragraphs' lands better than 'make it shorter'. And if a conversation has genuinely gone off the rails, a fresh chat with a better brief is usually faster than rescuing the old one."

"This is the upgrade almost everyone misses. 'Make it shorter' can be obeyed perfectly and still ruin the thing, because it cut the part you needed. Say what you're actually after: 'make this shorter, my goal is that the key finding survives a twenty-second skim'. Instruction plus goal. Now it can make the trade-offs the way you would have. It works on people too, which is why it's worth the habit."

"Stop describing your document to it. Give it the document. It reads reports, spreadsheets, photographs, slides. A conversation holds around five hundred pages, so 'read this sixty-page contract and flag anything unusual' is a normal ask, not a special one. And this is what makes the output sound like your work instead of generic: it is your work. The material is yours, it's just doing the reading."

"By now you might be thinking this is a lot of setting up every time. It isn't, because you do it once. A Project is a workspace: you put the files in once, the brand guide, the contract, the past work, and you write your standing instructions once, 'always plain English, always end with next steps'. Every conversation you start in there begins already knowing all of it. Separately, it picks up your role and preferences across chats, and you can look at what it holds and change it. Between the two, your tenth conversation should feel nothing like your first, because you've stopped introducing yourself."

"This is the part people skip, and it's the part that decides whether this works for you. Before you prompt anything, split the work three ways. What stays yours: the final judgement, anything confidential, anything you couldn't check if it were wrong. What you do together: thinking a problem through, drafting and revising, stress-testing a plan. And what you hand over: summarising, reformatting, first drafts of routine pieces, the research legwork. The goal isn't to automate everything. The middle bucket is where the value is, because you bring the expertise and the stakes and it brings speed and range. If you can't tell which bucket something belongs in, ask it to help you split the task. That conversation costs you nothing."

"Three checks before anything leaves your desk. Check the specifics: the names, the numbers, the claims, verified rather than assumed. Tell people where your audience would expect to know it helped. And put your name on it, because you own the result, not the tool. What 'telling people' means changes with the context: a client report, an internal note and a personal email carry different expectations. Know where your workplace draws the line, and when you're not sure, say it plainly in a footer."

"Everything today happens in a chat window. There's a further step, and it's worth knowing it exists: tools where it works in your actual files and hands back the finished document. The change is delegating rather than chatting. 'Look across the meeting notes, the email thread and the proposal, and write the one-page summary for the exec team.' It plans it, works through the steps, asks you before it does anything significant, and saves the result into your folder. That's a later session. Everything you learned today is what that stands on, so nothing here is wasted."

"One task this week. Not ten. Something recurring that you already do: the weekly email, the meeting notes, the spreadsheet check. Brief it properly, run the loop, and then do the thing that teaches you fastest: compare its version to yours. You'll see exactly where it saves you time and exactly where your judgement is still doing the work. Keep the prompt that worked. That's the beginning of your own library, and that's the whole thing, one task at a time."

"That's the session in one line. The tool predicts words. Everything else, whether it's worth anything to you, depends on you: what you bring it, how you brief it, what you check, and what you decide stays yours."