Ті, хто серйозно ставиться до бюджету контексту, отримають кращий досвід із підтримкою ШІ, ніж ті, хто сліпо накопичує навички.

Автор статті, джерело: 0x9999in1, ME News

Коротко

• Екосистема навичок/плагінів сучасних AI-асистентів для програмування переживає «перетравлювання після дикого зростання» — накопичення дублюючих, надлишкових та мертвих навичок, що серйозно знищує цінні ресурси контекстного вікна.
• Батько-лобстер (Lobster Dad) відкрив джерело метасkills, призначеного для повної діагностики Skill, який охоплює п’ять основних функцій: аудит бюджету, виявлення дублікатів, перевірка на наявність не використовуваних, аудит кореневої директорії, скорочення опису.
• Віконтексту — один із найбільш обмежених ресурсів великих моделей ШІ; кожен надлишковий навичок займає безглузді токени, віднімаючи простір для міркувань, який вам справді потрібен.
• Основна цінність цього інструменту — не «ще один навичок», а використання одного навичка для управління всіма навичками — це інфраструктурний рівень.
• Безлад у екосистемі Skill — це не ізольований випадок, а структурна проблема. Система плагінів без механізму аудиту неодмінно призведе до зростання ентропії.
• Відкритий код означає, що спільнота може робити ітерації на основі цього, що може стати початком стандартизації управління Skill.

Спочатку про поточний стан: ваш сховище навичок, ймовірно, вже перетворилося на смітник

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

Відповідь, найімовірніше, залишить людей у мовчанні.

З другої половини 2025 року такі інструменти AI-програмування, як Cursor, Windsurf, Codex, Claude Code, разом увійшли у «змагання за навички». Учасники спільноти безперервно надсилають внески, офіційні вбудовані бібліотеки постійно розширюються, а особисті налаштування шаруються один на одного.

Який результат?

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

Це не витрати. Це злочин.

Чому так кажуть? Тому що вікно контексту не є нескінченним. Навіть до 2026 року ефективна довжина контексту основних моделей буде в межах 128K–200K токенів, звучить багато, чи не так? Але порахуйте: системні підказки, історія діалогу, фрагменти коду, вміст файлів, визначення інструментів, описи навичок… Реальної простору для «мислення» набагато менше, ніж ви уявляєте.

Кожен додатковий опис непотрібного навички займає 200 токенів, 50 — це 10 000 токенів. Десять тисяч токенів — це достатньо, щоб модель могла прочитати ще 400 рядків коду.

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

Чому ніхто не втручається? Бо "додавати" у сто тисяч разів легше, ніж "віднімати"

У людей існує глибоко закорінений психічний упередження: схильність до додавання (Addition Bias).

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

Екосистема Skill ідеально відтворила це відхилення.

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

Хто видалятиме? Хто проводитиме аудит? Хто скаже: «Цей навичка дублює ту, видаліть одну»?

Ніхто.

Оскільки видалення не дає ніяких стимулів. Створіть новий навичок, який дозволить отримати зірки, отримати схвалення спільноти та включити його у резюме. Видалити старий навичок? Нічого не отримаєте.

Це структурна дилема. Це не технічна проблема, а проблема механізму заохочень.

Доки хтось не вирішив: мені байдуже на стимули, я це зроблю.

Батько креветки виступає: використовує один Skill, щоб керувати всіма Skill

Хто є батьком креветки? Якщо ви в колі спільноти інструментів AI для програмування, цей нік вам не буде незнайомим. Глибокий гравець, який довгий час активно діяв у екосистемах Codex і Claude, відомий системним мисленням і інженерною чистотою. Саме звання «батько креветки» свідчить про признання спільнотою — бути названим «батьком» означає, що в певній спеціалізованій галузі ви — та особа, від якої не можна уникнути.

Це, що він відкрив, суттєво є метанавичкою (Meta-Skill).

Що таке метанавички? Це «навички керування навичками». Вони не пишуть код за вас, не налаштовують API та не генерують документацію. Вони роблять лише одне: проводять глибокий, кількісний та виконуваний огляд усіх ваших наявних навичок.

П’ять функцій, розбір по кожній.

Це найбільш жорсткий з усіх.

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

Чому це важливо? Бо більшість користувачів взагалі не усвідомлюють, скільки ресурсів з'їв Skill.

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

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

Завдання бюджетного аудиту — відкрити рюкзак і сказати тобі: «Цей швейцарський ніж важить 3 кг, але ти його ніколи не використовував — викинь його».

Ця функція вирішує проблему, яка може бути серйознішою, ніж ви думаєте.

Його діапазон сканування охоплює чотири рівні:

• Вбудовані бібліотеки Codex
• Кеш плагіна
• Репозиторій
• Коренева папка особистих навичок

Сканування навичок з однаковими іменами, схожим описом та перекриваючими функціями між рівнями, позначення надлишкових елементів.

Чому виникають дублі? Причин багато.

Офіційно вбудований навичка "Форматування коду", якої ви не знали, і ви додали ще одну зі спільноти, майже ідентичну за функціоналом. Дві навички, виконують одне й те саме, займають два бюджети.

Або ще прихованіше: ви шість місяців тому написали власний Skill для обробки JSON, а потім офіційна версія оновилася, і вбудована бібліотека отримала кращий варіант. Ваша стара версія все ще існує, і ніхто не сказав вам, що її треба видалити.

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

На основі історичних журналів виявіть «зомбі-навички», які довго не використовувалися.

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

Будь яким був би варіант, висновок той самий: він просто витрачає бюджет.

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

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

Ця функція має більше "оперативний" характер, але дуже корисна.

Вони збирають всі каталоги джерел для Skill, позначають статус увімкнення/вимкнення та аналізують ланцюжок завантаження.

Чому це потрібно? Бо джерела навичок різноманітні: деякі походять із загальних налаштувань, деякі — із конфігурації проекту, деякі — автоматично додаються плагінами, а деякі — створюються користувачем вручну.

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

Аудит кореневої директорії — це як отримати карту, яка показує, де розташований кожен навичка, хто її завантажив, і чи вона активна чи неактивна зараз.

З цією картою ви зможете безпечно провести операцію.

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

Вони роблять: виявляють навички з надто довгим описом та рекомендують варіанти скорочення.

Чому важлива довжина опису? Повернемося до раніше сказаного: опис навички потрібно включити до системного промпту. Кожен символ — це токен. Якщо опис однієї навички можна скоротити з 200 токенів до 80, економія, помножена на кількість навичок, буде дуже значною.

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

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

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

Де цінність? Не в функціях, а в мисленні

П’ять функцій розібрано. Окремо кожна з них здається не надто “революційною”. Але разом вони означають зміну парадигми мислення:

Від «створення більше Skill» до «управління існуючими Skill».

Цінність цієї справи не в кількості коду, не в складності алгоритмів, а в тому, що хтось вперше ставиться до цього питання як до «гідного громадянина».

За останні два роки усі увага екосистеми інструментів ШІ була зосереджена на «додаванні». Більше моделей, більше функцій, більше плагінів, більше Skill. Бігли швидко, бігли сильно — ніхто не дивився назад.

Але будь-хто з інженерним досвідом знає: коли складність системи зростає до певного рівня, без відповідного механізму управління вона руйнується.

Не можливо. Це напевно.

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

Технічний борг екосистеми Skill дійшов до моменту, коли його потрібно визнати.

Цей інструмент, «Батько креветки», за суттю є аудитором боргів. Він не допомагає вам погасити борги, але повідомляє вам: скільки ви боргові, де саме та які борги слід погасити першими.

Це набагато цінніше, ніж «знову написав корисний навичок».

Значення відкритого коду: від індивідуальних інструментів до стандартів спільноти

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

Він міг би легко перетворити цей інструмент на платний плагін. Потреба на ринку очевидна, болі дійсні, платних користувачів буде багато. Але він обрав відкрите джерело.

Чому?

Я думаю, є два аспекти на розгляд.

Перший рівень: щоб цей інструмент справді виявив свою цінність, необхідна спільна робота спільноти. Механізми завантаження навичок, формати журналів та структура каталогів різняться між різними платформами ШІ. Один людина не зможе це адаптувати, але сто внесків — зможуть.

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

Відкрите кодування — найкращий спосіб досягти консенсусу.

Оглядаючи історію програмної інженерії, ESLint для стандартів JavaScript, Black для форматування Python, Prettier для стилю фронтенд-коду — ці інструменти стали фактичними стандартами завдяки тому, що відкрите джерело дозволило спільноті брати участь у визначенні правил.

Чи може цей Meta-Skill від батька креветки стати ESLint для управління Skill?

Зараз рано робити висновки. Але напрямок правильний.

Глибше питання: чи варто переробляти систему Skill?

Інструменти аудиту вирішують «проблеми наявності». Але якщо ми піднімемося на один рівень вище, то побачимо більш фундаментальну проблему:

Чому Skill виходить з-під контролю?

Відповідь: поточна система Skill не має управління життєвим циклом.

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

Порівняйте управління процесами операційної системи: є створення, планування, спання та завершення. Повний цикл життєвого циклу.

Порівняйте управління залежностями менеджера пакетів:npm auditперевірка безпеки, npm outdatedперевірка застарілих залежностей, npm pruneочищення непотрібних пакетів. Інструменти управління — це частина екосистеми.

А як система Skill? Створення → використання → … і все. Пропущено багато етапів.

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

Це не критика. Це необхідний етап розвитку. З 2024 по 2025 рік головною метою платформи було «запустити екосистему», а управління можна було відкласти на потім. Але до середини 2026 року екосистема вже працювала. Прийшов час докласти зусиль.

Наприкінці

Повертаючись до початкового питання: скільки навичок у вашому AI-асистенті є активними?

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

Батько креветки надав інструмент. Безкоштовно. Відкритий код. П’ять вимірів, повне покриття.

Це твоя справа — використовувати чи ні.

Але я точно знаю: ті, хто серйозно ставиться до бюджету контексту, отримають кращий досвід із підтримкою ШІ, ніж ті, хто сліпо накопичує навички.

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

Це не містика. Це теорія інформації.

Шеннон ще в 1948 році повідомив нам: ємність каналу обмежена, чим більше шуму, тим нижча ефективна швидкість передачі інформації.

Ті навички-зомбі у вашому списку — це шум.

Знищте їх.

Посилання

1. Адамс, Г. С., Конверс, Б. А., Хейлз, А. Х., & Клотц, Л. Е. (2021). Люди систематично не враховують субстративні зміни.Nature, 592(7853), 258–261.
2. Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
3. OpenAI. (2024). Документація щодо вікна контексту та обмежень токенів GPT-4 Turbo. https://platform.openai.com/docs/models
4. Anthropic. (2025). Карта моделі Claude: використання вікна контексту та накладні витрати системного запиту. https://docs.anthropic.com/en/docs/about-claude/models
5. Cursor Team. (2025). Правила та навички: Як користувацькі інструкції завантажуються в контекст. Документація Cursor.
6. Документація npm. (2025). npm-audit, npm-prune: Управління життєвим циклом пакетів. https://docs.npmjs.com/cli
7. Батько креветки. (2026). Перевірка здоров’я навичок — метанавичка [відкритий проект]. Репозиторій GitHub.
8. Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.