Build Your Knowledge Flywheel with AI

The AI on the other side listens carefully every time, and what it hands back is roughly usable every time, yet it always falls a bit short. I couldn't help but start to wonder: is it that I haven't learned the tools well enough? Should I go study some new features?

Later I figured out one thing: the problem may not be that I haven't learned enough, but that nothing has been accumulated.

In the past I used AI like a rocket—ignition, liftoff, done, one investment for one result. Once the material was written, that was the end of it; next time in a different direction, I'd have to ignite from scratch again. But people who truly get smoother the more they use it are actually using something else: a flywheel. The first turn of a flywheel is the hardest; you push for a long time and it barely moves; but once it spins, the same effort returns ever-greater speed. The difference is that the investment stays on the wheel.

So what this piece wants to say is not "learn a few more features," but why some people get more effortless with AI while others, after a year, are still repeating the same instructions from square one; and starting today, from which point you can begin to turn.

Learning itself is meant to accelerate

Set AI aside for a moment. Learning itself gets faster the more you learn.

A learning-science review by the U.S. National Research Council points out: all new learning builds on existing experience and knowledge. People with a solid foundation, who understand the underlying organizing principles, and who have practiced in multiple contexts are more likely to apply what they've learned to new problems. This transfer sometimes shows up as noticeably faster onboarding when entering an entirely new field.

In everyday life, this principle is especially intuitive. Someone who can ride a bicycle barely needs to relearn balance the first time they ride an electric bike; someone who has thoroughly grasped the logic of Excel will not find a database completely unfamiliar the first time they encounter one—concepts like "this column is the primary key" are connected to the "table" they are already familiar with.

The same applies to AI. Someone who is in the habit of breaking tasks into steps and clearly stating acceptance criteria will not panic the first time they encounter an Agent. Because what they bring is a method, not the location of some button.

Of course, this is not to say that everyone can strictly follow some kind of curve of growth. Accelerated learning has a precondition: the existing knowledge must be a systematic foundation, not a smattering of impressions; mistaken understanding can sometimes actually hold you back. But looked at the other way, this also means: what you learned in the past was not learned in vain, as long as it is a structure whose parts connect with one another.

People who can transfer skills do not count switching tools as relearning

So between AI tools, what exactly can be carried over, and what cannot?

First, one more term: Agent. You can think of it as a subordinate who works for you—give it a goal, and it can represent you, organizing the steps, tools, and judgments for a task and completing it relatively independently. What matters about it is not that it "can chat," but that it "can handle things according to a process."

Using an Agent is like using any tool: what can be carried over is the method, what cannot be carried over is the details. What can be carried over are those shared concepts—organizing steps around a goal, judging when to call which tool, and clearly explaining boundaries and acceptance criteria. What cannot be carried over are the differences among tools in permissions, context, interaction methods, and capability boundaries.

Just as knowing how to drive and being familiar with a particular car are two different things. Switch to another car, and for the first few days you always have to readjust the mirrors and find the wipers, but after a week, you can no longer feel the difference. What is really worth caring about is not "whether this tool will replace that one," but "whether my driving ability at this level has been accumulated somewhere outside the tools."

So do not be fooled by the saying "learn one and you will know them all." What can be transferred are concepts and methods; the layer of accumulation beyond the methods, you have to save a separate copy of yourself.

What becomes obsolete is the buttons, not the method

But thinking a bit deeper, a more piercing thought comes up: AI changes generations so fast that the buttons and terminology I spend weeks memorizing may be wiped out in the next version. Rather than putting in the effort to learn, it is better to wait until it stabilizes—this does not sound like laziness, but rather like calculating stop-loss.

What is wrong with this calculation is that it counts two things as being on the same level.The first things to become obsolete are where the buttons are, what the menus are called, this version's permission rules, and that vendor's prompting habits; what survives across versions better is how you break down tasks, how you define done, how you judge which steps cannot be handed to it, and how you review afterward.In my view, the former is operation, the latter is method—operations expire with each version, methods are what you accumulate.

And learning slowly is not necessarily a loss. Transfer often has an overlooked time lag: it may not pay off while you are learning, but waits until you encounter the next domain, where it shows up as getting up to speed faster. Seen this way, "learning slowly" and "being useless" are two different things—the slow stretch is precisely the stretch when structure is being stored in your brain. Of course, the preconditions still hold: the foundations are systematic, the principles can be stated clearly, and the old and new situations are similar.

So where is the expert fast? There are two mechanisms: accumulated knowledge lowers the attention burden when you perform skilled actions, and the saved attention can go entirely to the small part where the new tool is genuinely different; and knowledge organized into interconnected structures can be recombined to solve problems never seen before. Applied to AI, my more intuitive experience is comparison—experts in an unfamiliar interface see what is the same, what is different, and where the real pitfalls are, while novices can only memorize from scratch. With different starting points, experts are better positioned to reach for more complex things.

But don't hear this as "then just take it slow." Useful slowness is slowness in structure; what is dangerous is learning very smoothly but only smoothly on the surface of some tool—when that layer changes, you have nowhere else to fall back on. After learning each thing, I ask myself: apart from this button, what sentence do I have left that I can say to a new tool?

Finally, let me be clear about the cost of this account. If old knowledge is wrong, or tightly bound to a particular tool, it not only fails to help but also pre-judges for you, obscuring the places in the new tool that truly deserve attention; research also suggests that prior knowledge can bring bias, which must be actively corrected. So transfer is not free; the tuition is called correction—you have to admit which parts have expired and change them by hand, and only then has your past learning not been wasted.

Why, after a year of use, you still have no compounding

You understand all the principles, yet many people after a year of using AI are still spinning in place. Where is the problem?

From what I've observed, it is mostly these three things repeating.

First, every time it all depends on improvising out loud. Background, preferences, what can be moved and what cannot—each time you remember temporarily to say it once, and when you're done it's done, never written down a second time.

Second, when it's done, everyone disperses. Once something works, you don't look back to see which step was luck and which step was destined to be redone. So the same pit gets stepped in again next time.

Third, for repeated multi-step tasks, each time you let AI re-plan from scratch and re-understand your conventions. Because every time is a new beginning, its output is sometimes good and sometimes bad, and you can only keep redoing it along with it.

You can give yourself a quick self-check with three questions: Among the things you had AI do this week, how many were also done last week? For how many of them can you state clearly, within thirty seconds, their inputs and acceptance criteria? For how many did the failure occur because it did not understand your scenario? If more than two of these hit, your flywheel is very likely being pushed back to the starting point on every turn.

The problem is never that you are not working hard enough. It is that your effort has not been stored—it lives only in your own head, and the head forgets.

When a task is done, two things should be left behind

So what exactly should be stored, and how? I increasingly feel that when a task is done, two outputs should be left behind. The first is the result itself; the second is the material that keeps the next round from having to be explained again.

Write down the workflow that already works, why you judged it that way at the time, and what common exceptions exist, so that it becomes a clear explanation—far more reliable than improvising an oral account each time. With an explanation that has clear steps, specific actions, and coverage of boundary cases, AI will misunderstand much less and make fewer errors. OpenAI's Agent practice guide explicitly recommends: turn existing process documents into routines suitable for model execution; clear steps and specific actions reduce ambiguity and errors.

And when a pattern is frequent enough, stable enough, has clear inputs and outputs, and its results can be verified, you can go further and encapsulate it into a reusable capability module—like keeping a recipe for a dish you often make, so next time you just follow it. This kind of thing is what is commonly called a Skill. It packages repeated multi-step tasks, and what it saves is precisely the inconsistency and waste caused by re-planning and re-understanding the conventions each time.

But there is a key sense of proportion here: not everything is worth turning into a module. I generally judge by four layers:

One-off collaboration:Low-frequency, highly variable, and entirely dependent on on-the-spot judgment—no need to keep anything after it is done.
Knowledge documents:For explaining "why this decision was made" and your preferences, keep an explanation you can consult at any time.
Templates and checklists:Fixed structure with constantly changing content—turn it into a fill-in-the-blank template you can use directly.
Skills or workflows:Only high-frequency, stable tasks with clear inputs and outputs and verifiable results are worth encapsulating as capability modules.

Forcing the second and third layers into modules only produces a pile of things that need maintenance but nobody uses. More material isn't better either—long, conflicting, outdated documents only raise the cost of understanding.

So consolidation isn't about doing it again. It's about writing down the pass you already got right in a way that works next time.

AI understands you better because you built it a workstation

You wrote it down—then what? AI can't see what's on my hard drive anyway.

First, let's bust an illusion: "AI understands me more and more" isn't because it has a good memory and naturally remembers you. More precisely: it can access and correctly use the preferences, cases, rules and work materials you keep organizing. You've written the part it doesn't understand into a form it can look up.

One more term: runtime environment. You can think of the model as a smart brain, and what actually gets that brain working is the whole set of things around it—the workstation, toolbox, rulebook, filing cabinet, and the feedback loop that constantly checks whether it's doing things right. This whole set connects you, the brain and the tools into a loop, managing context, configuration and permissions so that encapsulated capability modules can actually be called up and used. Take tools like Codex that can write code on their own—the model you often hear about is only part of it; what actually executes the task and hands back the result is this whole environment.

OpenAI once publicly described how an internal engineering team did it: treat "making the environment readable to AI" as serious engineering—treat the knowledge base as the system of record, provide progressive navigation for materials, build test and feedback loops, and regularly clean up outdated docs and bad patterns. The stability of the output is built up bit by bit through these trivial actions.

Individuals can absolutely do the same. Your note library, templates, preference notes and past cases are your own layer of materials. Every time you organize, you're putting one more handy tool in the hands of that tireless assistant who knows nothing about you.

Of course, a runtime environment is not a guarantee of reliability. It still needs the right tools, clear boundaries, and human verification. This framing is just one practical explanation of mine—different teams divide it up differently. But the direction is clear: every piece of material you accumulate makes the next turn of the wheel less effortful.

Once the flywheel starts turning

Connecting these steps together forms a complete loop: with a solid foundation, you get up to speed quickly; once you're fast, you dare to take on harder things; tasks closer to real work force out feedback on "which steps rely on luck and which are bound to need rework"; when feedback is organized into reusable material, your assistant misunderstands less and becomes more stable; the time and trust you save get reinvested into the next round of learning and organizing.

Going around this loop, you'll feel a clear non-linear acceleration—the same effort yields more and more progress. It does not guarantee, nor equal, exponential growth in the mathematical sense.

It can also get stuck on three things: material that is only piled up and never organized, with outdated and conflicting content dragging you down; over-engineering low-frequency small tasks so that maintenance costs exceed the benefits; and assuming that switching to a new tool will inherit all your past accumulation with one click.

The flywheel is never automatic. It goes fast because effort gets stored up; it doesn't save effort, nor is it free of a ceiling. The direction it turns is always decided by your judgment.

No need to envy others for finding some magic tool. They have simply written down what they already know more times than you have.

Three things you can do today

If you only do three things, I suggest these three. None of them require you to switch tools, and you can start today.

First, pick something you've done more than three times in the past two weeks, and write down "how you did it, why you did it that way, and what counts as an exception" as a note you can still read next time. Don't chase completeness—just enough for your future self to understand.

Second, in the assistant you commonly use, find a fixed place to put this kind of note—and then actually use it the next time you do the same kind of thing. See whether this note helps you make fewer mistakes and give fewer explanations.

Third, look back after a month. Only those that are high-frequency, stable, have clear inputs and outputs, and produce verifiable results should be considered for upgrading into reusable workflows or capability modules. The rest are perfectly fine staying in documents.

Next time, when the same person comes to ask you about the same thing for the fourth time, you won't have to start again from "what it is, what you want, and where it can move." You only need to say: do it according to my note.