Becoming an AI Power User

You ask AI for a client update, the draft comes back close, and you fix the tone and the missing context by hand. It works, and you move on. Next week you ask for the same kind of update, and you fix the same two things again, because the fix you made the first time lived only in your head. It was never written down, so it could not travel to the next request. That reset, back to a blank request every time, is the default way of working with AI. One move ends it: write the fix down once, in a form your next request can reach, and the same two corrections stop being your job.

Each session restarts from zero unless your system remembers for you

Notice how you use AI today. You open a fresh conversation, and the model knows nothing about the last time you did this task. You retype the context from memory. You retype the constraints. If you found a follow-up move that worked last week, you have to remember it to use it again, and often you do not. As of 2026 this looks like typing into a chat model and rebuilding the setup each time. The interface will change, to voice, then to glasses, then to brain-computer interfaces, then to whatever comes after, and the blank-start problem rides along underneath every one of them unless you give the system something to remember. A saved standard is what carries your intent across that gap no matter how you reach the model.

Power users save the requests that worked and reach for them instead of rebuilding from scratch. They keep a small set of prompts and standards grouped by the work they do, and they improve the saved versions over time the way a cook improves a recipe: the version you reach for this month tends to be better than last month's, which was better than the first attempt. The pull is not only discipline. It is curiosity too, the steady 'wouldn't it be sharper if I tried it this way,' a small experiment folded into the saved version. Each pass carries forward what you learned and what you played with, so the asset keeps growing instead of evaporating when you close the tab.

Tal Raviv and Aman Khan's essay 'How to build AI product sense,' on Lenny's Newsletter, names a pattern that compounds across sessions: save one version that works as a baseline, then fork it for variations rather than starting each new attempt cold. A saved baseline you can copy and adjust is how separate sessions start adding up into a library you reuse, instead of staying a row of one-off conversations you never look at again.

Group your library by the job each asset does, not by where you found it

A library you open by habit is grouped by the work you do every week, so reaching for it is the obvious move. When the groups match your real jobs, your hand goes to the right shelf without thinking. The library that goes unused is the one grouped by where each prompt came from: a folder of clever prompts saved from a newsletter, a video, a thread you scrolled past. The collection grows, you feel productive saving to it, and you almost never open it, because nothing in the structure points back to your work.

An ungrouped library can rot into a graveyard, so the grouping is part of keeping it alive. A prompt you saved six months ago and never used is neither helping nor hurting. A prompt that silently produces weaker output because the model moved on is a quiet drag, and you will not find it to fix it unless the library is organized enough to review. The upkeep schedule comes later in this chapter, in the section on assets going stale. The habit to build now is to file each asset under the job it serves.

To keep the groups few enough to hold in your head, sort assets into a small set of named families instead of one long list. Six cover most knowledge work, with a seventh for projects that span many conversations:

The family names are yours to bend. If your week is mostly teaching, or mostly support tickets, or mostly grant writing, rename the families after those jobs. The principle is fixed and the labels are not: group by the work the asset helps you do again, so the structure points back at your real week.

Store your library wherever you will reach for it daily

The storage that works is the one you will open without effort, and the right choice depends on how you already work. There is no single correct place. There are three families of option, each strong for a different person, and the question is which one sits closest to where your hand already goes.

As of 2026 the three look like this, and the trade-off behind each survives whatever the tools become:

• Inside your AI tool. Some tools let you save instructions, reference documents, and starter prompts directly in a named project or custom assistant. This is the quickest to reach while you are already working, and the trade-off is that it stays locked to that one tool.
• In a notes app. A notes database or a folder organized by job family, in whatever notes app you already live in. This is portable across tools and easy to share, and the trade-off is one more app to open.
• In a text file or a code repository. A single markdown file, or a folder of plain text files under version control. This is durable and easy to track changes in, and it pays off especially when you work with coding agents, with the trade-off of feeling more technical to set up.

Pick the option with the least setup and start there; you can move later. The choice of store matters far less than getting your first three assets out of your head and into any one of them this week. A library you began in a plain text file beats a perfect system you never started.

Let the model extract the reusable asset before you close the tab

A quick way to grow a library is to ask the model to pull the asset out for you at the end of a session. After an exchange that produced something good, tell the model to turn it into a reusable prompt, a short quality checklist, and a one-sentence note on what made the output work. The model can often see which piece of context was load-bearing, which follow-up moves improved the result, and which constraints shaped it, and it can hand those back to you as something to save. You keep all three.

This is the meta-prompt move from the chapter on the power-user learning loop, aimed at your library. Every useful session hides a reusable pattern, and meta-prompting lifts it out before the session scrolls away. The same move works in reverse after a bad session: ask the model what was underspecified in your request and how to rewrite the prompt so the failure does not recur. Save its answer as a revised prompt with a one-line note naming the failure it now prevents, and that note keeps the same failure from sinking the next session.

Saved standards drift as models change, so plan to retest them

A library is a living system, and its standards go stale on their own. A prompt that works today can drift when the model updates, when your work changes, or when context that was current becomes outdated. The drift is quiet. The prompt still runs and still returns something, so nothing flags that the output got weaker. This is the upkeep cost named at the start of the chapter, arriving where you can do something about it.

A short, regular review keeps the compounding clean instead of letting it rot. Power users re-test the handful of assets they lean on most, on a schedule, retire any they have not reached for in months, and update any that name a specific tool, date, or constraint that has since changed. A quarterly pass is enough for most personal libraries. Without it, a library slowly fills with assets that produce confusing results, because the current model reads old instructions differently than the model they were written against.

Use each review to evolve the library, not just to clean it. Cleaning keeps the system alive; evolving moves it up a level. When a re-test turns up a better pattern, promote what you learned into a more durable form rather than patching the old prompt: a prompt becomes a spec, a spec gains a rubric, a set of rubrics becomes a standard or a small workflow that does not depend on one model's current habits. Each climb hands more of the recurring work to the system and frees you to aim at the next thing, which is what the next section is about.

Specs describe the destination, so they outlast the prompts that take one route there

A prompt tells the model how to produce an output; a spec describes what the output should be, and the difference is why specs last longer. A spec lists the required sections, the audience, the tone, the constraints, the conditions that make it good, and an example or two of what good looks like. Both are worth saving. The spec has a structural advantage: it names the destination instead of the route, and a destination does not change when the roads do.

Prompts encode your instructions in the model's current language, and that language shifts under them. When the model updates, some of those instructions get read differently, which is the quiet drift from the section above. A spec sidesteps much of this because it describes the deliverable's properties directly. A spec that says 'open with the three highest-priority findings, use active voice, run 400 to 600 words, and cite sources inline' will keep producing a consistent deliverable across model versions. A prompt that says 'write a concise research brief with key findings' can produce a different structure each time the model changes its default formatting.^[1]

You can start saving specs alongside your prompts today. After you produce a deliverable you are happy with, write a short description of what made it good: its structure, its length, its tone, what it assumed about the audience, the constraints it respected. Save that as a spec. The next time you need a similar deliverable, hand the spec to your AI tool and ask it to produce output that matches. The spec is portable across models, across tools, and across time, because it carries the standard rather than the phrasing.

Build your first working library this week