Becoming an AI Power User

A model may guess at the situation you forgot to describe

With a human colleague, you reach shared understanding through back-and-forth: the questions they ask, the assumptions they check, the references you both already hold. With AI, you build that shared situation first, because the model can only act on what it can see, and a great deal of what decides the work is in your head, not on the screen. Context engineering is the practice of making the deciding distinctions visible: the assumptions, priorities, and standards that feel obvious to you and are simply absent from the model's view. Your role, your audience, your goal, your constraints, your examples, and your source material are where those distinctions live. They are the same things a good collaborator would need to stand in for you.

A generic answer usually traces back to a generic input. A bare prompt gives the model too little to tell one good answer from another, so it fills the gaps with reasonable guesses, the way a colleague would guess if you said 'just handle it' and walked off without a briefing. The guesses are not careless. They are the average of all the ways that question has ever been asked, which is exactly why they fit no one in particular. The rules for a productive conversation with AI turn out to be the rules for a productive one between people: say enough for the listener to act, stay relevant, and be clear about what you need.^[1]

The same task asked two ways produces two different answers

Watch what one set of distinctions does to the same request. Here is a prompt that produces a generic, forgettable answer: 'Write a project update email.' And here is the same task carrying its context: 'You are a senior project manager writing a weekly update to a VP of Engineering who cares about three things, timeline risk, blocked dependencies, and headcount needs. The project is a data migration from a legacy Oracle database to PostgreSQL. We are two weeks behind because the vendor's API documentation was incomplete. Keep the tone direct and concise, and keep it under 300 words.'

The second prompt costs about thirty seconds more to write, and the output comes back usable instead of needing a rewrite. Read what the thirty seconds bought: a job title that sets the voice, a named reader with three stated priorities, the one fact that explains the delay, and two hard limits on tone and length. Each of those is a distinction that rules out a wrong version of the email. Power users build the situation into the prompt before any interaction worth getting right, so the model starts from their distinctions instead of guessing at them.

Give the model the situation before you ask for the output

You do not need to memorize a formula. You need one habit: before you ask AI for output, give it the situation. Six elements cover most of what a model needs to tell good work from generic work on a given task. They map the six places your deciding distinctions tend to hide, so naming them makes the hidden ones easy to find. You supply the ones that matter for the task in front of you, not all six every time.

The six fall into two layers, and naming the layers tells you how much to supply. Role, audience, and goal are the floor: who is speaking, who is listening, and what the output is for. Almost no task reads right without them. Constraints, examples, and source material are the depth you add when the task can go many ways: the limits that rule out wrong shapes, the model of a good version, and the raw material the answer must be built from. A simple request needs the floor. A request that could miss in a dozen directions needs the depth that closes those directions off.

Match the amount of context to how varied the task is. The cyberneticist W. Ross Ashby gave this its general form in 1956: to steer a situation with many possible states, your response needs enough variety to match it. A one-line brief cannot steer a task with a dozen ways to miss, the way one knob cannot tune a sound with a dozen settings. The harder and more open the task, the more of the depth layer it earns.

That match is the rule for today, and it loosens as you go. As your saved standards and examples accumulate, and as models grow better at inferring intent from less, more of the deciding distinctions come from your stored context instead of from each fresh brief. The aim is not to type more every time. It is intent understood deeply enough that even an underspecified request comes back aligned with what you wanted, because your accumulated principles and prior work already carry the specification.

The context you supply now becomes the standard you check against later. When you say 'under 300 words, direct tone, no jargon,' you have named three things the output can be measured on. As distinctions like these accumulate, they can grow into a written rubric, and later into a judge prompt that checks the work against them. The next chapter develops that move, so for now it is enough to notice that loading context and checking output draw on the same set of distinctions.

Curate the context, because leaving the wrong things out steers better than piling everything in

Context loading is not context dumping. Give the model the context a colleague would need for this task, and stop there, rather than every file, private note, client detail, or internal thread that happens to be nearby. The target is minimum sufficient context: enough for good judgment, with irrelevant or sensitive detail removed before it ever reaches the model.

Curating context is as much about what you leave out as what you put in. A transcript from a client call is useful context for drafting a follow-up email. The client's private financial details buried in that transcript have nothing to do with the email, so they come out before you paste. A project folder is useful context for a coding agent. Your credentials file inside that folder is a risk, not context. Treat every piece you share as something the model now processes, which can include reflecting it back somewhere you did not expect.

When more context makes the output worse, the cause is usually ordering, not volume. If you add detail and the answer drifts, the model may be weighting a nice-to-have as if it were a rule. The habit that fixes it is positional: state the non-negotiable constraints first, the preferences second, the background last. A model reads priority partly from position, so the distinctions that must hold belong at the top, ahead of the ones that would merely be nice. Put another way, the six elements describe what to include, and this ordering habit describes what to demote, so a long package full of the wrong emphasis does not drown out the few lines that decide the work.

Pause before you type, and the moment to load context appears

The pause is the switch from lookup mode to collaboration mode. When you type a bare question, you are treating AI like a search engine: you already know what you need and you want a fast answer back. When you load context first, you are treating it like a colleague: you brief them on the situation before you ask for their contribution. The first mode is fine for a fact you can verify at a glance. The second is what the work worth getting right deserves, and the half-second pause is what reminds you which mode you are in.

Watch advice you already knew turn into feedback you can act on

Tell the model what makes your day yours, not the average person's

Bring this back to the project running through the book: building your own personalized setup, tuned to how you live and work. As of 2026, using it looks like describing what you want to a chat model and refining what it gives back. The box you type into will not stay a box. It becomes voice, then glasses that carry world knowledge, then earbuds, then something closer to a thought. The interface keeps changing. What the model needs from you, the few distinctions that make your day yours, does not change with it.

Picture two ways the same request can go. The don't-apply path: ask 'build me a daily planner' and accept whatever comes back. A planner built from no distinctions is built from the average person's day, so it schedules deep work in your most distracted hour and treats the school pickup you cannot move as a soft preference. The do-apply path: supply the few distinctions that make your day yours before you ask. You write best before 10 a.m. Thursday evenings are nonnegotiable family time. You would rather miss a workout than a deadline. State the nonnegotiables first, the preferences after. Now the same model produces a setup that fits the one life it is for, because you told it where your life differs from the default.

Save those distinctions as a context block, not a memory you retype each session. A context block is a short, named piece of standing context you paste at the top of a prompt, or store where your AI assistant can load it on its own. Write it once, and the next request for a different part of your setup, the reading list, the travel routine, the weekly review, starts from the same true picture of you instead of from the average. How you store and reuse blocks like these grows into a small library, and the reusable-AI-assets chapter later in the book is where that library and its mechanics belong, so the work here stays at the level of writing one good block you can keep.

Build your context package for the task you do most

Pick one task you do at least weekly with AI. It could be drafting emails, preparing meeting notes, writing project updates, reviewing documents, or creating content. Write a context package you can paste at the top of every prompt for that task, with the deciding distinctions ordered non-negotiables first. Then let it sharpen itself: when a result misses, you can ask the model to compare what it produced against what you wanted and name the distinction that would have prevented the miss, then fold that distinction back into the package. Over a few rounds the package ends up sharper than you were when you first wrote it. Later in the book the same package becomes the shared specification you hand to several focused conversations at once, when a project is large enough to split across parallel work. The package you write today is the seed of that.