Вибір контексту: контекст як бюджет

1. «Дайте весь проєкт» робить результат гіршим

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

Контекст — це бюджет якості. Увага моделі обмежена; чим точніше ви її витратите, тим вищий шанс, що Claude побачить потрібний причинно-наслідковий зв’язок, а не піде блукати. Не максимальний, а достатній.

Погано:
"Прочитай увесь проєкт і полагодь логін."

Краще:
"Розберіть баг із білим екраном після неправильного пароля.
Працюйте лише з auth-модулем, наявним тестом і фрагментом логу нижче.
Спочатку поясніть імовірну причину, потім запропонуйте мінімальну зміну."

У другому випадку ви не жадібничаєте — ви заздалегідь звужуєте область пошуку й захищаєте проєкт від корисного, але небезпечного розмаху.

2. Джерела контексту: що допомагає, а що заважає

Помилка не в незнанні корисних джерел, а в невмінні відрізнити корисне від обов’язкового і зайвого. У сесію звалюється все: факт, гіпотеза, лог, README, .env, коментар із тікета двотижневої давності.

Тримайте цю таблицю в голові під будь-яку задачу:

Тепер подивімося на другу половину картини — що в контекст часто кладуть даремно.

Тут є важливий нюанс. Корисні джерела не означають, що їх потрібно давати всі одразу. Якщо ви оновлюєте документацію по одному endpoint у Commerce OS, вам, найімовірніше, не потрібні stack trace і лог помилки. Якщо ви виправляєте падіння під час логіну, вам майже напевно потрібні лог і reproduction, а от старий маркетинговий README взагалі ні до чого. Джерело контексту цінне не саме по собі, а лише в зв’язці із задачею.

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

3. Контекст — це не доказ

На цьому місці багато хто починає плутати дві різні речі. Контекст — це те, з чим Claude працює. Доказ, або evidence, — це те, що підтверджує ваші твердження й допомагає перевірити результат. Ці шари перетинаються, але це не одне й те саме. Якщо їх не розрізняти, модель дуже швидко починає звучати впевнено там, де насправді просто здогадується.

Уявіть короткий запис у вашому EVIDENCE_LOG.md для Commerce OS:

Проблема: після неправильного пароля UI показує білий екран.
Факт: помилку відтворюється стабільно.
Докази:
- скриншот порожньої сторінки
- stack trace з браузера
- failing тест AuthFlowTest.invalid_password
Гіпотеза:
- можливо, проблема в рендерингу помилки, а не в SessionService

Оце вже зрілий інженерний матеріал. Тут факт відділений від гіпотези. Лог відділений від інтерпретації. Якщо ж ви просто напишете Claude: «Схоже, проблема в backend, полагодь», ви покладете в контекст не доказ, а припущення. Модель дуже охоче підхопить його як робочий напрямок і може побігти не туди.

Різниця особливо помітна в діалогах такого типу:

Слабкий варіант:
"Схоже, SessionService ламає логін. Виправ."

Сильний варіант:
"При неправильному паролі UI показує білий екран.
Нижче stack trace і failing тест.
Перевірте, чи справді проблема в SessionService, перш ніж змінювати код."

У другому варіанті ви не забороняєте Claude думати. Ви просто не даєте йому прийняти неперевірене припущення за істину. А це і є доросла робота з контекстом.

Корисно запам’ятати просту формулу. Контекст відповідає на запитання «з чим працювати», а доказ — на запитання «чому ми взагалі так думаємо». Якщо в сесії є лише перше, відповіді будуть швидкими, але хиткими. Якщо є лише друге без конкретної області коду, відповіді будуть обережними, але розмитими. Потрібні обидва шари.

4. Відбір контексту: простий порядок дій

Хороший відбір контексту рідко починається з файлів. Він починається із задачі. Поки ви не розумієте, який результат взагалі потрібен, ви не зможете зрозуміти, які матеріали справді допоможуть. Тому корисно триматися одного й того самого порядку. Він доволі нудний, зате чудово економить час і нерви.

Ось найробочіший каркас:

Мета задачі → зачеплена область → evidence → обмеження → лише потім додаткові матеріали

Можна розкласти його в таблицю й користуватися як мініперевіркою перед початком сесії:

Цей порядок важливий з однієї причини: він не дає почати з хаосу. Якщо ви йдете від мети, то швидко розумієте, що половина матеріалів взагалі зайва. Якщо ж починаєте з файлів, майже неминуче вантажите в сесію все, що трапилося під руку.

Особливо корисний другий крок — зачеплена область. Припустімо, ви ще не знаєте точних файлів. Це нормально. Тоді правильна дія — не вантажити увесь проєкт, а спочатку попросити Claude допомогти знайти кандидатів на affected area. Наприклад, так:

Знайдіть, які файли, класи й тести, найімовірніше, відповідають
за обробку помилки неправильного пароля в Commerce OS.
Поки без змін у коді. Дайте лише кандидатів та evidence.

Це вже контекстна дисципліна. Ви не вдаєте, що знаєте все. Але й не влаштовуєте моделі екскурсію по кожному каталогу проєкту.

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

5. Commerce OS: білий екран після неправильного пароля

Тепер давайте подивимося, як усе це виглядає на тому самому багу в Commerce OS. Після неправильного пароля користувач замість зрозумілого повідомлення отримує білий екран. Це дуже хороша задача для теми про відбір контексту: тут легко побачити різницю між «дати все підряд» і «відібрати мінімально достатній набір».

Спочатку зафіксуємо суть у короткому фрагменті TASK_SPEC.md:

## Мета
Виправити білий екран після неправильного пароля.

## Область змін
Лише auth-модуль і пов’язані тести.

## Не-цілі
Не змінювати SSO, не чіпати payments, не додавати залежності.

Уже тут видно: увесь проєкт нам не потрібен, потрібен auth-модуль. Отже, як основний контекст підійдуть:

• src/auth/LoginController.java
• src/auth/SessionService.java
• src/auth/AuthFlowTest.java
• короткий фрагмент логу або stack trace
• reproduction steps із тікета

А ось що нам точно не потрібно на старті:

• payments/
• orders/
• dashboard/
• повний application.log
• production config із секретами
• будь-яка несуміжна документація

Уявімо, що лог виглядає так:

2026-05-12 10:14:21 ERROR LoginPage
TypeError: cannot read property "message" of null
at renderLoginError (LoginPage.tsx:48)
at handleFailedLogin (LoginController.java:73)

Це вже добрий evidence: у нас є спостережувана поведінка й точка входу в код. Тепер можна зібрати сильний запит для Claude:

Нижче задача і мінімальний контекст по багу в Commerce OS.

Задача:
Після неправильного пароля UI показує білий екран.

Використовуйте лише:
- src/auth/LoginController.java
- src/auth/SessionService.java
- src/auth/AuthFlowTest.java
- фрагмент логу нижче

Обмеження:
- не змінювати public API
- не чіпати SSO
- не додавати залежності

Спочатку поясніть імовірну причину та вкажіть,
чи достатньо цього контексту для мінімального виправлення.

Тут добре ось що. Ви не наказуєте «негайно лагодити». Спочатку ви перевіряєте, чи вистачає відібраного контексту. Це корисна звичка. Іноді модель чесно відповідає: «Потрібен ще один файл». І це чудовий результат. Отже, відбір контексту спрацював: ви почали з вузького набору та розширюєте його лише за підтвердженої потреби.

Якби замість цього ви дали увесь src/ і лог на тисячу рядків, у моделі було б набагато більше приводів розповзтися. Вона могла б, наприклад, вирішити, що проблема взагалі в глобальному error handler, у фронтенд-шарі цілком або в невідповідності формату помилок між модулями. Теоретично це можливо. Практично для цієї задачі — шкідливо.

Невелика самоіронія тут доречна: Claude і справді любить допомагати. Іноді навіть занадто. Якщо дати йому весь проєкт, він із серйозним виглядом врятує не лише логін, а й вашу архітектуру, стиль логування, правила іменування і, здається, внутрішню гармонію команди. Тому вузький контекст — це не недовіра до моделі. Це захист проєкту від надмірної турботи.

6. Один Claude, різний контекст для різних задач

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

Ось простий орієнтир для трьох типових задач у Commerce OS:

Зверніть увагу на другу строку. Якщо ви оновлюєте документацію по refund endpoint, лог помилки може бути взагалі марним. Набагато важливіше побачити поточну реалізацію контролера, наявний API test і ту частину документації, яку потрібно синхронізувати. Це інша задача, отже й бюджет якості витрачається інакше.

Або візьмімо невелику feature: наприклад, додати зрозуміле повідомлення про помилку у формі логіну. Тут stack trace вже може не знадобитися, якщо поведінка очікувана і задача формулюється як UX-покращення. Натомість корисним буде схожий компонент, де помилки вже оформлені правильно. Тобто в контекст піде не лог, а хороший зразок із поточного проєкту.

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

7. Робочий шаблон запиту для чистої сесії

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

Ось шаблон, який можна використовувати майже без змін:

Мета:
...

Поточна поведінка:
...

Очікувана поведінка:
...

Використовуйте як контекст лише:
- ...
- ...
- ...

Докази:
- ...
- ...
- ...

Обмеження:
- ...
- ...
- ...

Якщо цього контексту недостатньо, не розширюйте scope самі.
Спочатку скажіть, якого саме файлу або сигналу бракує і навіщо.

Сила цього шаблону не в красі. Сила — у двох звичках, які він формує. По-перше, ви заздалегідь розрізняєте мету, evidence та обмеження. По-друге, дозволяєте контексту розширюватися лише за запитом, а не самочинно.

Дуже важливо, що такий підхід не робить вас «жадібними» до інформації. Іноді Claude справді потрібен ще один файл. Іноді потрібен ще один test case. Іноді потрібен невеликий шматок config. Це нормально. Хороший відбір контексту — не про мінімалізм за будь-яку ціну. Він про усвідомлене розширення. Спочатку ви даєте мінімально достатній набір. Потім, якщо evidence показує нестачу, додаєте ще один шар. Але не раніше.

Якщо ви почнете використовувати такий шаблон хоча б на половині задач, швидко помітите приємний ефект. Сесії стають спокійнішими. Відповіді — менш розпливчастими. Diff — уже не таким широким. А головне, з’являється відчуття, що ви не «переконуєте AI не сходити з глузду», а просто керуєте інженерною роботою нормальним дорослим способом. І це, чесно кажучи, набагато приємніше, ніж потім пів години читати, чому для виправлення логіну потрібно терміново перебудувати архітектуру світу.