Сцену варто впізнати в обличчя, тому почнемо з неї. Ви дописали гру, рахунок після перезапуску обнуляється, і ви питаєте агента:
Чому після перезапуску втрачається рахунок?Відповідь приходить спокійна і доладна:
Рахунок у проєкті вже зберігається, просто запис ніде не увімкнено.
Досить змінити одне налаштування, і результат переживе перезапуск.Ви йдете перевіряти. Ні налаштування, ні збереження рахунку в проєкті немає і не було - ні рядка, ні натяку. Відповідь читалася як розбір вашого коду, а була припущенням про те, як зазвичай влаштовані такі проєкти.
А перед цим не прозвучало ні паузи, ні застереження. Інтонація точнісінько та сама, що й у всіх попередніх відповідях, які виявилися правильними. Інструмент при цьому справний, і модель не стала гіршою, ніж була вчора.
Причина в тому, як відповідь взагалі з'являється. Модель не дістає готовий факт зі сховища - вона добирає ймовірне продовження вашого тексту, шматок за шматком. А ймовірне і правильне це різні речі, особливо коли йдеться про ваш проєкт, якого модель не бачила. Вигадані, але правдоподібні подробиці прийнято називати галюцинаціями.
Далі - де розставлені пастки, чому помилка завжди має спокійний тон і які три перевірки закривають більшу частину таких випадків.
Що модель бачить у вашому запиті
Пастка тут найпростіша з усіх: здається, що модель дивиться на ваш проєкт. Насправді вона дивиться тільки на те, що їй передали, а передають їй ось що:
- Вбудовані знання. Закономірності, які закріпилися в параметрах моделі під час навчання. Не картки з фактами і посиланнями, а числа, тому навіть знайомий факт модель може відтворити неточно. І вони мають межу в часі: про бібліотеку, яка вийшла пізніше, модель знає лише стільки, скільки їй показали.
- Поточна розмова. Ваш запит, історія листування, файли, які агент прочитав, вивід команд, які він запустив.
- Пам'ять застосунку. Те, що збережено в окремі файли й підкладається в розмову на початку наступної сесії. У Claude Code це
CLAUDE.md, який пишете ви, і auto memory, куди агент записує нотатки сам. - Зовнішні джерела. Документація, пошук, база даних, файли проєкту - усе, чого в навчальних даних могло не бути або що відтоді змінилося.
Три останні приходять одним і тим самим шляхом: щоб вплинути на відповідь, вони мають опинитися в поточній розмові. Сама по собі модель у проєкт не заглядає.
Звідси наслідок, який варто перебудувати в голові один раз. Файл, який ніхто не відкривав, для моделі не існує. Поки його текст не потрапив у розмову, запитання "де в нас обробляється авторизація" чесніше читати як "як зазвичай називають такий файл у подібних проєктах". Відповідь ви отримаєте в обох випадках, і вигляд вона матиме однаковий.
Поруч живе пастка дрібніша, зате прикра. Прочитаний файл лишається в розмові таким, яким його прочитали. Ви поправили рядок у себе в редакторі, а в історії розмови лежить стара версія. Claude Code позначить, що файл змінився, але чи перечитає його агент, вирішує вже модель. Правили руками посеред розмови - надійніше прямо попросити перечитати.
Claude Code спочатку читає проєкт і запускає команди, а відповідає потім. У відповіді зазвичай видно, які файли він відкрив і що запускав. Якщо відповідь про ваш код з'явилася раніше, ніж агент хоч щось прочитав, ви дивитеся на припущення про типовий проєкт, а не на розбір вашого.
Чому формулювання змінює результат
З усього, що потрапляє в розмову, ваш запит - єдине, що ви пишете самі. Тому дрібниці в ньому і вирішують: переставили пару слів, додали уточнення - відповідь поїхала в інший бік. Це не примха інструмента.
Тут легко заплутатися, тому проговорю окремо. Той самий запит двічі теж дає різні відповіді: у відповідь іде не обов'язково найімовірніший варіант продовження, у генерації є налаштування, які задають, наскільки охоче береться варіант нижче. Напрошується запитання: якщо відповідь і так гуляє, до чого тут мої слова. Різниця в тому, що саме гуляє. Розкид між однаковими запитами це шум навколо одного й того самого вибору: формулювання розійдуться, напрямок залишиться попереднім. А слова в запиті рухають сам напрямок, і роблять це стійко.
Розпливчасте прохання працює найгірше. Воно лишає моделі вибір, а вибирає модель найімовірніше взагалі - усереднене з усього, що вона бачила. Візьміть просте "скороти текст". На скільки - на відсоток, на третину, вдвічі? Що можна викинути, а що чіпати не можна? На жодне з цих запитань у проханні відповіді немає, отже, відповідати буде модель, і формально вона матиме рацію. А "скороти опис на 30%" або "скороти опис до 300 символів" не лишають їй вибору там, де вибір ваш.
Добре видно на парі запитів про одне й те саме. "Полагодь сортування" лишає відкритим усе: який список, за яким полем, що взагалі вважати поломкою. А ось друге формулювання не лишає відкритим майже нічого:
У списку замовлень дати йдуть від старих до нових, потрібно навпаки.
Спочатку покажи файл і рядок, де задано порядок сортування, потім пропонуй правку.Воно довше саме настільки, наскільки перше вимагало здогадки. І заразом робить половину перевірки за вас: агент приносить місце в коді ще до того, як ви про нього спитали.
Висновок простий: що менше в запиті свободи, то менше у відповіді здогадки. Ідеться не про чарівні заклинання, а про звичайну річ - або рамку задаєте ви, або її оберуть за вас.
Впевнений тон не дорівнює факту
А ось і головна пастка. Модель не має окремої інтонації для "це я точно знаю" і окремої для "це я щойно добудувала": обидві фрази збираються одним і тим самим способом і виходять однаково спокійними. Зв'язок тут не те щоб нульовий, але користі з нього немає: упевненість моделі завищена завжди, тому за тоном ви не відрізните перевірене від добудованого.
У звичайному тексті дивне твердження ріже око, і ви пригальмовуєте самі. У коді цей захист не спрацьовує: імена здаються правильними, конструкції знайомі, а справжній метод бібліотеки від зібраного за аналогією на око не відрізнити, якщо не знаєш бібліотеку напам'ять. Тому промах частіше спливає не під час читання, а під час запуску.
Ім'я до того ж рідко буває вигадане з нуля. У розборі згенерованого коду, де шукали посилання на бібліотеки, яких не існує, більше третини таких імен виявилися склейкою двох справжніх. Звідси й відчуття достовірності: частини імені ви десь бачили, просто не в цьому поєднанні.
Чотири випадки, які впізнаються з першого разу, якщо знати, що шукати:
| Який це має вигляд | Що сталося | Чим ловиться |
|---|---|---|
| названо прапорець, якого команда не має | модель зібрала рядок за звичною формою, тому прапорець і здається справжнім | довідка команди або її документація |
| названо файл, функцію або поле конфіга, яких у проєкті немає | ім'я здається типовим для такого проєкту, але проєкт ніхто не читав | пошук у проєкті, прохання показати рядок |
| упевнено розказано, як влаштований ваш проєкт | у розмові не було жодного файлу проєкту, тому описано типовий | спитати, які файли він відкрив до відповіді |
| сказано "готово", а команда не запускалася | звіт зібрано з тексту завдання, а не з результату запуску | запустити самому і подивитися вивід |
Спільне в усіх чотирьох одне: відповідь звучить як результат роботи, хоча роботи за нею не стояло.
З останнім випадком варто розібратися окремо, бо скидається він на обман, а обману там немає. Агент зупиняється, коли робота здається зробленою. Якщо запустити йому нічого, "здається зробленою" - єдиний доступний сигнал, і контуром перевірки стаєте ви.
Це має вимірну ціну. В одному розборі агентських логів хибні "готово" дали майже половину всіх невдач. А там, де стан перевірявся незалежно від звіту самого агента, такі випадки майже зникали. У цьому і сенс другої перевірки з наступної секції: вона підставляє замість звіту те, що можна подивитися своїми очима.
Лишається питання, чому модель узагалі воліє добудувати, а не зізнатися. Річ у тім, як її вчили і як оцінювали. Уявіть тест із варіантами відповіді, де за порожній бланк гарантований нуль, а за навмання позначений - шанс на бал. Мовчати в такій системі невигідно завжди, і відповідати за будь-якої непевності розумно. Людина потім перевчається на живих завданнях, де неправильна відповідь обходиться дорожче за чесне "не знаю". Модель такого перевчання не має.
Попросити модель чесно попереджати, коли вона не впевнена, допомагає - але це теж текст, зібраний тим самим механізмом. Як додатковий сигнал згодиться, як заміна перевірці ні.
Інструменти зменшують сліпі зони
Тут корисно розвести два слова, які в розмові зазвичай звалюють докупи. Модель уміє лише одне: отримати розмову і видати продовження. Агент - це програма навколо моделі, яка має інструменти: читання файлу, запуск команди, правка проєкту.
А тепер деталь, від якої залежить, де саме буває помилка. Інструменти обирає не програма. Модель у своїй відповіді просить відкрити такий-то файл або запустити таку-то команду, а програма це прохання перевіряє, виконує і повертає результат назад у розмову. Рішення ухвалює модель, дію виконує програма. Отже, схибити може і саме рішення: не той файл, не та команда, не той тест.
Різниця все одно величезна. Поки файл не відкрито, відповідь про нього будується за пам'яттю про схожі проєкти. Щойно файл прочитано, а тест прогнано, у розмові з'являється факт: ось вміст, ось вивід. Це вже не спогад, а перевірка, і якість відповідей після неї помітно інша.
Звідси прийом, який коштує одного рядка на початку розмови:
Спочатку знайди і покажи, де це лежить у проєкті, і тільки потім пояснюй.Сліпі зони при цьому звужуються, але не зникають. Агент може відкрити сусідній файл замість потрібного, витлумачити вивід команди по-своєму або зупинитися на першому правдоподібному поясненні, не дійшовши до справжньої причини. Усе це я бачив, і не раз. Тому зовнішній сигнал - вивід тесту, текст документації, вміст файлу - важить більше, ніж найупевненіше міркування без опори.
Три перевірки, які коштують хвилини
Добра новина в тому, що ловити такі промахи можна майже без зусиль. Усе зводиться до однієї розвилки.
Дивитися тут потрібно не на те, наскільки переконливо написано, а на те, чи є у відповіді за що зачепитися: конкретний файл, конкретний рядок, команда з її виводом. Немає опори - отже, перед вами поки що гіпотеза, а не результат. Багато відповідей такими і починаються, питання тільки в тому, що ви зробите далі.
Далі три перевірки. Кожна займає менше хвилини, і всі три одразу потрібні рідко.
- Попросити показати місце. Не "поясни детальніше", а "покажи файл, рядок і сам фрагмент". Якщо місця немає, це з'ясується одразу.
- Відкрити або запустити результат самому. Сторінку в браузері, команду в терміналі, тест у проєкті. Звіт про роботу і робота - не одне й те саме.
- Звірити твердження про інструмент із самим інструментом. Команда має вбудовану довідку, бібліотека - документацію. Названий прапорець або ключ конфіга там або є, або немає, і з'ясовується це за півхвилини. З методом бібліотеки суворіше: у документацію потрапляє не все, тому його відсутність - привід перепитати, а не вирок.
Замість суперечки з відповіддю попросіть опору напряму:
Покажи файл і рядок, де це описано.
Якщо такого місця в проєкті немає, скажи прямо, що це припущення.Два рядки, які варто тримати під рукою. Перший відправляє агента в проєкт замість відповіді за пам'яттю про схожі. Другий дає йому вихід: сказати, що місця немає, виявляється дешевше, ніж добудувати відповідь до правдоподібної.
Для звіту "готово" працює те саме прохання, тільки про запуск: "покажи команду, яку ти запустив, і її вивід цілком".
Гарантією це не стає: фраза "це припущення" зібрана тим самим механізмом, що й усе інше. Шанс промаху вона знижує, перевірку не замінює.
І одразу застереження, щоб не лишилося неправильного присмаку. Перевіряти - не означає не довіряти інструменту. Свій власний diff ви теж перечитуєте перед комітом, хоча писали його самі. Тут те саме, тільки привід трохи вагоміший.
Що це означає для роботи з Claude Code
Що з усього цього випливає безпосередньо за клавіатурою:
- відповідь із посиланням на файл, рядок або вивід команди перевіряється за секунди. Відповідь без них перевірити нічим: її лишається тільки перечитати і погодитися;
- дайте агентові прочитати потрібне до того, як поставите запитання. Один зайвий крок прибирає цілий клас промахів;
- за впевненістю судити не можна: вона завищена незалежно від того, стоїть за словами перевірка чи здогадка;
- "звучить правильно" і "працює правильно" - різні речі, і розрізняє їх тільки запуск;
- що більша ціна помилки, то раніше в розмові має з'явитися щось зовнішнє: тест, документація, реальний файл. На дрібній правці вистачить погляду на diff;
- якщо агент помилився, скажіть йому про це фактом, а не оцінкою. "Такої функції в проєкті немає, ось що лежить у теці" рухає роботу далі, "ти знову все вигадав" не рухає нікуди. І тримайте на думці: на впевнене заперечення агент радше підлаштується, ніж стане сперечатися, навіть коли рацію мав він. Згода агента це не підтвердження вашої правоти.
Механізм, який іноді впевнено помиляється, при цьому лишається вкрай корисним. Знати про його межі потрібно саме для того, щоб не витрачати час на здивування і одразу переходити до перевірки.