52% of Workers Use AI at Work. The Median One Saves Three Hours a Week

On October 30, Philip R. Lane of the ECB's Executive Board gave a keynote at the San Francisco Fed that is worth reading for one reason: it replaces anecdotes with distributions. Two of the numbers sound like they cannot both be true. Half of workers report using AI at work, which is mainstream adoption by any definition. And only seven per cent of firms describe their own use as significant, which is a pilot programme. Both are correct, they come from different surveys, and the gap between them is the most useful thing in the speech: adoption is broad and shallow, and the time savings are real but concentrated in a way that a single average hides.

Code generation and debugging produced the largest time savings: six hours a week.

1. Two numbers that look contradictory, and are not

The 52 per cent comes from the ECB's Consumer Expectations Survey, which asks households about AI use in the workplace on a regular basis: the share of workers using AI has doubled in two years, from 26 per cent in 2024 to 52 per cent now. The seven per cent comes from the Survey on the Access to Finance of Enterprises, which asks firms, and which found in the fourth quarter of 2025 that 64 per cent were using AI experimentally or moderately while only 7 per cent called their use significant. Those are different populations answering different questions, so there is no contradiction — but there is a lot of daylight between a worker who opens a chat window a few times a week and a firm that has rebuilt a process around a model. Most of the economy currently sits in that daylight.

# The ECB numbers are distributions, so reproduce the distribution on your own
# data. Median first, mean second, and the no-gain share always.
import csv
import statistics as st
from collections import defaultdict

rows = []
with open("hours_saved.csv", newline="", encoding="utf-8") as fh:
    for r in csv.DictReader(fh):
        rows.append({
            "person": r["person"],
            "task_class": r["task_class"],      # code / writing / research / data
            "hours_saved": float(r["hours_saved"]),
            "used_ai": r["used_ai"] == "yes",
        })


def describe(values: list[float]) -> str:
    if not values:
        return "no samples"
    med = st.median(values)
    mean = st.mean(values)
    zero = sum(1 for v in values if v <= 0) / len(values)
    p90 = sorted(values)[int(len(values) * 0.9) - 1]
    return (f"n={len(values):<4} median={med:>5.1f}h mean={mean:>5.1f}h "
            f"p90={p90:>5.1f}h no-gain={zero:>4.0%}")


by_class = defaultdict(list)
for row in rows:
    if row["used_ai"]:
        by_class[row["task_class"]].append(row["hours_saved"])

for cls, vals in sorted(by_class.items()):
    print(f"{cls:<10} {describe(vals)}")

# The gap between median and mean is the honesty check. If mean is more than
# twice the median, you are looking at a tail, not at a typical result, and
# quoting the mean to a budget owner will get you caught.

2. The median user saves three hours. The average tells you nothing

The headline saving is three hours per week for the median working user, about 7.7 per cent of median working time. The distribution around it is the interesting part: the speech is explicit that most users enjoy only moderate time savings while a small number report very high efficiency gains. That shape should change how you report anything internally. A mean over a skewed distribution is dominated by the tail, so a team where two people automated half their week and eight people saved twenty minutes will show a flattering average and a median that is close to noise. Report the median, report the share of people who saw no gain at all, and report the tail separately — the tail is where the interesting engineering is, but it is not a plan you can roll out to everybody.

# Self-reported hours are soft. Instrument the thing instead: wall-clock per
# task, with and without assistance, recorded by the tooling rather than memory.
import json, time, uuid
from contextlib import contextmanager

LOG = "task_timings.jsonl"


@contextmanager
def task(kind: str, title: str, assisted: bool):
    rec = {"id": str(uuid.uuid4()), "kind": kind, "title": title,
           "assisted": assisted, "start": time.time()}
    try:
        yield rec
    finally:
        rec["seconds"] = round(time.time() - rec["start"], 1)
        with open(LOG, "a", encoding="utf-8") as fh:
            fh.write(json.dumps(rec) + "\n")


# Usage: wrap the work, not the meeting.
with task("write", "incident postmortem draft", assisted=True) as t:
    draft = "..."          # whatever the actual work is
    t["chars_out"] = len(draft)

# What this buys you: a per-task number you did not estimate afterwards, and a
# paired comparison when the same task class runs both ways. It does not
# capture thinking time, so pair it with one afternoon of observation per
# person rather than pretending the timer is the whole truth.

3. Coding saves the most hours and has the thinnest adoption

Generating or debugging code produced the largest measured gains at six hours per week — twice the median — and roughly 15 per cent of workers use AI for it. Meanwhile the most frequently cited uses are research, information gathering, writing and text editing, where reported savings are considerably lower. Put those two facts next to each other and you get the most misused statistic in the field. The six-hour number is a number about a small, self-selected group with unusually legible tasks: code either compiles or it does not, the failure is visible in seconds, and the feedback loop is short enough that a model is genuinely useful. It does not transfer to a task with a week-long feedback loop and a definition of done that four people have to agree on, which is most of the work in most organisations.

# Match the categories the ECB used before comparing: code generation and
# debugging, research and information gathering, writing and text editing,
# data analysis, routine automation. Pooling them into one number is how the
# six-hour headline gets misapplied to a writing team.
import json
import statistics as st
from collections import defaultdict

CATEGORIES = {
    "code": "generating or debugging code",
    "research": "research and information gathering",
    "writing": "writing and text editing",
    "data": "data analysis",
    "routine": "routine task automation",
}

groups = defaultdict(list)
with open("task_timings.jsonl", encoding="utf-8") as fh:
    for line in fh:
        rec = json.loads(line)
        key = CATEGORIES.get(rec["kind"])
        if key:
            groups[key].append((rec["seconds"] / 3600, rec["assisted"]))

for name, pairs in groups.items():
    assisted = [h for h, a in pairs if a]
    plain = [h for h, a in pairs if not a]
    if len(assisted) < 5 or len(plain) < 5:
        print(f"{name:<34} not enough pairs yet ({len(assisted)}/{len(plain)})")
        continue
    delta = st.median(plain) - st.median(assisted)
    print(f"{name:<34} saved {delta:>5.2f}h/task  "
          f"(n={len(assisted)}+{len(plain)})")

# Print the "not enough pairs" line rather than a number. Five samples per arm
# is already generous; a two-sample comparison on two data points is a story,
# not a measurement.

4. Firms say they use it for processes and invest in tools

The firm-side survey is blunt about motives: 62 per cent cite improving business processes, 23 per cent cite innovation, research and development or expanding the product range, and only 15 per cent cite reducing labour costs. That last number is worth sitting with, because the public conversation assumes the opposite. The investment plans tell a similar story with a gap in it: 49 per cent of firms planning AI investment intend to buy technologies and tools, 46 per cent intend to train employees, 40 per cent intend to spend on data and infrastructure, and 12 per cent intend to hire AI specialists. The odd one out is training. Half the firms are buying a tool whose value depends on people changing how they work, and fewer than half have budgeted for the part that makes that happen.

# Is your measured saving distinguishable from zero? Bootstrap the median
# difference instead of trusting a point estimate from a small sample.
import random
import statistics as st

random.seed(7)


def bootstrap_median_diff(assisted, plain, n=5000):
    diffs = []
    for _ in range(n):
        a = st.median(random.choices(assisted, k=len(assisted)))
        p = st.median(random.choices(plain, k=len(plain)))
        diffs.append(p - a)
    diffs.sort()
    lo = diffs[int(n * 0.025)]
    hi = diffs[int(n * 0.975)]
    return lo, hi


assisted_hours = [1.8, 2.2, 1.5, 3.1, 2.0, 1.2, 2.6, 1.9]   # replace with yours
plain_hours = [2.9, 3.4, 2.6, 4.2, 3.0, 2.4, 3.8, 3.1]

lo, hi = bootstrap_median_diff(assisted_hours, plain_hours)
print(f"median difference: {st.median(plain_hours) - st.median(assisted_hours):.2f}h")
print(f"95% interval: {lo:.2f}h to {hi:.2f}h")

if lo <= 0:
    print("interval crosses zero: report 'no measurable difference yet'")
else:
    print("interval excludes zero: the direction is supported by this sample")

# Crossing zero is the normal result for a small team in a slow-feedback task
# class. Saying so is cheaper than defending a number you cannot reproduce.

5. Why the aggregate productivity number stays small

Three mechanisms in the speech explain the gap between individual savings and national accounts. Breadth: adoption is wide but shallow, so the hours saved per worker are small when averaged over everybody. Depth: the big gains live in a minority of tasks and a minority of users, and they do not aggregate until a process is rebuilt around them rather than having a tool bolted on. And expectations: firms systematically underestimate how many of their competitors are investing, and that belief gap suppresses their own plans — the ECB's own research finds that firms raise their expected investment rate when they learn that more domestic peers are investing, by about 0.6 percentage points for every percentage point of perceived peer adoption. The investment is real: digital investment in the euro area is up 73 per cent in real terms since 2014, and firms report that AI has added about 10 per cent to their capital expenditure plans this year. What lags is the reorganisation that turns spend into output.

# The one page that survives being asked "how do you know". Median, spread and
# the no-gain share, per task class, with the sample size visible.
import json
import statistics as st
from collections import defaultdict


def load(path: str):
    rows = []
    with open(path, encoding="utf-8") as fh:
        for line in fh:
            rec = json.loads(line)
            rows.append((rec["kind"], rec["seconds"] / 60.0, rec["assisted"]))
    return rows


def page(path: str, min_n: int = 5) -> str:
    groups = defaultdict(lambda: {"ai": [], "no": []})
    for kind, minutes, assisted in load(path):
        groups[kind]["ai" if assisted else "no"].append(minutes)

    lines = ["task class      n_ai  n_no  median_ai  median_no   saved  no-gain"]
    for kind, g in sorted(groups.items()):
        if len(g["ai"]) < min_n or len(g["no"]) < min_n:
            lines.append(f"{kind:<15} {len(g['ai']):<5} {len(g['no']):<5}  "
                         "not enough paired tasks yet")
            continue
        ma, mn = st.median(g["ai"]), st.median(g["no"])
        flat = sum(1 for a, b in zip(g["ai"], g["no"]) if a >= b) / len(g["ai"])
        lines.append(f"{kind:<15} {len(g['ai']):<5} {len(g['no']):<5}  "
                     f"{ma:>9.0f}  {mn:>9.0f}  {mn - ma:>5.0f}m  {flat:>6.0%}")
    return "\n".join(lines)


if __name__ == "__main__":
    print(page("task_timings.jsonl"))

# Three columns do the work: the median (what a typical task looks like), the
# no-gain share (how often the assistant changed nothing), and n (whether any
# of it is worth reading). A dashboard without n invites the wrong argument.

6. Measure your own median, and stop borrowing the headline

The number your manager will quote at you is six hours a week, and it is not about your team. Do the small, unglamorous thing instead: pick one task class, log task start and end times for a few weeks with and without the assistant, and report the median difference and the share of tasks where it made no difference at all. Two rules keep it honest. Never report a mean over a skewed distribution without the median next to it, and never let the person who is enthusiastic about the tool be the only source of the measurement. If the honest number turns out to be forty minutes rather than six hours, that is still a real number, and it is the only one you can defend when somebody asks how the licence gets renewed.