Таємниці рептилоїда Опуса або на що здатний ваш Claude Code

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Ти на звичайному маршруті у себе на Зоні.

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

І раптом! Раптом ти бачиш як щось шевелиться в тумані.
Ти наводиш свою зброю, готовий стріляти, і чуєш:

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

Ти підходиш на місце де вони стояли, забираєш їхній модем. І через кілька днів коли ти нарешті вибрався із зони, починаєш тестувати їхній чудоапарат (тобто спамити емейлами своїх нових друзів).

І виявляєш для себе кілька властивостей цих рептилоїдів:

І це звісно ж страшенно нудно щоразу самому врукопашку копіювати попередні переписки.

Це рутинна фігня, яку можна і треба автоматизувати. Тому ти вирішив написати програму-посередник (англійською agent), яка буде внизу мати текстовий інпут, і в пам’яті триматиме вашу історію переписки. І ти будеш просто в текстовий інпут писати щось від себе, а програма буде брати те, що ти написав, діставати з пам’яті історію вашої переписки, склеювати твій короткий промпт і всю історію переписки в один великий промпт і посилати рептилоїду оцей великий промпт. А коли він пришле відповідь — відображати це красиво у вигляді чату і зберігати його відповідь в пам’ять. І так по колу.

Вітаю. Ти щойно винайшов браузерний ChatGPT 2022року.

Розгадка до всього дальшого: LLMки є stateless:

LLMки є stateless. Вони десь там в собі пам’ятають увесь інтернет в тому його вигляді, в якому він був на момент їх навчання, але твою з ними переписку вони не пам’ятають. Ти мусиш щоразу посилати їм усе заново.

> Кожна відправка повідомлення — це відправка повністю нового повідомлення, просто з прикріпленою історією переписки.

Ось що було б якби твоя програмка-посередник не зберігала історію чатів і не посилала її кожен раз наново:

Спробуймо здогадатись про що спитає співробітник регіонального відділу)))

Tools

Життя ставало все кращим і все цікавішим. Рептилоїди відповідали неймовірно швидко і допомагали знайти відповіді на багато питань. Завдяки твоєму примітивному агенту (програмці-посереднику) який більше нагадував чат, спілкуватись з рептилоїдами було неймовірно зручно.

Але в якийсь момент ти захотів більшого: ти захотів щоб рептилоїди замість тебе писали код.

Спершу ти почав з того, що писав рептилоїдам який код ти хочеш щоб вони написали. Вони питали тебе щоб ти скинув пару файлів для контексту. Ти їм його посилав. Тоді вони тобі присилали той код. І ти йшов і вставляв той код в файл вручну. І в якийсь момент це тобі теж набридло, і ти захотів піти ще далі — автоматизувати навіть оцей ctrl+c + ctrl+v.

Тому ти вдосконалив свою програмку-посередник (агента) і вона почала працювати наступним чином:
Коли ти пишеш якийсь текст в текстове поле і нажимаєш ентер — твоя програмка бере твій текст, до цього тексту додає:

Тоді твій агент склеює докупи твій промпт який ти написав в текстовому полі + історію переписки + опис доступних Tools як у прикладі вище. І весь цей добротний промпт посилає рептилоїду.
Рептилоїд це все читає. Якщо йому достатньо наданої тобою інформації, то він присилає «!_&Write_! ./index.ts line:23 Content: const abracadabra...». Твій агент, тобто твоя програмка парсить цю відповідь, дістає з цієї відповіді аргументи, і просто виконує роботу з файловою системою.
Якщо рептилоїд вирішує, що наданої йому інформації недостатньо, то він присилає ключове слово для Grep, твоя програмка-посередник парсить відповідь, і виконує Grep, а тоді бере результати того пошуку, додає їх до всього того попереднього промпта і історії переписки і все це пересилає новим запитом до рептилоїда.

Рептилоїди (LLMки) живуть на Нібіру, вони не мають прямого доступу до твого комп’ютера, до його файлової системи чи до гугла чи до ще чогось. Рептилоїди можуть лише отримувати повідомлення і відповідати на повідомлення.

Але твоя програмка-посередник автоматично будує великий промпт з усіма деталями, саме твоя програмка-посередник вклеює до твого промпта опис інструментів, які вона може надати для рептилоїда. Тоді рептилоїд присилає наказ для твого агента в спеціальному форматі, і вже твоя програмка-посередник виконує дії з файловою системою.

Ось так Claude Code «звітує» про що він робив згідно наказів LLM

А ось так це можна зобразити схематично:

Hooks

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

Але тобі все ще доводиться вручну запускати лінтер.
Ба більше, ти би хотів обмежити можливість рептилоїда читати .env файл.

Звісно ж ти міг такий функціонал хардкодити прямо в коді самого агента. Але в одному проекті одна ситуація, одні потреби, в іншому проекті інші.

Тому ти вирішив створити гачки (hooks):
Ти розширив свою програмку-посередника наступним чином:

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

• умову коли саме цей хук має вклинитись
• що треба зробити

Наприклад для обмеження доступу до .env файла ти прописуєш в той файл хук, де прописуєш:

• умова коли вклинитись: перед виконанням тулзи Read
• що треба зробити: перевірити чи міститься серед списку файлів для Read які прислав рептилоїд файл з назвою .env. Якщо не міститься, то нічого не робити. Якщо міститься, то скасувати відхилити виконання тулзи

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

Для запуску лінтера ти додаєш в той файл де прописуєш:

• умова коли вклинитись: після виконання тулзи Write
• що треба зробити: запустити npm run lint

Я навів прості приклади. Але фішка якраз в тому, що така архітектура агента (програмки-посередника) дозволяє дуже гнучко налаштовувати роботу цього агента (програмки-посередника) під кожен проект.

Звертаю увагу!:

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

Ось так можна зобразити схематично:

Звертаю увагу:
Я навів два найбільш уживаних хука (PreToolUse (перед виконання тулзи) і PostToolUse (після виконання тулзи)). Але також існують Stop, Notification, SubagentStop та інші.

Якщо брати аналогію, то можна уявити, що прописати хук для claude code — це як написати document.addEventListener("тип події коли вклинитись", (event) => що зробити). Причому якщо брати цю аналогію, то всередині «що зробити» можна написати event.preventDefault() (тобто обірвати стандартне виконання).

MCP сервери

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

І взагалі, взагалі, це все можна було б зробити як Tool. Але це все hardcode. І якщо у випадку з Read Write хардкод має сенс, бо це прям базовий функціонал який точно треба всюди. То різні додаткові інструменти — це вже те, чого може бути дуже багато дуже різного. Причому для одного проекту таке, для іншого проекту інше.

Тому ти зробив по іншому:

По-перше, від друзів-масонів ти дізнався, що вони придумали спеціальний MCP протокол для серверів (спеціальні правила, за якими сервер отримує питання і посилає відповіді. Набагато краще адаптовані під роботу рептилоїдів чим якийсь GraphQl наприклад).

По-друге, ти додав у свою програмку-посередник можливість працювати з такими MCP серверами від Figma, від Playwright, та від інших.

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

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

* Чому Model Context Protocol? Чому не інший протокол?

Тому, що після зустрічі з рептилоїдом Опусом ти почав серйозніше досліджувати тему рептилоїдів і почав ходити на зібрання масонів. І там дізнався, що крім Опуса з Нібіру, є ще Codex з планети OpenAI, DeepSeek з планети Серп&Молот, Grok з планети ВідСерцяДоСонця та інші. І виявилось, що іншим масонам було лінь робити окремий протокол (а отже окремий сервер) для кожного окремого рептилоїда, тому вони домовились використовувати однаковий протокол незалежно від з яким рептилоїдом вони дружать. А ти такий подумав і «а чому б і ні? Теж буду користуватись».

Важливе уточнення: MCP сервер — це прям сервер, це не абстракція. MCP сервер може бути запущеним не лише локально (як від playwright чи від nextjs devtools), а й віддалено: наприклад Figma, Github, Jira.

Subagents

Все уже дуже і дуже добре. Але є проблема:

Розмір повідомлення, яке ти можеш послати рептилоїду за раз — дуже великий, але всеодно обмежений.

В якийсь момент історія переписки з усім вмістом файлів, з історією що куди в який файл було вписано, з історією запитів на MCP сервери і їх відповідей, все оце, вся оця історія переписки з рептилоїдом стає настільки величезною, що вона просто не вміщається в одне повідомлення до рептилоїда.

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

І от виходить:

• якщо програмка-посередник обріже частину історії переписки, то може втратитись контекст і вірогідність, що рептилоїд пришле шібурду виростає
• якщо програмка-посередник не обріже частину історії переписки, а просто напіхає туди всього підряд, вірогідність, що рептилоїд пришле знову ж таки шібурду, теж виростає. Гірше того, рано чи пізно історія переписки стане завеликою і рептилоїд взагалі перестане відповідати

Як бути?

Один з варіантів — це запустити новий інстанс програмки-посередника, в якому послати знову ж таки список тулзів, список MCP серверів і все інше рептилоїду, і ту задачу, яку рептилоїд поставив програмці посереднику в першому головному чаті, в головному інстансі, в головній сесії, ту задачу переслати рептилоїду в новій сесії. І після того як новий інстанс програмки-посередника (тобто subagent) закінчить переписку з рептилоїдом, вернути короткі результати в основну сесію, в основну переписку.

Тому ти так і зробив. Ти зробив так, що тепер твоя програмка до твого промпта крім інформації про базові тулзи і інформації про MCP сервери додає також:

Шановний Опусе! Це твій друг Андрій!
Ми як друзі повинні один одному помагати.
Тому допоможи мені зробити ось це: ${promptFromUser}.
Пам'ятай, що ти можеш наказати мені виконати ту чи іншу дію, а саме ${toolsWithGuide}.
Також пам'ятай, що ти можеш наказати мені відправити запит на MCP сервер, а саме ${mcpServersWithGuide}.

БІЛЬШЕ ТОГО, шановний друже Опусе, якщо ти вважаєш, що жоден з описаних мною вище тулзів
чи MCP серверів не достатній для вирішення цієї проблеми, то опиши своїми словами
що я маю зробити і я це неодмінно зроблю.

Але після того як Опус пришле задачу тобі саме тобі, то твоя програмка-посередник не чекає поки ту задачу зробиш саме ти. Після того, як Опус пришле задачу тобі саме тобі, твоя програмка-посередник створює новий інстенс себе (програмки-посередника, тобто запускає субагента), і передає цю задачу в той новий інстенс (в той субагент) як стартовий промпт. І потім коли той новий інстенс закінчить переписку з Опусом де Опус вирішить свою ж задачу руками твоєї програмки-посередника, той новий інстанс програмки-посередника (субагент) поверне в першу переписку лише результат вирішення тієї задачі (а не всю історію переписки). І твоя програмка-посередник відпише Опусу:

Шановний Опусе!
Ми з тобою спілкувались про:
${chatHistory}.

Твою задачу, яку ти мені поставив, я сумлінно виконав. Ось що з того вийшло ${answerFromSubagentChat}.
З урахування цього, прошу виконай початкову задачу, яку я тобі ставив.

І хоч це звучить трохи кіберпанково, навіть по-чітерськи. Але як ми знаємо, рептилоїд Опус не пам’ятає попередні переписки. Все, що ми хочемо йому сказати — ми повинні йому сказати в цьому одному повідомленні. Тому це теж досить популярний спосіб.

Фіксована інформація про проект

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

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

Розділена на шматочки інформація про проект (Skills)

Час ішов. Кількість нотаток для рептилоїда в CLAUDE.md постійно росла. І в якийсь момент стала надто величезною.

Тому ти вирішив обійти це наступним способом:

В CLAUDE.md ти залишив лише найважливішу інформацію для рептилоїдів. А все інше вирізав звідти і поділив на багато багато менших markdown файликів. В кожному файлику ти нагорі написав коротко назву, коротко опис (максимум 1024 символи). І нижче саме то знання уже в усій повноті.

І переробив свою програмку-посередника наступним чином:
Твоя програмка-посередник посилає рептилоїду твій промпт, список доступних тулзів, MCP серверів, а також, також посилає список отих .md файликів і каже

Шановний Опусе. Ось є список доступних знань:
${knowledges.list("name", "description") /* вміст не передається */}.
Якщо потребуєш якесь із них, то напиши мені ключову фразу "Потребую знання із назвою ___"
і я тобі його пришлю.

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

Чому skills називаються skills, а не on demand knowledge loading?
Я теж згоден, що on demand knowledge loading для цієї фічі підходить набагато більше.
Але якщо ти скажеш інвесторам: «Ми додали до програмки-посередника можливість ділити знання з одного великого файлу на багато маленьких і посилати на початку рептилоїду лише список цих файлів щоб не перевантажувати контекст. І назвали цю фічю On Demand Knowledge Loading» — тобі ніхто грошей не дасть.
А от заява: «Наші агенти — це тепер не просто суміш конструктора для побудови промптів і парсера який потім виконує ті чи інші дії. Наші агенти тепер — це щось нове і нейомвірне: вони можуть мати НАВИЧКИ. Це нова революція! Новий прорив! Світ змінився незворотньо. Ми в три рази обігнали конкурентів, вдвічі наблизились до винайдення AGI, і от от захопимо світ. Несіть гроші поки ще беремо!» залучає інвестиції набагато краще. Тому так історично склалось, що назвали їх все ж таки Skills, а не On Demand Knowledge Loading. Власне пора звикнути, що в 21 столітті назви інструментам дають маркетологи, а не інженери.

Commands

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

Спершу ти просто тримав список таких промптів десь в окремому записнику і йшов копіював. Але потім тобі це набридло. І ти створив в себе в проекті папочку commands, для кожного шаблонного промпта створив окремий .md файл. І переробив свою програмку посередника так, щоб він брав ім’я кожного з тих файлів у тій папочці, і давав тобі можливість в чаті написати /імя-файлу типу як команду, потім після команди аргумент, і нажавши ентер щоб твоя програмка брала вміст того файлу і поводилась з ним так, нібито ти його щойно ввів в текстове поле.

Тут доречі назва досить непогано передає суть.

Ремарки

1. Матеріал написаний людиною. Рептилоїди лише давали відгук і пропонували поправки.
2. Матеріал писався 26 травня 2026 року
3. Спочатку зав’язка (пояснення, звідки взявся модем і як відбулось знайомство з рептилоїдами) була не на Чорнобилі, а порятунку від ТЦК. Саме звідти пішли коментарі про ТЦК
4. Для чистоти совісті мушу уточнити: в реальному житті рептилоїди не гуляють по Чорнобилю, живуть в датацентрах (а не на Нібіру) і отримують від програми-агента список доступних `tools` зазвичай в JSON форматі і як окреме поле в payload згідно спеціального синтаксису, а не отого.«!&Read&! всередині промпту як я наводив приклад.
5. Попри увесь цей розвиток програмок-посередників, LLMки залишились LLMками. І вони досі галюцинують. Навіть при купі налаштувань, купі правильно підібраних контекстів і т д, все ще достатньо часто галюцинують. Причому галюцинуують дуже небезепечно, бо дуже правдоподібно (помилки виглядають дуже схожими на правду і їх дуже важко відрізнити). Автор всього лиш оглядає наявні фічі і в жодному разі не закликає до YOLO-mode вайбкодингу. Особливо на продакшні.

Кінець

Підсумуємо:

• LLMки є stateless — вони не пам’ятають твоїх попередніх повідомлень. Усю історію переписки щоразу пересилає програмка-посередник (агент).
• Tools — це не магія: агент описує LLMці які «накази» вона може прислати, LLMка їх присилає, і уже агент виконує реальні дії на комп’ютері. Причому агент — це не «розумна» фігня, а звичайна програма, яка крім натискання на кнопки трігером для виконання дій використовує накази LLMки.
• Hooks — спосіб вклинитись у виконання тулзи «до» або «після», щоб додати свою логіку (лінтер, обмеження доступу ітд).
• MCP сервери — сервери, які працюють згідно спеціального стандарту, Model Context Протоколу, щоб не хардкодити кожну інтеграцію в самого агента.
• Subagents — це така собі «мета-тулза». Тобто коли замість Read, Write, або звернення на MCP, агент відкриває нового підагента, де починає переписку з LLMкою сам.
• CLAUDE.md — файл з фіксованим контекстом проекту або папки, який програмка-посередник вставляє в кожен промпт. Такий собі аналог README.md, але для LLMки.
• Skills — той самий CLAUDE.md, але порізаний на шматочки, які підвантажуються за потреби (по суті своїй On Demand Knowledge Loading, але маркетологи захотіли назвати це Skills).
• Commands — шаблонні промпти, які зручно викликати через /назва-команди.

Ну і Обов’язково став лайк та пиши в коментарях
— лайфхаки, best practises та інші інсайти зі свого масонського досвіду
— критику
— і чи виникало в тебе іноді бажання застрілити рептилоїда?