AINEWS
The friction has only moved, from writing the code to shipping it: the tests, the staging, and the on device check that decides whether the software actually works for users.
Three FaceID prompts to confirm a $4 coffee. The bank's app lets you tap the order, walk to the counter, and then makes you prove, three times in a row, that you are the person holding the phone. The third prompt is the one that finally opens 3D Secure, the card network's required fraud check for online purchases. Until then, the transaction is held hostage to your face.
This is the kind of small, ordinary friction that used to be a punchline about legacy banking software. In 2026, it is the punchline about the bank app, the car's infotainment, the fridge's warranty portal, and the Slack window that steals focus every time the dock bounces. The "agentic era," the name product teams gave to the moment AI coding tools could finally generate production-ready code largely on their own, was supposed to make all of this go away. The narrative in product orgs was that the model had eaten the hard part. Instead, the friction moved.
Piotr, a product manager who writes at ptrchm.com, opened a recent essay that has been drawing discussion on Hacker News with a list: a car infotainment that reboots mid-drive, the turn-signal click that goes silent, screen taps that land in the wrong app, one to two seconds of input lag. A warranty form that fails at the last field. Slack stealing focus mid-dock-bounce. The bank app's three FaceIDs. Each item is small. The list is the point. The author calls the current moment an "AI-induced mass psychosis" in which "token-maxxing," the practice of measuring engineering output in tokens consumed rather than outcomes shipped, has become a stand-in for shipping better products. The contradiction lands hard in one detail: a LinkedIn post by a PM on the car-OS team congratulating the team on a redesign that the same users now find less responsive than what it replaced.
The argument underneath the list is precise. The constraint on user-visible quality was never the model's ability to write code. It was always the workflow between the code and the user: the tests, the staging environments, the observability, the end-to-end feedback loop that tells a team what their software actually does to a real person in a moving car. AI jumped the first constraint. The second one widened. A team can now ship a complete feature in an afternoon, with passing unit tests, and still have no idea that the same flow fails on a real iPhone with a saved card, because the loop between the code and the user is the layer that was never automated and never gets staffed for.
DHH, the creator of Ruby on Rails, has been writing a parallel argument for years. In "Merchants of Complexity", he frames complexity as something actively sold: clever over basic, subscription over ownership, marketed through fear, vanity, sloth, and pride. His Linux distribution, Omarchy, is pitched as an "act of rebellion" against the current state of macOS and Windows, with a deliberately small surface area and a deliberately small set of defaults. The two essays are independent diagnoses that converge on the same place. The bottleneck is no longer where product orgs think it is.
The cleanest test of the model-as-constraint story is also its strongest counterargument. If model capability were truly the binding constraint, the regression would correlate with model adoption in a way these anecdotes do not show, and teams without AI tooling would not be shipping the same kind of friction. The author's own evidence points the other way. The teams shipping the three-FaceID flow and the rebooting car screen almost certainly have access to the latest models with generous token budgets. The binding constraint is the workflow around the model, not the model itself.
The rubric is the part that lasts. A banking app that holds a transaction hostage to three FaceID prompts is a flow that would have failed an end-to-end test on a real device with a real card. A car screen that lags two seconds after a tap is an interface that would have failed a tap-check while the car was moving. A warranty form that fails at the last field is a form that would have failed a submission check in the browser the customer uses. The shipping velocity is no longer the score. The user-visible quality is.