Статья об AI в работе на Habr за 79 минут чтения и с охватом 6,9 тыс. читателей попала ровно в нерв рынка: от сотрудников уже ждут не любопытства к нейросетям, а внятного ответа, где именно они ускоряют процессы. Для русскоязычной IT-аудитории это не очередной разговор про хайп, а напоминание: если в компании начались KPI на интеграцию AI, отговорка «мы изучаем тему» больше не работает.
Автор материала, как пишет Habr / Карьера, описывает знакомую для многих сцену: менеджер приходит с коротким вопросом «а как у нас там с AI?», после которого становится ясно, что времени на медленное погружение уже нет. Отсюда и логика текста: не спорить о том, нужен ли AI в работе, а быстро разложить по полкам, как устроен современный стек агентных инструментов и где команды сами себе создают проблемы. В центре статьи — Claude Code как практический пример среды, в которой AI перестаёт быть просто чат-ботом и превращается в набор рабочих ролей, сценариев и подключённых инструментов.
Сначала автор проходит по базовым сущностям, без которых разговор об агентной автоматизации превращается в магическое мышление. MCP, или Model Context Protocol, он описывает как открытый протокол для подключения языковых моделей к внешним данным и сервисам: от календаря до корпоративной базы знаний. Далее идут skills, то есть заготовленные сценарии и специализированные знания для агентов; сами агенты как отдельные экземпляры с ролью, инструментами и циклом работы; hooks как автоматические действия в нужный момент; и plugins как способ собрать это в один пакет, а не настраивать вручную по кускам. Важный акцент здесь не в терминах самих по себе, а в смене подхода: AI в работе — это уже не один удачный промпт, а инфраструктура, которую надо проектировать хотя бы на базовом уровне.
Самая сильная часть текста — не обзор функций, а разбор типовых ошибок, в которые компании и отдельные специалисты влетают почти с разбега. Автор жёстко проходится по так называемым «вайб-сетапам», когда человек просит систему самой же настроить «20 агентов, 40 MCP и скиллы на всё это», а потом получает нерабочую или непрозрачную конструкцию. В приведённом кейсе коллега уверял, что агенты у него есть, но в файловой структуре их не оказалось вовсе: настройки существовали только в auto memory, то есть в памяти модели между диалогами. Для рабочей среды это плохая новость. Если команда не понимает, где физически лежат конфиги и как именно устроены роли агентов, она теряет управляемость, воспроизводимость и возможность нормально дебажить процесс.
Отдельно автор бьёт по другой популярной болезни — попытке засунуть всё в один гигантский системный промпт, например в CLAUDE.md. Мотивация понятна: хочется иметь единый источник правил, истории проекта, стайлгайда и команд. На практике такой файл начинает съедать контекстное окно на каждом шаге и мешает модели не меньше, чем помогает. Рецепт у автора вполне инженерный: в системном слое должны жить только короткие и действительно постоянные правила, а всё ситуативное лучше выносить в skills, которые активируются по задаче. Туда же относится проблема конфликтующих инструкций, когда в одном месте сказано «всегда отвечай по-русски», в другом — «talk to me in English», а в третьем агенту выдана ещё одна несовместимая роль. Модель в такой конструкции не обязана быть последовательной, потому что сама система противоречива.
Есть и ещё один неприятный, но полезный тезис: дорогая модель не делает плохой процесс хорошим. Автор отдельно указывает на неверный выбор модели под задачу. Если отправлять сильную и дорогую модель на механическую работу вроде переименования переменных, команда просто сжигает токены без явной пользы. Если же, наоборот, дать слабую модель сложному агенту, который должен разбирать архитектуру или проектировать логику, результат будет таким же предсказуемым, как попытка собеседовать senior-разработчика по шпаргалке из трёх пунктов. То же касается описаний skills и ролей агентов: слишком абстрактное описание не помогает, а мешает, потому что система не понимает, когда именно этот навык применять и когда лучше не трогать его вообще.
Для рынка это важный сдвиг в риторике. Ещё недавно разговор об AI в командах часто сводился к личной продуктивности: кто умеет лучше писать промпты, тот и молодец. Теперь фокус явно смещается на организационный дизайн. Нужны не просто люди, которые «пользуются нейросетями», а сотрудники, понимающие ограничения инструментов, стоимость ошибок, цену лишнего контекста и разницу между демонстрацией активности и реальным ускорением. Для разработчиков это означает рост спроса на прикладную грамотность: уметь собрать минимально жизнеспособный агентный процесс, назначить модели роли, ограничить доступ к инструментам и не превратить всё это в чёрный ящик. Для менеджеров и IT-директоров вывод ещё жёстче: давление KPI без понимания архитектуры внедрения почти гарантированно рождает имитацию прогресса.
На этом фоне материал Habr интересен не тем, что обещает «спасти рабочее место» с помощью одного инструмента, а тем, что фиксирует взросление самой темы. AI в работе перестаёт быть набором лайфхаков и становится дисциплиной с базовыми правилами гигиены: прозрачные настройки, конкретные роли, адекватный выбор модели и отказ от магии там, где нужен обычный инженерный контроль. Главный вопрос теперь не в том, будет ли AI встроен в повседневные процессы, а в том, сколько команд успеют пройти путь от показного энтузиазма к работающей системе до того, как от них начнут требовать результат уже не на уровне презентации, а на уровне P&L и сроков поставки.