Anastasiia Mudra · 7 серпня 2026

Заборони для AI-агента: чи варто казати йому, чого НЕ робити?

Що кажуть інші

Погляди на це різняться: офіційна документація Anthropic сама собі суперечить, аргумент "рожевого слона" застерігає проти заборон, і Sourcery зіткнулися з цим на практиці, а практика Cloudflare, навпаки, будується саме на запереченнях. Жодне з цих джерел не є контрольованим експериментом, лише практика та думки компаній, що будують подібні продукти.

Офіційна документація Anthropic суперечить сама собі

Актуальна інструкція Claude з інженерії запитів прямо радить:

Tell Claude what to do instead of what not to do.
Instead of: "Do not use markdown in your response" →
Try: "Your response should be composed of smoothly flowing prose paragraphs."

Anthropic, «Prompting best practices»

Але в тому ж гайді, у розділі "Overeagerness" (це загальна порада для Claude Opus 4.5 і Opus 4.6, які схильні переускладнювати рішення), офіційна рекомендація складається із суцільних заборон:

Avoid over-engineering. Only make changes that are directly requested or clearly
necessary. Keep solutions simple and focused:

- Scope: Don't add features, refactor code, or make "improvements" beyond what was
asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't
need extra configurability.

- Documentation: Don't add docstrings, comments, or type annotations to code you
didn't change. Only add comments where the logic isn't self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation for
scenarios that can't happen. Trust internal code and framework guarantees. Only
validate at system boundaries (user input, external APIs).

- Abstractions: Don't create helpers, utilities, or abstractions for one-time
operations. Don't design for hypothetical future requirements. The right amount of
complexity is the minimum needed for the current task.

Тобто сам Anthropic одночасно каже "не формулюй негативно" і рекомендує чисто негативне формулювання як офіційний спосіб виправлення відомої поведінкової проблеми (надмірне ускладнення рішень). Це не помилка документації. Запит до агента варто писати під конкретну модель і її відомі недоліки, а не за одним універсальним правилом.

"Проблема рожевого слона" — негативні інструкції як парадоксальний тригер

Пояснення цього ефекту аналогією до теорії іронічного контролю (ironic process theory) детально розбирає стаття "The Pink Elephant Problem: Why 'Don't Do That' Fails with LLMs": згадка небажаної дії в запиті підвищує її помітність, замість того щоб зменшити ймовірність її появи. Як доказову базу автор наводить повідомлення користувачів на Reddit.

Конкретний практичний випадок описує Sourcery у пості "Don't tell me what (not) to do!": команда намагалася відучити модель пропонувати рядки документації (docstrings) для функцій, які їх не мають, через пряму заборону в системному запиті. Жодне з негативних формулювань не спрацювало. Проблему вирішили не забороною, а переформулюванням задачі в класифікацію (чи в цієї функції вже є docstring) із фільтрацією небажаних відповідей поза моделлю.

Cloudflare будує запит до агента саме на запереченнях

У статті "How we built an AI code reviewer" Cloudflare описують систему спеціалізованих агентів-оглядачів коду. Один із них, агент безпеки (security reviewer), отримує явну вказівку зважати лише на те, що "exploitable or concretely dangerous" (експлуатовне або конкретно небезпечне), і для цього має не лише список того, що шукати, а й чіткий список того, що ігнорувати:

It turns out that telling an LLM what not to do is where the actual prompt engineering value resides. Without these boundaries, you get a firehose of speculative theoretical warnings that developers will immediately learn to ignore.

Cloudflare, «How we built an AI code reviewer»

Ключова метрика, яку вони наводять на підтримку цього: у продуктивному середовищі їхня система дає в середньому ~1.2 знахідки на один огляд: навмисно мало, бо вони свідомо обирають сигнал замість шуму. Важливо: це порівняння "негативний список є" проти "негативного списку немає"; у статті не показано, щоб вони перевіряли, чи те саме обмеження, сформульоване позитивно, дало б інший результат. Це якраз питання, яке перевіряється нижче.

Академічні дослідження

На відміну від думок практиків вище, це вже опубліковане наукове дослідження, і воно на боці обережності щодо заперечень. У дослідженні "Can Large Language Models Truly Understand Prompts? A Case Study with Negated Prompts" (Jang et al., 2022) показали інверсне масштабування: кілька моделей (GPT-3, InstructGPT, OPT) ставали гіршими в обробці заперечених інструкцій (наприклад, «не класифікуй це як X») зі збільшенням розміру моделі, усупереч звичайному тренду. Дослідження 2025 року (CVPR, vision-language моделі для зображень, відео та медичних знімків) незалежно підтверджує, що моделі систематично не розуміють заперечення у запитах. Одна з гіпотез щодо причини, яку висувають самі автори дослідження про інверсне масштабування: модель може сприймати слово заперечення як граматичну помилку і продовжувати генерувати текст так, ніби його немає, хоча самі автори наголошують, що це потребує додаткової перевірки.

Важлива обмовка: ці академічні роботи тестували моделі 2022–2025 років переважно на класифікаційних заданнях або мультимодальних моделях "зображення-текст", а не на сучасних агентних, інструкційно натренованих моделях у ролі агента, що оглядає код. Це контекст, а не спростування, саме тому нижче це перевірено емпірично на актуальній моделі й актуальному завданні, а не просто перенесено висновки старих досліджень на сьогодні.

Експерименти

Дві перевірки: спочатку контрольований тест на підготовлених прикладах із заздалегідь відомою "правильною" відповіддю, потім та сама перевірка на реальному робочому запиті до агента (prompt).

Синтетичний тест

Мета: відтворити ситуацію з Cloudflare і перевірити, чи заборона у формі "не позначай X" справді краще запобігає хибним спрацюванням, ніж відсутність межі взагалі, чи та сама межа, сформульована позитивно, без жодного слова заперечення. Три невеликі приклади коду (кожен з однією реальною вразливістю: SQL-ін'єкція, обхід авторизації або обхід каталогів і кількома деталями коду, які виглядають як проблема, але офіційно нею бути не повинні, далі — хибні проблеми) віддано трьом незалежним агентам (без спільного контексту) з трьома варіантами інструкції:

• A: лише позитив — лише список "що позначати", без жодних меж.
• B: негатив — той самий список + окремий блок "чого не позначати" (негативне формулювання).
• C: позитивне переформулювання — та сама інформація, подана як критерії включення ("позначай, лише якщо виконуються всі умови..."), без жодного заперечення.

Реальну вразливість знайшли всі три варіанти в усіх трьох прикладах (3/3), тобто жодне формулювання, включно з повною відсутністю інструкції, не завадило основній задачі. А от кількість інших знахідок на приклад коливалась від 1 до 5 без чіткого патерна між варіантами: десь найбільше зайвих коментарів давав варіант без будь-яких меж (A), десь, навпаки, найменше. Далі йдеться про одну категорію хибних проблем, де формулювання дало вимірювану різницю.

Де формулювання таки мало значення

Найскладніший тип хибної проблеми — це коли код виглядає незахищеним, хоча насправді перевірка просто винесена в інше місце. Наприклад: функція отримує дані від користувача і сама їх ніяк не перевіряє — на перший погляд це схоже на вразливість. Але ці дані насправді вже перевірені раніше, ще до того як потрапили в цю функцію, — просто іншим шматком коду. Агенту треба не просто побачити відсутність перевірки в цьому конкретному місці, а зрозуміти, чи вона взагалі потрібна тут, якщо вже є десь раніше. Ось де формулювання дало реальну різницю:

Явна заборона (B) не допомогла уникнути цю помилку краще, ніж повна відсутність будь-якої інструкції (A). Те саме правило, сформульоване позитивно, як умова ("познач цю проблему, лише якщо перевірки справді бракує") — без жодного слова заперечення — повністю усунуло цю помилку в усіх трьох прогонах. Решту категорій хибних проблем усі варіанти, включно з A, уникали на 100% — чіткий список найбільше потрібен саме для таких "важких" суджень, а не для очевидних категорій.

Перевірка на робочому запиті Mavka

Ту саму перевірку повторено на робочому запиті Mavka (prompt) для рев'ю коду: варіант із прямими запереченнями проти його позитивного переформулювання на наборі реальних багів. Кількість знайдених реальних багів була практично однаковою в обох варіантах — прибирання прямих заперечень не коштувало жодного пропущеного бага. Різниця проявилась лише в кількості побічних коментарів понад очікуваний баг — і тут чітка заборона не дала жодної стабільної переваги: там, де вона давала трохи менше зайвого, різниця була на рівні одного коментаря, а не стабільною закономірністю. Для цього типу інструкцій (короткі поведінкові запобіжники, а не судження) формулювання не впливає на результат: заборону можна лишати як є, а нові інструкції з нуля так само вільно писати позитивно.

Що це означає: три типи інструкцій, а не одне правило

Дані з обох експериментів і з літератури складаються не в протиріччя, а в чітку картину: тип інструкції визначає, чи негативне формулювання коштує щось.

Тип 1. Поведінкова заборона проти відомої помилки. "Не створюй дублікати файлів", "не підганяй рішення під тестові значення", "не ускладнюй надмірно", "не вигадуй, не прочитавши код" — дискретна, перевірювана після факту дія. Негативне формулювання працює нормально. Це власна практика Anthropic, і це підтверджено на реальному робочому запиті до агента — вимірюваної різниці в шумі чи якості результату між формулюваннями не було. Модель звіряється з цим уже після того, як текст згенеровано, як з пунктом чек-листа, а не бореться з бажанням порушити правило по ходу самого написання.

Тип 2. Судження в задачі класифікації. "Чи це варто позначити" — де відповідь залежить від оцінки чогось третього ("чи це вже перевірено в іншому місці коду", "чи цей ризик взагалі реалістичний"). Точний сценарій Cloudflare. Негативне формулювання — слабке місце. У синтетичному тесті вище воно не перевершило повну відсутність інструкції. Позитивний критерій включення виявився надійнішим — ймовірно тому, що фокусує модель на оцінці умови ("чи виконано критерій"), а не на тому, щоб стримати висновок, який вона вже внутрішньо "згенерувала".

Тип 3. Стилістичне/генеративне формування виводу. Формат, тон, обсяг, markdown чи проза — відкрита генерація без чіткої точки зупинки для перевірки. Позитивне формулювання краще — тут думка Anthropic, аргумент "рожевого слона" і академічні дані про заперечення сходяться: заборона розмивається в довгій відкритій генерації й може навіть підвищити помітність небажаного патерну.

Практичний висновок для продукту рев'ю коду: список "чого не позначати" вартий існування (він явно ріже шум — і без нього, і з негативним формулюванням модель час від часу помилково позначає хибну проблему), але там, де межа — це судження про третю сутність (чи це вже перевірено в іншому місці, чи ризик взагалі реалістичний), варто спробувати переформулювати саме ці пункти як позитивний критерій включення ("познач, лише якщо..."), а не залишати їх як "не позначай...". Для очевидних категорій (стиль, значення, схожі на паролі чи ключі доступу, а насправді публічні) формулювання, схоже, взагалі не критичне — модель і так з ними добре справляється.