Fewer than one in ten. That is how often AI takes over a whole task from start to finish, according to a July 2026 survey of 1,106 employed Americans run by Epoch AI. In most cases, it handles a piece of the job and a person handles the rest.
That is easy to miss, because the usual conversation is about whether AI can do a task. The more useful question is which part of the task it should do. The same survey found that when AI did most or all of a task, people reported saving time 53% of the time. And roughly one in six AI-assisted tasks took longer than before.
That is a time issue because the gap between those two results is not about the tool. It is about where we cut the task. A well-chosen slice gives back minutes at the start of the job. A badly chosen slice quietly adds minutes of checking, stitching and rework at the end.
------------- Context -------------
Most of us still describe our work in whole tasks. Write the proposal. Prepare the report. Answer the enquiry. Plan the event. When AI arrives, we tend to hand over the whole label and see what comes back, because the label is how the work sits in our heads and on our to-do lists.
The trouble is that a whole task is rarely one kind of work. A client proposal holds research, structure, pricing judgement, wording, formatting and a final read for tone. Some of those pieces are easy to describe and easy to check. Others depend on things only we know, like how this particular client reacts to a number.
When we hand over the whole label, the machine does a bit of everything and nothing completely. We then spend time working out which parts to trust. That sorting is the hidden cost. It is invisible work, because it never appears on the list, and it is a likely reason why one in six tasks ends up slower.
The better framing is the slice. A slice is a piece of a task with clear edges: we can say what goes in, what should come out, and how we will know it is right in under two minutes. Research summaries, first-pass outlines, tidy-ups of rough notes and reformatting all tend to make good slices. Pricing decisions and tone calls usually do not.
This matters for time because a good slice has a predictable payoff. If the slice takes four minutes to hand over and two to check, and it replaces twenty-five minutes of our own effort, the saving is real and repeatable. If we cannot name the edges, the saving is a guess.
------------- Whole Tasks Hide the Parts That Slow Us Down -------------
One of the quietest costs in modern work is the time spent deciding what to trust. When AI returns a full draft of something we asked it to do end to end, every sentence becomes a small question. Did it get the figure right? Is that claim current? Does this sound like us? Those questions cost seconds each, and a long document holds hundreds of them.
Consider an events coordinator who asks AI to produce a complete run sheet for a two-day workshop. It returns four pages in a minute. She then spends fifty minutes checking timings against venue rules, catering cut-offs and speaker availability, because the draft mixed sound structure with confident guesses. The same job done by hand takes about ninety minutes, so she saves forty. It feels like a win, but most of the benefit went on sorting good from doubtful.
Now suppose she hands over only the first slice: a list of the sessions in a sensible order with suggested durations. That takes five minutes to request and five to check, because the edges are clear and she knows the answer when she sees it. She writes the venue-specific parts herself in thirty-five minutes. Total: forty-five minutes. That is a saving of forty-five minutes against the original ninety, with less doubt along the way.
This is a direct time gain, and it comes from cutting the task rather than from a better model. The minutes were not saved by speed. They were saved by removing the sorting step.
------------- A Good Slice Can Be Checked in Two Minutes -------------
The shift from asking whether AI can do something to asking how we would know it did it right is subtle but meaningful. It turns the check from an afterthought into part of the choice. If we cannot describe a quick check, the slice is probably too large or too tangled with our own judgement.
Take a consultant who needs to digest a forty-page report before a client call. The whole task might be called prepare for the call. A good slice is smaller than that: list every figure in the report with its page number. The check is quick, because she can spot-check five figures against the pages in two minutes. If those five are right, the rest are very likely right too.
By contrast, a request such as tell me what matters in this report has no quick check. She would need to have read the report to know. The summary may be excellent, but she cannot tell, so she either trusts it blindly or rereads the document, and the second path cancels the saving.
The time effect is clear. A checkable slice might take eight minutes in total and replace forty. An uncheckable one takes five minutes to request and thirty-five to verify. Same tool, same minutes of AI effort, very different afternoon. The edge of the slice decides the outcome.
------------- Review Time Belongs in the Estimate, Not After It -------------
Many teams measure AI savings by looking at how long the output took to appear. A draft arrives in ninety seconds, so the task is declared a two-minute job. But the clock does not stop when the text appears. It stops when the work is ready to use.
This is where the one-in-six figure becomes useful. When roughly one in six AI-assisted tasks takes longer, the cause is very often time that nobody counted: reading, correcting, rerunning and reassembling. Two-thirds of outputs in the same survey needed little or no revision, which is encouraging, but it also means the remaining third carries a lot of the cost, and we do not know in advance which third we will get.
Picture a small agency with four people who each use AI to draft client updates, ten a week between them. If each draft saves eight minutes of writing but one in three needs fifteen minutes of repair, the week looks like this: ten drafts save eighty minutes, and three or four repairs cost about fifty. The net is thirty minutes across four people. That is useful, but it is a long way from the headline.
Counting review time at the start changes the choice of slice. We begin asking for the pieces where the repair rate is low, such as structure, first-pass wording and tidy formatting, and we keep the pieces where repair is likely, such as claims, numbers and tone, in our own hands. The net saving rises because the repairs shrink, not because the model improved.
------------- The Slice We Keep Is Where Our Judgement Lives -------------
There is one more benefit to thinking in slices, and it has to do with focus. When AI takes the preparation, we are left with the part that actually needs a person. That part is usually shorter than the whole task, and it tends to be the part we do best when we arrive with a clear head.
A sales manager who hands over the slice of gathering last quarter's notes on an account, and keeps the slice of deciding what to say on the call, arrives better prepared. The gathering took twenty-five minutes before. Now it takes six. The decision still takes ten, but it happens with fresh attention rather than after twenty-five minutes of digging.
This is the time connection people often miss. Saved minutes are valuable, but saved attention is worth more. Fifteen minutes of fresh thinking on the right question usually beats forty-five minutes of tired thinking on everything.
Across a working week, a manager who makes four such calls recovers around seventy-five minutes of effort and spends it where it counts. The slice is not just a unit of delegation. It is a way of choosing where our own time should land.
------------- Practical Moves -------------
First, pick one task from this week and write down its parts on a single line: research, outline, draft, numbers, tone, final check. It takes two minutes and shows which parts could stand alone as slices.
Second, for each part you might hand over, write the two-minute check before you ask. If you cannot name one, keep that part, because uncheckable slices are where the minutes leak away.
Third, give AI only the slice with the clearest edges and the lowest repair risk, such as gathering, sorting or first-pass structure, and note the time the request takes alongside the time the check takes.
Fourth, track the total for two weeks, from the first request to the moment the work is ready to use, rather than the time the output took to appear. That is the number that matches your calendar.
Fifth, once a slice has saved time three times running, turn it into a saved instruction you reuse, so the setup cost falls toward zero and the minutes you reclaim stay reclaimed.
------------- Reflection -------------
The headline of the Epoch findings is that AI mostly takes a part of the work, not all of it. That sounds like a limitation, but it is better read as an instruction. If the tool takes slices, then the skill that matters is slicing: seeing where a task can be cut cleanly, and knowing which cuts are checkable.
That is why the choice of slice ties so directly to time. A good one saves twenty or thirty minutes and leaves us calmer. A poor one saves five and costs thirty, and we only discover that when the afternoon has gone. The difference is not luck. It is how the task was cut before anything was asked.
In the end, the shift worth noticing is from asking what AI can do to deciding which part of our work we want handed over, and which part we want to meet with our full attention. When we make that choice on purpose, the saved time stops being an average on a chart and becomes minutes we can actually feel.
Which task on your list this week could be cut into three parts, and which of those parts would you be happy to check in two minutes?
Where have you handed over a whole task and spent longer sorting the result than the task would have taken?
What would you do with the extra thirty minutes if one slice stayed reliably quick?