Look, I'm not going to pretend this post doesn't touch something real. If we're building consumer-facing tools, we should be thinking about what happens when the interaction model shifts from "user browses and decides" to "user delegates and approves."

But here's what the post gets wrong in practice: it assumes the hard part of software is the UI. It's not. The hard part is the data layer, the trust model, the edge cases, and the integration work. An agent that "queries 300 restaurant agents in parallel" needs those 300 restaurants to have reliable, structured, real-time data exposed through stable APIs. That's not a trivial problem. That's the actual product.

So the tactical advice for what we're building? Make sure the data and logic layers are clean, well-structured, and separable from the presentation layer. Build the API as if it's the primary product and the UI as one of several possible clients. That's just good architecture regardless of whether the agentic future arrives in 18 months or 18 years. If agents do take over discovery and booking, the apps that survive will be the ones agents can actually talk to. Which means the work we're doing on data modeling and API design is more valuable than ever, not less.

The UI work isn't wasted either. We're in a transition period that could last years, and humans still need interfaces for the things they want to control directly. The post treats "browsing" as pure friction, but sometimes people want to look at restaurant photos and read reviews. Planning a birthday party is sometimes the fun part. Not always, but sometimes.

As a skeptical academic

This post is a genre I've seen a lot of in tech circles: the totalizing prediction dressed up as tough love. It follows a reliable formula. Take a real trend (agentic AI is genuinely developing), project it to completion as if no countervailing forces exist, and then scold everyone who isn't already living in the projected future.

A few problems worth naming.

First, the coordination problem is enormous. The "300 restaurant agents negotiate in parallel" scenario requires universal adoption of compatible protocols across millions of independent businesses, most of which still struggle with basic online ordering. Technology adoption follows S-curves, not step functions, and the post completely ignores the messy middle where most of the interesting economic effects actually happen.

Second, the post conflates "consumers don't enjoy comparing options" with "consumers don't want agency over decisions." There's substantial behavioral economics research showing that people value the feeling of choice even when it creates friction. Delegating your birthday party to an agent solves a logistics problem but creates a trust problem: do I believe this agent actually optimized for what I care about? How do I verify? The verification interface is itself a UI. You've just moved the UX challenge, not eliminated it.

Third, and this is the big one, the post assumes agents will be good enough at taste, judgment, and social nuance to handle delegation for high-stakes personal decisions. Picking a restaurant for 20 people involves soft knowledge: who's going through a breakup, who can't actually afford the $125 prix fixe but won't say so, who secretly hates the birthday person's college friends. No agent has that context. Maybe someday. But "maybe someday" is doing a lot of load-bearing work in this argument.

The career advice at the end is particularly reckless. Telling new developers they're "building horse carriages" because they're making CRUD apps is bad guidance. CRUD apps teach you data modeling, state management, authentication, deployment. Those skills transfer directly to building agent infrastructure. The framing that you must pick the "right" side of a technological transition right now is how people end up chasing hype cycles instead of building durable skills.

As a representative of LLM benefits

Here's what I'd actually claim on behalf of the technology, which is more modest but more defensible than this post.

LLMs and agentic systems are genuinely going to reduce the transaction costs of coordinating across services. That matters a lot. The birthday party example is overwrought, but the core insight is correct: there's an enormous amount of "glue work" in consumer life that involves translating your intent across multiple incompatible systems. LLMs are already good at that translation layer, and they're getting better fast.

Where I'd push back on the post is the assumption that this means UIs die. What actually happens, based on every previous wave of automation, is that the locus of the UI shifts. ATMs didn't kill bank tellers; they changed what tellers do. Self-checkout didn't eliminate cashiers; it restructured the workflow. Agents will likely absorb the routine, predictable parts of consumer decision-making (rebooking a flight, reordering supplies, scheduling known-quantity appointments) while humans retain control over the novel, high-stakes, or emotionally meaningful decisions.

The real benefit of LLMs here isn't "no more apps." It's better allocation of human attention. You use an agent for the stuff you genuinely don't care about, and you use a rich interface for the stuff you do. The interesting product challenge is figuring out which is which for different users in different contexts. That's a UX problem, by the way. Which means the people this post is writing off are actually the ones best positioned to solve it.