Перейти к содержанию

«Skill hell» и проектирование LLM-native проекта✦

Проблема «skill hell»✦

В 2026 году в командах появилась проблема, которую называют «skill hell»: внутри компании плодится огромное количество собственных скилов, но почти никто их не переиспользует. Проверить, что там написано и подходит ли скил под твой проект, — отдельный геморрой, поэтому проще поставить своё. В итоге на одну и ту же задачу накапливается десяток пересекающихся скилов, и разобраться в них дороже, чем написать заново.

Внешние источники описывают тот же эффект: каждый установленный скил модель «прочитывает» на каждом шаге («description tax»), скилы залипают в контексте и размывают фокус, а из-за пересекающихся описаний агент выбирает не тот скил. Вывод совпадает с нашим: небольшой аккуратный набор работает лучше, чем тридцать плохо управляемых.

LLM-native проект вместо облепливания скилами✦

Ключевая идея из опыта команды: правильно настроенный проект не развивается по принципу «облепим его скилами и описаниями». Наоборот — надо понять, что модель уже знает нативно и на чём её учили, и менять сам проект так, чтобы типовые действия были для модели очевидны и их не нужно было описывать.

Отсюда — приоритет стандартных решений над кастомными. Кастом сегодня дорог: модель на нём не училась, плохо им пользуется, и даже подробное описание не даёт хорошего результата. Своя библиотека или фреймворк раздувают кодовую базу почти экспоненциально, засоряют контекст и в какой-то момент делают работу модели только тяжелее. Это, кстати, противоречит популярному тезису «раз ИИ пишет любой код, выкинем все библиотеки и напишем сами»: иногда так надо, но чаще крупное продуманное стандартное решение выгоднее.

(Внешняя рамка отличается акцентом: документация Anthropic подаёт Agent Skills как основной способ «оснастить» агента экспертизой, тогда как наш операционный вывод — количество скилов минимизировать, перенеся нагрузку на сам проект.)

Синхронизация терминологии✦

Хороший проект нельзя описать за один присест — это долгий процесс: смотришь, где модель постоянно «тупит», и вместо очередной строчки в AGENTS.md проверяешь, не используется ли в проекте понятие криво, устарело или живёт в разных контекстах.

Пример из практики Hexlet: сущность coursemember («member») означает не человека, а участника курса. Пока в словаре терминов не закрепили, что по-английски это правильнее назвать enrollment (запись/вступление в курс), модель регулярно переспрашивала «это же не человек?». Где можно — такие вещи переименовывают, где нельзя — описывают явно. За год команда сделала много рефакторингов именно ради синхронизации понятийного аппарата с моделью — поэтому Hexlet скилами не обвешан, их число сознательно минимизируют.

Кодогенераторы и скилы из зависимостей✦

Вместо ручного кода команда опирается на генераторы: например, OpenAPI-генератор делает не только DTO, но и заготовки хендлеров — тонны предсказуемого кода, о котором не надо думать. Модель нужно лишь научить (через AGENTS.md), что сгенерированную часть править руками нельзя: есть цепочка «поправил исходник → сгенерировал → дописал вызовы».

Часть скилов и вовсе можно не писать: производители фреймворков всё чаще кладут скилы прямо в пакеты. Упомянутый в подкасте инструмент, автоматически подтягивающий скилы из зависимостей проекта, — это, судя по описанию, skilld: он сканирует NPM-зависимости и генерирует версионные SKILL.md локально, без MCP (поддерживает также crates.io; для Python есть аналоги вроде skillkit). Нюанс из опыта: иногда официальные скилы расходятся с тем, как команда пишет код, и от них приходится отказываться в пользу кастомного — но таких случаев немного.

Источники✦