Чому цей тест важливий

ШІ-асистенти для написання коду часто дозволяють командам просто закинути файл із «правилами» у репозиторій, очікуючи, що модель дотримуватиметься його вказівок у кожному запиті. На практиці модель може взагалі не побачити файл або побачити його, але проігнорувати вміст. Нещодавній експеримент із Claude Code продемонстрував обидві проблеми. Інструмент мовчки проігнорував файл AGENTS.md розміром 72 КБ; коли той самий файл було перейменовано на CLAUDE.md, асистент завантажив його, що збільшило кількість токенів у кожному запиті. Цей додатковий бюджет токенів збільшує затримку (latency) та вартість, а також може призвести до перевищення лімітів моделі.

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

Три запитання, які варто поставити

  1. Налаштовано (Configured) — Чи розміщено файл там, де його шукає асистент? Різні інструменти мають жорстко прописані шляхи або конвенції щодо імен файлів; невідповідність означає, що файл ніколи не потрапить у конвеєр промптів (prompt pipeline).
  2. Завантажено (Loaded) — Чи надає асистент будь-яке підтвердження того, що він отримав файл? Хеш може підтвердити ідентичність файлу на диску, але лише слід завантаження (наприклад, рядок у логах або зміна кількості токенів) доводить, що модель дійсно його побачила.
  3. Корисно (Useful) — Чи покращує наявність файлу результат виконання завдання? Завантажений файл, який збільшує кількість токенів, але не змінює результат, є суцільною втратою ресурсів.

Проведення тесту

Процедура навмисно максимально спрощена, щоб її можна було повторити на будь-якій платформі.

  1. Створіть помітне правило — Напишіть просту інструкцію, результат якої можна відстежити. Наприклад: «Перед редагуванням виведи список рівно з двох файлів». Ефект від правила можна перевірити у відповіді асистента.

  2. Перевірте версію інструмента та модель — Відкрийте нову сесію, зафіксуйте рядок версії та ідентифікатор моделі. Різні версії можуть використовувати різні назви файлів для розпізнавання.

  3. Виконайте два заходи Запуск А: Використовуйте назву файлу, яку інструмент не розпізнає (наприклад, AGENTS.md). Запуск Б: Використовуйте стандартну назву файлу для цього інструмента (наприклад, CLAUDE.md).

    Зафіксуйте:

    • Хеш-суму вихідного файлу (щоб довести, що вміст на диску не змінювався).
    • Точний шлях, що використовувався.
    • Будь-які докази завантаження файлу в логах асистента (збільшення кількості токенів, явне повідомлення «loaded X.md» тощо).
    • Кількість токенів для кожного запиту.
    • Результат завдання (чи вивів асистент список рівно з двох файлів?).

Якщо під час Запуску Б правило виконується, а кількість токенів зростає на очікувану величину, це означає, що файл і завантажено, і він є корисним. Якщо правило ігнорується, попри збільшення кількості токенів, це означає, що файл зчитується, але парсинг промпту моделлю відкидає інструкцію. У такому разі додавання тексту до файлу не допоможе; замість цього перенесіть правило у жорстко запрограмовану політику (policy gate) або тестову оболонку (test harness).

Що показують дані

Випадок із Claude Code продемонстрував суттєву розбіжність між конфігурацією та завантаженням. Файл розміром 72 КБ існував, мав правильний хеш і був синхронізований із репозиторієм, проте асистент ніколи до нього не звертався. Перейменування файлу на стандартний CLAUDE.md ініціювало завантаження, але також призвело до значного збільшення кількості токенів. Кожен зайвий токен споживає обчислювальні цикли та може призвести до перевищення лімітів запитів (rate limits).

Триетапний тест виявляє такі приховані витрати до того, як вони стануть перешкодами для роботи в продакшені. Фіксуючи дельту токенів, команди можуть вирішити, чи переваги правила варті його ціни.

Висновок

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