Three years ago, Byun Kyuhyun used Claude much as he had used a search engine. When he had a programming question, he asked it. If he needed to know how to delete from a Go map while iterating, Claude was simply a faster alternative to searching Stack Overflow.
That is not how he uses it now. In describing his current workflow, Kyuhyun says he gives the model more context, asks it to question him before answering, compares alternatives, and uses it as a kind of rubber duck that talks back. He sometimes separates jobs between Claude and Codex and uses one to check the other. The change, he argues, is not just that he learned better prompts. The way he thinks alongside the tools changed.
His experience points to a more useful way of thinking about AI skills. People are often told that they need to learn how to use AI. But what they are actually learning is how to work when another, increasingly capable intelligence can participate in the work itself.
The difference sounds subtle. It is not.
The first lesson is not prompting
Good prompts help. Clear instructions have always helped people get better work from other people and from software. But treating AI proficiency as a matter of learning the right words puts the skill at the wrong level.
Consider a simple task: summarize a 40-page business report.
A beginner might write, “Summarize this report.” A more experienced user might specify the audience: “Summarize this for a CFO, focusing on decisions, risks, and financial implications.” A more capable user might ask the model to identify the three decisions the report requires, cite the evidence for each, flag missing information, draft a one-page brief, and then critique that brief against explicit criteria.
The last prompt is better because the user understands the work better. The user knows that a useful executive brief is not simply a shorter version of a report. It needs decisions, evidence, uncertainty, and a way to distinguish what the report establishes from what it does not.
That is why “prompt engineering” is an incomplete description of what people are learning. The prompt is the visible part of the interaction. Underneath it are more general skills: defining an objective, supplying relevant context, specifying constraints, decomposing a task, establishing a standard of quality, and deciding what should happen next.
Those skills existed before generative AI. AI makes them unusually visible because the machine can now participate in so many parts of the process.
Microsoft and LinkedIn’s 2024 Work Trend Index found that 75 percent of knowledge workers were using AI at work, while only 39 percent of AI users reported receiving training from their employers. The report also identified a group of AI power users who had changed their workdays and reimagined business processes around AI. Much of the learning, in other words, was happening through work itself rather than through a formal course.
Kyuhyun’s story suggests what that learning looks like from the inside. The user starts by asking for answers. Eventually the user starts thinking about how the work should be done.
Then the user starts delegating
The next change is from asking to delegating.
At first, AI produces an output: an email, a summary, some code, a list of ideas. The human decides whether the result is useful.
With experience, users begin assigning bounded pieces of the job. Research this question. Compare these alternatives. Find contradictions in this argument. Turn these notes into an outline. Generate three approaches. Review this code. Identify what I have overlooked. Produce a first draft and mark the places where evidence is missing.
The human role changes with the delegation. The person is no longer necessarily performing every step. The person is deciding which steps should exist and which can be handed to the machine.
Jessica Camilleri-Shelton, a UK freelance copywriter and content creator, describes what this looks like in a very different kind of job. After about two and a half years of using AI, she had built a collection of tools around the different parts of her day. She uses ChatGPT for daily planning, prioritization, brainstorming, and breaking intimidating tasks into small steps. Claude is her creative writing partner. Perplexity handles research. Fathom records meetings and produces action items. Canva helps with design and social-media planning.
The interesting part of this story is not that she uses five AI products. It is that she has stopped thinking of “AI” as a single tool. Different systems occupy different places in the workflow.
Camilleri-Shelton says that in the six months before the article was published, she had doubled her copywriting income and freed roughly two eight-hour workdays each week for building her business and social-media presence. Those are her own reported results, not evidence that the tools caused them. What the story does show is the shape of a mature workflow: planning, writing, research, meetings, and design have each been assigned to systems according to what the user thinks they do well.
Anthropic’s Economic Index provides a larger-scale view of the same distinction. Its research separates augmentation, where people collaborate with Claude, from automation, where tasks are delegated more completely. The boundary moves as models improve. A task that requires close supervision today may become easier to hand over tomorrow; another may turn out to need more review when the consequences become higher.
That means AI skill cannot be a fixed list of commands. It includes judgment about where the boundary belongs.
The workflow becomes the skill
Eventually, a successful interaction becomes a process.
Joe Hu is a useful example because he describes himself as a product person rather than a developer. His current Claude Code workflow starts before he opens the AI tool. He writes down what he wants first. Then he uses planning, context management, subagents, and manual testing. When something breaks, he approaches the agent like a product manager: provide evidence, explain what happened, and work through the problem rather than simply demanding a fix.
A person who can describe the desired result, supply the relevant context, and recognize when the implementation is wrong can use an AI coding system very differently from someone who simply asks it to build an application. The first person is designing a workflow. The second is asking for a magic trick.
Guohui Jiang, an economist who writes about his use of AI in research, describes the next step. He argues that the assistant should be taught once and then reused). Instructions, skills, hooks, and memory can compound across projects and machines. He also argues for structure rather than willpower: planning and review mechanisms keep the AI from charging ahead in the wrong direction. One of his rules is that the reviewer should not be the builder, because the system that produced something is also the least likely to notice what it missed.
A good prompt is useful once. A good workflow can be useful hundreds of times.
The progression is something like this:
prompt → process → infrastructure
At the first stage, the user learns how to ask. At the second, the user learns how to organize the work. At the third, the user starts building a persistent environment around the work: reusable context, instructions, evaluation criteria, tools, and automated steps.
The person is no longer merely learning an AI application. The person is redesigning a way of working.
Fluency looks like iteration
That redesign usually happens through trial and error.
A user asks for a draft. The draft is wrong in some way. The user explains why. More context is added. An assumption is challenged. A second approach is tried. Eventually a pattern emerges that works reliably enough to keep.
One of the clearest signs that someone has learned to work with AI is that they stop expecting the first answer to be the final answer.
Anthropic’s 2026 AI Fluency Index provides some empirical support for this pattern. The study examines 24 behaviors associated with effective human-AI collaboration. In its sample, 85.7 percent of conversations included iteration and refinement rather than ending with the first response, and iteration was strongly associated with other fluency behaviors.
That changes how we should think about prompting. The perfect first prompt is less impressive than the user’s ability to notice that the answer is not good enough and know what to do next.
This resembles collaboration more than search. Search rewards finding the right query. Collaboration rewards knowing how to react to the answer.
Research on software developers shows a similar progression. A 2025 study of 91 software engineers found that code generation was nearly universal among active generative-AI users, while stronger proficiency was associated with more nuanced uses such as debugging and code review. Developers also preferred iterative, multi-turn interactions over single-shot prompting.
Generating code is an output. Debugging and reviewing code are parts of a workflow.
The danger of becoming productive without becoming competent
There is an uncomfortable problem hidden inside this new way of working. If AI makes execution cheap, people can become productive before they become good at judging the work they produce.
That reverses part of the normal apprenticeship model.
A young writer once had to write enough bad prose to discover why it was bad. A junior programmer had to encounter enough broken code to develop an instinct for where systems fail. An analyst had to build enough spreadsheets to learn which assumptions mattered. The work itself was part of the training.
AI can remove some of that friction, but friction sometimes carries information.
Anthropic found a version of this problem in its fluency study. When users were producing artifacts such as code, documents, apps, or interactive tools, they were less likely to question the model’s reasoning or identify missing context. A polished result can create its own illusion of competence.
A person can now produce a competent-looking report without knowing whether the evidence supports its conclusion. A novice programmer can produce working code without understanding the design decisions inside it. A manager can ask for a strategic analysis without knowing which assumptions deserve scrutiny.
The answer is not to preserve every old inconvenience. Nobody needs to type machine code to become a good programmer, and nobody needs to calculate a column of figures by hand to understand accounting. Tools routinely remove low-value labor while making higher-level understanding more valuable.
The problem is knowing which friction was low-value and which friction was teaching judgment.
A June 2026 Reddit post from a data engineer describes the inverse problem. The writer had become so accustomed to using Claude first for issues, planning, and development that when the service went down, they felt unable to work. The post is one person’s experience, not evidence of a widespread phenomenon. But it captures a real possibility: a workflow can become more capable while the person becomes less confident in what they can do without it.
AI fluency therefore needs a learning boundary as well as a delegation boundary. There are things worth handing to a machine because they are repetitive, and things worth learning yourself because your ability to judge them is part of the job.
Knowing what not to delegate
The most interesting AI users are not necessarily the ones who delegate the most. Sometimes sophistication is visible in the boundary they refuse to cross.
Nicholas Thompson, CEO of The Atlantic and former editor in chief of WIRED, uses AI extensively in both his professional and personal life. He built a custom GPT containing his workouts, previous races, and other training information and uses it as an AI running coach. He also used AI extensively while writing his memoir, The Running Ground.
But he did not use AI to write the book.
Instead, he uploaded transcripts of interviews with people who appear in the memoir and asked the system to check whether his account was faithful to what they had said, identify useful quotations he had not used, flag factual inaccuracies, and point out themes the interviews seemed to emphasize that he had overlooked. Thompson estimated that this kind of checking could have taken many hours of work by himself or a research assistant. AI could do it quickly.
Writing the sentences was different. He considered the authorship and copyright questions too consequential, and he did not think the resulting prose was good enough anyway.
Maria Sukhareva describes a similar boundary in her account of using AI for writing. Her two rules are that she decides what to write and that her texts retain her individuality. She uses AI paragraph by paragraph for grammar correction, claim validation, and maintaining voice, rather than handing over ownership of the writing.
These are highly integrated uses of AI with explicit limits, rather than anti-AI positions. The goal of learning to work with AI is not to maximize the percentage of a job performed by a machine. It is to find a division of labor that produces better work while preserving the parts of the work that require human responsibility, judgment, or authorship.
A new kind of software literacy
It is reasonable to object that none of this is unique to AI. People have always had to learn new tools and redesign their workflows. The spreadsheet changed accounting. The web changed research. Email changed communication. Every technology created new habits around itself.
That is true, but AI collapses some of the distance between tool and collaborator.
A spreadsheet gives you capabilities. An AI system can discuss the capabilities with you. A conventional application executes the workflow you designed. An AI system can design the workflow. A traditional interface waits for you to understand it. An AI interface can explain itself, suggest alternatives, and adapt to the context you provide.
That makes learning unusually interactive.
Someone who does not know how to accomplish a task can ask the system for a method, try it, inspect the result, and ask why it failed. The system becomes part of the learning loop. That does not guarantee good learning—the model can be wrong, and the user can misunderstand the explanation—but it lowers the cost of experimentation.
OpenAI’s 2026 Academy courses offer a revealing industry signal. The training progresses from AI foundations to applied AI and then to agents and workflows. Prompting, context, and output review remain part of the curriculum, but they sit inside a larger progression toward recurring work and structured processes. Because this is an AI company’s own training program, it is not independent evidence that the progression works, but it does show where one major provider thinks the skill is heading.
The larger research points in the same direction. A six-month randomized field experiment involving roughly 6,000 knowledge workers found that access to generative AI reduced time spent on email and moderately sped document completion, while not significantly changing meeting time. (Shifting Work Patterns with Generative AI) Individuals can change their own habits quickly. Work that depends on coordination with other people changes more slowly.
That is another reason the individual journeys matter. Installing an AI application does not redesign a job. The redesign happens when a person starts changing the sequence of work around the tool.
What people are actually learning
Look at the journeys together and the progression becomes easier to see.
Kyuhyun started by asking AI questions and gradually learned to think with it. Camilleri-Shelton divided her work among several systems and made AI part of her daily planning as well as her professional output. Hu learned to turn written product intent into an AI-assisted software-building process. Jiang turned successful interactions into persistent instructions and review mechanisms. Thompson embedded AI deeply in research and coaching while reserving authorship of his memoir for himself.
None of them simply learned a list of prompts.
They learned to describe a goal. They learned what context the machine needed. They learned how to break complicated work into pieces. They learned which pieces could be delegated and which required their own judgment. They learned to inspect the result rather than merely admire it. They learned to correct the machine when it was wrong. Some learned to turn successful interactions into reusable systems. Others learned where delegation should stop.
Those are not really AI skills in the narrow sense. They are skills for working in a world where the boundary between tool and collaborator has become porous.
The people who become unusually capable with AI often seem to have changed more than their software habits. They have changed the shape of their work. They spend less time asking, “What can this tool do?” and more time asking, “What is the best way to accomplish this?”
That is the real acquisition.
You don’t learn AI.
You learn a new way of working.