Market value in an automated economy is decided less by which tasks a person can defend from a machine than by how well that person works with one. The competence is practical rather than theoretical: splitting a task, directing a system, judging what comes back, and owning the result. It is learnable, demonstrable and worth documenting.
Quick Overview
What you’ll learn from this article:
- Why the useful question is how work is divided, not which jobs disappear
- How to decide, task by task, which part belongs to you and which to the system
- How to review output you did not produce, and why that is harder than producing it
- How to map where a system stops being reliable in your own domain
- How to build a documented practice instead of a collection of tricks, and how to make it visible to an employer
Who this article is for: individual professionals deciding where to invest their own development, and managers who need a realistic picture of what the capability consists of.
Reading time: 20 minutes
What Actually Changed in the Work, and What Did Not
The public conversation about automation is organised around the wrong unit. It asks which occupations disappear, when the observable change happens inside occupations, at the level of tasks. The International Labour Organization’s Generative AI and Jobs: A global analysis of potential effects on job quantity and quality frames the effect this way explicitly: for the large majority of exposed roles the realistic outcome is augmentation of some tasks rather than elimination of the role, with full automation concentrated in a narrow band of clerical work. The follow-up Generative AI and Jobs: A Refined Global Index of Occupational Exposure keeps the same unit of analysis, scoring occupations by how much of their task content is exposed rather than by whether the occupation survives.
That distinction matters to an individual because it changes what there is to do about it. If the unit is the occupation, the only strategies available are defence and flight — pick a job the machine cannot do, or leave before it can. If the unit is the task, a third strategy appears, and it is the one that generalises: change how you allocate the tasks you already have.
What did not change is the accountability. When a generated draft goes out under your name, the responsibility for it is yours entirely, and no part of it transfers to the tool. That asymmetry — the machine produces, the person answers — is the structural fact that turns collaboration into a competence rather than a convenience. Someone who cannot answer for the output has not delegated the work; they have abandoned it.
The second thing that did not change is that domain knowledge still decides outcomes. It decides them harder, in fact. Producing a solution and evaluating one require the same knowledge, but evaluation is the more demanding of the pair, because the reasoning that produced the answer is not visible. A person who could not have written the output cannot reliably tell a correct one from a plausible one — which is why the naive expectation that these systems flatten the gap between novice and expert tends to invert in practice.
The Division of Labour Is the Skill
Everything else in this competence rests on a single repeated decision: for this task, right now, what does the person do and what does the system do. Most of the visible failures — the hallucinated citation that reached a client, the analysis that missed the obvious context, the code that passed review and broke in production — trace back to that split being made badly or not made at all.
The split is not a matter of taste. It follows from properties of the task that can be checked before starting.
- How verifiable is the output? Where correctness can be established quickly and cheaply — a test suite runs, a figure reconciles, a citation resolves — generation is low-risk, because a wrong answer is caught. Where verification is slow, expensive or subjective, generation moves the effort rather than saving it.
- How costly is a wrong answer that survives review? A draft email and a regulatory filing carry different exposure. The split should be more conservative in proportion to what an undetected error would cost.
- How much undocumented context does the task require? Systems work from what they are given. Where the decisive information lives in a conversation last month, an unwritten political constraint or a client’s history, the machine is missing the input that determines the answer.
- Is the value in the artefact or in having made it? Some work exists to produce a document. Other work exists so that a person understands something by the end. Generating the second kind produces the artefact and destroys the point.
Applied honestly, these criteria produce an uncomfortable result: the tasks where generation helps most are often not the ones people reach for first. The instinct is to automate the visible, tedious, high-volume work. The leverage is frequently in the opposite place — in the early, exploratory part of a task, where the cost of a bad idea is nil and the value of a wide field of options is high.
A useful discipline is to name the split out loud before starting, in one sentence: what the system will produce, what you will check, and what you will not delegate under any circumstance. Written down, the sentence takes seconds. Unwritten, the split defaults to whatever is convenient at the moment, which is how a first draft becomes a final version without anyone deciding that it should.
Within a single task the split is rarely a single cut. Most substantial work has stages — framing the question, gathering material, generating options, selecting among them, constructing the argument, checking it, deciding — and the right allocation differs at each. A common and effective arrangement gives the system the widening stages and keeps the narrowing ones: it is good at producing more material and more options than a person would generate alone, and unreliable at choosing between them against criteria that were never fully articulated. Selection is where the undocumented context enters, and undocumented context is exactly what the system does not have.
Staging the handoffs also makes the failures cheaper. A task delegated end to end fails at the end, after the effort is spent, and the diagnosis has to work backwards through everything that happened. A task delegated stage by stage fails at a stage, where the input and the expectation are both still in view, and the correction is local. The overhead is a few extra exchanges; the return is that you retain a place to intervene, which is the practical meaning of staying accountable for the result.
The split is also not permanent. It should move as capability changes on either side — as models improve, as your own understanding of their failure patterns deepens, and as the stakes of a particular piece of work rise or fall. Someone whose division of labour looks identical to the one they used a year ago has stopped calibrating.
Judging Output You Did Not Produce
Review is the part of the practice most people underestimate, and it is where the value concentrates. Reviewing text or code you wrote yourself is a matter of checking work whose reasoning you remember. Reviewing generated output is a different cognitive task: you are assessing a conclusion with no visible derivation, produced by a process optimised for plausibility.
Fluency is the trap. Generated output arrives well-formed, confident and internally consistent, and those properties are uncorrelated with correctness. Human judgement uses surface signals — hedging, awkward phrasing, visible uncertainty — as cues that something needs checking, and generated text supplies none of them. The reviewer therefore has to replace an automatic signal with a deliberate procedure.
A procedure that works is short and adversarial. Check the claims that carry the argument, not the ones that are easy to check. Resolve every reference, quotation and figure to its source rather than accepting that it looks like a real one. Ask what the output would have said if the premise were false, and see whether it would have noticed. And look specifically for the omission rather than the error — generated output rarely tells you what it left out, and the missing constraint is more dangerous than the wrong sentence, because nothing on the page points at it.
Effort should be graded by consequence, not spread evenly. A uniform review standard is either too slow for low-stakes work or too shallow for high-stakes work, and usually both at once. The Artificial Intelligence Risk Management Framework (AI RMF 1.0) published by the National Institute of Standards and Technology makes this proportionality explicit at organisational level — control effort scales with context and potential harm — and the same logic applies to the individual reviewing a single artefact.
There is a second-order habit worth building here: recording what the review caught. The errors a system makes in your particular domain are not random, and after a modest number of instances the pattern becomes predictable enough to check for directly. That pattern is domain-specific and largely undocumented anywhere, which is precisely why the person who has catalogued it has something the market cannot buy off the shelf.
Building that catalogue takes almost no ceremony, and the shape matters more than the tooling. Each entry needs the kind of task, the class of error rather than the individual instance, the signal that gave it away, and the check that would have caught it earlier. Classifying by class is what makes the record useful: “invented a plausible internal document reference” is actionable across every future task of that type, whereas “got the name of the policy wrong on Tuesday” is an anecdote. After a while the entries stop being a list of incidents and start behaving like a checklist for your own domain — the handful of things worth verifying first, ordered by how often they have actually gone wrong rather than by how often they are said to.
The catalogue then feeds back into the split. A class of error that turns out to be frequent and hard to detect is an argument for pulling that stage back to the person; a class that is frequent but trivially caught is not, because the verification is cheap. This is the loop that separates a practice from a habit: review produces evidence, evidence changes the allocation, and the allocation changes what there is to review.
Knowing Where the System Stops
The single most useful thing to know about a tool is where it stops being reliable, and that boundary is domain-specific. General accounts of model limitations are true and nearly useless in practice, because what matters is the point at which output stops being trustworthy for your work, on your data, under your constraints.
Mapping that boundary is an experimental activity. It means posing tasks whose correct answer you already know, and pushing along dimensions until the output degrades: complexity, ambiguity, specialised terminology, contested subject matter, recency of the underlying information, cases where the honest answer is that the evidence is insufficient. The point at which the output stops being merely worse and starts being confidently wrong is the boundary, and knowing it is worth more than any prompt template.
The controlled evidence is instructive about scope. The National Bureau of Economic Research working paper Generative AI at Work and the study The Impact of AI on Developer Productivity: Evidence from GitHub Copilot both measure real gains on real tasks, and both are careful about the conditions under which the gains hold — task type, experience level, and the presence of an evaluation loop. Read as a claim about specific work, the results are strong; read as a claim about work in general, they are being misused. The person who has mapped their own boundary is the one who can tell the difference.
The map is also perishable. Model behaviour changes with versions, and a boundary charted against one release can be wrong against the next in both directions — a task that failed may now succeed, and a task that worked may have quietly regressed. Re-testing a small standing set of known-answer cases after a version change costs little and is the only reliable way to notice.
Regulation is beginning to treat this understanding as an expectation rather than an advantage. Regulation (EU) 2024/1689 (Artificial Intelligence Act) places an obligation on providers and deployers to ensure a sufficient level of AI literacy among the people who operate these systems on their behalf, taking account of their technical knowledge, their training and the context of use. The competence described in this article is, in part, what that obligation is asking for — which means it is moving from a differentiator towards a baseline, and the differentiator moves up a level.
Building a Practice Instead of Collecting Tricks
The gap between people who use these systems occasionally and people who work with them well is not a stock of clever prompts. It is a practice: a small set of habits that turn scattered experience into transferable knowledge.
Deliberate variation. Running the same task in more than one formulation and comparing what changes teaches more than any amount of reading, because it isolates what the system is actually responding to. Done casually, this is noise. Done with a note of what varied and what changed, it accumulates.
A record of failures. Successes are pleasant and teach little, because a success does not tell you which part of your approach mattered. A failure with a diagnosis — what was asked, what came back, why it was wrong, what fixed it — is a reusable asset, and the collection of them is the closest thing to a map of your own domain’s edges.
A pattern library with context. Storing a prompt is close to worthless; storing the situation in which it worked is not. A useful entry records the kind of task, the constraints that made the approach fit, the failure modes it avoids, and the cases where it should not be used. The context is what makes the pattern transferable to a task you have not met yet.
Graduated stakes. New approaches belong on work where being wrong is cheap, and move up as they earn confidence. The opposite sequence — trying an untested method on the most consequential task of the quarter because that is where the pressure is — is how a reasonable technique acquires a bad reputation.
A standing reserve of unassisted work. Deliberately doing some work the long way keeps the underlying judgement alive. This is not nostalgia. Review capability rests on the ability to produce, and a professional who has stopped producing anything unaided gradually loses the standard against which output is assessed. The reserve is what keeps the review honest.
Structured instruction shortens the early part of this considerably, mainly by supplying failure cases you would otherwise have to discover at your own cost, and by giving the practice a shape before habits set. A programme such as prompt engineering and collaboration with artificial intelligence is aimed at exactly that: the operating discipline of directing a system and evaluating what it returns, rather than a tour of features.
What This Looks Like in Different Kinds of Work
The practice is general; its expression is not. The division of labour that works in one kind of work is wrong in another, and the differences are instructive.
In work whose output is verifiable mechanically — much of software, parts of finance, anything with a test or a reconciliation — generation is comparatively safe, because errors surface fast. The limiting factor is review capacity, and the professional’s leverage lies in designing the verification so that it catches what the system gets wrong rather than what it happens to get wrong loudly.
In advisory and analytical work, the decisive input is context that is not written down anywhere: the client’s history, the internal politics, the constraint nobody states. Systems handle the reproducible layer — synthesising material, generating options, stress-testing an argument — while the professional supplies the context and owns the recommendation. The failure mode here is not a wrong fact; it is a technically defensible recommendation that ignores the reason the question was asked.
In regulated and safety-relevant work, the split is constrained from outside. What may be generated, what must be reviewed by a named person, and what must be traceable are decided by rules rather than by preference, and the professional’s competence includes knowing where those lines fall before proposing an efficiency.
In creative and communication work, the risk is convergence. Systems trained on what exists reproduce the centre of the distribution, and output that is fluent and unremarkable is the default. The useful split treats generation as a way to clear the obvious ground quickly, so that the human effort goes into what is not obvious — which is the opposite of using it to produce the finished piece.
Across all of these the transferable part is the method: name the split, verify proportionately to consequence, map the boundary, record what you learn. The domain supplies the specifics.
Making the Capability Visible to an Employer
A capability nobody can see does not affect market value, and this one is unusually hard to see. It leaves no certificate, it is not a tool on a list, and self-assessment is unreliable in both directions. Making it legible is part of the work.
Claiming familiarity with named tools is the weakest available signal, because everyone can make it and it says nothing about judgement. The stronger evidence is specific and situated: a piece of work whose division of labour you can explain and justify, an error class in your own domain that you identified and now systematically check for, a documented boundary showing where you stopped trusting the output and why, a process you changed on the basis of what you learned, and — the strongest of the set — a case where you decided not to use the system and can articulate the reasoning.
That last item carries disproportionate weight, because it is the one an unreflective user cannot produce. Enthusiasm is common; calibrated refusal is not, and it is the clearest available proxy for understanding the tool rather than merely enjoying it.
Where the work is done in a team, another visible form of the capability is having raised the standard around you: a review practice adopted, a failure catalogue others use, a decision rule about what gets delegated. That is the point at which an individual practice becomes an organisational asset, and it is far easier to point to in a conversation than any personal productivity claim.
The counter-signal is worth naming as well, because it is common. A professional who reaches for generation reflexively, cannot say where the boundary is, and treats fluent output as finished work is producing risk at speed. This is visible to anyone reviewing their output, and it is more damaging to a reputation than not using the tools at all.
Learning in the Open, Because the Practice Compounds in Groups
The knowledge that matters here — where the system fails on this kind of document, which framing survives review, what went wrong last time — is tacit, unpublished and expensive to acquire alone. It is also cheap to share, which makes the group the natural unit of learning even though the capability is individual.
What makes a group faster than an individual is that failure is pooled. One person meets a given failure mode a handful of times; a whole team meets it many times over, and once the failures are written down somewhere shared, everyone gets the diagnosis without paying for the discovery. The mechanism is unglamorous and consists mostly of a place to put things and a habit of putting them there.
A pair of conditions decides whether this works. The first is that reporting a failure has to be safe. Where admitting that a generated output slipped through review is treated as a performance problem, the failures stop being reported and the shared catalogue fills with successes, which teach nothing. The second is that the record has to be maintained by someone. An unmaintained shared document decays into a graveyard of outdated prompts within months, and the decay is invisible until someone relies on it.
Pairing across experience levels tends to move faster than formal instruction, in both directions. The less experienced participant usually has more hours with the tools; the more experienced one has the domain judgement that decides whether the output is any good. Neither half is sufficient, which is why the pairing produces more than either person’s individual practice.
The team-level version of this competence — which roles are needed, what a group has to learn collectively, how the capability is distributed across a team rather than concentrated in one enthusiast — is developed separately in the account of AI agents in the enterprise and the competencies a team needs. This article stays with the individual, on the assumption that the organisational version is built out of people who have the personal practice first.
Measuring Your Own Progress Honestly
Self-assessment in this area is systematically unreliable, in the familiar direction: fluency with the interface is mistaken for judgement about the output. A few observable measures cut through that.
Whether your split is getting more specific is the first. Early practice divides work crudely, by whole tasks. Mature practice divides it finely, by stage within a task, and can state the reason for each cut. The move from “I use it for reports” to “I use it for the first structure and the counter-arguments, never for the recommendation” is real progress and is easy to notice.
Whether your predictions are getting better is the second, and it is the most diagnostic. Before running a task, write down whether you expect the output to be usable. Then check. A practitioner whose predictions are accurate has an internal model of the system’s behaviour in their domain; one whose predictions are no better than chance is still guessing, however comfortable the interface has become.
The prediction exercise is worth running properly rather than in your head, because memory reconstructs it favourably. Recording the expectation before the attempt, in a single line, and marking it afterwards costs a few seconds per task and produces something no amount of reflection will: a rate. The interesting signal is not the overall accuracy but the direction of the misses. Systematic optimism means you are still being persuaded by fluency and your review effort is set too low. Systematic pessimism means you are leaving usable leverage unclaimed and probably doing by hand work that would survive a check. Both are correctable, and neither is visible without the record.
Whether review is catching things earlier is the third. Errors caught before the work leaves your desk are cheap; errors caught by a colleague are expensive; errors caught by a client are damaging. The migration of detection towards the front of that sequence is a direct measure of the practice working.
And whether the reserve of unassisted capability is intact is the fourth, the one most easily neglected. Periodically doing a representative piece of work without assistance, and noticing whether it is harder than it used to be, is the only honest test of whether the underlying skill is being maintained or quietly traded away.
What This Article Deliberately Leaves Out
This article is about the individual’s practice of working alongside a machine and how that practice converts into market value. Two adjacent subjects are treated elsewhere in this knowledge base and are deliberately not repeated.
The first is the taxonomy question — which categories of capability hold their value as automation advances, and how technical depth and transversal skills relate to each other. That argument is made in technical skills and soft skills: where the balance sits, which establishes what automation does to the price of judgement. This article takes that conclusion as given and asks the next question instead: what the resulting practice consists of, day to day, and how a person demonstrates it.
The second is prompting as a technique — formulation patterns, context construction, the craft of getting a specific behaviour out of a specific model. That has its own treatment in the knowledge base and belongs there; it is a component of the competence described here, not the whole of it. The distinction is deliberate, because a practitioner with excellent prompting technique and no review discipline produces polished errors faster than before, and the market eventually prices that accurately.
Also outside the scope: the leadership version of this question — how a manager runs a team in which part of the work is done by systems — and the organisational strategy version, concerning where a company should invest in capability. Both are covered separately. The perspective held throughout this article is the individual’s own.
Frequently Asked Questions
Will this competence still matter once the systems get better?
The specific techniques will not; the structure will. Improving systems change where the boundary sits, not whether there is one, and they raise rather than lower the demands on review, because the errors that survive become harder to spot. The durable part of the competence is the habit of locating the boundary and calibrating trust against it, and that habit transfers across model generations in a way that any particular technique does not.
Do you need technical knowledge of how these systems work?
Not at the level of building them, but more than nothing. What is required is a working understanding of why the output behaves as it does — why it is confident when wrong, why it invents plausible references, why it is weaker on recent or contested material. That understanding is what makes review targeted rather than generic, and it can be acquired without any ability to train a model.
How do you develop this when your employer restricts the tools?
By working on the parts that do not require unrestricted access. The division-of-labour analysis, the review discipline and the failure catalogue are all method rather than tooling, and they can be developed on whatever is sanctioned, or on personal work outside it. Restrictions usually exist for defensible reasons, and a professional who understands those reasons and can propose a compliant split is more valuable than one who circumvents them.
Is there a risk of losing your own skills by relying on these systems?
Yes, and it is the risk least often planned for. Capability that is never exercised degrades, and review depends on the same judgement that production builds. The mitigation is structural rather than moral: keep a deliberate share of work unassisted, and test periodically whether an unaided piece of work is getting harder. Noticing the drift early is straightforward; noticing it after several years is not.