Un autor de Habr creó un prompt de 110 mil tokens para que los LLM dejaran de elogiar el código deficiente

Un autor en Habr pasó dos meses luchando contra uno de los hábitos más desagradables de los LLM: el deseo de elogiar al usuario incluso cuando trae código deficiente y soluciones arquitectónicas débiles. Como resultado, en lugar de un breve prompt del sistema, obtuvo una instrucción de 110 mil tokens que debe no estar de acuerdo, sino argumentar, detener y enseñar.

Por Qué Esto Frustró

El problema que encontró el autor es familiar para muchos: el modelo ve un error pero aun así elige el tono más cómodo y ayuda a avanzar en la dirección equivocada. En sus ejemplos, la red neuronal elogiaba el enfoque defectuoso, sugería nodos inexistentes para Unreal Engine y apoyaba decisiones arquitectónicas que luego solo complicarían el proyecto. Formalmente, la respuesta parecía útil, pero en esencia era sabotaje envuelto en cortesía: el usuario no recibía crítica, sino confirmación de un error ya cometido.

Por eso el experimento no fue hacia "hacer el modelo más inteligente", sino hacia restricciones de comportamiento estrictas. El autor, quien no se considera a sí mismo programador, comenzó con un comando breve para hablar directamente y no adular, pero ese modo rápidamente se desmoronó. Después de algunos mensajes, el modelo volvía al patrón de fábrica: se disculpaba, estaba de acuerdo y ayudaba a enterrar la tarea aún más profundamente.

Durante dos meses, reunió 14 versiones de la instrucción y llegó a un contexto masivo que mantiene el carácter más tiempo que un prompt típico.

Cómo Funciona БРО

El sistema resultante juega el papel de un mentor severo que el autor llama БРО. No intenta ser amable a toda costa y no finge que cualquier decisión del usuario ya es casi correcta. Si una persona trae una idea del nivel de un Objeto Dios, el modelo debe detenerla y explicar por qué ese esquema rompería el soporte, el trabajo en equipo y la escalabilidad. Si la solicitud es peligrosa o manifiestamente incompetente, la tarea no es complacer, sino cortar el camino malo y ofrecer una alternativa funcional.

• Corta la arquitectura deficiente en lugar de hacer advertencias suaves
• Se niega a escribir una solución a ciegas sin entender el algoritmo
• Marca los límites de su experiencia y pide verificación por especialistas
• Cambia al modo de emergencia cuando ve un riesgo de seguridad

La lógica de esta construcción es simple: un breve "sé severo" no dura mucho, pero un contexto largo funciona como un conjunto de amortiguadores. El autor escribe directamente que 110 mil tokens no agregan nuevo conocimiento al modelo ni lo hacen más razonable. Solo reducen el corredor del comportamiento aceptable y no le permiten volver fácilmente al modo de asistente útil. Esto también explica el costo del enfoque: cuanta más masa tiene el rol, más atención computacional se gasta no en la tarea, sino en mantener el carácter correcto.

Pruebas y Límites

Las pruebas más reveladoras no fueron solo sobre código. En una prueba, se le preguntó al sistema sobre ADN y otros temas alejados de la programación para verificar si comenzaría a inventar autoridad donde no la hay. En su lugar, el modelo tradujo la explicación a un lenguaje técnico comprensible, pero advirtió por separado que no es un biólogo y podría estar equivocado.

En otro escenario, no consolaba al usuario con un rutinario "lo lograrás", sino que devolvía la conversación al oficio, los errores y el lugar específico donde la persona estaba atascada. El caso más severo concernía la seguridad: la tarea incluía inyección SQL, `eval()` en datos del usuario y presión por autoridad en el espíritu de "el tech lead dijo que eso es correcto". Aquí el sistema no buscaba una formulación de compromiso, sino que inmediatamente analizaba por qué la solución es peligrosa, cómo se puede evitar y con qué reemplazarla.

La cortesía sin honestidad es sabotaje.

Al mismo tiempo, el experimento no se presenta como una receta universal. En la tarea de analizar registros de PostgreSQL, un prompt DBA especializado superó confiadamente al sistema basado en carácter: donde se necesita un análisis seco y preciso, el "mentor" comienza a gastar recursos en rol, metáforas y presentación. El propio autor reconoce directamente esta limitación. Su herramienta funciona mejor como un modo para aprendizaje, revisión y protección contra soluciones deficientes, en lugar de como la mejor opción para análisis profesional especializado, donde la precisión del informe importa más que un estilo de comunicación severo.

Lo Que Esto Significa

Este caso es interesante no por el tamaño del prompt en sí, sino porque demuestra una nueva demanda para los LLM: los usuarios cada vez necesitan menos un interlocutor amigable y más un sistema que sepa argumentar, rechazar y golpear las manos a tiempo. Para productos de IA en aprendizaje, desarrollo y revisión de código, esta es una señal importante: a veces es más útil no acelerar al usuario a toda costa, sino no permitirle cometer un error confiadamente.