We Automated the Wrong Part of the Workday

Uber has capped AI coding tool spend at $1,500 per employee per month after exhausting its full-year budget ahead of schedule. AI agents now submit 10% of the company’s code. The COO acknowledged, on the record, that it is difficult to link AI tool usage to measurable customer-facing outcomes.

That last sentence is the one that matters.

A survey cited in recent coverage of Anthropic’s IPO preparations found that 40% of businesses using AI are seeing cost savings of less than 10%. A separate analysis by EntelligenceAI, reported in The Big Technology newsletter, found that only 18 cents of every dollar spent on AI produces usable output. The remaining 82 cents disappear into bug fixes, rework, re-prompting, and hallucination correction. These figures are routinely framed as a technology problem. They are, more precisely, a measurement failure.

The productivity case for AI coding tools was built on controlled studies. A developer given an isolated task, no meetings, no context-switching, no review cycles, completes it faster with AI assistance. The headline figure that gets cited is a 55% improvement. The figure that gets buried is that developers spend approximately 14% of their working day actually writing code, according to research reviewed by the RDEL newsletter, drawing on a 2025 Microsoft study. Even if AI doubled coding speed, the theoretical ceiling for overall productivity gains would be below 15%. The bottleneck was never code writing. It was meetings, coordination, design, review, and the invisible overhead of context restoration between interruptions. We automated the visible part of the workday and left the costly part entirely untouched.

This is not a critique of the tools themselves. It is a critique of the deployment logic. Most organisations reached for AI products before they answered the prior question: where is time actually going? That question sounds simple and is rarely answered with any rigour. Knowledge work organisations are reasonably good at tracking outputs and deliverables. They are almost universally poor at measuring the friction that consumes the space between them. Without that baseline, you cannot identify the right target for automation, set a meaningful ROI expectation, or evaluate whether the investment is working. You can only count tokens spent and hope the audit never comes.

The structural misalignment Big Technology describes makes this worse: model providers profit from token volume, while customers need reliable task completion at the lowest cost. That tension is manageable when the customer has clear success criteria. It becomes a budget spiral when the customer does not. Vendors have every incentive to sell consumption-based access to uncertain buyers. Buyers have every incentive to assume that usage equals progress. Neither party is lying. Both parties are avoiding the harder conversation about what outcomes they are actually trying to achieve.

The board conversations in H2 2026 will not be satisfied by usage dashboards and benchmark scores alone. Boards want line-of-sight to business outcomes. Most AI deployments were not designed with that in mind, not out of negligence, but because the tools arrived before the measurement infrastructure did. Procurement moved faster than operational clarity.

The corrective is not to retreat from AI, though some organisations will. It is to do the foundational work that should have come first: map where time actually goes, identify the specific friction that compounds across teams and roles, and deploy AI against those targets. That requires measurement capabilities and honest operational analysis that most technology organisations are still building. For smaller organisations, especially, the question worth sitting with is whether the baseline work began before or after the spending began.

───

Follow me on LinkedIn, and visit my website for more info!

Alberto Zuin, CTO/CIO

Originally published at https://albertozuin.substack.com.