The question everybody asks first
The question arrives in the same shape almost every time. Which one should I be learning? Is it worth paying for the better model? Should I be doing the prompting course, or waiting until this settles down?
It is a reasonable question and it has an answer, and the answer matters much less than the person asking believes. Underneath it sits an assumption worth dragging into the light, which is that competence with these systems is a property of the systems, and that it transfers when you learn the interface.
The research does not support that assumption. What it supports is stranger and more useful. Whether one of these tools raises the quality of your work or quietly lowers it depends on facts about your job and about you, and it depends on them so heavily that two people running the same software on the same afternoon can get opposite results. The variable doing the most work is not the model. It is how well the person using it can describe what they do.
Almost nobody can. That is the real gap, and it is the one this article is about.
Your job is not one thing
Start with the observation that makes the rest of the research legible, and it predates the current tools by two decades.
Autor, Levy and Murnane argued that a job is not a unit at all. It is a bundle of tasks, and machines do not consume jobs, they consume tasks. Their framework separated the two kinds. Computer capital substitutes for people on cognitive and manual tasks that can be carried out by following explicit rules, and complements people on nonroutine problem solving and complex communication. Looking at task input across American work from 1960 to 1998, they found computerization associated with less routine manual and routine cognitive labor and more nonroutine cognitive labor, and they found that task changes inside occupations with the same name accounted for almost half of the effect on demand for college educated workers (Autor et al., 2003).
Hold that last part, because it is the part that reaches you personally. The work changed inside job titles that did not change. Two people with the same title on the same organizational chart were doing measurably different work by the end of the period, and the title recorded none of it.
So the first thing to notice is that the question of what a tool will do for you cannot be answered at the level of your profession, or your title, or your industry. Those are aggregates. The tool meets your tasks, and your tasks are yours.
The frontier is jagged, and it is not marked
If work is a set of tasks, the next question is which of your tasks these systems are any good at. The most careful answer we have comes from a large field experiment, and the answer is not a line.
Working with a global consulting firm, researchers built realistic management consulting work and ran a preregistered experiment with 758 knowledge workers. Each person was measured on a baseline first, then randomly assigned to work without AI, with access to GPT-4, or with access plus an overview of prompt engineering. Across eighteen realistic tasks chosen to sit inside the frontier of what the model could do, ranging from creative to analytical, the people using AI completed 12.2 percent more tasks, completed them 25.1 percent more quickly, and produced work of significantly better quality. Then the researchers included one complex managerial task chosen to sit outside that frontier. On that task, the people using AI were 19 percent less likely to produce a correct solution than the people working without it (Dell'Acqua et al., 2026).
The name they gave the shape is the one worth carrying: a jagged technological frontier. Capability is uneven across tasks that sit inside the same workflow and look about equally hard from the outside. Inside the frontier the assistance is substantial and real. Outside it, the assistance is worse than nothing, because it is confident and it is wrong and you have no signal telling you which side of the line you are standing on.
Nothing in the interface marks the boundary. The tool does not slow down or change color when it leaves the region where it is competent. The only instrument available for locating the edge is a person who knows the work well enough to check the output against what a correct answer would look like. That instrument is you, and it only functions on tasks you understand in detail.
The same tool, opposite results
There is one more finding, and it is the one that should stop anybody who believes tool skill is a single ladder everyone climbs.
Brynjolfsson, Li and Raymond studied the staggered rollout of a generative AI assistant across 5,172 customer support agents, measuring issues resolved per hour. On average, productivity rose 15 percent. The average conceals the finding. Less experienced and lower skilled workers improved on both speed and quality. The most experienced and highest skilled workers saw small gains in speed and small declines in quality. The gains were largest for moderately rare problems, where human agents had less baseline experience but the system still had enough training data to be useful. They also found the assistance facilitated worker learning and improved English fluency, particularly among international agents (Brynjolfsson et al., 2025).
Read that carefully, because it says something that almost no coverage of these tools says out loud. The same software, in the same building, in the same week, raised the quality of some people's work and lowered the quality of others. The direction of the effect depended on what the worker already knew.
This is not an argument that experienced people should avoid the tools. It is an argument that the question of what a tool will do to your work has no general answer, and that it is answerable only once you can say, task by task, where you are the experienced worker and where you are the novice. Most people cannot say this about their own job, because nobody has ever asked them to, and because the parts of their work they are best at are the parts they think about least.
The unwritten brief
Put the three findings together and a single object comes into focus, and it is not a program.
Your work divides into tasks rather than sitting as one lump. Some of those tasks fall inside the frontier of what a tool can do and some fall outside, and the boundary is unmarked and irregular. On top of that, your own level of expertise on each task determines whether assistance improves your output or degrades it. Answering the question of what any tool will do for you therefore requires a document nobody has ever written.
I want to call it the unwritten brief. It is the account you would give if somebody competent sat down and asked you to describe what your job consists of, not at the level of the title and not at the level of achievements, but at the level of the things you do in a week and how each one gets done.
What belongs in it is specific. It names the recurring tasks plainly, and it sorts them, marking which ones run on explicit rules you could write out for somebody else and which ones require reading a situation that does not repeat. It records where you are the most experienced person in the building and where you are competent but unremarkable. It notes which parts of the output somebody downstream depends on being right, and it says which judgments you make that nobody ever sees you make, along with what you are drawing on when you make them.
Every organization you have worked for held a small fragment of this and threw the rest away. Your job description was written before you arrived and described a role rather than your practice of it. Your performance reviews recorded outcomes. Your résumé records roles and results. Nothing anywhere in the record describes your work at the level the research says matters, which is the level of the individual task and of your own competence at it.
The reason this matters for AI specifically is blunt. A model cannot ask you what you do. It can only work with what you tell it, and the quality of what you tell it is capped by how well you have thought about your own work. Somebody who can say that they spend Tuesday mornings reconciling two reports that disagree for four predictable reasons, and that the reconciling is rule following but deciding which report to trust when the reasons do not apply is judgment they have built over six years, is going to get something out of these tools that no prompt engineering course can supply. Somebody who can only say that they work in operations is going to get generic output, conclude the tool is overrated, and stop.
What separated the people who got it
There is a version of this finding that predates the current systems entirely, and it is the reason I have been confident about this argument for longer than the current tools have existed.
My doctoral research was a qualitative descriptive multiple case study of Fortune 500 leaders and their adoption of social business platforms. The technology is a generation old now and the pattern it surfaced has not aged at all. What separated the leaders who adopted from the leaders who resisted was not age, and it was not budget. It was early exposure and sustained engagement (Goodwin, 2014).
Those two conditions carry the whole thing. Exposure means having touched it personally rather than having been briefed on it. Sustained means having kept touching it after the first attempt disappointed, which the first attempt reliably does. The resisters were not less intelligent and they were not poorer. Many of them had larger budgets than the adopters and could have bought any capability they wanted. What they did not have was accumulated contact with the thing itself, and so they never developed the sense of what it was for, and so every decision they made about it was made from a description rather than from experience.
Sustained engagement is precisely how the unwritten brief gets written. Not in one sitting and not from introspection. It comes from using a tool on real work, noticing where the output is good, noticing where it is confidently wrong, and gradually building an accurate map of which of your tasks sit on which side of the jagged line. The map is the competence. The tool is the instrument you used to survey it.
Reasonable pushback
This sounds like a reason to delay. It is the opposite, and the dissertation finding is the reason. Early exposure was half of what separated the adopters, and you cannot write the brief from a chair. The argument is not to wait until you have described your work perfectly. The argument is to stop treating the software as the subject and start treating your own work as the subject, which you can begin doing in the first hour of using anything.
My work is too varied to write down. Varied work is exactly the work this helps most, because variety is what makes the jagged frontier dangerous. If every task were identical you would learn the boundary once. Where the tasks differ week to week, the boundary moves constantly, and the only defense is knowing your own tasks well enough to classify a new one on sight.
I am senior, so the tools will not do much for me. The customer support study is the honest answer to this, and it cuts both ways. The most experienced workers did see small gains in speed, and they also saw small declines in quality. Seniority does not exempt you and it does not protect you. What it changes is where the risk sits, which moves from missing out to quietly degrading work that used to be excellent, and the only way to see that happening is to know what excellent looked like before.
Surely the models will get good enough that none of this matters. Perhaps, for the tasks inside the frontier, which have been expanding. The frontier moving does not remove the problem, because the problem was never the location of the boundary. The problem is that the boundary is unmarked, and a person who cannot describe their own work has no way to locate it wherever it happens to be this year.
Where this leaves you
The instinct to start with the software is understandable, because the software is the part that is new, the part with a name, and the part somebody will sell you a course in. It is also the part that will be different in eighteen months.
The other half is the part that keeps. An accurate account of your own work, at the level of tasks and of your own competence at each one, is useful against every tool that has not been built yet, and it is the only thing that tells you whether the output in front of you is better than what you would have produced alone.
So start the brief this week, on the work you were going to do anyway. Take one recurring task, the kind that shows up most weeks, and write two lines about it before you touch anything: what the task involves when you break it down, and whether you would call yourself expert at it or merely competent. Then do that task with a tool, and afterward write one more line about where the output was good and where you had to correct it.
That comes to three lines a week, against one task, on work you had to do regardless. Inside a couple of months you will have a map of your own work that no course sells and no vendor can hand you, and you will find you have stopped asking which tool to learn, because the question answers itself once you can see which of your tasks are sitting on which side of the line.