Learn to Drive Before You Study the Engine

Take the transcript of an hour-long meeting you sat through, one where you know five decisions were made. Paste it into an AI assistant and ask for the decisions and who owns each one.

The answer comes back in seconds, cleanly formatted, and it lists four decisions. Three are right. The fourth names an owner who was in the room but never volunteered. The fifth decision, made in the last few minutes, is missing. You can see all this only because you were there.

So you change what you gave it. You add the list of attendees. You ask for each decision to be followed by the line from the transcript that supports it, and for "no owner named" when nobody took the task. The invented owner disappears. The missing decision either shows up with its quote, or it's still missing and you can check the last ten minutes yourself. The output has gone from something you'd have to trust or redo to something you can verify in two minutes.

Ten minutes, and you've learned more that you'll actually use than a chapter on how transformers work would teach you. That's the argument of this piece. You can get good at AI long before you understand how it works. It takes practice on your own work, a personal map of where the output can be trusted, and only the few pieces of mechanism that change what you do. People learn to drive years before they could explain a gearbox, and most never learn to.

Why use comes before reading

Most advice for newcomers starts with the engine: transformers, training, embeddings, agents. Three properties of this technology make that the wrong place to start.

The car changes model every few months. Between November 2025 and September 2026, Anthropic's Opus line went from Opus 4.5 to Opus 5.5, with four versions in between, and a pricier tier appeared above it. Even basic controls moved. By Anthropic's own estimate, its newer models count the same text as roughly 30 percent more tokens, the chunks of text a model reads and is billed by, than their predecessors did. A week spent reading about last year's models teaches you about last year. A week spent using this year's tools on your own work teaches you what they do with your work.

What you need to know is specific to your tasks. In a 2023 field experiment with 758 consultants at Boston Consulting Group, those given GPT-4 finished 12.2 percent more tasks, 25.1 percent faster, at quality rated more than 40 percent higher, on tasks inside what the authors called the jagged frontier of AI capability. On a task designed to fall just outside it, consultants using AI were 19 percentage points less likely to get the right answer than those working alone. Tasks of similar apparent difficulty landed on either side of that edge. Where it falls for you depends on your tasks and your material, so nobody can draw it for you in advance.

Producing and checking teach more than reading. Memory research has found for decades that people remember what they generate better than what they only read, and that testing yourself beats rereading over time. Those studies measured memory for words and prose, not skill with AI, so applying them here is an inference. It's a reasonable one. Writing your own request and judging the answer makes you produce and retrieve. Reading a guide to prompting asks for neither.

Two cautions

A good teacher would push back, with evidence. Research on discovery learning finds that novices left to explore with minimal guidance learn poorly, and that students who study worked-out solutions beat students who solve the same problems from scratch. "Just play with it" is weak advice for that reason.

The fix is to practice with an example beside you. Take a request that works for someone who does work like yours, run it on your own material, notice what changes, then vary it. That's a worked example followed by your own attempt, the combination the research supports. Lean on examples early and drop them as your own feel for the tool fills in.

The second caution is sharper. In a 2025 field experiment with nearly a thousand high-school math students in Turkey, those given unrestricted GPT-4 during practice did 48 percent better on practice problems, then scored 17 percent lower on the exam, taken without AI, than students who never had it. Many had simply asked for the answers. A tutor version that gave hints instead largely removed the harm.

Use teaches you the tool. It can also stop teaching you your craft, when the tool does the part that would have taught you.

So keep two kinds of learning apart. Learning to use AI benefits from use, because you write the request and do the checking. Learning your own craft can suffer from use, if the tool does the thinking the craft is made of.

The loop: try, check, adjust, record

The meeting exercise was one turn of a loop, and getting good is just that loop, repeated.

Scroll sideways to see the whole figure

Try the tool on a real task where you already know roughly what good looks like. Check the output against what you know, not against how convincing it sounds. Adjust, usually by changing what you gave the model (the material, the audience, the purpose, an example of a good result) before you touch the wording. Record one line about what you learned: "Meeting decisions: reliable with quotes requested; owners need a check; late decisions sometimes dropped."

Each place people stall feels reasonable at the time. Hunting for magic wording feels like skill, but the model was usually missing information, and no phrasing supplies it. Keeping the lesson in your head is the quietest stall of all: it fades, nobody else benefits, and when the model changes you can't tell which habits to retest.

A map only you can draw

That recorded line is the start of a map, and the map is the real skill.

Calibration means your trust matches reality. A weather forecaster is well calibrated when it rains on about 70 percent of the days she gives a 70 percent chance. You're well calibrated with AI when, for each kind of task you do, you know how often the output is usable as it stands, usable after a check, or wrong in a way that costs you.

Feel is a poor guide to it. In a 2025 randomized trial by METR, experienced open-source developers working on code they knew well took 19 percent longer with AI tools, and afterward still believed they'd been about 20 percent faster. The study was small, and a follow-up with newer tools estimated a modest speedup instead, with wide uncertainty. The lesson that survives is about people: experienced professionals misjudged a tool they used every day. Feeling faster is not a measurement.

So build the map deliberately, and cheaply. Use tasks where you hold the answer key: work you've already done, documents you know well, numbers you can verify. Run each kind of task five to ten times on different material and tally three outcomes: usable, fixable, wrong. Next to each row, note what a miss costs and whether you'd see it.

Scroll sideways to see the whole figure

That last column matters as much as the tally. A wrong spreadsheet formula usually breaks something you notice. A wrong figure copied from a PDF sits quietly in a report until someone else finds it. A task that fails visibly one time in five can be safer to delegate than one that fails silently one time in twenty.

The map describes a combination: one model, the product around it, and your tasks. Change any of the three and some rows move. When a new model ships, rerun the same handful of examples for each row. That small fixed set is a personal evaluation set, and twenty minutes of rerunning it tells you more about whether a new model helps you than any launch announcement, because the announcement measured someone else's work (Leaderboards Measure the Test).

Trust belongs to a task, a model and a product together. Change any one of them and that part of the map needs a recheck.

The four pieces of the engine worth knowing

The test for any piece of mechanism is whether knowing it changes something you do. Most of the vocabulary fails that test for a beginner. Four pieces pass.

It reads tokens, not letters. A model doesn't see characters; it sees tokens, often whole common words or fragments of rarer ones. So tasks that depend on individual characters, like counting letters or hitting an exact length, are weak spots. Ask it to use code when the product can run code. And remember that limits and prices are counted in tokens, which shift from one model to the next (The Model Never Sees Your Words).

Its knowledge lives in three places. Training is what the model absorbed before a cutoff date: broad, blurry at the edges, fixed for that version, with no source attached. Anything after the cutoff, and anything private to you, isn't there. Context is everything in front of it in this conversation, meaning your messages, your files and the results of any tool the product ran. This is where precision comes from, and where most "it doesn't know" problems get fixed: give it the document instead of asking it to remember one. Product memory is notes some products save between conversations and put back into a new conversation's context. The common confusion sounds like "it learned that from me last week." It almost certainly didn't. The product stored a note and showed it to the model again, which is why that note can be stale, differs by product, and stays behind when you switch tools (What It Means for AI to Remember).

Fluency is not evidence. A model produces the continuation that best fits its training and its context. Training rewards plausible text first and pushes toward correct answers only later, and unevenly, so smooth prose is guaranteed and truth is not. People have the matching weakness: in a 1999 experiment, statements printed in an easier-to-read color were judged true more often. A model that writes smoothly and a reader who trusts smooth writing make a pair that needs a deliberate check. Check names, numbers, dates, quotes and citations whenever they matter, and ask for the supporting passage when you supplied the material.

The product around the model matters. You rarely use a model directly. You use a product that wraps it in instructions you don't see, tools such as web search or code execution, file handling and memory. The same model can succeed in one product and fail in another because it was shown or allowed different things. Before concluding it can't do a task, ask what it could see and do (Same Model, Different Results).

Everything else can wait until a failure repeats after you've changed both what you gave the model and how you asked. That's the moment an explanation changes the fix, and an explanation that arrives attached to a real problem tends to stick. Many prompting tricks, meanwhile, were patches for one generation of models and fade with it. Staying a little behind the frontier on tricks while keeping your own map current is a cheap position to hold.

First exercises

A good first exercise uses your own work, has an answer you already know, costs minutes when it goes wrong, and can be checked in minutes. Use material your organization allows in the tool.

Rewrite something you've already written for a different reader. You know what you meant, so distortions jump out, and you'll learn that saying who the reader is changes results far more than rephrasing the request.

Summarize something you know completely, like the meeting above. It teaches the gap between fluent and correct, and the single most useful adjustment: ask for the supporting quote.

Ask about your own field. Your expertise makes confident errors easy to spot. Expect solid ground on widely discussed topics and thin ground on recent, local or specialized ones.

Try a task with an exact answer, twice: once plainly, once asking the model to use code, and compare both with the source.

Avoid, at first, tasks you can't check. A question about a field you know nothing about teaches you nothing about reliability, because you can't see the errors.

From one person's skill to a team's

Individual calibration lives in heads, fades, and goes stale with every model. My advice to anyone running a team is to move it into shared form with three habits.

Share worked examples, not magic phrases. The useful unit is a complete case: the task, what the model was given, what it returned, how it was checked and the verdict. A library of clever prompts without the check and the verdict keeps the perishable part and throws away the durable one.

Keep a small shared evaluation set for common tasks: ten examples each, with known good answers and a named owner. When a model or product changes, rerun them. "Should we switch?" stops being a debate about announcements and becomes an afternoon of evidence.

Treat a caught failure as a contribution. Failures are the most valuable entries and the least shared, because nobody enjoys admitting the tool fooled them. A team where "it was wrong and I caught it" counts builds its map much faster than one that only circulates wins.

That suggests a better measure of skill than prompts sent or seats used: how many of your common tasks have a known answer to "can we trust this, and how do we check?" This is how work starts to compound (When Work Starts to Compound), and it pays even before the company has picked a tool for every need, because the habits carry over to whatever arrives next.

The specifics here will date. Model names will change, memory will work differently, and your map will need redrawing more than once a year. What carries over is the way of working: try the tool on tasks you can judge, check it against what you know, change what you give it before how you ask, and write down what you learned, so you can tell what to retest when the car changes underneath you.

Check yourself

Why does the author say to start by using the tool, not by studying how it works?

Models change every few months, and where the tool can be trusted depends on your own tasks and material. Producing and checking teaches more than reading about it.

What happened to the students who practiced with unrestricted GPT-4, and what does it show?

They did better on practice problems but worse on the exam taken without AI, because many just asked for answers. Use teaches you the tool, but it can stop teaching you your craft when the tool does the part that would have taught you.

Why can a task that fails visibly one time in five be safer to delegate than one that fails silently one time in twenty?

You catch the visible failures, while a silent wrong figure sits in a report until someone else finds it. What a miss costs and whether you would see it matter as much as the tally.