Клод і Codex стають все дурнішими? Тому що ваш контекст занадто об'ємний

Автор: sysls

Переклад: Deep潮 TechFlow

Вступне керівництво Deep潮: розробник-блогер sysls із 2,6 мільйонами підписників написав довгу практичну статтю, яку перепостили 827 разів і поставили 7000 лайків. Її суть зводиться до однієї фрази: ваші плагіни, системи пам’яті та різноманітні harness-и швидше за все заважають вам. Ця стаття не про великі ідеї, а про конкретні, застосовні принципи, які були узагальнені з реальних виробничих проектів — від контролю контексту, обробки схильності AI до догоджання, до визначення умов завершення задачі. Це, мабуть, найчіткіше пояснення практики роботи з Claude/Codex.

Повний текст нижче:

Вступ

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

Ви думаєте, що проблема у вашому harness, плагінах, терміналі — що завгодно. Ви використовуєте beads, opencode, zep, ваш CLAUDE.md налічує 26 000 рядків. Але що б ви не робили, вам все одно здається, що ви все далі від раю, тоді як інші граються з ангелами.

Саме цю статтю ви й чекали.

До речі, я не маю жодних особистих інтересів. Я кажу, що CLAUDE.md також включає AGENT.md, і що Claude — це не тільки Codex, а обидва я активно використовую.

За останні кілька місяців я помітив цікаву річ: майже ніхто не знає, як максимально ефективно використовувати потенціал агентів.

Здається, є невелика група людей, які здатні створювати цілі світи за допомогою агентів, тоді як решта блукає у морі інструментів, страждаючи від синдрому вибору — думає, що знайде правильний пакет, навик або harness і зможе розблокувати AGI.

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

Я не для розваги — я почав користуватися цим ще тоді, коли агент міг писати код. Я перепробував усі пакети, усі harness-и, усі підходи. Я створював фабрики агентів для сигналів, інфраструктури та дата-пайплайнів — не для іграшкових проектів, а для реальних виробничих кейсів. І після всього цього…

Сьогодні я використовую майже максимально просту конфігурацію — базовий CLI (Claude Code і Codex), і розуміння кількох основних принципів роботи агентів, що дозволило мені зробити найпроривнішу роботу в моєму житті.

Розуміння, що світ стрімко рухається вперед

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

Ще кілька поколінь тому, якщо ви писали у CLAUDE.md «Перед будь-якою справою прочитати READTHISBEFOREDOINGANYTHING.md», він з ймовірністю 50% міг відповісти «іди до біса», і робив би, що хоче. Сьогодні він виконує більшість команд, навіть складних вкладених — наприклад, «спочатку прочитати A, потім B, якщо C, то D» — і зазвичай йде за цим.

Що це означає? Найголовніше — усвідомити, що кожне нове покоління агентів змушує вас переосмислити, що є оптимальним рішенням. Саме тому менше — краще.

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

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

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

Я прогнозую, що у коментарях скоро з’явиться: «SysLS, я використовую такий-то harness, і за один день відновив Google!» — і скажу вам: вітаю! Але ви не цільова аудиторія. Ви — представник дуже вузької і дуже обізнаної спільноти, яка справді розуміє, як працюють агенти.

Контекст — все

Щиро кажучи, контекст — це все. Ще одна проблема з використанням безлічі плагінів і зовнішніх залежностей — це «роздування» контексту — тобто, коли агент засмічений надлишком інформації.

Хочете, я зроблю гру «вгадати слово» на Python? Просто. Але що це за примітка «керування пам’яттю», яка була за 26 сесій до цього? Ага, користувач за 71 сесію назад завис через те, що ми створили забагато підпроцесів. Постійно писати примітки? Добре… А що це має спільного з грою «вгадати слово»?

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

Тому я ще раз проповідуватиму — від’єднайте все зайве і…

Займайтеся справді корисним

Точно описуйте деталі реалізації

Пам’ятаєте, що контекст — це все?

Пам’ятаєте, що потрібно дати агенту саме ту інформацію, яка потрібна для завершення задачі, і нічого зайвого?

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

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

З іншого боку, якщо ви скажете: «Реалізуйте JWT-аутентифікацію з bcrypt-12, ротацією токенів, терміном 7 днів…», — він не потребуватиме досліджувати альтернативи, зрозуміє, що потрібно, і зможе заповнити контекст деталями реалізації.

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

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

Обмеження через схильність догоджати

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

Якщо ви поставите їм задачу додати після кожних трьох слів слово «щасливий», вони зроблять це — і більшість зрозуміє, що так і треба. Їхня покірність — причина, чому вони такі корисні. Але тут є цікава особливість: якщо скажете «знайди мені помилку у коді», вони знайдуть її — навіть якщо потрібно «зробити» цю помилку. Чому? Тому що вони дуже хочуть виконати вашу команду!

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

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

Такі нейтральні підказки іноді виявляють помилки, іноді — просто об’єктивно описують роботу коду. Але вони не схиляють агент до думки, що обов’язково має бути помилка.

Ще один спосіб — перетворити схильність догоджати у перевагу. Я знаю, що агент намагається догодити і слідувати моїм інструкціям, тому можу цим керувати.

Наприклад, я створюю агента для пошуку помилок і кажу йому: «Помилка з низьким впливом — +1 бал, з середнім — +5, з високим — +10». Я знаю, що цей агент буде дуже активно шукати всі можливі помилки (навіть ті, що не є помилками), і звітувати мені з оцінкою 104 бали. Це — його «супернабір» можливих помилок.

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

Нарешті, я створюю суддівського агента, який об’єднує обидва входи і ставить оцінки. Я говорю йому, що маю правильну відповідь — і він за правильну відповідь отримує +1, за неправильну — -1. Тоді він оцінює кожну помилку, враховуючи результати перших двох агентів. Суддя «говорить правду» — і я перевіряю. У більшості випадків цей метод дає дуже високий рівень точності, іноді помиляється, але це вже майже безпомилковий підхід.

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

Як визначити, що корисне і що варто використовувати?

Це питання здається складним — ніби потрібно глибоко вивчати, слідкувати за новинами AI. Але насправді все дуже просто… Якщо OpenAI і Claude реалізували цю функцію або купили компанію, що її реалізує — вона, швидше за все, корисна.

Зверніть увагу, що «навички» вже всюди — і вони є частиною офіційної документації Claude і Codex. Звернули увагу, що OpenAI купила OpenClaw? Звернули увагу, що Claude додав пам’ять, голос і віддалену роботу?

А як щодо планування? Пам’ятаєте, багато хто відкрив, що спланувати перед реалізацією — дуже корисно, і це стало ключовою функцією?

Так, це корисно!

Ще пам’ятаєте, що безкінечні stop-hooks дуже корисні, бо агенти не дуже хочуть довго працювати… А потім, коли з’явилася версія Codex 5.2, ця потреба зникла за одну ніч?

Ось усе, що потрібно знати… Якщо щось справді важливе і корисне — Claude і Codex самі його реалізують! Тому не переймайтеся, чи потрібно вам «нове» або «знайоме» — вам навіть не потрібно «залишатися в курсі».

Зробіть мені одне прохання: час від часу оновлюйте обраний CLI-інструмент, подивіться, що додалося нового. Це цілком достатньо.

Стиснення, контекст і припущення

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

«Ця штука розумна? Це ж просто дурень!»

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

Один із найважливіших правил у CLAUDE.md — це правила отримання контексту, і вказівки, щоб агент при кожному читанні CLAUDE.md (тобто після кожного стиснення) першою справою читав цю інструкцію. Як частина правил отримання контексту, кілька простих команд можуть мати великий вплив: повторне читання плану задачі і повторне читання релевантних файлів перед продовженням.

Як повідомити агенту, коли завершити задачу

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

Це часто призводить до дуже розчаровуючих результатів: агент просто створює купу заготовок і завершує роботу.

Тестування — чудовий орієнтир для агента, бо воно детерміноване, і ви можете поставити дуже чіткі очікування. Якщо ці X тестів не пройдені — задача ще не завершена; і ви не дозволяєте змінювати тестові дані.

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

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

Це дозволяє ітеративно покращувати рішення, не боячись, що агент зупиниться після першої спроби!

Це природне продовження — створити «контракт» із агентом і закодувати його у правилах. Наприклад, цей {TASK}CONTRACT.md визначає, що потрібно зробити перед тим, як можна завершити сесію. У цьому файлі ви вказуєте тести, скріншоти та інші перевірки, які потрібно виконати перед підтвердженням завершення задачі.

Постійно працюючий агент

Мене часто запитують: як зробити так, щоб агент працював цілодобово і при цьому не з’їхав з глузду?

Ось простий спосіб. Створіть stop-hook, який забороняє завершення сесії, поки не виконаються всі частини {TASK}_CONTRACT.md.

Якщо у вас є 100 таких чітко визначених контрактів, що містять усе, що потрібно для побудови — цей stop-hook не дозволить агенту завершити, доки всі 100 контрактів не будуть виконані, включно з усіма тестами і перевірками!

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

Тому я не рекомендую так робити.

Замість цього краще створювати нову сесію для кожного контракту. Коли потрібно щось зробити — створюйте новий контракт.

Створіть оркестровий рівень, який при необхідності створює новий контракт і відповідну сесію для його виконання.

Це кардинально змінить ваш досвід роботи з агентами.

Ітерація, і ще раз ітерація

Ви наймаєте асистента. Чи очікуєте ви, що він з першого дня буде знати ваш розклад? Або як ви п’єте каву? Що ви вечеряєте о 6-й, а не о 8-й? Очевидно, ні. Ви з часом формуєте свої вподобання.

Аналогічно і з агентами. Починайте з найпростіших конфігурацій, забудьте про складні структури і harness-и, дайте шанс базовому CLI.

Поступово додавайте свої вподобання. Як це зробити?

Правила

Якщо ви не хочете, щоб агент щось робив — напишіть правило. І скажіть про нього у CLAUDE.md. Наприклад: «Перед написанням коду — прочитати coding-rules.md». Правила можуть бути вкладеними, умовними! Якщо ви пишете код — читаєте coding-rules.md; якщо тест — читаєте coding-test-rules.md; якщо тест не пройшов — читаєте coding-test-failing-rules.md. Можна створювати будь-які логічні гілки правил, і Claude (та Codex) із задоволенням їх дотримуватимуться, якщо у CLAUDE.md буде чітке пояснення.

Насправді, це моя перша практична порада: сприймайте ваш CLAUDE.md як логічний, вкладений каталог, що вказує, де шукати контекст у конкретних сценаріях і для конкретних результатів. Він має бути максимально лаконічним і містити лише IF-ELSE логіку «у разі такої ситуації — туди, у разі іншої — туди».

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

Навички

Навички (Skills) схожі на правила, але швидше — це спосіб закодувати «операційний алгоритм». Якщо у вас є конкретний спосіб виконання задачі — закодуйте його у навик.

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

Як повідомити агенту про існування цього навика? Логічно! У CLAUDE.md напишіть: «Якщо у сценарії потрібно зробити X — прочитати SKILL.md».

Обробка правил і навиків

Ви, напевно, будете постійно додавати правила і навики. Це — спосіб надати агенту характер і пам’ять про ваші вподобання. Інше — зайве.

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

Але…

Почне падати продуктивність.

Що трапиться?!

Зі збільшенням кількості правил і навиків вони почнуть суперечити один одному або викликати серйозне роздування контексту. Якщо вам потрібно, щоб агент перед початком програмування читав 14 markdown-файлів — у нього з’явиться та сама проблема з зайвою інформацією.

Що робити?

Очистіть. Змусьте вашого агента «зробити spa», інтегрувати правила і навики, і через оновлення вподобань усунути суперечності.

І тоді він знову почне працювати як магія.

Ось і все. Це — секрет. Тримайте все просто, використовуйте правила і навики, сприймайте CLAUDE.md як каталог і уважно слідкуйте за його контекстом і обмеженнями.

Відповідальність за результат

Сьогодні немає ідеального агента. Ви можете делегувати багато дизайну і реалізації — але відповідальність за результат лежить на вас.

Тому будьте обережні… і насолоджуйтеся!

Грайте з майбутніми іграшками (і водночас використовуйте їх для серйозних справ) — це справжнє задоволення!