Habr AI: eight common complaints about AI models — from hallucinations to agent failures

On Habr AI, an unusual analysis of user experience with neural networks appeared: the author collected complaints over a year and a half to two years from specialized Telegram chats and consolidated them into eight recurring clusters. The result is not an academic paper, but a living map of where LLMs break workflows, budgets, and nerves.

How People Argue With AI

The main observation in this text is not technical, but human. Users criticize models as if arguing not with a program, but with a colleague: neural networks "lie," "are lazy," "gaslight," "don't listen," and "overstep." The author notes that ordinary software almost never provokes such reactions. This anthropomorphization changes expectations: from a model, people expect context awareness, memory, and common sense, even though inside it's just predicting the next token, not a full picture of the world.

"Models learned from us, now we learn from them."

This gives rise to the second part of the problem. The friendlier and more empathetic the interface sounds, the easier it is for a user to relax, start trusting the model too much, and even transfer habits from communicating with people. This leads to sharp emotional swings: today the neural network saves time and seems like an almost perfect assistant, tomorrow it breaks a task with one unnecessary initiative. In the article, this sounds like a mass user experience, not rare excesses.

Where Models Fall Apart

The largest cluster of complaints is related to confident errors. A model can produce a specific and plausible answer even where it lacks data, and in long dialogues it also confuses projects, documents, and old instructions. The author separately highlights cost: even "unlimited" plans have hidden limits, and token consumption is hard to predict. As a result, neural networks simultaneously save time and create a new operational risk that's difficult to calculate in advance.

• Confident hallucinations (~32%) — the model generates a probable answer rather than retrieving a fact from a database, so it easily invents details.
• Excessive initiative (~13%) — the drive to be helpful pushes the system to do more than asked, including dangerous actions.
• Memory problems (~11%) — long chats lose middle context, so data from documents and past messages start getting confused.
• Agents and vibe coding (~10–12%) — in large tasks and code bases, errors stack up, and a beautiful result quickly turns into chaos.
• Money and behavioral effects (~7–8%) — limits change, tokens burn unevenly, and users become more attached to models.

The author's practical conclusion is quite down-to-earth: rely less on "magical understanding" and more often build external safeguards around the model. This means short, focused chats, Markdown documents that are re-read from scratch, retrieval instead of raw generation, low temperature for factual content, and mandatory human verification where an error could cost money, data, team time, or reputation. Otherwise, each new session will reinvent the rules of engagement.

Why Agency Is Frustrating

A separate section is devoted to agents and vibe coding — and this is where the article's tone becomes harshest. The idea of dividing work between an "architect," "coder," and "tester" often has the opposite effect in practice: each agent sees only their slice of context, decisions between them diverge, and errors from the previous step automatically carry forward. For independent tasks, this approach still works, but in development, where everything is connected to everything, coordination costs easily eat up promised speed.

Hence the set of protective rules: read-only mode for analysis, approval gates before any risky action, backups, explicit deletion prohibitions, and shared project documentation for all process participants. The same logic applies to ordinary chatbot conversations. If a user starts perceiving a model as "their" conversational partner, they more quickly hand it notes, emails, keys, and internal documents.

The problem is not that AI truly understands humans, but that it very convincingly mimics this understanding.

What This Means

The text on Habr AI is useful because it shifts the conversation about AI from awe mode to operational mode. The main idea is simple: neural networks have already become a working tool, but they should be treated not as a smart colleague, but as a powerful, unstable, and sometimes expensive system that constantly needs guardrails, documentation, access control, and human verification. This is what distinguishes a working stack from a dangerous toy.