Coding agents make bug blindness a product problem, Dan Luu argues

Why it matters

AI lowers the cost of generating and repairing software, raising the value of teams that can recognize broken workflows before customers teach themselves to leave.

Dan Luu published a diagnosis on August 30th for why software teams ship products that users struggle to operate: the people building them have learned to stop seeing their own bugs.

In his new essay, "Bug Blindness", Luu argues that engineers and experienced users build up a private collection of pauses, restarts, avoided features and carefully ordered clicks. Those workarounds eventually become automatic. The underlying defect disappears from conscious view, even as every new user continues to encounter it.

Luu has spent much of his career close to the machinery where subtle failures matter. He worked for eight years at Centaur Technology on x86 processors and related validation, then became the second engineer on the project that developed into Google's Tensor Processing Unit. He later worked on Microsoft's BitFunnel search infrastructure; BitFunnel's team page describes his earlier work across network virtualization hardware, deep-learning hardware and x86 and ARM processors.

That background matters because Luu's argument comes from repeated debugging work rather than a theory about user experience. He says executives at several employers asked him to evaluate products when they wanted an opinion from someone likely to identify problems and push for fixes. The troubling cases were products that required several non-obvious workarounds while internal discussion described them as working well.

Luu says he works around hundreds of bugs in an average week and thousands in a bad one. The estimate is anecdotal, though he previously published a log of one week of newly encountered bugs to document the scale of what he was seeing.

The workaround becomes part of the workflow

One of Luu's clearest examples is mundane. After opening a new Google Doc, he learned to wait before changing its title because text entered immediately could be overwritten. He also developed timing habits around search inside Google Docs, where invoking search at the wrong moment could open the browser's native search instead.

At Microsoft, Luu says he and other employees sometimes disabled Wi-Fi before logging into their laptops. An unreliable service could reject a login with an error about unavailable servers, while disconnecting the laptop caused the check to be bypassed. The workaround solved the immediate problem and made the defect easier to tolerate.

These habits are often mistaken for computer literacy. An experienced user appears fast because they know which controls to avoid, how long to wait and when to restart. A first-time user sees a product that behaves unpredictably.

Luu traces his awareness of the pattern to childhood. A mechanical mouse on his computer had accumulated enough dirt to move erratically. He had unconsciously learned to compensate by throwing his hand in countervailing directions, while a friend found the machine nearly impossible to use. Familiarity had concealed the hardware failure.

The same adaptation weakens dogfooding inside startups. Engineers are unusually capable of working around software problems, then explaining those workarounds as reasonable instructions. A product can appear usable to the people who built it while remaining hostile to anyone without their accumulated knowledge.

Luu says he has seen teams ship products with little chance of succeeding because everyone involved believed the quality was high. Deliberately trading polish for speed is a product decision. Failing to perceive the trade leaves a team unable to price the risk it is taking.

AI makes judgment the scarce input

His new essay examines the other side of that productivity gain. Agents can generate features, tests and patches quickly, yet the team still has to identify which behavior is broken and whether a proposed fix improves the experience. A group that has normalized its own workarounds can direct more code at the wrong problems with greater speed.

Luu also sees LLMs as part of the remedy. He says models can act like different types of ordinary users, helping determine whether an issue reproduces across multiple scenarios. That approach could give small teams a cheap source of unfamiliar behavior before a release reaches customers.

Model-driven testing cannot supply the missing judgment by itself. Teams still decide which failures count, whether an agent's simulated behavior resembles a real user and when an awkward workflow deserves engineering time. A test generator can explore a product. It cannot force a team to accept that a familiar sequence of clicks is unreasonable.

The practical response starts with treating workarounds as product data. A pause that everyone on the team knows to take is evidence of a timing defect. A login ritual points to an authentication failure. A support document explaining an elaborate sequence may describe accumulated product debt rather than user education.

That framing gives founders a useful quality check as AI expands how much a small engineering group can ship. Fresh-user observation becomes more valuable when code is cheap. So does asking experienced users to narrate the steps they normally perform without thinking. The hidden steps expose the difference between a working product and a product its builders have learned to operate.

Luu had considered writing the essay for roughly a decade. He says repeated launches eventually resolved his concern that he was merely finding obscure edge cases: ordinary users encountered the same failures once the products reached them. LLMs can now help expose whether those failures reproduce. The harder task is building an organization willing to notice them.