People Blamed AI for These UI Bugs. I Started Wondering Why.

A few days ago, I came across a post showing a strangely broken interface in Meituan, one of China’s most widely used food delivery and local services apps. In one screenshot, a delete button had expanded into a huge red block, occupying almost half the screen. Other users joined the discussion with their own examples: text cut off by containers, overlapping components, oddly placed buttons, and stores more than ten kilometers away appearing before nearby options.

The screenshots were funny, but the comments were more interesting. “Please bring the frontend developers back,” one person joked. Another claimed that product managers were now using AI to write frontend code. Someone else wondered whether design and testing had been removed from the process too.

No one in the discussion knew how these interfaces were actually built. Still, many people reached for the same explanation: AI. That reaction stayed with me. A few years ago, users seeing a broken interface would probably blame a rushed developer or insufficient testing. Now, they imagine a product manager prompting an AI model and shipping whatever comes back. We do not know whether that happened here. But the fact that it already sounds believable tells us something about how software work is changing.

The Bug Doesn’t Prove Anything, but the Reaction Does

A broken interface is not evidence of AI-generated code. The giant delete button could have come from a layout error. Cropped text might be caused by an unexpected content length or poor adaptation to a particular screen size. Incorrectly ranked stores may be a location or recommendation problem rather than a frontend issue. Human developers produced all of these bugs long before generative AI arrived.

At the same time, the comments are not based on pure imagination. Meituan has released NoCode, an AI coding tool that allows users to create and deploy websites and software tools through natural-language conversations. According to the company, it can be used for product prototypes, internal tools, data analysis, and web portals. That does not connect NoCode to these screenshots. It does, however, show why users can easily imagine software being built differently now.

• A product manager can describe an interface and receive working code.
• A designer can turn a visual concept into a prototype without waiting for an engineer.
• A developer can generate components, tests, documentation, and product copy in the same workflow.

Work that once moved between several specialists can increasingly happen in one conversation. But this also changes where mistakes come from. When producing a page becomes easier, teams can move from idea to release much faster. Review, testing, and judgment do not automatically speed up with it.

An AI model can generate a button in seconds. It does not necessarily ask whether that button still works when the product name takes up three lines, the user has enabled larger fonts, the network response is delayed, or a promotional label is inserted above it at the last minute. Real products rarely look like the clean examples used in a prompt. They contain missing images, unusually long names, changing prices, conflicting campaigns, old components, multiple screen sizes, and experiments running for different groups of users. The interface often fails not in the state someone designed, but in the state nobody remembered to describe. This is why “the AI generated working code” and “the product is ready” are two very different claims.

When Execution Gets Cheaper, Judgment Becomes the Bottleneck

The screenshots made me think that AI may be changing the bottleneck of software development. In the past, a team could understand the problem but still struggle to build the solution. Turning an idea into a functioning product required time, technical knowledge, and coordination between product managers, designers, developers, and testers. AI reduces some of that friction. It makes technical execution available to more people and allows each person to cover a larger part of the product process.

But easier execution does not guarantee a better product. It may simply allow a team to produce more decisions-and more mistakes-in less time. Once almost anyone can generate an interface, the difficult part becomes knowing what the interface should do. Someone still needs to understand why a nearby restaurant should appear before one fifteen kilometers away, why a delete action needs a clear warning, and why a button that looks acceptable on one screen may become unusable on another.

These are not only design or engineering questions. They are product questions because they require someone to connect technical behavior with the user’s actual situation. This is where I think the value of “understanding the product” is growing. Not because product managers will automatically replace developers, but because AI rewards people who can move between an idea and its implementation without losing sight of the user.

• A product manager who can generate code but cannot evaluate it may only create bad software faster.
• A developer who accepts every AI suggestion without understanding the product faces the same problem.

The vulnerable skill is not programming or design itself. It is execution without judgment.

The Future Developer May Own More of the Product

This does not convince me that developers are disappearing. It does make me think their work will become broader. Writing a familiar component from scratch may become less valuable. Understanding how that component fits into a larger system, what can break, and whether the generated solution will remain maintainable is harder to automate.

The same expansion is happening in other roles:

• Designers can test interactions directly.
• Product managers can build early prototypes.
• Developers can contribute to product decisions instead of receiving a finished requirement and translating it into code.

The boundaries between these jobs may become less rigid, creating a more general kind of product builder: someone who can understand a user problem, use AI to create a solution, and recognize when the result is misleading, fragile, or simply wrong. Deep expertise will still matter. Large platforms cannot be maintained by prompts alone. But smaller teams may be able to build more, and companies may expect each person to take responsibility for a larger part of the final experience.

We may never know whether AI had anything to do with the strange Meituan interface. It could have been an ordinary layout bug, a failed experiment, or a release that moved too quickly. But the comments revealed a shift that feels more important than the bug itself. Users already believe that software may be generated by AI and lightly reviewed by humans. The question is no longer whether AI can produce an interface. It is whether someone still knows the product well enough to notice when the interface makes no sense.

The screenshots and discussion came from a public Xiaohongshu post. The comments are users’ speculation and do not confirm Meituan’s internal development process. Meituan describes its AI coding product in the company’s official NoCode announcement.