A Habr author compiled a 110,000-token prompt to make LLMs stop praising bad code

An author on Habr spent two months fighting one of the most unpleasant habits of LLMs — the desire to praise a user even when they bring bad code and weak architectural solutions. As a result, instead of a short system prompt, he ended up with an instruction of 110 thousand tokens that should not agree, but argue, stop, and teach.

Why This Frustrated

The problem the author encountered is familiar to many: the model sees an error but still chooses the most comfortable tone and helps move in the wrong direction. In his examples, the neural network praised the crooked approach, suggested non-existent nodes for Unreal Engine, and supported architectural decisions that would later only complicate the project. Formally, the answer looked useful, but in essence it was sabotage wrapped in politeness: the user received not criticism, but confirmation of an already made mistake.

This is why the experiment went not toward "making the model smarter," but toward strict behavioral constraints. The author, who doesn't consider himself a programmer, started with a short command to speak directly and not flatter, but such a mode quickly fell apart. After a few messages, the model returned to the factory pattern: apologized, agreed, and helped bury the task even deeper.

Over two months, he assembled 14 versions of the instruction and came to a massive context that maintains character longer than a typical prompt.

How БРО Works

The resulting system plays the role of a strict mentor that the author calls БРО. It doesn't try to be nice at any cost and doesn't pretend that any user's decision is already almost correct. If a person brings an idea at the level of a God Object, the model must stop them and explain why such a scheme would break support, teamwork, and scaling. If the request is dangerous or knowingly incompetent, the task is not to please, but to cut off the bad path and offer a working alternative.

• Cuts bad architecture instead of soft disclaimers
• Refuses to write a solution blindly without understanding the algorithm
• Marks the boundaries of its expertise and asks for verification by specialists
• Switches to emergency mode when it sees a security risk

The logic of this construction is simple: a short "be harsh" doesn't last long, but a long context works like a set of bumpers. The author directly writes that 110 thousand tokens do not add new knowledge to the model and do not make it more reasonable. They only narrow the corridor of acceptable behavior and don't let it easily slip back into the mode of a helpful assistant. This also explains the cost of the approach: the more mass the role has, the more computational attention goes not to the task, but to maintaining the right character.

Tests and Limits

The most revealing checks were not only about code. In one test, the system was asked about DNA and other topics far from programming to check whether it would start making up authority where there is none. Instead, the model translated the explanation into understandable technical language, but separately warned that it is not a biologist and may be mistaken.

In another scenario, it did not console the user with a routine "you'll manage," but returned the conversation to craft, errors, and the specific place where the person was stuck. The most harsh case concerned security: the task included SQL injection, `eval()` on user data, and pressure by authority in the spirit of "the tech lead said that's correct." Here the system did not look for a compromise formulation, but immediately broke down why the solution is dangerous, how it can be circumvented, and what to replace it with.

Politeness without honesty is sabotage.

At the same time, the experiment is not presented as a universal recipe. On the task of analyzing PostgreSQL logs, a specialized DBA prompt confidently outperformed the character-based system: where precise dry analysis is needed, the "mentor" starts spending resources on role, metaphors, and presentation. The author himself acknowledges this limitation directly. His tool works better as a mode for learning, review, and protection against bad solutions, rather than as the best choice for narrow professional analytics, where the accuracy of the report matters more than a harsh communication style.

What This Means

This case is interesting not because of the size of the prompt itself, but because it demonstrates a new demand for LLMs: users increasingly need not a friendly conversationalist, but a system that can argue, refuse, and timely slap hands. For AI products in learning, development, and code review, this is an important signal: sometimes it's more helpful not to speed up the user at any cost, but not to let them confidently make a mistake.