"12 to 13 hours a day just to press enter": one tweet, no data

What was actually published

On 26 September 2026, Simon Späti published an 882-word note titled The Problem is not the AI Code, but Nobody Knows Anything Anymore, updated two days later. Its centrepiece is a quoted post from someone identified as Voxium, describing half a month at a new role at a big company: “The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code.” The line that travelled furthest: “People are working 12 to 13 hours a day just to press enter. Nobody is reading anything.”

That is the whole evidentiary base. A blog note, a quoted post, and three short comments from other practitioners. No survey, no defect rates, no incident data, no named employer. Before anyone reorganises a team around this, that distinction matters more than the argument itself.

The claim, stated precisely

Späti is not arguing that AI-generated code is bad. He quotes a comment from a discussion that says the opposite: AI “writes probably average code,” so a below-average codebase can be lifted up to average. The alleged damage is somewhere else entirely — in what stops being carried in human heads.

Three pieces of jargon do the heavy lifting, so here they are in plain terms. System architecture is the shape of a piece of software: which parts exist, what talks to what, and which constraints everything else is built around. Intent is the reason a past decision was made — the tradeoff someone accepted and why. A PRD is a product requirements document, the written statement of what a thing is supposed to do before anyone builds it. None of the three is visible in the code. All three live in people who were in the room, and they are what you consult when something breaks at 3am or when a regulator asks why a system behaves as it does.

The mechanism the note describes is straightforward: if a model produces the spec, the ticket, the code, the tests and the report, no human ever had to hold the reasoning. The artefacts exist; the understanding does not. Späti's own summary of the resulting failure mode is “You end up with no plan whatsoever.”

He names the consequence too, and it is the least speculative part of the piece: maintenance. The easier it becomes to generate a pipeline, an app or a dashboard, the more surface area exists that somebody must keep alive. Generation is cheap and one-off. Maintenance is expensive and permanent. A codebase nobody understands is not cheaper to run — it is cheaper to produce and dearer to own.

Where the argument is contested, even in the source

The note does not pretend to consensus. Hoyt Emerson is quoted arguing data engineering is different, because data people “had to know everything about the product/business from day 1” and AI merely removes friction. Späti half-concedes: that was true for people who grew up pre-AI, but someone starting today in a new field and prompting their way through simply never acquires it.

Sean Behan's point cuts the other way — non-technical product people who know what they want have always been valuable, and now they can build it. Späti's counter is specific and worth keeping: pick the wrong language or the wrong mental model at the start, and iteration does not save you. You have the wrong foundation from the get-go.

The note also floats a structural cause it does not defend at length: that this is self-inflicted, and that if companies still hired juniors, it would not be happening. Stated, not demonstrated.

Questions You Should Be Asking

• If the engineer who shipped a system left tomorrow, who could explain why it is built that way — not what it does, but why?
• Management in the quoted account said “pushing code is not a bottleneck, so why are we slow?” What is your organisation's actual bottleneck, and do you have a number for it or a vibe?
• Are you measuring output in merged changes, or in changes that stayed merged and did not generate follow-up work?
• When you stopped hiring juniors, what did you assume would replace the pipeline of people who learn a system by maintaining it?
• Would you accept this evidence base — one anonymous post, no metrics — from a vendor pitching you the opposite conclusion?

What To Watch Next

Watch for the first organisation that publishes maintenance numbers rather than shipping numbers: time-to-diagnose on production incidents, or the share of changes that reverse a change made in the previous quarter. Until someone does, the “nobody knows anything” thesis stays what it currently is — a sharply argued hypothesis, widely recognised by people who feel it, and entirely unmeasured.