← Back to Articles

By ·

I Keep Making My Own Work Disappear

An editorial collage showing an automated card system narrowing into tangled material being handled by a human hand

AI is making implementation cheaper. It is also concentrating ambiguity, exceptions and responsibility in the work that remains.

Every week, I build another system that automates something I used to spend hours doing.

A few years ago, if I wanted software built, a meaningful part of my value was being able to actually build it, or at least understand enough of the technical detail to work through it properly with someone who could. Now I can describe what I want, give an agent access to the codebase, let it do a large part of the implementation, test what it has done and spend most of my time on the bits that don’t quite make sense.

The same thing is happening across the rest of my work. I write less code, manually move less data around, prepare fewer documents from scratch, search through systems less and spend far less time turning meetings into notes, notes into actions and actions into whatever system is supposed to remember them.

This is mostly good. I don’t miss copying information between systems, and I’m not nostalgic for work just because a human used to do it.

What I have noticed, though, is that the better I get at automating parts of my own job, the harder it becomes to explain what my job actually is. I’m still busy, probably busier, but I do less of the stuff I would have pointed to a few years ago as proof that I was useful.

Increasingly, the work is deciding what should exist, working out what someone actually means, choosing between two imperfect options, noticing when something technically correct is still obviously wrong, and deciding when a system should be trusted to act without asking anyone.

I’ve been thinking of this as my value moving upstream, although I’m not completely convinced that is the right way to describe it. It sounds a bit too neat, as though automation politely removes the boring work and everyone naturally ascends into more important thinking.

The reality feels messier than that.

Most knowledge work is preparation

In 1960, computer scientist J.C.R. Licklider tracked how he actually spent his working time and concluded that about 85 per cent of his “thinking” time was spent getting into a position to think.

That observation still feels surprisingly current because an enormous amount of knowledge work is not really the decision itself. It is finding the information, organising it, calculating something, translating between formats, checking what happened last time and assembling enough context that a decision can finally be made.

Take a client meeting. Before it happens, someone might find the documents, check the CRM, read the previous notes, work out what is outstanding and reconstruct what has happened since the last conversation. Afterwards, someone writes a file note, updates the CRM, creates tasks, sends an email, changes a workflow and records whatever new information emerged.

Somewhere in the middle is the bit we actually care about: what does this person need, what has changed, what matters, and what should we do about it?

A lot of my work in advice technology over the past couple of years has basically involved trying to collapse everything around those questions.

One of the systems we’ve been designing takes a client conversation, transcribes it, identifies evidence-backed changes, proposes updates against the relevant records, lets the adviser approve or reject them, writes the accepted changes back and then verifies that the system saved what we thought it saved.

There is nothing particularly profound about most of those individual steps. Listening back to a meeting so someone can copy an updated salary into Salesforce is not where the interesting part of the job lives, but when humans are required at every little junction, the whole process consumes an extraordinary amount of attention.

I think attention is probably more important here than time, because I’m not actually getting much time back.

That has been one of the stranger things about AI. You automate ten hours of work and somehow do not end up with ten empty hours. Software becomes dramatically cheaper to make, so you make more software. Analysis takes ten minutes instead of two hours, so you start analysing things that previously were not worth analysing. A rough idea can become a working prototype in an afternoon, so suddenly every half-decent idea gets a prototype.

There is a Jevons-paradox-ish thing happening where making something more efficient creates more demand for it.

The saved time gets reinvested into ambition.

That is probably why we all have access to technology that would have looked absurdly powerful ten years ago and yet nobody seems to have accidentally acquired a quiet calendar. The gain is not necessarily more empty time; it is having more of your finite attention available for things that used to be crowded out by preparation, administration and translation.

And then you discover that the things waiting underneath are often harder.

Automation leaves people with the exceptions

There is a nice version of the automation story where machines take repetitive work and humans move into higher-value work. I broadly believe it, but it hides something important about the kind of work that remains.

Lisanne Bainbridge wrote about this in Ironies of Automation in 1983, arguing that the designer who tries to eliminate the operator tends to leave the operator with whatever the designer could not work out how to automate.

That is much closer to what I see in practice.

The system gets the normal household structure. The human gets the couple with multiple entities, unusual ownership, old data that doesn’t quite line up and three records that probably should have been one.

The system handles the normal workflow transition. The human gets the client who skipped two meetings, changed direction halfway through the process and now needs to be represented somewhere that is both technically correct and not completely stupid.

A clear statement in a meeting can become a proposed data update. Something that could mean three different things depending on the previous six months of context still needs someone to think about it.

Automation slowly consumes the middle of the distribution, which means the work that still arrives at your desk becomes progressively stranger.

That is why I’m a little suspicious when people describe all remaining human work as automatically “higher value”. Some of it genuinely is, because it involves judgment, context and decisions with consequences. Some of it is just an increasingly concentrated pile of exceptions.

You can end up in the odd position where technology has made the average task in the business much easier while making the average task you personally deal with harder. You stop seeing the easy things because the easy things now work.

I’ve noticed this a lot during a Salesforce build.

Producing a screen is becoming easier and easier. Working out what the screen should mean is not.

When we reviewed part of the implementation, the problem was not a lack of output. It was that too many unanswered design decisions had quietly been filled with standard Salesforce patterns: too many fields, unfamiliar terminology, weak information hierarchy and workflows that existed without really representing how anyone thought about the work.

We eventually adopted a simple rule: where a requirement was unclear, stop rather than quietly turning ambiguity into a default platform decision.

The implementation can increasingly be delegated, but the ambiguity comes back.

Fred Brooks made the distinction years ago between accidental complexity and essential complexity in software. The accidental complexity is the friction around expressing the solution — syntax, boilerplate, plumbing and tooling — while the essential complexity belongs to the problem itself.

AI is removing accidental complexity incredibly quickly. Unfortunately, it has done very little to make people less contradictory, businesses less political, families less messy, or security and convenience suddenly want the same thing.

AI has made code cheaper. It has not made reality cleaner.

When it took weeks to build a feature, a lot of energy went into getting the feature built. When a credible first version can appear in a day, the uncomfortable question of whether it should exist in the first place arrives much sooner.

That feels like a fairly good description of what is happening to a lot of my work. The implementation recedes and whatever was hiding behind it becomes easier to see.

Automating expertise forces you to explain it

There is another complication when the thing you are automating is something you are already good at.

Experienced people often know that a piece of work is wrong before they can neatly explain why. That is perfectly workable when you are doing the work yourself. It is less useful when your instruction to a machine is essentially: make this good, but not like that.

So you start pulling your own judgment apart.

What am I actually noticing? What do I look at first? What makes this wrong rather than merely different? What would I need to see before I trusted it? Which rules are real rules and which ones are habits that survived because nobody bothered to question them?

We’ve been doing this with adviser conversations. We built a coaching system that looks at whether an adviser really understood the person in front of them, whether their questions went below the obvious facts, whether they talked too much, whether they jumped into solving before properly understanding the problem and whether they explained the value of advice in a way that related to the actual person.

An experienced adviser can watch a conversation and have a reasonably good instinct for whether it was strong. Turning that instinct into something repeatable is harder because eventually you have to explain what “strong” means.

Then, almost immediately, you create another problem.

Once you describe the visible behaviours associated with a good conversation, people can perform them. A polished but generic meeting should not suddenly score brilliantly because the adviser has learned the rubric. A question is not powerful merely because it contains the words “how do you feel?”, and silence might mean someone is listening carefully or that they have simply lost their train of thought.

Every time you try to codify judgment there seems to be another layer of judgment underneath it.

I’ve ended up doing something similar with writing. Even this article now goes through a fairly ridiculous process involving the original idea, personal examples, research, drafting, a separate voice pass and another edit designed specifically to make sure all that process has not cleaned away whatever made the thing sound like me in the first place.

It is objectively too much infrastructure for writing something on the internet, but it exposed something useful. I used to think “writing” was one activity, when it is really a loose bundle of decisions.

Choosing the actual idea is different from finding evidence for it. Both are different from recognising which personal example makes it real, and that is different again from knowing when a sentence sounds clever but is not doing much.

Once those decisions become visible, some are surprisingly easy to hand off and others become much more obviously yours.

There is an economic consequence to this as well.

A large study of customer-support workers using generative AI found that less experienced workers improved considerably more than experienced ones. One plausible explanation was that the technology was distributing patterns that had previously separated stronger workers from the rest.

From the company’s perspective, that is exactly what you want. If someone has figured out a better way of doing something, it is useful if the business can turn that knowledge into software, process, training, templates or systems rather than requiring the original person to keep doing it forever.

From the perspective of the person who figured it out, there is a stranger dynamic: getting sufficiently good at your job can give you the tools to destroy some of the conditions that made you scarce.

I don’t think that is necessarily bad. There is a difference between automating labour away and converting labour into an asset.

If something you know becomes reusable software, a methodology, a workflow or a model that keeps creating value, then the work has not simply disappeared. It has changed form.

Who owns that thing starts to matter. So does what you do after building it.

I’ve found that more interesting than asking whether AI can do a particular task. The visible activity is not always where the value was.

Was the value in typing the code or understanding the business well enough to know what the code should do? Was it in producing the financial model or understanding which assumptions mattered? Was it in writing the file note or knowing what part of the conversation should become durable information?

Sometimes the answer genuinely is the craft itself, and I don’t think we should pretend losing craft is irrelevant. There are parts of coding I enjoy, and there is an obvious problem in asking future senior people to supervise work they never had to learn how to do themselves.

But often the activity was the mechanism through which something else useful happened.

Once the mechanism gets cheaper, you find out what that something else was.

AI systems need verbs before authority

The easy conclusion from all of this would be that humans move from execution into strategy.

I don’t love that framing because strategy has become one of those words that can mean almost anything, especially once it happens in a meeting.

What I can actually see my work becoming is more concrete: choosing problems, maintaining context, designing architecture, dealing with exceptions, applying taste and deciding what other people or systems are allowed to do without me.

That last one is becoming much more important.

I’ve started thinking about AI systems as things that should inherit verbs before they inherit authority.

Finding something is a verb. Comparing two records is a verb. Drafting a response, identifying a discrepancy, proposing a change, creating a task and showing me what changed are all verbs I am increasingly comfortable handing over.

“Decide this is true and permanently update the client record” is different.

So is “send this to the client”.

So is “make this recommendation”.

The distinction matters because the technical capability to perform an action is arriving faster than our ability to work out when the system should be allowed to perform it on its own.

A machine can be perfectly capable of updating a record without being entitled to decide that the record should be updated. It can draft an excellent client email without having authority to send it. It can produce a plausible recommendation without being the thing that should own the consequences of that recommendation.

That means the interesting design question is increasingly not just: what can this system do?

It is: what can this system do without me?

And under what conditions?

What evidence needs to be preserved? What happens when the underlying information is ambiguous? How reversible is the action? How obvious will the error be if the system gets it wrong? Who owns the result?

There is already a fairly dodgy version of “human in the loop” where a system does 99 per cent of the work, a person sees the final answer for twelve seconds, presses Approve and we describe the whole thing as human-controlled.

The person may have performed one click, but the organisation can still attach all of the responsibility to it.

This is why I think the language of work simply moving “upstream” is incomplete. The remaining decisions can become much smaller in volume while getting much larger in consequence.

Sometimes you are not doing less work so much as sitting at the point where all the uncertainty accumulates.

What remains when execution gets cheaper

As the activities get cheaper, I keep having to ask whether I valued the craft itself or what the craft allowed me to do. The answer is probably different for each thing. If the outcome was what mattered, there are suddenly more ways to get there. If the craft mattered too, I may need to protect some of it deliberately.

Maybe a job is not really a fixed collection of tasks. Maybe it is just the temporary boundary between what the system around you can already do and what it still needs from you.

If that is even partly true, doing the job well should keep moving that boundary. You spend some portion of your time removing reasons for your future self to be needed, then eventually find out what remains.

Right now, I would say a lot of what remains for me is judgment, but even that answer feels a little too convenient. Some judgment will get codified, some will get distributed, models will improve and things that feel unusually senior or difficult today will eventually become boringly normal.

Then the boundary moves again.

I don’t think the goal is to remain indispensable. That seems like a terrible design principle for a company and probably not a particularly healthy one for a career.

I’d rather keep moving toward the problems where my involvement genuinely changes the outcome, while building systems that mean everything else no longer needs it.

I don’t want the business to depend on my hands forever.

I do want it to keep benefiting from what those hands learned.

Sources