Штучний інтелект і граблі: Як перестати отримувати сміття і не збожеволіти

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

AI

Логин Свят

7/1/20261 min read

Штучний інтелект і граблі: Як перестати отримувати генеративне сміття і не збожеволіти

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

ШІ робить це настільки впевнено, що виникає бажання йому повірити. Але не варто — швидше за все, вам щойно згенерували добірне сміття. Ось 5 причин, чому ваш AI-помічник іноді поводиться як дуже самовпевнений джуніор, і головне — як це нарешті виправити.

1. ШІ не вміє читати думки (і в нього пам'ять як у золотої рибки)

Коли ви сідаєте за задачу, у вас в голові вже є контекст, тиждень роздумів і домовленості з колегами. А ШІ приходить у чат абсолютно пустим. Він як головний герой фільму «Мементо», який нічого не пам'ятає і мусить бити татуювання, щоб хоч якось функціонувати. Все, що для нього існує — це текст у поточному вікні чату

Найгірше те, що коли ШІ чогось не знає, він нізащо не зізнається. Він буде вгадувати! Моделі поводяться як студенти, що не вивчили предмет на іспит: за неправильну відповідь і за "я не знаю" дають нуль балів, тому математично вигідніше нести впевнену нісенітницю — а раптом вгадає?

Як НЕ треба: "Напиши мені код для сторінки логіну." (Модель не знає вашого стеку, проєкту та попередніх рішень, тому просто вигадає щось абстрактне і непотрібне).

Як треба (Злам мотивації): "Напиши сторінку логіну для проєкту Х. [TAG: INTERVIEW_MODE] Спершу постав мені уточнювальні питання, поки не збереш достатньо контексту. [TAG: PERMISSION_TO_FAIL] Якщо чогось не знаєш або не впевнений — не вигадуй. Даю тобі прямий дозвіл сказати 'Я не знаю'".

2. Ласкаво просимо в «Зону тупості» (The Dumb Zone)

Ви коли-небудь пробували уважно зробити код-рев'ю на пул-реквест із 150 файлів? На якомусь етапі ви просто втомлюєтесь і починаєте сліпо клікати "Approve". ШІ робить те саме! Якщо ви звалюєте всю переписку, код і купу плагінів в один нескінченний чат, ви заганяєте модель у так звану Dumb Zone (зону тупості).

Через ефект «загубився посередині» (Lost in the Middle) модель прекрасно пам'ятає початок і кінець чату, а всередині просто ігнорує текст

Як НЕ треба: Підключити 10 розширень (які забивають вікно службовим текстом), завантажити туди половину репозиторію і вести один нескінченний чат, змушуючи модель постійно переписувати код.

Як треба (Spec-Driven Development): Одна задача = один свіжий контекст.

  1. Попросіть модель скласти стислий конспект (Markdown-специфікацію) вашої роботи.

  2. Відкрийте новий чистий чат.

  3. Головну думку покладіть на самий початок, а найважливішу інструкцію — продублюйте в самому кінці промпту (там, де ШІ найуважніший)

Для чебе ще відкрив, коли ви бачите що один чат вже переповнений контекстом, і щоб модель знала в новому чаті все те що ви робили раніше і щоб не писати все заново - попросіть просто зробити самері конетксту в минулому чаті і перемістіть це самері в новий чат.

3. Синдром «Ну, на вигляд начебто працює»

ШІ — це той самий хитрий підрядник, який зупиняє роботу рівно тоді, коли вона виглядає готовою. Код гарно оформлений, синтаксис правильний... але ШІ не натискає кнопки і не компілює його!. Статистика невблаганна: понад 15% згенерованих ШІ комітів мають критичні баги, і 22% з них так і залишаються в коді назавжди.

Як НЕ треба: Подивитися на згенерований код і подумати: "О, красиво". Або ще гірше — спитати в самої моделі: "Ти впевнена, що цей код працює?". Просити ШІ оцінити власну роботу — це як дозволити студенту самому перевірити свою курсову. У моделі в цьому ж чаті ті самі сліпі зони.

Як треба (Цикл верифікації): Не вір на слово — вимагай вивід тесту!. Напишіть: "Покажи логи тесту або компілятора. Якщо тести впали — виправляй, поки не позеленіють". Або використайте Agent Reviewer — окрему модель з чистим вікном, яка перевірить код свіжим поглядом.

4. Оцінка "на око", або «Сьогодні зірки зійшлися»

Як ви міряєте якість відповідей? Прочитали, здалося, що «начебто годиться»? (Vibes). Ваші відчуття — це не метрика, особливо коли відповідей стає 300 і вони змінюються від кожної коми в промпті.

Як НЕ треба: Оцінювати генерацію емоційно, намагаючись вловити "тон" чи "повноту" без чітких правил, і сподіватися, що зміна промпту нічого не зламала в іншому місці.

Як треба (EVALS та LLM as a Judge): Зберіть власну колекцію факапів ШІ (error analysis) і перетворіть їх на жорсткі бінарні критерії (Так/Ні). Ніяких оцінок «від 1 до 5». Далі найміть іншу незалежну модель-суддю, яка автоматично проганятиме тести і видаватиме конкретну цифру якості "До" і "Після".

5. День бабака (Навчання на помилках, якого немає)

Ви спіймали ШІ на помилці, насварили його, пояснили «у нас так не роблять», він виправився. А наступного дня в новому чаті він робить абсолютно те саме.

Як НЕ треба: Виправляти наслідок (симптом) у поточному чаті і бігти далі. Наступного разу ви знову наступите на ті ж граблі.

Як треба (Механізми пам'яті): Виправте причину один раз. Запишіть правило у глобальну пам'ять (наприклад, файл claude.md або agent.md), який автоматично завантажується в кожну нову сесію. Але обережно: не роздувайте цей файл! Якщо він перевалить за 1000 рядків, модель знову впаде в «Зону тупості». Регулярно чистіть його і тримайте в межах 200 рядків.

Підсумок: Збираємо інженерного Мегазорда

Отже, замість того, щоб сваритися з монітором, просто налаштуйте процес. Це один великий ланцюг, де кожна ланка підпирає наступну: Дали контекст ➔ є чим керувати ➔ покерували ➔ є що перевіряти ➔ перевірили ➔ є що міряти ➔ поміряли ➔ є що накопичувати в пам'ять.

Не хапайтеся за все одразу, сам по собі знаю і нажать продовжую так і робити, бо така позиція від якої вимагають одразу все)))) Але сам раджу, якщо ви звичайно не можете витримати напругу багатозадачності одночасно, а так - візьміть одну проблему, яка бісить вас найбільше, і застосуйте інженерне рішення вже на наступній задачі. І хай прибуде з вами чистий код!