Чи варто “скидати” ваш штучний інтелект кожні пів року? Розбираємось з експертом за порадою творця Claude Code
Світ штучного інтелекту (ШІ) сьогодні нагадує вирву. Нові терміни, як-от “інженерія петель” (loop engineering) чи “інженерія графів” (graph engineering), з’являються з блискавичною швидкістю. Часто це супроводжується зневажливим зауваженням: “Те, що ви робили досі, застаріло. Викиньте це і купуйте нове!” Нещодавня заява Бориса Черни, творця Claude Code, викликала подібну бурю. Здавалося, він натякнув, що вся ваша наполеглива праця над побудовою ШІ-шарів (AI layers) – марна.
Зокрема, я чув, що його рекомендація полягає в такому: “Кожні шість місяців видаляйте весь ваш ШІ-шар. Ваші правила, навички, зв’язки – все, над чим ви так старалися. Ви будете здивовані, на що здатна велика мовна модель (LLM) без вашого керівництва.” Це відчувається як ляпас: “Ваші зусилля марні, Opus 5 – надто потужний.” Але чи дійсно все так просто? На моєму багаторічному досвіді роботи з бізнес-аналізом та автоматизацією, я з’ясував, що навіть найсміливіші заяви експертів часто мають приховані нюанси. Багато людей, прочитавши лише твіт, роблять поспішні висновки.
Саме тому я прагну розкласти цю ситуацію по поличках. У словах Бориса Черни є слушні думки, але є й аспекти, з якими я категорично не погоджуюсь. Ми розберемо це детально, щоб ви могли визначити, що робити вже сьогодні.
“Абляція” або “Просто видаліть все”: розбір заяви Бориса Черни
Давайте заглибимося в деталі з виступу Бориса Черни на Y Combinator. Я не буду переглядати весь запис, але виберу ключові цитати, які задають тон дискусії.
Ось момент, який викликав найбільший резонанс:
Борис Черни: “100%. Так, і для тих, хто не створює агент-орієнтовані продукти, але використовує Claude Code: кожні шість місяців видаляйте свій квантовий D, видаляйте свої навички, свої зв’язки, подивіться, що зробить модель, і це може вас здивувати”.
І далі, у контексті Opus 5:
Борис Черни: “І насправді для Opus 5, це те, що ми справді рекомендуємо: просто спробуйте видалити всі ці речі, тому що моделі, ймовірно, не знадобляться ті інструкції, які були потрібні для попередніх моделей”.
Звучить так, ніби Opus 5 – це надрозумна сутність, яка знає краще за вас. “Просто видаліть все!” Вражає, чи не так? Але секундою раніше він використав термін “абляція”, який має дещо інше значення.
“Абляція”: не сліпе видалення, а дослідження
Борис Черни: “Це так. Це так. Ми… точніше, ми не видаляємо всю кодову базу, але ми видаляємо багато. Кожного разу, коли виходить нова модель, ми намагаємося… ми в дослідженнях називаємо це абляцією. Це означає, що ви видаляєте всю системну підказку, а потім повертаєте її рядок за рядком, щоб з’ясувати, який вплив має кожен окремий рядок. Це щось на кшталт оцінки, і ви можете її оцінити, а абляція – це, по суті, оцінка, але ви видаляєте речі, щоб зрозуміти вплив”.
Ось де криється справжня цінність його ідей! Вони не просто “викидають” все і сліпо покладаються на модель. Вони проводять систематичний процес, щоб зрозуміти, що саме є критично важливим для їхнього ШІ-шару. Повернення елементів назад дозволяє ідентифікувати, які навички чи правила дійсно покращують результат моделі, навіть якщо це найсучасніша LLM.
Основна теза Бориса цілком логічна: чим досконалішими стають LLM, тим менше потреба в детальних, специфічних правилах та обмеженнях. Ймовірно, багато елементів у вашому ШІ-шарі, які ви вважали необхідними, насправді обмежують можливості моделі, а не допомагають.
Він також наголошує на поширеній помилці:
Борис Черни: “Дуже поширена помилка, яку я бачу: люди використовують Claude Code, вони використовують Claude, і вони просто дають йому надто специфічні інструкції. Вони кажуть: “Я хочу, щоб ти зробив це, але я хочу, щоб ти зробив це так, так, так. Ти повинен зробити один, потім два, потім три, потім чотири”. І для сучасних моделей це насправді не той шлях. Ви хочете піднятися трохи вище. Ви хочете описати завдання, ви хочете описати обмеження, ви хочете описати критерії виходу, а потім просто дозволити моделі…”
Борис Черни: “…дозволити моделі готувати”.
Саме так, “дозвольте моделі готувати”! А абляція – це процес, який допомагає нам зрозуміти, де ми надмірно деталізуємо інструкції для сучасних LLM. Але ми робимо це зворотним шляхом: починаємо з мінімуму і додаємо елементи лише тоді, коли розуміємо, що агент дійсно потребує цього керівництва, незалежно від того, яка це модель – Fable, Opus чи GPT Soul.
Виклики “абляції”: коли це стає занадто дорого
На перший погляд, це звучить чудово. Але є кілька значних “але”, які я, як практик з багаторічним досвідом, мушу виділити.
По-перше, сам процес абляції може бути надзвичайно дорогим. Я можу навести численні приклади тестувань, які підтверджують слушність порад Бориса, але лише до певної межі.
Основна проблема, на мою думку, полягає в тому, що нам не завжди практично видаляти весь наш ШІ-шар і будувати його з нуля. Борис, працюючи в Anthropic, ймовірно, має доступ до безлімітного бюджету на токени. Багато його стратегій зводяться до того, щоб агент працював протягом тривалого часу. Це, повірте мені, не завжди реалістично, особливо в корпоративному середовищі, де кожен токен має свою вартість, або коли ви використовуєте підписки, які вже досягли своїх лімітів.
Коли він говорить про роботу агентів протягом двох тижнів для досягнення “неймовірних результатів”, складається враження, що він живе у своєму окремому світі без обмежень.
Інтерв’юер: “І як довго це зайняло, щоб запустити?
Борис Черни: – Це ще триває.
Інтерв’юер: – Коли ви почали?
Борис Черни: – [Сміх]
Інтерв’юер: – Це вже трохи більше двох тижнів.
Борис Черни: – Більше двох тижнів.
Інтерв’юер: – [Сміх]
Борис Черни: – Так.
Інтерв’юер: – Це мають бути мільйони токенів”.
Мільйони токенів! Навіть з найдорожчими підписками Claude, такий обсяг ресурсів не є доступним для більшості. Це нереалістично.
Перерва на роздуми: ваш код – під надійним захистом!
Тепер дозвольте мені зробити невеличку перерву, яка, до речі, чудово вписується в тему. Коли ви працюєте з кодувальними агентами, найслабшою ланкою стає не написання коду, а його перевірка. Ось де на сцену виходить Code Rabbit – неймовірно корисний інструмент для вирішення цієї проблеми. Я особисто використовую його для всіх своїх відкритих проєктів.
Уявіть класичний спосіб внесення змін – Pull Request (PR). Але проблема полягає в тому, що PR – це просто плоский список файлів, організованих за алфавітом. Жодної логічної структури. Це працює, коли у вас кілька невеликих змін. Але коли ви масштабуєте свою роботу з кодувальним агентом, ви неминуче стикаєтеся з величезними PR, що містять десятки змінених файлів. Вам потрібен спосіб краще організувати цей процес, щоб полегшити масштабування перевірки.
Code Rabbit саме це і робить: він реорганізує той самий PR у “когорти”. Він групує окремі частини роботи та навіть впорядковує їх за шарами. Спочатку йдуть моделі даних та контракти, а потім код, який від них залежить. Це саме те, як досвідчений інженер переглядає PR, і Code Rabbit виконує цю організацію за вас.
Уявіть, Code Rabbit працює в реальному часі над моїм PR для Arkon. Він виявляє реальні проблеми та пропонує рішення. А ще, я можу спілкуватися з ним, щоб уточнити будь-які деталі.
Отже, головна думка: так, ваш ШІ-шар, ймовірно, перевантажений. Ви, швидше за все, надто деталізуєте певні аспекти для сучасних LLM. Але повне “видалення всього” – нереалістично. Це вимагатиме надто багато часу, буде надзвичайно дорогим, і багато чого у вашому ШІ-шарі, навіть якщо воно здається трохи надлишковим, насправді не шкодить продуктивності ваших кодувальних агентів.
Спектр ШІ-шару: де я згоден з Борисом, а де – ні
Давайте розглянемо це як спектр. У нашому ШІ-шарі є три основні компоненти, які надають контекст агенту:
- Правила (Rules): глобальні правила та інший контекст, який агент читає або який ми йому надаємо.
- Навички (Skills): робочі процеси, які агент може використовувати.
- Під-агенти (Sub-agents): “робітники”, яким ми делегуємо завдання.
З усього цього, лише правила варто суттєво скорочувати. Особливо глобальні правила, які завантажуються на початку кожного запиту. Тут найвищий ризик надмірної специфікації та обмеження LLM, адже вона завжди мусить дотримуватися цих вказівок.
Anthropic багато говорить про це у своїй документації Claude Code, і це слушна порада для будь-якого кодувального агента. Вони рекомендують, щоб файл claude.md (глобальні правила) не перевищував 200 рядків. Правила мають бути лаконічними, оскільки спектр йде від того, що завантажується в агент щоразу, до того, що є більш контекстно-ефективним, не займаючи “психічного простору” агента.
І ось тут я повністю згоден з Борисом: щодо правил є значний тиск на скорочення. Важливо тримати їх “легкими”. Часто варто тестувати максимально скорочену версію правил.
Але чим далі ми просуваємося по спектру, до навичок та іншого контексту, що завантажується за вимогою, тим менш важливою стає спроба зробити все максимально стислим. Якщо ви зосередитеся головним чином на глобальних правилах, це зробить процес абляції менш болісним і дешевшим.
Отже, ідеї Бориса слушні, я просто не думаю, що вони стосуються всього. Під-агенти, навички, інший контекст за вимогою – це ті речі, до яких я звертаюся рідко. Я роблю їх працездатними один раз, а потім залишаю їх такими ж протягом виходу нових моделей. Але, так, я визнаю, що щодо глобальних правил – там варто бути надзвичайно уважним.
Звісно, в ідеальному світі з безлімітним часом та бюджетом, як у Бориса, абляція всього ШІ-шару має сенс. Адже кожна LLM інтерпретує ваші інструкції по-своєму. Але в реальному житті ми повинні визначити межу: коли це виправдано з точки зору нашого часу та ресурсів?
Тому моя рекомендація: ми хочемо рухатися в бік скорочення правил. Якщо ви хочете розширити це на навички чи під-агенти, робіть це, можливо, раз на рік. Але не щоразу, коли виходить нова LLM, і тим більше не кожні шість місяців, як пропонує Борис. Це здається надто агресивним.
Тестування на реальному проєкті: архітектура витримала, але деталі виявилися слабкими
Як я і обіцяв, я провів власне тестування на одній зі своїх кодових баз. Це критично важливо, бо показує, які правила нам дійсно потрібні, а які можна відкинути, коли LLM стають розумнішими.
І ось що я виявив: “оголений” ШІ-шар витримав у певних аспектах. Борис частково має рацію. Але коли я прибирав певні типи правил, продуктивність різко падала.
Я тестував на Arkon, моєму відкритому конструкторі ханесів. Якщо ви дивилися мої попередні відео, це не буде для вас новиною. Arkon – це складний і зрілий застосунок. І, мушу зізнатися, файл глобальних правил, arclaw.md, зараз має близько тисячі рядків! Це, звісно, надто багато, якщо вірити документації Anthropic (рекомендовано близько 200 рядків).
Ми намагалися скоротити його раніше, коли використовували opus 4.5 чи 4.7, і результати погіршувалися, коли ми прибирали певні конвенції. Але тепер, з Fable 5, Opus 5 та іншими моделями нового покоління, я знаю, що такі довгі правила нам не потрібні.
Я провів тест: взяв arclaw.md і перетворив його на… ось це. Це повна абляція: кілька команд, трохи контексту про Arkon, і все. Я порівняв Arkon, що працює з нашими “роздутими” правилами, і з цим “оголеним” варіантом, виконуючи різні завдання з GitHub.
Я також використовував навик, який навчає, як загалом користуватися Arkon. Я теж його “облявав” (приблизно 350 рядків). І тепер модель мала б розуміти, як працювати з Arkon, спираючись лише на розуміння кодової бази.
Я щиро думав, що Claude Code провалиться. Але… половина тестів показали однакові результати!
- Архітектурні рішення: Здатність кодувального агента приймати складні архітектурні рішення в нашій кодовій базі.
- Відповідність конвенціям: Наскільки добре він дотримується специфічних для проєкту конвенцій.
Повний ШІ-шар показав високу якість в обох категоріях. Але коли ми взяли “оголений” шар (близько 20 рядків claude.md і жодного Arkon-скілу), він чудово впорався з архітектурними рішеннями! А от з дотриманням конвенцій – зазнав поразки. Це стосується того, як ми реєструємо тести, як пишемо функції, як імпортуємо речі. Ось тут він зламався.
Це означає: чим кращими стають LLM, тим менше нам потрібно вказувати їм, як працювати як загальний інженер-програміст. Багато правил, які ми використовували раніше, були покликані заповнити прогалини в LLM, а не навчити їх нашим конкретним стандартам. Але коли йдеться про правила “як ми хочемо працювати” – вони досі важливі. Ви не можете повністю “облявати” ваш ШІ-шар, бо багато чого в ньому вчить агента, як кастомізувати речі саме для вас.
Наступні кроки: ваш особистий план абляції
Моя фінальна рекомендація: так, процес абляції варто проходити. Але не все. Почніть з правил. Це найлегша здобич, щоб не витрачати час і токени даремно. Так ви зможете визначити, які правила навчають загальним практикам (їх можна видалити), а які – специфічним стандартам вашого коду (їх варто залишити).
Звісно, навіть специфічні речі ваш кодувальний агент може розпізнавати під час роботи. Але я говорю про найлегші кроки.
Подумайте так: правила, які допомагали з міркуваннями, втратили актуальність, бо LLM стали достатньо розумними. Але правила, які спрямовують увагу та кастомізують – вони так само важливі.
На допомогу – ваш особистий “абляційний” помічник!
Наостанок, я хочу показати вам інструмент, який я створив, щоб допомогти вам пройти той самий процес абляції, який я пройшов сам. Це “абляційний” скіл для Claude, який працює з будь-яким кодувальним агентом.
Я можу присвятити йому окреме відео, але зараз коротко: коли ви викликаєте цей скіл, він спочатку визначає ваш ШІ-шар (навички, правила, під-агенти). Потім він створює завдання для тестування вашого коду як з повним, так і з “оголеним” ШІ-шаром. Він запускає ці тести паралельно і дає вам звіт: наскільки кожна частина вашого ШІ-шару допомагає вам у повсякденній роботі.
Я не тестував його сотні годин, тому не можу гарантувати, що він підійде для кожного кодового бази. Але я хотів створити ресурс, який ви можете використати негайно.
Підсумовуючи: те, що каже Борис, – це правильна інтерпретація, але з нюансами. Його стратегії варто розглядати, але з розумінням їхніх обмежень.
Якщо вам сподобалося це відео і ви чекаєте на більше матеріалів про інженерію агентів та навички, поставте лайк і підпишіться! І до наступної зустрічі!
