Nobody Is Reading Anything

An engineer who posts as voxium went viral on X this weekend. 2.7 million views and counting, and a second life on LinkedIn after Aakash Gupta reshared it and said he couldn't stay quiet about it.

The story, in voxium's telling. Two weeks into a new role at a big company. Specs, code, tests, PRDs, tickets, the resolution of those tickets, reports, all of it generated by Claude Code. Everyone from L1 to L7 doing the same thing all day. Twelve to thirteen hour days spent pressing enter. Nobody reading anything, nobody resolving bugs, nobody thinking. And the line from management, heard more than once: pushing code is not a bottleneck, so why are we slow?

I can't verify any of it. I don't need to. Twenty-three thousand people hit like because they recognized their own org.

The popular read is that this is what AI does to engineering. That read is wrong, and it's wrong in a way that will get more orgs into the same hole. The tool did exactly what it was asked to do. What broke is the operating model around it.

The short version

Voxium's company made generation free and never funded the reader. Goldratt's rule from the factory floor applies without modification: speed up a step that isn't the constraint and you don't get faster, you get inventory in front of the step that is. The inventory here is unread PRDs, unreviewed diffs, and tickets closed by the same model that opened them. Management's own line, "pushing code is not a bottleneck," is the diagnosis; they just never asked where the bottleneck went. It went to reading. The absence of victory is the second symptom, and it's the one I'd worry about more: nobody owns an outcome, so output got measured instead, and AI makes output free. The fix doesn't use less AI. It funds review and eval capacity like headcount, names a reader of record for every artifact, puts evals before volume, gives one person ownership from prompt to landing, and measures direction weekly instead of tickets closed.

Management diagnosed it and didn't notice

Read the management line again. Pushing code is not a bottleneck, so why are we slow?

They're right. Code isn't the bottleneck. It stopped being the bottleneck about a week after the Claude Code licenses landed. The question they didn't ask is the only one that matters: if it isn't code, what is it?

Goldratt answered this forty years ago in a book about a factory, and I've never found a software org it didn't apply to. Every system has one constraint. Improve anything other than the constraint and throughput doesn't move; what moves is the pile of work-in-progress stacking up in front of the step that's still slow. In a plant, that's pallets on the floor. In a software org in 2026, it's the unread PRD, the unreviewed diff, the ticket the model opened and the model closed. "Nobody is reading anything" is a description of inventory.

So where did the constraint go? To understanding. Reading the diff. Deciding whether this ticket should exist. Knowing whether the thing that shipped on Tuesday changed anything for a customer by Friday. I've been writing about this for a year as the shift from building to landing, and the landing ledger has the numbers: build cost fell off a cliff, land cost didn't move, and most orgs still budget for the one that fell. Voxium's post is what that looks like from a desk on the inside. Twelve hours a day feeding a step that was never the problem, while the step that is the problem runs on nobody's calendar.

When generation is free, reading is the scarce resource

Every artifact needs a reader to be worth anything. A PRD nobody reads is exhaust. A test suite nobody reviewed is a vibe. A report on a fix, written by the model that wrote the fix, read by no one, is a closed loop with no human in it, running at full speed toward nowhere in particular.

This is the argument behind the PRD collapsing into three artifacts, and voxium's org is the counterexample that proves it. AI took the cost of producing a document to zero. It did nothing to the cost of reading one. An org that responds by generating everything is spending its scarcest resource, human attention, to manufacture its cheapest one. That's a budgeting error, and budgeting errors have fixes.

The second thing in the post is the one I'd lose sleep over if I ran that company. There is no sense of victory.

Of course there isn't. Victory requires owning an outcome. If your unit of work is pressing enter, you own nothing. You're a throughput node. And this is what outcome accountability treated as a luxury good looks like at the bottom of the org chart: the company can't measure outcomes, so it measures output, AI makes output free, and the output graphs go vertical while the meaning goes to zero. People feel that long before a dashboard shows it. "Soul-sucking" is a leading indicator. It shows up months before the churn does, and it's cheaper to read.

I ran experimentation at Airbnb for a while, and the reason holdouts existed is that "shipped" and "worked" are different claims. Most orgs only track the first one. An org that only tracks the first one, with a generator that never gets tired, will ship itself into the ground and feel busy the whole way down.

What I would change, and none of it is "less AI"

The teams getting this right use the same tools voxium's company uses. Same Claude Code, same models. They run a different system around them, and the system has five parts.

Fund the reader. Name the constraint out loud and plan for it. Review and evaluation capacity gets budgeted the way you budget headcount, because it's the thing that limits throughput now. If your engineers spend twelve hours generating and zero hours reading, you don't have a velocity problem, you have a staffing plan that's a year out of date. Some of the best engineers in that org should be reading full time. That's the job now.

Reader of record. This is the one rule I'd install on day one, because it stops the pile from forming. Before an artifact gets generated, it names the human who will read it end to end and is accountable for what it says. No reader, no artifact. It sounds bureaucratic and it's the opposite: it kills most of the PRDs, most of the reports, and every ticket that exists to close another ticket, because nobody will put their name on reading them. What survives is what someone actually needs.

Eval before volume. Define what good looks like before the model writes a line. The eval is the spec: thirty to two hundred real cases, labeled, scored on every change. Done stops meaning "the ticket closed" and starts meaning "the score moved." That single change gives the twelve-hour day a point, because now pressing enter is running an experiment, not feeding a belt.

One owner to landing. Somebody owns the change from the prompt that produced it to the customer behavior it was supposed to change. That's the Product Builder: prompts it, ships it, watches it land, gets the win when it does. This is where the sense of victory comes back, because that's what accountability feels like from the inside when it's attached to a real outcome and a real name.

Measure direction weekly, outcomes quarterly. Outcome cycles are still slow, and an org that iterates ten times a week can't steer by them. So steer by direction: eval pass rate, reversal rate on agent actions, adoption of what shipped last week, escalations. Tickets closed is not on the list. Lines generated is not on the list. If a number goes up when you press enter more, it's a speedometer bolted to a car with no steering wheel.

Monday, if I walked into that org

I wouldn't touch the tooling. I'd take "why are we slow" out of the standup and onto a whiteboard, and I'd pick one change that shipped last week. Trace it. The prompt that produced it, the diff, whoever looked at the diff, the ticket, whoever closed the ticket, the customer it was supposed to help, and what that customer did differently afterward. Mark every step where the work waited for a person. Most orgs find two of those steps, and both are reading.

Then the five artifacts. Pull the last five things the model generated for the team and ask who read each one end to end. In voxium's org the answer is nobody, five times. Every artifact type that scores nobody gets paused until a reader of record claims it. That alone drops the pile by half in a week, and the people who were pressing enter get their afternoons back to do the reading that was never staffed.

Then the eval. One feature, one eval set, before the next prompt. Small. The first one takes an afternoon.

That's the whole plan. The leaders in voxium's post asked the right question. They just asked it in the wrong room, and they answered it with a tool instead of an operating model.

This isn't the end of engineering. It's the end of pretending volume is progress, and that was overdue.

Pick one thing to try this week: pull the last five AI-generated artifacts your team produced and ask who read each one end to end. If the answer is nobody, stop generating that artifact type until someone owns it.

Sources: voxium on X, September 20, 2026, 2.7M views and 23K likes at the time of writing, reshared on LinkedIn by Aakash Gupta (Product Growth). Quoted by Simon Willison the same day. Eliyahu Goldratt, The Goal (1984), for the theory of constraints.

Part of the running argument on Product Leadership: the operating model is the product decision most leaders never make on purpose.

Related answer: Why does an AI-first engineering org feel slow?