Being useful when everyone can build

Over the last year, people around me have stopped asking for some of the things they used to come to me for.

There is this colleague who was not always confident writing corporate emails, and now she can send a clear one without asking me to check her grammar and her diplomacy. Another friend who used to call me with technical questions can build a small app and send me a clickable HTML file. A friend who has never worked in design can make a fairly good poster for her kid’s birthday and share it with her WhatsApp group. A junior analyst can ask a model how two tables fit together and get surprisingly far into the analysis before needing to pull in anyone else on the team.

These are all versions of the same change. The minimum capability required to begin has fallen very quickly across a wide range of knowledge work.

You do not need to be a coder to make a piece of software the way you did even two years ago. You do not need to write particularly well to produce a decent first draft. You do not need to know every attribute in the data warehouse before you can start asking questions of it. The old knowledge still helps, sometimes enormously, but it no longer controls who gets to begin.

Beginning is the important word here. A clickable prototype has become cheap. A secure product that handles exceptions, protects the data, survives old dependencies and remains useful after a couple of months has not. The barrier has fallen much further for producing something that looks finished than for producing something that holds up in the world.

Still, this feels hopeful when you look at what people can suddenly do. It feels different when the things they can suddenly do are the things you spent years becoming known for. A lot of us built our careers by compounding one particular capability. We became the person people called for the analysis, the code, the presentation, the campaign, or simply to go and find something for them. Now a machine with a chat window produces a respectable version of that work in minutes, at a cost that is almost silly. There is fear in that, and grief too, in watching a hard-earned part of your identity become available to everyone else.

I have also had to admit that I had confused being useful with being needed. They can look very similar when people still have to come to you. If my colleague can now write the email herself, the capability has spread and something has improved, even if I have lost the small importance of being the person who fixed it. A good teacher, manager or tool often becomes useful by making itself less necessary.

That is an uncomfortable way to look at the quiet queue now. It makes me ask myself whether I wanted to help people become capable, or whether I wanted to remain central to their capability.

Looking for the next scarce task and guarding it will only repeat the same mistake. Every task we name as safely human seems to become partly machine work a few months later. I have come to think that usefulness sits across the whole path: deciding what is worth doing, understanding enough to judge the work, connecting the people and systems around it, and staying until something changes for the person at the other end. I think of that as stitching.

The choice is what to hand over

I see three habits in the way people use these tools. Sometimes we ask the machine, accept what comes back and pass it on because checking would cost the speed that was the point. Sometimes we refuse the tools because their failures are real: they make things up, produce insecure code, flatten writing and create new problems around privacy and ownership. Sometimes we stay involved, bring a messy problem and its context, push back on the first answer, ask for another path and use the response to work out what we ourselves think.

I like Niklas Gruhn’s phrase for the first habit: a “meat proxy”. The output may have been cheap for the sender, but the work of reading, checking and making sense of it has only moved to the receiver.

These are habits rather than types of people. I have been in all three, sometimes at the same time, depending on how tired, curious or rushed I am and whether the task feels consequential. A workplace that rewards ten outputs and gives nobody time to inspect them will create uncritical use. Refusal can also be responsible when the data is sensitive, the decision is difficult to reverse, or the person using the tool has no way to verify what it returns.

I think the useful habit to develop would be selective offloading. We have always handed parts of our thinking to tools: writing carries memory, calculators carry arithmetic and search remembers where facts live. AI widens that range. It can draft the argument, write the code, query the data, compare options and operate other tools on our behalf, which makes the choice of what to retain much more consequential.

I am happy to hand over memorising the syntax differences between programming languages. I will gladly ask for twenty alternatives. I do not need to spend a whole afternoon formatting a deck if the machine can get the first version close. What I want to retain is the reason the system works the way it does, what I am trying to say, who needs to hear it and which assumption would make the whole thing wrong.

The line moves with the situation. If I am making a birthday poster, I can give away nearly all the execution and live quite happily with a miss. If I am putting a customer number in front of a business, I need to know which population it describes, which records were excluded and whether the number is plausible. If a decision could deny someone a service or move a large amount of money, staying in the loop has to mean more than reading the final paragraph and clicking approve.

Microsoft researchers surveyed 319 knowledge workers and found that higher confidence in generative AI was associated with less critical thinking, while confidence in one’s own ability was associated with more. Critical thinking shifted toward verifying information, integrating the response and taking stewardship of the task. You can delegate the production and still remain responsible for what it causes.

For me, a simple test is whether I can explain what I am putting my name on with the tool closed. Can I describe the important assumptions? Can I tell which part is likely to fail? Could I take over, or at least bring in the right person, when it does? Sometimes I cannot, and the honest answer is to slow down rather than perform understanding I do not have.

This is where the current conversation about human review often becomes too comfortable. Leaving a person at the end of a machine process does not make the process safe. The reviewer needs enough knowledge to recognise a problem, enough time to investigate it and enough authority to stop or redirect the work. Accountability without the authority to change the decision is merely somewhere for the blame to land.

Selective offloading has no fixed human percentage. The right choice depends on the stakes, the reversibility of the mistake and how much understanding the person will need when the first answer fails. Making that choice well depends on judgment, and judgment has always come from somewhere.

The work was also training us

I do not want to romanticise mundane work. Anyone who has spent hours fixing a SQL join, formatting a deck or tracing one field through five tables knows that boredom and sheer grit do not automatically produce wisdom. Some work was waste, and it is good that a machine can take it.

Still, some of that work gave us repetitions we did not realise we were collecting.

An analyst who reconciled reports by hand learned that two columns with the same name can describe different populations. An engineer who sat with a production failure learned how a clean architecture becomes messy once real users and old dependencies get involved. A product manager watching customers struggle through onboarding developed a sense of what confusion looks like before it appears in a metric. Sometimes I can look at a business number and have a directional sense that it is wrong. That came from years of tallying the numbers, asking why they moved and making sure I could defend them before sending them to stakeholders.

The same process was producing the report and, slowly, somebody who could be trusted with a harder number later.

This creates a problem for apprenticeship. If a junior analyst can generate the SQL, the explanation and the chart in one pass, where do they develop the instinct that tells them the population is wrong? If a new engineer can build an application without reading much of the code, what happens when the root cause sits across three files and the model’s first fix makes it worse?

In Anthropic’s June 2026 Economic Index survey, early-career respondents said AI could already do the largest share of their work, and they were the most worried about losing their jobs. Respondents with at least fifteen years of experience saw more of their work as dependent on context, trust and situational judgment. People who accumulated judgment under the old system now have an advantage while that same system removes the work through which the next group might accumulate it.

Companies can remove a large part of the junior workload and celebrate the productivity now. A few years later they may find that they also removed the path through which juniors became seniors. We cannot automate the junior work and then tell juniors to develop judgment in their spare time.

Making young people repeat every bit of drudgery we went through would be like insisting they use a paper map for five years before allowing GPS. The old apprenticeship was slow partly because the feedback was slow. You wrote something, waited for a review, tried again and gradually learned what good looked like.

AI can compress that loop. A junior data scientist can try ten different algorithms on a business problem, compare the results with what stakeholders expected, ask for competing approaches, inspect why one failed and have the architecture explained visually. They can make more attempts in a week than we could in a month.

But ten generated alternatives are not automatically ten learning experiences. Learning happens when you make a prediction before seeing the answer, inspect what came back, choose between the options, explain the choice and stay close enough to reality to discover whether you were wrong. Without that contact, volume can create fluency and confidence while leaving the underlying judgment untouched.

The reps worth protecting are the ones that expose failure modes, show where the system boundaries sit and connect the output to a real consequence. An analyst should sometimes take a number from the raw pull to the final decision. An engineer should sometimes follow the failure across the codebase rather than accepting the first patch. A manager should let a junior make a prediction before showing them the answer. We can give away the repetition whose only product was fatigue. Those experiences now have to prepare someone to choose, measure and carry the work into the world.

A working app may still solve nothing

Building used to consume so much of the effort that we focused more on the output than the outcome. Pause on that for a second. The model was never the outcome. It was useful only if it led to a better customer decision or more sales. The brand asset was useful only if somebody noticed it, trusted it or remembered the brand because of it.

None of the work that turned those outputs into outcomes is new. We always had to get the app used, the analysis trusted and the recommendation acted on. Building simply consumed so much time that we often stopped at the artefact. If AI makes the artefact cheaper, we can spend more of the effort on what happens after it exists.

Now a person can build a decent-looking app over a weekend. That gives us more room to ask whether the problem is worth solving, what another person would have to change in their behaviour for the app to matter and who stays with the exceptions after it launches.

The time saved does not automatically become a better outcome. Visible output can still hide wasted months because the builder feels productive every day. The screens multiply, the features work and the underlying problem remains occasional, weak or already solved well enough by something less exciting. Building faster helps only when somebody uses what we built and something changes because of it.

I use the word stitching for this work around the artefact. The customer problem may sit in one place, the useful data somewhere else, the tool in another system and the authority to act with somebody else. The app or analysis may connect the technical pieces. Stitching means getting the work into somebody’s hands, giving them a reason to use it, responding when it fails and staying long enough to see whether anything changed. AI gives us more room to do that work; it did not create the need for it.

A demo shown once for the “wow” and never used in the real world has not achieved much. At best, it proved that the thing could be built. If the goal was to change how people work, the effort went nowhere. The same is true of an analysis that nobody trusts enough to act on. If making the artefact takes less time, we can spend more time getting it used.

The birthday poster shows the same distinction on a smaller scale. It is cheaper to produce, while a more personal birthday for her child has not become less valuable.

These skills are familiar because they were always part of turning an output into an outcome. I think three sets now deserve more of our attention.

• Choosing and framing. When hundreds of things can be built, deciding what deserves attention becomes a bigger part of the work. I have usually found better problems by staying close to them: hearing the same complaint at work, seeing a related issue elsewhere and speaking to somebody who lives with it every day. This is where taste and judgment matter. You form a view before asking the machine, choose among plausible options and let reality prove you wrong. Experience can sharpen that instinct, but it can also become a detailed explanation for why nothing new will work. I would not trust taste that cannot be explained, tested with the people it is for or changed when the world disagrees. It may only be old bias with seniority behind it.

• Measurement and evaluation. Once the output exists, we need a way to tell whether it mattered. Before the work begins, somebody has to decide the baseline, relevant population, success metric, threshold, time horizon and failures they are unwilling to accept. Some checks are direct: the calculation reconciles, the application passes its tests, the data contains the expected number of rows. Other outcomes depend on context. A customer journey can pass every written check and still confuse the customer. We can observe users, run experiments and listen, but somebody still has to decide what evidence counts, whose experience matters and which failure is acceptable. What we learn should change both the measurement framework and the next attempt.

• Stitching and stewardship. Even with the right problem and a clear measure, the output still has to survive contact with the organisation and the people it is for. Somebody has to connect the data, tool, people, incentives, adoption and feedback, then stay with the work when it crosses organisational boundaries. In practice, that means bringing in the right person, translating between technical and business language, making dependencies visible and keeping somebody responsible. Stewardship also requires enough authority to slow, stop or redirect the work when something is wrong.

We build these skills by following outputs far enough to see their outcomes. For an individual, that means making a prediction before prompting, occasionally taking an analysis from the raw pull to the final decision, following a failure across the codebase and staying around long enough to see what happened after launch. Cheap attempts help, but they become useful training only when we find out where we were wrong.

Individuals cannot create those conditions alone. Organisations receive much of the productivity gain, so they also have to protect the path through which people learn to own an outcome. They can require a clear problem statement and measurement framework before generating at scale, give juniors safe end-to-end ownership, expose people to customers and adjacent functions, and give reviewers enough time and authority to challenge the work. That may look inefficient in the short term. It is also how we produce the people we will later depend on for judgment.

AI will also make parts of stitching easier. Agents already search across files, connect tools and carry longer tasks with less supervision. That should free more time again, not end the work. We still have to decide which outcome is worth pursuing and remain answerable for what happens.

A system can rank the options, recommend an action and optimise a metric. The people deploying it still choose the objective, decide whose interests count and give it permission to act. I am not sure how much machine judgment these decisions will involve eventually. But the people and institutions using the system remain answerable because the consequences land with a customer, a worker or a business, not inside the model.

Following an output into its outcome also means asking whom the outcome serves. A person can become extremely useful to a company while their workload rises and the productivity gain goes somewhere else. A model can make a manipulative product more effective. An analyst can optimise a metric that makes the customer experience worse. Sometimes the useful act is to slow the system down, refuse the request or make yourself inconvenient to an outcome that should not happen. Being able to produce more does not tell us what is worth producing.

There is another trap here: turning economic usefulness into a measure of human worth. The grief in the quiet queue is real, but the answer cannot be to find a new way for people to depend on you. I would rather become useful by helping other people do the old task without me, while staying close enough to help them carry it towards an outcome that matters.

The neighbour making the birthday poster may already have completed the whole loop. Her child likes it, the party feels more personal and the work is done. The colleague pulling the data has a longer loop to close. She needs to know whether she asked the right question and what somebody should do with the answer. The friend who built the app will learn what he has made only after another person tries to use it, ignores it, breaks it or asks for something he never imagined.

When I use AI, I want to get better at asking three fairly ordinary questions. Do I understand enough of what it produced to take over when it fails? What decision or action changed because this exists? Who is better off at the end of it, and who carries the downside?

Those questions are a decent place to start.