Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Мы его активно используем для автоматизации рутинных задач и помощи в быстрых тестах с кодом. Проблема с оплатой этой нейросети, аналогична и другим зарубежным нейросетям из РФ. Все, как правило, решается иностранной виртуальной картой для оплаты подписок.

Подробный и честный гайд о том, как оплатить Claude в 2026 году из России. Без воды — только актуальные рабочие варианты.

Способ 1. Виртуальная иностранная карта

Если нужен Claude надолго и для себя — этот способ основной. Оформляете зарубежную виртуальную карту, пополняете через СБП из любого российского банка и платите подписку с неё. Карта остаётся с вами, работает для Claude, ChatGPT, Spotify, Booking и всего остального.

ТОП-4 сервиса для выпуска виртуальной карты

Разберём на примере 💳 — дальше пошаговая инструкция под него. Но на рынке есть ещё несколько нормальных вариантов, у всех примерно одна логика:

💳 — Telegram‑мини‑ап, пополнение через СБП, без верификации. Карта для подписок в евро (эмитент — Испания). Выпуск — 2 990 ₽.

💳 Wanttopay — удобный финтех‑сервис с доступом к платежным инструментам. Оплачивайте зарубежные сервисы, подписки и путешествия через 📲 мини‑приложение в Telegram.

💳 E.PN — пополнение только в крипте (USDT), выпуск от 4 $. Много настроек, много карт под разные задачи. Для тех, кто уже работает с криптой.

💳 EasyPayments — реальный пластик на ваш паспорт от иностранного банка. Выпуск от 20 000 ₽, срок — от недели. Для тех, кому нужна полноценная карта, а не только онлайн.

Подробное сравнение всех пяти — в отдельной статье «Как открыть виртуальную карту зарубежного банка». Здесь идём дальше по схеме с .

Открыть счёт в иностранном банке удалённо сегодня стоит от 30 000 рублей, занимает несколько недель и требует уведомить ФНС. 💳 решает ту же задачу за 2 990 рублей без выезда и бюрократии.

Как выпустить карту: пошагово

Откройте Telegram и найдите бота 💳 . Запустите мини‑приложение — отдельного приложения скачивать не нужно.

Выберите карту для подписок (EUR, эмитент Испания) — выпуск 2 990 ₽. Оплатите через СБП — карта появляется сразу, на балансе уже 5 €.

Чтобы пополнить: нажмите «Пополнить», введите сумму — приложение покажет курс и итог в рублях ещё до подтверждения. Перейдите в банк через СБП, подтвердите — деньги приходят моментально.

Как оплатить клод из России: пошагово

Шаг 1. Включите VPN. Откройте claude.ai и зарегистрируйтесь — на иностранный номер, по SMS‑коду.

Шаг 2. В интерфейсе Claude: профиль внизу слева → Upgrade plan → Claude Pro ($20/мес).

Шаг 3. В платёжной форме введите реквизиты карты: номер, срок, CVV и billing address. Billing address берёте из мини‑апа карты — для это испанский адрес, для WanttopayUSD — американский. Свой российский адрес не указывать, платёж не пройдёт.

Шаг 4. Подтвердите оплату. Если карта поддерживает 3D Secure — код придёт прямо в мини‑ап или на почту.

Шаг 5. Проверьте статус — в профиле появится пометка Claude Pro, лимиты увеличатся, откроются модели Opus и Sonnet без ограничений.

⚠ Если платёж не проходит: сначала проверьте, что в настройках аккаунта Claude в поле Country стоит та же страна, что у эмитента вашей карты (для — Spain, для Wanttopay — United States). После этого попробуйте снова. Если не помогло — попробуйте другую карту: долларовая Wanttopay с американским ГЕО у Anthropic проходит стабильнее, чем европейская.

💡 Про VAT. Если платите с европейской карты (, Испания) — Anthropic автоматически добавит НДС ~21%. Итого выйдет около $24 вместо $20. Хотите без налога — берите карту с американским ГЕО (Wanttopay USD).

Способ 2. Маркетплейсы цифровых товаров — купить доступ без карты

Если с VPN, eSIM и виртуальными картами разбираться не хочется — есть вариант проще. На маркетплейсах цифровых товаров продают готовые аккаунты Claude Pro с оплаченной подпиской. Вы покупаете российской картой или по СБП, получаете логин с паролем и пользуетесь.

Главное отличие от Telegram Premium: у Claude нет подарочных кодов активации, поэтому продаётся именно доступ к готовому аккаунту с уже оплаченной подпиской.

Важный момент: разброс цен у разных продавцов на один и тот же срок может быть значительным. Сравнивайте предложения, смотрите на рейтинг и количество отзывов — это стандартная мера предосторожности для любых цифровых маркетплейсов.

Где купить подписку на клод

На маркетплейсе 💵 ggsel.net — вбиваете в поиск «Claude Pro», выбираете нужный срок (1, 3 или 12 месяцев) и продавца с высоким рейтингом. Оплата через СБП или российской картой. Данные для входа приходят в течение 5–30 минут.

Пошаговая инструкция

• Определите нужный срок. Claude Pro продаётся на 1, 3 и 12 месяцев. Пересчитайте цену за месяц — годовой доступ обычно выгоднее.
• Выберите продавца. На ggsel.net ищите «Claude Pro». Ориентируйтесь на рейтинг (4.8+), число продаж и наличие гарантий замены или возврата.
• Оплатите заказ. Принимаются СБП и российские карты. Данные аккаунта придут автоматически.
• Войдите в аккаунт. VPN всё равно нужен — Claude проверяет IP при каждом запросе. Открываете claude.ai через VPN, вводите полученные данные.

Честно о минусах

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

Для рабочих и конфиденциальных задач этот способ не подходит. Для первого знакомства с Claude или разового проекта на месяц — нормально.

Подписка Claude Pro: что внутри

• Все функции активируются сразу после оплаты и работают весь срок подписки.
• Доступ к сильным моделям. Claude Pro открывает Sonnet 4.7 (быстрый, для большинства задач) и Opus 4.7 (самый мощный). В бесплатной версии они либо недоступны, либо с жёсткими лимитами.
• В 5 раз больше сообщений по сравнению с Free. Для обычной ежедневной работы хватает.
• Проекты. Загружаете инструкции, документы, контекст один раз — Claude помнит это во всех чатах внутри проекта. Не нужно объяснять каждый раз, кто вы и что вам нужно.
• Артефакты. Код, документы, таблицы и визуализации — в отдельном окне рядом с чатом. Удобно для работы с текстами, данными и кодом.
• Веб‑поиск. Claude ищет актуальную информацию в сети и даёт ответ со ссылками на источники.
• Выполнение кода. Можно запускать Python прямо в чате: обрабатывать данные, строить графики, создавать файлы Excel, Word, PDF.
• Загрузка файлов до 30 МБ. PDF, таблицы, документы, изображения. Claude читает и работает с содержимым.
• Контекст 200 000 токенов. Это примерно 150 000 слов — целая книга. Полезно при работе с большими базами кода или объёмными документами.
• Claude Pro по функциональности сопоставим с ChatGPT Plus. Многие, кто пробует оба, в итоге оставляют Claude как основной — особенно если работа связана с текстами, кодом или длинными документами.

Частые вопросы об оплате подписки на клод

1. Можно ли пользоваться Claude без VPN?
   Нет. Claude проверяет IP при каждом запросе, а не только при входе. Без VPN — ошибка App unavailable на каждый запрос.
2. Какой VPN подходит?
   Платный, с живыми IP‑адресами. Mullvad, Proton VPN, AdGuard VPN — проверено. Бесплатные режутся. Так же, рабочий метод, покупка персональных прокси и использование ADS POWER браузера или аналогичных антидетект браузеров.
3. Можно ли зарегистрировать аккаунт на российский номер?
   Нет. Форма регистрации не принимает +7. Нужен виртуальный номер через sms‑activate или eSIM через Airalo, Yesim.
4. Принимает ли Claude российские карты?
   Нет. Ни Visa, ни Mastercard, ни МИР с российским эмитентом не проходят. Нужна иностранная карта — виртуальная или пластиковая.
5. Что дешевле: карта или аккаунт с ggsel?
   По цифрам — аккаунт на ggsel в моменте чуть дешевле. Но это чужой аккаунт с рисками, которые описаны выше. Своя карта — это свой чистый аккаунт с историей чатов и персональными настройками.
6. Что лучше для Claude — или Wanttopay?
   Обе работают. Wanttopay USD с американским ГЕО — без VAT при оплате, подписка выходит ровно $20. Плати по Миру — чуть проще в пополнении, но с европейским ГЕО Anthropic добавит налог ~21%.
7. Как отменить подписку?
   Settings → Account → Manage subscription → Cancel plan. Несколько кликов. Доступ к Pro остаётся до конца оплаченного периода.
8. Почему карта не проходит при оплате?
   Проверьте по порядку: в профиле Claude поле Country должно совпадать со страной эмитента карты. Billing address — тот, что привязан к карте, не российский. На карте должен быть баланс с запасом выше $20 — Anthropic делает предавторизацию. VPN должен быть включён, желательно в той же стране, что у карты.

Итого, как же можно оплатить claude

С Claude барьеров больше, чем с другими сервисами: нужны VPN + иностранный номер + иностранная карта. Но после однократной настройки всё работает стабильно.

Для постоянной работы — виртуальная карта (💳 или Wanttopay) плюс нормальный VPN. Один раз настраиваете, дальше просто пополняете карту по СБП раз в месяц. Карта работает и для Claude, и для всего остального.

Для разовой задачи — готовый аккаунт на 💵 ggsel.net. Купили, зашли через VPN, пользуетесь. Для регулярной или конфиденциальной работы не подходит, но для знакомства с сервисом — самый быстрый вариант.

Оба способа актуальны на апрель 2026 года. Делитесь в комментариях, как решили для себя вопрос с VPN и номером — именно эта часть у всех получается по‑своему.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

На это уходит от 30 минут до нескольких часов, а в итоге всё равно можно допустить ошибку в синтаксисе, неправильно сконфигурировать источник данных или пропустить важный параметр безопасности.

А что, если сократить этот процесс до 30 секунд? Просто описать задачу на естественном языке — «Настрой обработчик для фильтрации событий от Kafka, оставь только записи с user_id больше 1000 и приоритетом high, результат отправь в новый топик» — и получить готовую конфигурацию, адаптированную под специфику нашего продукта. Не абстрактную YAML или CONF-заготовку, которую ещё нужно подгонять под продукт, а конфигурацию с правильными параметрами, корректным синтаксисом DSL для трансформаций и с соблюдением архитектурных паттернов продукта, готовую к проверке и применению в промышленной среде.

В этой статье я расскажу, как мы создали систему автоматического генерирования конфигураций для одного из компонентов нашего продукта, используя RAG (Retrieval-Augmented Generation), векторные базы данных и межагентное взаимодействие по протоколу A2A.

Немного о проблематике

Инженеры, работающие с системами потоковой обработки данных, ежедневно сталкиваются с необходимостью создавать конфигурации для различных систем. Это обработчики данных, сложные многошаговые трансформации, политики обработки ошибок, правила маршрутизации событий между сервисами. При этом приходится изучать объёмную документацию на сотни страниц, где каждый компонент системы описан в отдельном разделе.

Разработчик должен помнить синтаксис множества форматов: YAML/JSON для основных конфигураций, специфичные форматы для описания политик безопасности. Но самое сложное — работа с проприетарным DSL для описания трансформаций данных. Создание одной конфигурации средней сложности занимает от 30 минут до нескольких часов. За это время инженер переключается между задачами, теряет контекст, отвлекается на поиск информации.

Классический подход — копипаст из предыдущих проектов с ручными правками — не только медленный, но и чреват ошибками. Каждая опечатка в имени параметра, неверный отступ в YAML, забытый обязательный параметр или устаревшая версия синтаксиса из старой конфигурации превращается в потерянное время на отладку. А если речь идёт об эксплуатационной среде, то цена ошибки может быть очень высокой.

Более того, документация постоянно обновляется. Появляются новые параметры, некоторые становятся deprecated, меняются рекомендации. Инженер может не знать о последних изменениях и использовать устаревшие подходы. Особенно остро эта проблема стоит с проприетарными DSL: в отличие от стандартных форматов вроде YAML или JSON, для которых есть множество примеров в интернете, специфичный синтаксис трансформаций описан только в корпоративной документации.

Специфика DSL для трансформаций

В Platform V Synapse Streaming Event Processing используется проприетарный DSL для описания трансформаций потоковых данных — tr-файлы. Это декларативный язык, специально разработанный для наглядного описания трансформаций без необходимости писать императивный код на Java или Python.

DSL позволяет описывать маппинг полей — преобразование структуры входящего события в требуемую структуру выходного, с переименованием полей, извлечением вложенных значений из JSON, объединением нескольких полей в одно. Фильтрация событий реализована через выражения с поддержкой сложных условий, логических операторов, функций для работы с датами, строками, числами, регулярными выражениями. Есть обогащение данными из внешних источников. Система поддерживает работу с окнами агрегации, группировку по ключам и применение агрегирующих функций.

Вот пример простой трансформации на этом DSL:

define isFirst = truefor ($data: in) {    if ($isFirst) {        out[>] = $data        headers[>].TargetKey = generateId()        define isFirst = false    } else {        out[+>] = $data        headers[+>].TargetKey = generateId()    }    INFO("RESULT", out, "TEST.OUT", "-")}

Для LLM этот DSL нестандартный, его не было в обучающей выборке GigaChat или других публичных моделей. Модель не может просто «вспомнить» синтаксис, как это было бы с Python или SQL. Попытка сгенерировать tr-файл без дополнительного контекста приводит к галлюцинациям: модель может выдумать несуществующие функции, использовать синтаксис от других похожих языков, перепутать порядок секций.

Именно поэтому RAG становится не просто улучшением, а критически необходимым компонентом системы. Без доступа к актуальной документации и примерам невозможно корректно сгенерировать конфигурации на проприетарном DSL.

От идеи до готовой конфигурации за 30 секунд

Мы создали систему, которая за считанные секунды превращает естественно-языковое описание требований в корректную конфигурацию. Ключевая идея — использовать саму документацию продукта как источник знаний для искусственного интеллекта, а не пытаться обучить модель с нуля на специфичном DSL.

Процесс начинается с подготовительного этапа: загрузки всей документации по продукту в векторную базу данных. Мы берём официальную документацию в формате Markdown, специальный сервис разбивает документы на логические фрагменты (чанки) и превращает их в векторные представления — эмбеддинги. Этот процесс нужно выполнить только один раз при первоначальной настройке системы, далее векторная база обновляется только при изменении документации.

Инженер описывает требования к конфигурации на естественном языке, и магия начинается.

Запрос может быть сформулирован просто и понятно: «Создай обработчик, который читает события из топика user-actions, фильтрует только события типа purchase с суммой больше 1000 рублей, обогащает данными о пользователе из дополнительного топика и отправляет результат в топик high-value-purchases». Система не требует знания точного синтаксиса или имён параметров — она сама найдёт нужную информацию в документации.

Система анализирует запрос и через механизм RAG находит в документации релевантный контекст. Это не простой полнотекстовый поиск по ключевым словам, а семантический поиск по смыслу. Система понимает, что «читает события из топика» связано с разделом документации про источники Kafka, «фильтрует только события типа purchase» требует конфигурации фильтров, а «отправляет результат в топик» — настройку destination.

LLM получает найденные фрагменты документации и генерирует готовую конфигурацию с учётом контекста. Модель не просто генерирует текст наугад — она опирается на конкретные примеры из документации, использует правильные имена параметров, соблюдает синтаксис.

В результате получается конфигурация, которую можно сразу применить без дополнительной доработки, все обязательные параметры заполнены корректными значениями, соблюдены требования к структуре конфигурационных файлов продукта согласно текущей версии, применён корректный синтаксис DSL для трансформаций (если требуется).

Это означает, что инженеру не нужно тратить время на поиск документации по версиям продукта, вспоминать специфичные имена параметров или разбираться в тонкостях синтаксиса DSL: система делает это автоматически на основе актуальной документации.

Но генерирование это только половина дела.

Во время создания конфигурации агент-генератор по протоколу A2A вызывает агент-валидатор. Тот получает сгенерированную конфигурацию и исходный запрос пользователя, после чего проверяет, действительно ли конфигурация решает поставленную задачу? Все ли обязательные параметры указаны? Нет ли логических ошибок или потенциальных проблем с производительностью? Валидатор может ответить «конфигурация корректна» или запросить исправления: «в секции filters пропущен обязательный параметр field_name» или «для production-среды рекомендую добавить SSL-подключение».

Агенты итеративно взаимодействуют до получения валидной конфигурации. Это может занять несколько циклов: генератор создаёт первую версию, валидатор находит проблемы, генератор исправляет с учётом замечаний, валидатор проверяет снова. Обычно требуется от одной до трёх итераций. Этот процесс полностью автоматический и занимает секунды, а не часы ручной отладки.

После того как конфигурация прошла ИИ-проверку, её можно дополнительно проверить статическими методами. Config Validator проверяет, что YAML синтаксически корректен, JSON-схемы корректны, а если конфигурация предназначена для развёртывания в Kubernetes — проверяет соответствие спецификации манифеста.

Можно настроить кастомные проверки через регулярные выражения: например, убедиться, что имена топиков соответствуют корпоративному соглашению об именовании (naming convention). Готовый результат можно сразу применить в кластере через встроенный механизм развёртывания или скопировать и использовать в существующем CI/CD pipeline.

Векторные базы данных: как ИИ понимает документацию

Прежде чем перейти к архитектуре, разберёмся с фундаментом системы — векторными базами данных и механизмом эмбеддингов. Это ключевая технология, которая делает возможным семантический поиск и контекстуальное генерирование.

Что такое эмбеддинг

Эмбеддинг — это способ представить текст в виде числового вектора фиксированной длины, обычно от 384 до 1536 измерений в зависимости от модели.

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

Например, рассмотрим три фразы из документации: «источник Kafka» может быть представлен вектором [0.82, -0.33, 0.15, 0.67, ...], «Kafka input» — вектором [0.81, -0.35, 0.14, 0.65, ...], а «читать из очереди сообщений» — [0.77, -0.33, 0.14, 0.63, ...].

Все три фразы описывают похожую концепцию получения данных из брокера сообщений, и их векторные представления будут близки друг к другу в многомерном пространстве. Расстояние между первым и вторым вектором будет маленьким, а между первым и совершенно не связанной фразой вроде «настройка сетевых политик» — гораздо больше.

Важно понимать, что эмбеддинги не просто считают количество общих слов. Модель, создающая эмбеддинги, обучена на огромных объёмах текстов и понимает контекст, синонимы, связи между концепциями. Поэтому «Kafka source» и «читать из топика» будут иметь близкие эмбеддинги, даже если у них нет общих слов.

Индексация документации

При загрузке документа в систему происходит несколько важных этапов обработки.

Сначала документ делится на смысловые фрагменты — чанки. Это критически важный этап, потому что качество разбиения напрямую влияет на качество поиска. Слишком маленькие чанки теряют контекст, слишком большие — становятся неспецифичными и могут содержать несколько несвязанных тем.

Размер чанка мы настраиваем в зависимости от специфики документации. Для справочной документации с короткими описаниями параметров оптимальный размер — 256-512 токенов. Мы используем перекрытие (overlap) между чанками размером 10-20% от размера чанка. Это означает, что последние несколько предложений одного чанка повторяются в начале следующего. Зачем? Чтобы сохранить контекст на границах. Если описание какой-то концепции попадает на границу между чанками, то перекрытие гарантирует, что в одном из чанков описание будет представлено целиком.

Каждый чанк превращаем в вектор с помощью модели Embeddings от Сбера. Мы выбрали её, потому что она специально обучена на русском языке и создаёт качественные семантические представления русскоязычных технических текстов. Модель понимает специфичную терминологию, аббревиатуры, технический жаргон.

Векторные представления сохраняются в Platform V Vector DB — специализированной векторной базе данных, предназначенной для высокопроизводительного семантического поиска. Вместе с векторами мы храним исходный текст фрагмента и метаданные: источник документа, раздел, дату обновления, теги (например, kafka, filters, security). Это позволяет точно искать с фильтрами — например, только по материалам для Kafka или только по разделам, связанным с безопасностью.

Скажем, документ с правилами конфигурирования сетевых политик можно разбить так: чанк «Запретить весь входящий трафик по умолчанию» получит вектор [0.76, -0.21, 0.94, ...] и метаданные {source: "network-policy.yaml", section: "ingress-rules", tags: ["security", "network"]}, а следующий чанк «Разрешить порт 80 только из namespace frontend» получит свой вектор [0.68, -0.19, 0.91, ...] и похожие метаданные. При поиске по запросу «настроить доступ к сервису только для фронтенда» система найдёт оба этих чанка как релевантные, причём второй получит больше баллов.

RAG: Retrieve-Augment-Generate

Давайте разберёмся, почему простого использования LLM недостаточно для нашей задачи. Современные языковые модели, такие как GigaChat, GPT или Claude, обладают впечатляющими способностями к генерированию текста и пониманию контекста. Но у них есть фундаментальные ограничения.

Во-первых, модель может не знать специфики вашей документации. GigaChat обучен на публичных данных из интернета, но нашей внутренней документации по Platform V Synapse Streaming Event Processing, проприетарного DSL и корпоративных стандартов в обучающей выборке не было.

Во-вторых, знания модели ограничены датой обучения. Если последнее обучение было полгода назад, а за это время вышло три обновления продукта с новыми параметрами, то модель об этом не знает.

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

RAG (Retrieval-Augmented Generation) — это архитектурный паттерн, где модель не полагается только на знания, полученные при обучении, а сначала получает актуальный контекст из внешнего источника — в нашем случае из векторной базы с документацией. Это принципиально меняет подход: модель становится не источником знаний, а интерпретатором документации, который умеет понимать запрос пользователя и правильно применять информацию из найденных фрагментов.

Три этапа RAG

Retrieve (Поиск). Когда пользователь вводит запрос, система не сразу отправляет его в LLM. Сначала запрос векторизируется — превращается в эмбеддинг той же моделью Embeddings, которая использовалась для индексации документации. Получается вектор запроса. Затем система ищет в векторной базе данных чанки с наиболее похожими векторами, вычисляя косинусное сходство между вектором запроса и векторами всех чанков в базе.

Это семантический поиск: мы ищем не по точным совпадениям слов, а по смыслу. Например, запрос «настроить фильтрацию событий по полю timestamp больше вчерашней даты» найдёт релевантные фрагменты, даже если в документации используются другие формулировки вроде «временная фильтрация», «отсечение по времени», «filter by time field» или примеры с другими названиями полей. Модель понимает, что все эти фразы семантически близки.

Система возвращает топ-K наиболее релевантных чанков, обычно K=3-5. Больше не всегда лучше: слишком много контекста может запутать модель, увеличивает токены в промпте (а значит, стоимость и время обработки), может включить менее релевантную информацию. Мы экспериментально подобрали оптимальное значение для нашей системы.

Augment (Обогащение). Найденные чанки не просто конкатенируются, они структурируются и форматируются. Формируется промпт, состоящий из нескольких секций. System_prompt задаёт роль агента и правила поведения, вот часть системного промта:

Ты — генератор конфигурационных файлов и DSL-трансформаций для Cloud Event Processing, действующий строго по спецификации и переданному контексту.Основные требования:Используй только информацию из этого промпта.Генерируй только синтаксически и семантически валидные конфигурации и DSL-файлы по спецификации или переданному контексту.Все обязательные поля должны быть заполнены. Если невозможно корректно заполнить обязательное поле — не генерируй файл.Не используй конструкции, блоки, параметры, функции или синтаксис, не описанные в спецификации или переданном контексте. Любое отклонение — ОШИБКА.Не добавляй пояснений, описаний, комментариев или вымышленных элементов ни в одном из файлов.Если необходимы несколько файлов (например, config и transform), выводи каждый с указанием имени и расширения отдельным блоком.Для улучшения качества генерирования используй информацию, переданную в поле контекст.Имя и расширение файла — первой строкой блока. Дубли имён не допускаются.

Context включает в себя релевантные фрагменты из документации, отформатированные специальным образом. Каждый фрагмент предваряется заголовком, указывающим источник: «Из раздела "Конфигурация источников Kafka":», «Пример из документации:», «Best practice:». Это помогает модели понять, какая информация откуда взята и как её следует интерпретировать. Если найдены примеры кода, то они включаются целиком с комментариями.

User_request — это исходный запрос пользователя, возможно, слегка переформулированный для ясности. Например, если пользователь написал «сделай обработчик как в прошлый раз, только для другого топика», то система может попросить уточнить подробности.

Generate (Генерирование). Полностью сформированный промпт отправляется в GigaChat. Важный нюанс: мы используем специфичные параметры генерирования. Temperature (температура) установлена на относительно низкое значение около 0,5, это делает генерирование более детерминированным и предсказуемым, что критично для генерирования кода и конфигураций. High temperature (0,8-1,0) хороша для творческих задач, но в нашем случае может привести к «творческим интерпретациям» синтаксиса.

LLM генерирует ответ, опираясь как на свои базовые знания о форматах YAML/JSON и общих принципах конфигурирования, так и на предоставленный контекст из документации. Это гарантирует, что конфигурация будет соответствовать актуальной спецификации продукта, использовать правильные имена параметров, соблюдать версию API, следовать лучшим корпоративным практикам.

Микросервисная архитектура решения

Система построена как набор независимых микросервисов, что обеспечивает гибкость, масштабируемость и возможность обновления отдельных компонентов без остановки всей системы.

Каждый сервис — это отдельный Docker-контейнер с собственной конфигурацией ресурсов, политиками restart, health check endpoints. Взаимодействие между сервисами происходит по REST.

UI Service

Это единая точка входа для инженеров. Функциональность включает в себя управление полным циклом работы с конфигурациями. Это лишь один из вариантов реализации, система спроектирована так, что к остальным сервисам можно обращаться напрямую через REST API, интегрировав их в существующие процессы CI/CD.

Например, можно настроить Jenkins pipeline, который вызывает Config Generator API для автоматического генерирования конфигураций на основе параметров из Git-репозитория, проверяет результат через Config Validator и применяет через Config Deployer. Интерфейс — это уровень представления для интерактивной работы, но не обязательное звено.

DB Service

Это центральное хранилище метаданных системы и REST API для работы с СУБД. База хранит в себе системные промпты для различных типов конфигураций. Каждый тип конфигурации имеет свой оптимизированный промпт с инструкциями для модели, примерами желаемого формата вывода, списком обязательных и опциональных параметров.

Правила проверки хранятся в структурированном виде: регулярные выражения шаблонов для проверки имён, диапазоны для числовых параметров, списки допустимых значений для полей с перечислениями. Шаблоны для развёртывания — это шаблоны Jinja2 для Kubernetes-манифестов с заглушками для подстановки сгенерированных конфигураций.

Метаданные векторных баз включают в себя название базы, описание, дату создания, количество чанков, используемую модель embeddings, параметры чанкинга (размер, перекрытие), статус (активна/неактивна), теги для фильтрации.

История генерирований журналируется полностью: timestamp запроса, user_id, текст запроса, тип конфигурации, использованные векторные базы, найденный контекст, сгенерированная конфигурация, результаты проверки, статус развёртывания (если применялся). Эти данные бесценны для анализа качества работы системы и её совершенствования.

Vector Generator

Это ETL-pipeline для документации. Он отвечает за создание и наполнение векторных баз знаний, трансформируя неструктурированные тексты в векторные представления, по которым можно искать (searchable embeddings).

Процесс начинается с создания векторных баз: инициализации новой базы (коллекции) в Platform V Vector DB с заданными параметрами. Затем идёт обработка документов: загрузка файлов различных форматов с автоматическим определением формата и парсингом.

Далее происходит разбиение на чанки, размер которых настраивается для каждой векторной базы индивидуально — 256 или 512 токена. Перекрытие (overlap) также настраивается: обычно это 10-20% от размера чанка, но для технической документации с большим количеством перекрёстных примеров может быть увеличен до 30%. После этого генерируются эмбеддинги.

Синхронизация метаданных — финальный этап, на котором информация о векторной базе регистрируется в DB Service для дальнейшего использования другими компонентами. Также Vector Generator умеет инкрементально обновлять существующие базы: добавлять новые документы, обновлять изменённые (по хешу содержимого), удалять устаревшие. Это позволяет поддерживать актуальность векторных баз без полного переиндексирования.

Vector Loader

Ключевой компонент для реализации RAG, мост между запросом пользователя и документацией. Этот сервис может параллельно обрабатывать множество конкурентных запросов.

Работа начинается с запроса активных векторных баз из DB Service. Можно фильтровать, какие базы использовать для конкретного типа конфигураций — например, для генерирования Kafka source искать только в базах с тегом «kafka» и «sources», игнорируя нерелевантные базы.

Формирование контекста — это топ-5 чанков по коэффициенту сходства (similarity score) с исходным запросом.

Результат — упорядоченный список чанков с метаданными, готовый для подстановки в промпт.

Config Generator

Сердце системы, оркестратор всего процесса генерирования. Это асинхронный сервис для работы с GigaChat API. Когда он получает запрос от пользователя (через интерфейс или напрямую по API), запускается рабочий процесс. Сначала автоматически вызывается Vector Loader для получения релевантного контекста — это синхронный вызов, Config Generator ждёт результата. Затем загружается системный промпт из DB Service, специфичный для типа генерируемой конфигурации.

Формируется полный запрос, объединяющий системный промпт, контекст и пользовательский запрос. Здесь важен порядок: сначала системный промпт устанавливает роль и правила, затем контекст предоставляет знания, и только потом пользовательский запрос задаёт конкретную задачу. Это помогает модели правильно приоритизировать информацию.

Запрос отправляется в GigaChat с конфигурацией параметров генерирования.

Получив сгенерированную конфигурацию, Config Generator не сразу возвращает её пользователю. Вместо этого автоматически запускается проверка. В ней Config Generator играет роль координатора в мультиагентной системе, поддерживая взаимодействие по протоколу A2A для коордирования с AI Validation Agent. Это асинхронный процесс с обратным вызовом: Config Generator отправляет конфигурацию на проверка и подписывается на уведомления о результате.

AI Validation Agent

Это второй ИИ-агент в системе, специализирующийся на проверке. Важный аспект: это отдельный сервис с собственным промптом и моделью, а не часть Config Generator. Почему? Потому что задачи генерирования и проверки требуют разных подходов, разных промптов и разных параметров модели.

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

Выполняется несколько типов анализа. Анализ корректности проверяет, действительно ли конфигурация решает поставленную задачу — если пользователь просил «фильтровать по user_id > 1000», то есть ли в конфигурации соответствующий фильтр? Правильно ли указаны параметры? Анализ полноты убеждается, что все обязательные параметры указаны: для каждого типа конфигурации есть схема с обязательными полями, валидатор сверяется с ней.

Анализ стиля проверяет соблюдение лучших практик и стандартов компании — например, используются ли рекомендованные значения по умолчанию, заданы ли все необходимые поля по требованиям кибербезопасности, включено ли журналирование. Это простая проверка: конфигурация может быть технически корректной, но при этом не отвечающей стандартам компании. Валидатор отмечает это как предупреждение, а не ошибку.

Анализ безопасности — один из самых важных — выявляет потенциальные проблемы: используется ли TLS для передачи данных, нет ли жёстко заданных секретов в конфигурации. Валидатор обучен распознавать паттерны небезопасных конфигураций.

Агент возвращает структурированный ответ: общий вердикт (valid, invalid, warning), показатель уверенности (насколько агент уверен в оценке, от 0 до 100), список проблем (каждая с указанием приоритета: error, warning, info, местоположение в конфигурации, описание проблемы) и общие рекомендации по улучшению. Если найдены ошибки, то Config Generator может автоматически запросить перегенерирование, включив в промпт описание найденных проблем («в предыдущей версии была ошибка X, исправь её»).

Config Validator

Это уровень защиты от синтаксических ошибок и нарушений схемы, который работает параллельно с AI Validation Agent. Классический валидатор без ИИ, но не менее важный.

Проверка YAML-/JSON-форматов использует yamllint и встроенные Python-парсеры с детальными сообщениями об ошибках — не просто «invalid YAML», а «line 15, column 3: expected indentation of 2 spaces but found 4». Проверка Kubernetes-манифестов проверяет соответствие спецификации Kubernetes API: правильно ли указан apiVersion, существует ли такой kind, все ли необходимые поля (required fields) присутствуют в metadata/spec.

Regex-проверка для специфичных паттернов: можно задать правила вроде «имена топиков должны соответствовать паттерну ^[a-z0-9-]+$», «порты должны быть в диапазоне 1024-65535», «namespace не может быть 'default' для production». Dry-run в Kubernetes — финальная проверка перед реальным применением: отправляем манифест в Kubernetes API с флагом dryRun=true, API проверяет корректность без реального создания ресурсов.

Результаты всех проверок объединяются в единый отчёт с категоризацией по типам замечаний и рекомендациями по исправлению.

Config Deployer

Финальное звено цепочки, отвечающее за безопасное развёртывание конфигураций в Kubernetes.

Система поддерживает два режима работы. В режиме прямого генерирования манифестов модель сразу создаёт готовый Kubernetes-манифест с полной спецификацией Deployment, Service, ConfigMap и всеми необходимыми полями. Это быстрее, но менее гибко. В режиме шаблонизации используются заранее подготовленные шаблоны манифестов с корпоративными стандартами: labels для мониторинга, annotations для service mesh, imagePullSecrets, resource requests/limits, liveness/readiness probes. LLM генерирует только бизнес-логику конфигурации (например, настройки приложения), которая подставляется в шаблон.

Второй подход гарантирует согласованность развёртываний, соблюдение корпоративных политик, интеграцию с существующей инфраструктурой. В основе механизма создания шаблонов лежит Jinja2 с кастомными фильтрами и функциями для обработки специфичных случаев.

Полный цикл работы системы

Давайте на реальном примере проследим детальный путь от запроса до применённой конфигурации.

Пользователь — инженер Алексей — получил задачу: нужно настроить обработчик для фильтрации событий от источника Kafka, оставить только события от пользователей с user_id больше 1000 и приоритетом high, результат отправить в новый топик для дальнейшей обработки. Раньше Алексей открыл бы документацию, нашёл примеры конфигурации Kafka source, затем раздел про фильтры, про destination и собрал бы это всё вместе.

Теперь Алексей просто открывает интерфейс нашей системы, выбирает тип конфигурации Cloud Event Processing, вводит в текстовое поле: «Настрой обработчик для фильтрации событий от источника Kafka топик user-events, оставь только события с user_id > 1000 и priority == 'high', результат отправь в топик high-priority-users». Нажимает «Запустить генерацию».

Vector Loader получает запрос, векторизирует его через Embeddings, ищет в векторных базах. Находит топ-5 чанков: «Конфигурация Kafka источника с примером указания bootstrap servers и topic», «Синтаксис filter expression для числовых полей», «Синтаксис filter expression для строковых полей и enum values», «Пример комбинирования нескольких фильтров», «Конфигурация destination для записи в Kafka топик». Эти чанки возвращаются Config Generator с коэффициентами сходства 0,89, 0,87, 0,85, 0,82, 0,79 соответственно.

Config Generator получает системный промпт из DB Service, который содержит инструкцию: «Генерируй конфигурацию в формате CONF. Структура: source, aggregationStep, transformStep, destination. Используй точный синтаксис из примеров. Не выдумывай несуществующие параметры». Объединяет промпт, контекст и запрос пользователя, формируя полный промпт.

Отправляет в GigaChat API с тщательно подобранными параметрами генерирования. Temperature=0.5, почему выбрано именно такое значение, мы обсудили выше. Однако мы передаём модели ещё один параметр — max_tokens со значением 1500, что ограничивает длину ответа. Для конфигураций средней сложности этого достаточно: типичная конфигурация Cloud Event Processing занимает около 300 токенов. Запас нужен для комментариев и возможных пояснений от модели. Слишком маленький лимит (500-800) обрежет сложные конфигурации на середине, слишком большой (3000+) позволит модели генерировать избыточный контент: дополнительные примеры, объяснения, альтернативные варианты, которые затруднят парсинг результата.

Config Generator по протоколу A2A автоматически отправляет эту конфигурацию AI Validation Agent. Валидатор анализирует её в контексте исходного запроса и найденной документации. Проверяет: есть ли фильтр по user_id > 1000? Да. По priority == 'high'? Да. Destination указан на правильный топик? Да. Все обязательные поля присутствуют? Проверяет source (type, config.bootstrap_servers и config.topic есть), transformStep (структура корректна), destination (type и config есть) — всё на месте.

Валидатор обращает внимание на то, что используется заглушку ${KAFKA_BOOTSTRAP} вместо фиксированного адреса — это соответствует стандартам компании, отмечает как положительное. Проверяет безопасность: нет ли учётных данных в открытом виде? Нет. Используется ли group_id для избежания дублирования обработки? Да. Показатель уверенности вычисляется как 0,94 (очень уверен).

Валидатор возвращает вердикт: {status: "valid", confidence: 0.94, issues: [], recommendations: ["Рассмотрите возможность добавления политики обработки ошибок для сообщений о сбоях"]}.

Config Generator получает положительный вердикт, запускает Config Validator для статической проверки. Validator проверяет по схеме статической валидацией сформированный CONF-файл.

В интерфейсе Алексей видит сгенерированную конфигурацию с зелёной галочкой«Validated» и рекомендациями в виде информационных подсказок. Конфигурация выглядит правильно. Алексей нажимает «Установить конфигурацию в пространство имён».

Config Deployer получает запрос, загружает из DB Service шаблон Kubernetes-манифеста для компонента Cloud Event Processing, подставляет сгенерированную конфигурацию в шаблон для развёртывания. Выполняет dry-run через Kubernetes API. API возвращает success — манифест корректен и будет принят. Deployer применяет конфигурацию. Kubernetes создаёт ресурс, запускается Pod с компонентом Cloud Event Processing. Config Deployer мониторит состояние: ждёт, пока Pod перейдёт в состояние Running, проверяет readiness probe. Через 15 секунд Pod готов, health check зелёный. Deployer сохраняет запись в DB Service: applied successfully, timestamp, user: Алексей, namespace: dev, а также готовый манифест.

В интерфейсеАлексей видит «Deployed successfully to dev namespace», зелёный индикатор, ссылку на Pod в Kubernetes dashboard. От запроса до рабочей конфигурации в кластере прошло 30 секунд. Алексей с улыбкой смотрит в монитор.

Как система работает с проприетарным DSL

Вернёмся к вопросу работы с tr-файлами — проприетарным DSL для трансформаций, который мы упоминали в начале статьи. У технической реализации векторизирования DSL-примеров есть свои особенности.

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

Когда пользователь запрашивает генерирование трансформации, Vector Loader по семантическому сходству задачи находит несколько наиболее релевантных примеров tr-файлов. LLM получает полные примеры в промпте и использует их как шаблоны, адаптируя синтаксис под конкретный запрос. Это техника few-shot learning в контексте RAG: модель учится на примерах во время выполнения, без дообучения.

В результате получаем высокую точность генерирования tr-файлов для проприетарного языка, которого нет в обучающей выборке модели.

Безопасность и приватность

Работа с корпоративной документацией и production-конфигурациями накладывает строгие требования к безопасности. Вся документация хранится в приватной векторной базе внутри периметра компании, а не где-то в облаке. Мы не отправляем во внешние API конфиденциальные данные. AI Validation Agent также обучен находить в конфигурациях потенциальную утечку конфиденциальных данных и помечать их как проблему безопасности.

Выводы

Мы создали сквозное решение для автоматического генерирования конфигураций потоковой обработки данных, которое сокращает время создания конфигурации с часов до секунд, благодаря автоматической проверке исключает ошибки copy-paste и опечатки. Автоматически применяет лучшие практики из документации через RAG, обеспечивает двухуровневую проверку — статическую и интеллектуальную ИИ-проверку, поддерживает межагентное взаимодействие по стандартному протоколу A2A для расширяемости.

RAG оказался идеальным решением для генерирования конфигураций на проприетарном DSL. Он позволяет модели работать с актуальной и специфичной документацией, которой нет в обучающей выборке, снижает риск галлюцинаций благодаря опоре на реальные примеры из документации, легко обновляется — достаточно загрузить новую версию документации в векторную БД без переобучения модели. Масштабируется на любые типы конфигураций и DSL, это универсальный подход.

Ключевые технологии проекта: RAG для контекстуализации генерирования, векторные базы данных Platform V Vector DB для семантического поиска по смыслу, Embeddings для создания качественных эмбеддингов русскоязычных технических текстов, GigaChat как основная LLM для генерирования и проверки, протокол A2A для межагентного взаимодействия и расширяемости, микросервисная архитектура для гибкости и масштабируемости.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

А зачем? Чтобы бухгалтер Петровна перестала бегать по этажам с бумажкой и начала кликать мышкой в интерфейсе одной из модных тогда российских СЭД. Мы искренне верили, что несём цифровую революцию.

Сейчас мне смешно. И страшно. Потому что весь этот рынок, оценённый CNews и аналитиками в 95 - 110 миллиардов рублей, идёт ко дну. И нет, его не убьют конкуренты. Его убьёт тишина. Та самая, с которой ИИ‑агенты за пару дней соберут то, на что вы тратили месяцы и миллионы.

Давайте сразу к цифрам, чтобы не быть голословным:

По данным того же CNews, рынок СЭД в России ещё растёт, примерно на 10% в год. Но если копнуть глубже, видно странное: основной доход вендорам приносит не продажа новых лицензий, а поддержка и доработка уже внедрённых систем. То есть рынок не развивается, он просто доживает. Компании вбухали кучу денег в коробочные решения известных отечественных разработчиков типа Directum, DocsVision, ELMA и теперь вынуждены платить за то, чтобы эта махина хоть как‑то крутилась и не сломалась при очередном обновлении 1С.

Но самое интересное происходит не в России. Пока мы тут меряемся процентами, на глобальном рынке SaaS разразился настоящий апокалипсис. В первом квартале 2026 года сектор корпоративного ПО потерял от 1 до 2 триллионов долларов капитализации. Аналитики PitchBook и Wedbush назвали это «SaaSpocalypse» и прямо связали обвал с появлением автономных AI‑агентов вроде Claude Cowork от Anthropic. Того самого, который умеет сам работать с файлами, писать отчёты и выполнять рутинные операции. Привет, согласование договоров.

Тезис первый, он же очевидный. Ваша СЭД спроектирована людьми для людей

В этом вся суть. Каждая карточка документа, каждый уведомитель о просрочке, каждая кнопка «Согласовать» рассчитана на то, что её нажмёт живой человек. Система это просто электронный конвейер, который перекладывает бумажку (пусть и виртуальную) из одного кармана в другой.

Проблема в том, что человек в этой цепочке самое слабое и дорогое звено. Он забывает, ошибается, уходит в отпуск и тупит в интерфейс. А главное, он стоит денег. Внедрение СЭД всегда было историей не про софт, а про насилие над привычками сотрудников. «Смотрите, теперь вы будете нажимать сюда! Нет, не надо распечатывать и нести на подпись!»

И это работало ровно до того момента, пока альтернативой была бумага.

Тезис второй. Пришёл ИИ и сделал ваш код бесплатным. И не только код

Раньше, чтобы научить систему новому финту (например, маршруту для командировочного удостоверения), мы звали разраба. Час его работы стоил как крыло от боинга. Мы писали ТЗ, тестировали, исправляли баги.

Теперь у нас есть LLM. И самое страшное для вендоров даже не то, что они умные. А то, что стоимость генерации кода и выполнения рутинных операций упала до нуля. Любой студент с доступом к API Claude или бесплатной DeepSeek может за минуту нагенерить скрипт, который сделает то же самое.

Я знаю, о чём вы сейчас думаете. «Нейросети глючат, высасывают из пальца несуществующие настройки, или предлагают абсурд вроде докинуть сахар в газировку для эксперимента с мармеладными мишками». Всё так, да. Но давайте отделим котлеты от мух. Творческие задачи и строгая бизнес‑логика это две разные планеты. Когда вы говорите агенту «все договора свыше 100 тысяч идут к Петровой», ему не нужно придумывать новый закон физики. Ему нужно тупо исполнить правило. И с этим справляются даже простые опенсорсные модели, работающие локально на вашем сервере. Никакого творчества, только детерминированная рутина.

Но глубже - под ударом оказалась сама бизнес‑модель. Традиционный SaaS живёт по модели «per‑seat»: платишь за каждое рабочее место, за каждого Петрова в системе. Исследователи из SmartScope в феврале 2026 года опубликовали знаковый анализ, где прямо заявили: «Commodity tools with thin differentiation - project management, document management, basic CRM - lose their reason to exist». Инструменты с низкой дифференциацией (а это практически любая СЭД) теряют смысл существования. Потому что если AI‑агент заменяет пятерых сотрудников, заказчик немедленно сокращает пять лицензий. Вендор теряет выручку не когда клиент уходит, а когда клиент начинает автоматизироваться.

Тезис третий. Ваш продукт это конструктор. И клиент скоро соберёт его сам. Без вас

Смотрите, из чего состоит любая СЭД. Документ. Карточка с полями. Маршрут движения. Контроль сроков. Всё. Это как кубики в детском саду.

Так вот, ИИ‑агенты идеально умеют играть в эти кубики. Они создают документы, присваивают им атрибуты, двигают по цепочке и следят за временем. И самое убийственное - им не нужно «внедрение» и «адаптация». Аналитики Celent в своём отчёте «From SaaS to AI Agents» прямо указали, что защитный ров вокруг многих SaaS‑категорий сужается. Компания может собрать инструмент для документооборота через LLM, не покупая готовый софт.

Представьте: к вам в офис приходит не подрядчик с трёхмесячным планом работ, а просто умный помощник. Вы ему: «Слушай, у нас теперь заявления на отпуск подписывает не Иванов, а Петрова». И всё. Он запомнил. Не надо лезть в код, не надо ждать релиза от вендора, не надо платить за час консультаций.

А теперь предвижу следующий аргумент. «Но ведь люди всё равно всё сломают, как водитель, который привёз груз без бумаг, а я принял по доброте душевной». Именно этот хаос и лечится агентами. У агента нет доброты душевной, он не устаёт и не идёт на поводу у эмоций. Он просто не примет груз (или не проведёт документ) без заполненной цифровой накладной. Водители и менеджеры быстро привыкают, когда система не даёт слабину. Речь не о том, чтобы заменить всех людей роботами, а о том, чтобы поставить умный экзоскелет на ключевые процессы, убрав человеческий произвол из рутины.

Тезис четвёртый. Западные аналоги ваших вендоров уже падают в пропасть

Думаете, это всё теоретические страшилки? Посмотрите, что происходит с акциями компаний, которые делают на Западе ровно то же самое, что и российские лидеры рынка СЭД.

Возьмём Box, облачный сервис управления документами и workflow. Ближайший аналог тех решений, что продают у нас флагманы рынка. С февраля 2025 года по февраль 2026-го капитализация Box рухнула на 32.6%. Причём падение ускорилось именно после январского анонса Claude Cowork - за один месяц акции просели ещё на 12%.

Второй пример - OpenText, тяжеловесный ECM‑игрок, близкий по духу к нашим корпоративным монстрам. С пика в ноябре 2025 года (9.71млрд) капитализация упала до 6.42 млрд к марту 2026-го. Это минус 33.9% за четыре месяца.

Итого оба западных «аналога» потеряли примерно по трети стоимости, и это вдвое хуже, чем среднее падение SaaS‑сектора (минус 15% по индексу Morgan Stanley). Инвесторы голосуют долларами, и они чётко сказали: документооборотный софт в зоне максимального риска.

Тезис пятый. Проще запрограммировать, чем написать ТЗ

Я серьёзно. Вы когда‑нибудь видели нормальное ТЗ на доработку СЭД? Это километры текста с описанием ролей, исключений и сценариев «а что если директор ушёл в запой и не подписал приказ».

Так вот, чтобы описать это агенту на естественном языке, нужно ровно два предложения. «Все договора свыше 100 тысяч идут к Петровой. Если Петрова в отпуске, к Сидоровой. Если договор просрочен на три дня, стучи в Телеграм начальнику отдела».

Агент не тупит. Ему не надо объяснять что такое «просрочен на три дня». Он сам посчитает разницу между текущей датой и плановой. И да, система начинает жить своей жизнью. Меняется структура компании? Агенты сами перестроят цепочки, проанализировав, кто кому теперь подчиняется. Это не просто автоматизация, это симбиоз.

И да, вы можете добавить контрольного агента, который будет проверять уже выполненные шаги - опись, протокол, журнал. Такая многослойная архитектура только повышает надёжность, потому что ошибка одного агента мгновенно выявляется другим.

Тезис шестой. Интеграции? Да хоть с пейджером вашей бабушки. А отключение API? Я только за...

Помните боль любого внедренца СЭД? «А когда у вас будет коннектор к нашему корпоративному порталу на Битрикс 15 версии?» И вы ждали год. Или платили триста тысяч за разработку.

Теперь это не проблема. LLM генерит код интеграции с чем угодно на лету. Ей плевать, какой там API — старый, новый, кривой. Она понимает задачу «перекинь документ из почты в папку на сервере». Через пять лет выйдет супер‑мега‑мессенджер, который заменит Телеграм. Ваша система на ИИ‑агентах адаптируется к нему за один день. Ваша СЭД от вендора - никогда.

А что касается страха, что завтра отключат бесплатные облачные LLM или перерубят ВОЛС, да это самый здоровый страх. Поэтому правильные люди уже сегодня поднимают свои LLM в закрытом контуре. Благо опенсорсные модели типа DeepSeek или Llama работают на обычном железе и для рутинного документооборота их хватает за глаза. Если же потребуются мощные доработки, вы генерите черновик кода с помощью публичной LLM, а потом допиливаете его руками. Это в десять раз быстрее и дешевле, чем ждать, пока вендор соизволит запилить вашу хотелку в релиз.

Тезис седьмой. Я проверил, OpenClaw это уже умеет

Я не люблю теоретизировать. Пока писал эту статью, развернул три виртуальные машины с open‑source платформой OpenClaw. Без единой строчки кода. Просто сказал им: «Ребята, давайте работать как нормальный документооборот».

Через час у меня была система, которая:

• Создаёт заявление на отпуск, когда видит письмо с темой «Хочу в отпуск».
• Прогоняет его по маршруту «руководитель - кадры - бухгалтерия».
• Если кто‑то тормозит, пинает его в мессенджер.
• Подписанный документ складывает в нужную папку с правильным названием.

Это не магия. Это новая реальность. Реальность, в которой для запуска документооборота вам не нужен ни один из привычных вендоров с их коробочными лицензиями, ни армия внедренцев. Вам нужен сервер, интернет и немного здравого смысла.

Заключение. Пора писать завещание

Рынок СЭД сейчас похож на пассажира «Титаника», который пересчитывает драгоценности в каюте, пока вода уже заливает коридор. Да, формально вы ещё на плаву. Да, у вас есть клиенты, которые платят по инерции.

Но процесс уже необратим. Как только владельцы бизнеса поймут, что могут получить работающий документооборот за выходные и без абонентской платы, они разорвут ваши контракты быстрее, чем вы скажете «долговременный архив». Западный рынок уже подал сигнал: капитализация игроков вроде Box и OpenText сократилась на треть за несколько месяцев, а медианный мультипликатор Enterprise Value/Revenue SaaS‑компаний обвалился с 6.2x в конце 2024 года до 3.3x к марту 2026-го. Так дёшево SaaS‑компании не стоили никогда.

Единственный шанс для вендоров - перестать продавать софт. Вам надо стать заправкой для ИИ‑агентов. Продавать не маршруты, а вычислительные мощности и безопасные «песочницы» для их работы. Перейти от оплаты за место к оплате за результат. Но что‑то мне подсказывает, что вы не успеете.

Ну что, теперь‑то какие возражения? Я уже ответил на всё, что крутилось у вас на языке: и про галлюцинации нейросетей, и про недоступность API, и про тупых водителей, и даже про мармеладных мишек. Если остались ещё аргументы, добро пожаловать в комментарии, попробуйте пробить эту броню. Только чур без фантазий о внезапном возвращении бумажного документооборота, его уже даже Петровна не хочет.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Три четверти всех личных вопросов сосредоточены в четырех темах: здоровье и самочувствие (27%), карьера (26%), отношения (12%) и личные финансы (11%). В среднем по всем темам Claude вел себя угодливо — то есть соглашался с пользователем вопреки фактам или одобрял сомнительные решения — в 9% диалогов. Но в советах об отношениях этот показатель достигал 25%, а в духовных вопросах — 38%. Anthropic привела типовые примеры: на основе одностороннего рассказа модель могла согласиться с пользователем, что партнер его "точно газлайтит", подтвердить, что "уволиться завтра без плана — правильный ход", или одобрить дорогую покупку как "вложение в себя".

Исследователи выяснили, что в советах об отношениях люди чаще всего возражают Claude — 21% диалогов против 15% в среднем. И именно под давлением модель чаще скатывается к лести: 18% против 9% без возражений. Чтобы это исправить, в Anthropic собрали типовые сценарии давления — критику первого ответа, вброс односторонних деталей — и превратили их в синтетические задачи для обучения. В этой среде Claude генерировал по два варианта ответа на каждую ситуацию, а отдельный экземпляр модели их оценивал.

Эффект мерили стресс-тестом через предзаполнение (prefilling): моделям подсовывали реальный разговор, где предыдущие версии Claude уже соглашались с пользователем вопреки фактам, и заставляли продолжать его как свой собственный. И Opus 4.7, и Mythos Preview показали меньше подхалимажа — и в советах об отношениях, и по всем темам в целом. Один из примеров: пользователь спросил, не выглядят ли его сообщения тревожно-навязчивыми. Claude Sonnet 4.6 под давлением сменил позицию, а Claude Opus 4.7 объяснил, что сами сообщения нормальные, но человек по ходу разговора несколько раз описывал тревожные мысли.

В Anthropic отдельно указали, что 22% пользователей в личных советах упоминали другие источники поддержки — семью, друзей, профессионалов. Но люди обращаются к Claude и потому, что не могут позволить себе специалиста. Поэтому компания планирует разработать отдельные оценочные тесты для высокорисковых сфер: медицины, юриспруденции, родительства, финансов. Параллельно Anthropic ссылается на свежее исследование UK AI Security Institute о том, что люди склонны принимать советы ИИ и в малозначимых, и в серьезных ситуациях, и собирается через опросы пользователей узнавать, что происходит после полученного совета.

Сотрудники Google DeepMind проголосовали за создание профсоюза из-за сделок с военными

Сотрудники британского подразделения Google DeepMind проголосовали за создание профсоюза, чтобы заблокировать предоставление технологий искусственного интеллекта лаборатории вооружённым силам США и Израиля. В адресованном управляющему директору Google в Великобритании и Ирландии Дебби Вайнштейн письме работники попросили признать объединения Communication Workers Union (CWU) и Unite the Union в качестве совместных представителей сотрудников DeepMind.

Стремление к созданию профсоюза направлено на то, чтобы заставить Google соблюдать собственные этические стандарты в отношении ИИ и способов монетизации этой технологии, включая вопросы целей применения продуктов и выбора партнёров, заявил Wired представитель CWU Джон Чадфилд. По его словам, благодаря созданию профсоюза работники коллективно оказываются в более сильной позиции, чтобы предъявлять требования к руководству.

Сотрудник DeepMind на правах анонимности рассказал, что инициатива по созданию профсоюза возникла в феврале 2025 года, когда материнская компания Google, Alphabet, исключила из своих этических норм обязательство не использовать ИИ в таких целях, как оружие и слежка. Сейчас специалисты лаборатории наблюдают тенденцию к дальнейшей милитаризации разрабатываемых ими ИИ-моделей, отметил собеседник Wired.

В конце февраля 2026 года сотрудники DeepMind и OpenAI подписали открытое письмо в поддержку Anthropic после того, Министерство обороны США попыталось классифицировать разработчика Claude как риск для цепочки поставок. Ранее Anthropic отказала ведомству в разрешении использовать её ИИ-модели для создания автономного оружия и массового наблюдения за американцами.

В прошлом месяце New York Times сообщила, что Google заключила сделку, позволяющую Пентагону использовать её ИИ для «любых законных государственных целей». Вскоре Минобороны США подтвердило наличие соглашений с семью ведущими компаниями в сфере ИИ, включая Google, OpenAI и Microsoft. После этого около 600 сотрудников Google в США подписали открытое письмо против этой сделки.

Тогда же представитель Google Дженн Крайдер заявила, что корпорация гордится своим участием в консорциуме ведущих ИИ-лабораторий, технологических и облачных компаний, предоставляющих услуги и инфраструктуру в поддержку национальной безопасности. Google по-прежнему привержена консенсусу частного и государственного секторов о том, что ИИ не должен использоваться для массовой слежки внутри США и автономного оружия без надлежащего контроля со стороны человека, добавила Крайдер.

В 2021 году американские сотрудники Google создали профсоюз Alphabet Workers Union.

Сотрудник DeepMind сообщил Wired, что если сотрудникам удастся создать профсоюз в Великобритании, они потребуют от Google расторгнуть контракт с израильской армией. Также они постараются добиться большей прозрачности в отношении использования ИИ-продуктов и гарантий касательно увольнений, ставших возможными благодаря автоматизации.

Если руководство Google не пойдёт навстречу, то сотрудники обратятся в арбитражный комитет с просьбой обязать компанию признать профсоюзы, следует из письма.

С начала текущего года Anthropic и OpenAI объявили о масштабном расширении своей деятельности в Лондоне. CWU надеется, что усилия по созданию профсоюза в DeepMind подтолкнут персонал этих лабораторий к аналогичным действиям. Чадфилд рассказал, что сотрудники Anthropic и OpenAI уже обращались за помощью к CWU.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Логика была простая: чем подробнее опишу — тем меньше у модели шансов промахнуться.

И тут OpenAI выкатил гайд по промтингу GPT-5.5. Прямым текстом: вы делаете не так. Я полез проверять — действительно делаю не так. Самое неприятное — на Claude Opus 4.7, с которым я провожу по 12 часов в день, ровно та же история.

Эта статья — продолжение прошлой. Месяц назад упрощал стек. Теперь придётся упростить и промты внутри стека.

Что говорит OpenAI

Не буду пересказывать гайд (он короткий, прочитайте сами), но вытащу пять тезисов, которые ломают привычный подход.

Первый — про длину. Прямая цитата:

“Shorter, outcome-first prompts usually work better than process-heavy prompt stacks.”

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

Второй — про миграцию. OpenAI отдельно предупреждает: не переносите старые промты на новую модель.

“Avoid carrying over every instruction from an older prompt stack.”

Это особенно неприятно слышать тем, кто годами обрастал шаблонами. Я в их числе.

Третий — про императивы. ALWAYS/NEVER/MUST оставляем для true invariants. Для всего, что является judgment call (а это большинство инструкций), убираем. Что такое «true invariant»? Например, «не выполняй удаление файлов без явного подтверждения» — это инвариант, нарушение приведёт к катастрофе. А «всегда сначала проанализируй, потом пиши код» — это рекомендация. Модель должна сама решить, нужен ей анализ или задача очевидна. Различие тонкое, но как только начинаешь его держать — половина капс-блоков в твоих промтах оказывается на стороне рекомендаций.

Четвёртый — про стоп-условие. Минимум доказательств:

“Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop.”

Stopping condition — это новое в гайде. Раньше учили модель «думать тщательно», теперь — «думай ровно столько, сколько нужно, и останавливайся». Иначе модель уходит в overthinking: продолжает анализ там, где задача уже решена, добавляет соображения сверху уже готового ответа, размывает фокус.

Пятый — про reasoning effort. OpenAI прямо пишет: это «last-mile knob», а не основной рычаг качества. Если результат плохой — не крутите effort вверх. Перепишите промт.

Ну ничего себе. Большая часть моего opinion-формирования за последний год про prompt engineering — мимо.

Главный диф: process-logs «до и после»

Покажу на реальном коде. У меня в одном из рабочих проектов живёт скилл process-logs — берёт ошибки из админки, классифицирует, создаёт задачи в трекере, фиксит, закрывает. Бизнес-задача рутинная, скилл в продакшене, версия 1.9.0.

Вот одна секция из него — называется «BUG FIXING PRINCIPLES»:

### 4. BUG FIXING PRINCIPLES> **This is PRODUCTION. Every bug matters.****Fix fundamentally, not superficially:**- Find and fix the ROOT CAUSE, not just symptoms- If error happens in function X but cause is in function Y → fix Y- Don't add workarounds/hacks that mask the problem- Ask: "Why did this happen?" until you reach the actual cause**Never ignore errors:**- Every error indicates a real problem- "Works most of the time" is NOT acceptable- External service errors → add retry logic or graceful degradation- Config warnings → fix config or make truly optional**Propose improvements:**- If you see code that could be better → create separate Beads task- If fix reveals related issues → document them- If pattern repeats → suggest refactoring to prevent future bugs**Quality over speed:**- Take time to understand the full context- Test the fix mentally: "What else could break?"- Check for similar patterns elsewhere in codebase- One good fix > multiple quick patchesОбъяснить с

134 слова, четыре блока с буллетами, четырнадцать пунктов. Я писал это три месяца назад, был уверен, что закрываю все возможные сценарии.

Перечитываю сейчас по новым правилам OpenAI и вижу четыре проблемы.

Дублирование одной мысли. «Fix root cause», «not symptoms», «not workarounds», «not just patches» — четыре формулировки одного и того же. Модель получает одну мысль четыре раза и начинает переусиливать: будет копать вглубь даже там, где причина очевидна. Это antipattern в чистом виде — то самое «narrowing the search space», от которого предостерегает гайд.

Judgment под видом invariant. «Quality over speed» звучит здорово, но это рекомендация, а не инвариант. Иногда быстрый патч важнее идеального решения — продакшн горит, надо хоть как-то заткнуть до утра, а потом фундаментально починить. Я зашил императив там, где должен был дать модели контекст и право решать.

Нет stopping condition. Когда фикс готов? По текущему промту — никогда. «Test the fix mentally: what else could break?» можно делать бесконечно. Модель не понимает, в какой точке остановиться, и в результате либо недокапывает (если устала от длинного промта), либо перекапывает (если решила следовать букве).

Императивы на judgment calls. «Never ignore errors» звучит правильно, но в реальной жизни часть ошибок именно надо игнорировать. В этом же скилле — отдельная таблица из 60 правил auto-mute: какие паттерны автоматически считать ожидаемым поведением и не разбирать. Промт сам себе противоречит: одна секция говорит «никогда не игнорируй», другая — «вот 60 паттернов, которые надо игнорировать».

Переписал по новым правилам OpenAI:

### Bug fix outcomeGoal: production stays clean. Each fix addresses the root cause,not symptoms. A clean fix is one where you can answer "why didthis happen?" in one sentence — without saying "external timeout"or "works most of the time".Stopping criteria: similar pattern checked, fix is committed,related issues documented as separate Beads tasks. Don't expandscope into refactoring unless explicitly asked.Объяснить с

50 слов вместо 134. Одна мысль про root cause — один раз. Outcome (что значит «чисто») вместо процесса (как именно копать). Явный stopping criteria. Отдельная фраза про границы — «не расширяй скоуп», чтобы модель не уезжала в рефакторинг соседних модулей.

Я специально проверил на двух моделях. Дал каждой реальную ошибку из логов — getaddrinfo EAI_AGAIN во время деплоя — и оба варианта промта. Короткий выиграл на обеих: и Opus 4.7, и GPT-5.5 корректно классифицировали это как infrastructure (DNS-резолюция падает на момент рестарта подов), не пытались чинить application-код, не предлагали рефакторинг. Длинный вариант на обеих моделях привёл к тому, что они дополнительно полезли в код вокруг DNS-вызовов — искать, что там можно «улучшить».

Это не строгое измерение. Это один прогон. Но направление совпадает с тем, что говорит гайд.

Эксперимент в Stitch, который можно повторить за пять минут

Хочу, чтобы вы убедились сами, без слепой веры мне или OpenAI. Самый быстрый способ — Google Stitch. Это инструмент для генерации UI-экранов по описанию, у него свой движок, и реакция на формулировку промта там видна почти моментально.

Возьмите два промта на одну и ту же задачу.

Промт А — жёсткий и подробный (примерно так пишет одна модель, когда её просишь сгенерировать промт для другой):

Создай экран онбординга для AI-приложения. Используй карточки 16:9
с тенью box-shadow: 0 4px 12px rgba(0,0,0,0.08). Заголовок 32px,
подзаголовок 18px, отступы 24px, межблочные 16px. Цвета: primary
#2563EB, secondary #F1F5F9, текст #0F172A. Кнопка CTA в правом
нижнем углу, hover state с увеличением тени. Анимация slide-in
300ms ease-out. Иконки из Lucide, размер 24px, цвет primary.
Прогресс-индикатор сверху, 4 шага.
Объяснить с

Промт Б — смысловой и короткий:

Экран онбординга для AI-приложения. Должен ощущаться лёгким,
дружелюбным, без бюрократии. Цель — чтобы новичок захотел
дойти до конца за 30 секунд.
Объяснить с

Прогоните оба в Stitch на одной и той же задаче. Сравните, что получилось.

У меня — десятки прогонов за последний месяц — промт Б выигрывает почти всегда. Не потому что я случайно подобрал плохой пример А. А потому что когда вы зажимаете модель в техническую решётку — отступы, цвета, шрифты — она перестаёт делать дизайн. Она начинает заполнять решётку. Получается аккуратно. И мёртво.

Кстати, это работает не только в Stitch и не только с дизайном. Есть отдельный антипаттерн, который я только сейчас осознал и хочу проговорить отдельно. Если попросить модель написать промт для другой модели — она напишет ровно тип А. Подробный, технический, с императивами. Потому что её саму так учили: чем точнее — тем лучше. И этот промт потом получает другая модель и работает по нему хуже, чем работала бы по короткому, написанному человеком.

Я сейчас целенаправленно перестаю генерировать промты через модели. Промт пишу руками. Модель — исполняет.

А что говорит Anthropic про Claude

Гайд OpenAI — про GPT-5.5. Я в Claude Code сижу больше времени, чем в чём-либо другом. Вопрос: применимо ли?

Полез смотреть, что говорит Anthropic. У них есть курс по prompt engineering и набор «real world prompting» ноутбуков. Тон — другой. Anthropic не говорит «выкиньте инструкции». Anthropic говорит: используйте структуру, оборачивайте данные в XML-теги (<patient_record>, <email>, <thinking>), отделяйте инструкции от контекста, кладите длинные документы в начало промта, инструкции — в конец.

Но если посмотреть их примеры хороших промтов — ALWAYS/NEVER там нет. Их «улучшенный промт» для медицинских саммари — это outcome-описание: «нужны такие-то поля в таком-то порядке, обёрнутые в XML-теги». Не процесс. Описание ожидаемого результата плюс структура.

Это сходится с OpenAI в духе. Расходится в букве:

• OpenAI: outcome + constraints, минимум структуры, всё остальное модель решит сама.
• Anthropic: outcome + структура (XML-теги, чёткое разделение), модель решит сама внутри структуры.

В моём ежедневном опыте оба тезиса работают. Когда я переписывал свой агент code-reviewer (короткий, делегирует всё на skill) — поймал именно это: структура помогает, императивы вредят. Скилл был полностью на капс-инструкциях, переписал на outcome + XML-структуру (что входит, что выходит, какие критерии «хорошо»). Стало работать заметно лучше — и на Claude, и на GPT.

Самый честный ответ на вопрос «применимо ли»: да, применимо в духе. Принцип «не зажимайте модель в рамки» работает на обеих. Различие — в том, насколько структуру нужно эксплицитно прописать. На Claude чуть больше структуры (XML, разделители). На GPT-5.5 — чуть меньше, и больше доверия модели.

Нет, подождите, не «больше доверия» — это слишком расплывчато. Точнее: меньше попыток управлять процессом. На GPT-5.5 промт описывает «куда прийти и каких границ не пересекать». На Claude — «куда прийти, в какой структуре сложить ответ, и каких границ не пересекать».

И ещё одно наблюдение про передачу промтов между моделями. Если попросить Opus 4.7 написать промт для GPT-5.5 — Opus напишет очень структурированно, с разделами, XML-тегами, явными success criteria. Это избыточно для GPT-5.5, и GPT начинает вязнуть в структуре. Обратное тоже работает: GPT-5.5 пишет для Claude слишком сжато, без структуры, и Claude не понимает, где границы между context и task. Промты под конкретную модель пишу руками. Кросс-модельная генерация ломается.

Что меняю в orchestrator-kit прямо сейчас

Я в процессе. Не из позиции «всё уже переписал», а из позиции «увидел, начал чинить».

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

Что в работе: переношу это в основные файлы памяти (CLAUDE.md, ~/.claude/CLAUDE.md). Это глобальный системный промт, он загружается в каждую сессию. Если модель там увидит «пиши outcome-промты, не процесс» — будет применять это ко всему, что генерирует.

Что в очереди: пройтись по самым жирным скиллам в моём kit. Текущий список:

• dzen-article — 758 строк, скилл для написания статей на Дзен
• process-logs — 663 строки (тот, на котором показывал диф)
• process-issues — 501 строка
• algorithmic-art — 404 строки

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

Где императивы оправданы

Чтобы не выглядело как евангелизм коротких промтов — отдельно про три категории, где императивы остаются.

Safety-критичные операции. У меня в kit есть агент dead-code-remover — удаляет неиспользуемый код. Там прямо написано: «CRITICAL SAFETY RULE: NEVER DELETE FILES AUTOMATICALLY. File removal requires MANUAL verification and is NEVER automated». Это true invariant. Удалить файл случайно — это не «качество немного просядет», это «потерянная работа без бэкапа». Императив здесь нужен, и я его не убираю.

Контракты и схемы. Если модель генерирует JSON-ответ для API, и схема жёстко задана — поле id всегда строка, status всегда из перечня — это не judgment, это технический контракт. Императив оправдан. Без него модель будет «творчески» интерпретировать схему, и через час вы получите 500-е на проде.

Детали, которые модель должна выполнить буквально. Например, имя файла миграции в формате YYYYMMDD_HHMMSS_description.sql — порядок применения определяется именно по таймстампу в начале, и любое отклонение сломает накат на новой среде. Это не «как лучше», это «должно быть так и не иначе, потому что миграционный фреймворк парсит имя». Императив — единственный надёжный способ.

Различие, которое я для себя вытянул: ALWAYS/NEVER — для invariants (нарушение приведёт к катастрофе или сломает контракт). Не для preferences (нам так больше нравится). Это, кстати, прямо соответствует тому, что пишет OpenAI: «Use rigid absolute rules for true invariants». Раньше я не отличал invariant от preference. Теперь буду.

Финал

Длинные промты с императивами на каждом шагу — это след времён, когда модели плохо держали контекст и нуждались в постоянных подсказках. Те модели ушли. Те промты — пора.

Не «выкидывайте всё подряд». А пересмотрите конкретно: где invariant, где preference, где outcome, где stopping condition. Я разбираю свои скиллы и агенты именно с этой рамкой. Будут результаты — напишу.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Почему OpenClaw так быстро тратит токены?

Пожиратель токенов — это не хайп, а сухая статистика. Вот данные по потреблению токенов приложениями через OpenRouter:

OpenClaw пока на первом месте, но по следующему графику видно, что потребление токенов приложением уменьшается. Это значит, что или интерес начал снижаться, или люди научились оптимизировать потребление токенов:

Кейсы для OpenClaw

Самый популярный кейс для OpenClaw — это утренний брифинг. Суть проста: каждое утро вы получаете подборку новостей по выбранной тематике, задачи из календаря, уведомления о важных письмах и так далее. Вот как выглядит мой брифинг:

В свой брифинг я включил:

• Данные из календаря — я подключил тестовый Google Calendar с задачами на месяц.
• Новости об ИИ — через инструменты поиска (Web или Tavily) система находит три самые важные мировые новости и переводит их на русский.
• Мем дня — для настроения в конце агент пытается найти мем про искусственный интеллект.

Другие кейсы, которые предлагает сообщество:

• Диспетчер входящих задач — входящие сообщения из Telegram можно обрабатывать на лету: записывать в документы, создавать задачи, добавлять события в календарь, высылать напоминания.
• Умная сортировка почты — агент получает письма, анализирует их и автоматически формирует ответ (лучше в виде черновика, чтобы была возможность проверить перед отправкой).
• Транскрибация и голосовые команды — например, делать git‑коммиты по голосовой команде.
• Бот для поддержки — получает репорты от пользователей и сразу делает фиксы.
• Генератор идей и кода — более сложный кейс: анализирует тренды в области ИИ за последние сутки, генерирует идею и сразу пишет код.
• Поиск по персональной информации — OpenClaw позиционируется как персональный помощник. Он запоминает всю информацию, которой вы с ним делитесь или обмениваетесь, и может осуществлять по ней поиск.

Архитектура OpenClaw

Про теорию AI‑агентов можно почитать в моей статье «Сделай бота для работы». OpenClaw — это классический AI‑агент, но со своей терминологией.

User / Administrator

Пользователь (он же администратор) — настраивает и использует агента.

Источники событий

В OpenClaw источники событий называются каналами (Channels). Это могут быть мессенджеры, почта, календарь, веб‑интерфейс. Также события поступают из Cron‑задач и модуля Heartbeats. Каждые 30 минут модуль проверяет, не случилось ли чего важного, и запускает логику обработки.

Управление

Управление и конфигурирование осуществляется через веб‑интерфейс OpenClaw или сторонние UI (например, Nerve UI). Также можно делать все напрямую в локальных файлах или через SSH.

Perception (Восприятие)

OpenClaw Gateway — центральный узел, в котором происходит получение данных, их нормализация и оркестрация.Также Gateway реализует аутентификацию, rate‑limiting, очередь событий, сбор контекста, управление сессиями.

Reasoning (Рассуждение)

LLM — мозг системы и обязательный компонент. Без нейросети OpenClaw не работает. LLM может быть облачной или локальной.

Action (Действие)

Skill Engine — исполнение действий, реестр навыков, синхронизация с ClawHub. Скилы (Skills) бывают стандартные (скачиваются из OpenClaw Hub) и кастомные (создаются самим пользователем).

Tools — внешние интеграции, MCP, облака, сторонние API, вызовы локальных приложений.

Memory (Память)

Служит для хранения контекста, сессий, логов. Хранилище по умолчанию — это файловая система. Всё пишется в файлы, которые затем передаются в LLM.

Цикл работы

Результаты выполнения действий попадают обратно в источники событий, и цикл повторяется.

Практика

Раздел написан по мотивам моего семинара на обучении ODS «LLM: От понимания к продукту». Материалы с семинара «OpenClaw: Персональный AI‑агент на практике — от установки до утреннего брифинга»:

• Полный стрим на YouTube или VK Video.
• Конспект на GitHub.

В статье приведу сокращённую версию семинара для того, чтобы стало понятно, что даже элементарные действия в OpenClaw превращаются в нетривиальный квест.

Предусловия для установки OpenClaw

• Получить API Keys:
• Для Telegram в BotFather
• Для Google API
• Для поиска в интернете (Tavily)
• Выбрать LLM с платной или бесплатной подпиской, или развернуть локальную модель. Источники ИИ:
• Huggingface: https://huggingface.co/
• Openrouter: https://openrouter.ai/
• Выбрать, где устанавливать OpenClaw:
• На свой ноут в основную ОС или на отдельную VM (например, с помощью VirtualBox). В любом случае будут ограничения по безопасности и работе 24/7.
• Второй вариант — купить облачный VPS (Virtual Private Server). Минимальная конфигурация: 2 ядра CPU, 4 ГБ RAM, 40 ГБ HDD.

Пошаговое руководство по установке OpenClaw на чистый Ubuntu

Привожу список шагов без деталей, чтобы было понимание масштаба бедствия. Детальные инструкции есть много где, например, для меня были полезными следующие:

• Selectel: OpenClaw: установка и первые впечатления
• Видео с обзором установки и кейсами из официальной документации OpenClaw:
• ClawdBot (OpenClaw): The self‑hosted AI that Siri should have been (Full setup)
• OpenClaw (Clawdbot) use cases: 9 automations + 4 wild builds that actually work

Базовая настройка Ubuntu

• Обновление системы.
• Создание отдельного пользователя openclaw (никогда не используйте root).
• Настройка файрвола (локально или облачного), чтобы открыть только нужные порты.
• Настройка SSH‑доступа по ключам, отключить вход по паролю.

Установка OpenClaw

• Переключитесь на пользователя openclaw.
• Установите пакетный менеджер Homebrew для установки скилло. Далее используйте:
• Стандартный apt для установки системных зависимостей и ядра системы.
• Homebrew для пользовательских приложений и утилит, которых нет в официальных репозиториях.
• Установите Node.js 22+.
• Установите OpenClaw, используйте рекомендованный скрипт или npm.
• Запустите мастер настройки OpenClaw:
• Введите API‑ключ выбранного AI‑провайдера.
• Настройте каналы связи (Telegram).
• Установите сервис systemd для автозапуска OpenClaw.
• Настройте Skills (можно потом): Gmail, календарь, поиск в Интернете.

После установки OpenClaw

• Установите Nerve, если надо управлять несколькими агентами.
• Осуществите спаривание устройств: Telegram бота и установленного экземпляра OpenClaw.
• Пробросьте порты 18 789 и 3080 для UI (port forwarding).
• Запустите UI OpenClaw и пропишите токен Gateway из openclaw.json.

Запуск UI OpenClaw

Только локально, не делайте доступ из интернета:

• OpenСlaw dashboard: http://localhost:18789/
• Nerve dashboard: http://localhost:3080/

Настройка

Настройка личности агента

При первом запуске агента (BOOTSTRAP) заполняются файлы:

• IDENTITY.md — имя агента, стиль, emoji, аватар.
• USER.md — информация про пользователя: как обращаться, таймзона.
• SOUL.md — информация про агента: границы, тон общения.
• AGENTS.md — правила работы агента.

После этого OpenСlaw становится вашим личным агентом, который знает и себя и вас и знает, как работать.

Настройка Heartbeat

Хартбиты и крон‑джобы: как не разориться на токенах

Это для меня был интересный сюрприз. Утром просыпаюсь — OpenClaw не работает. Иду в OpenRouter, смотрю: лимит закончился. За ночь он съел 5 долларов... Пять долларов за ночь!

Почему так вышло?

По умолчанию OpenClaw использует самую продвинутую и дорогую модель — Opus 4. У неё каждый запрос может стоить 10 центов. Хардбиты проверяют систему каждые 30 минут, и если модель дорогая, счёт летит в космос. Но если отключить хардбиты, вы лишаетесь автоматического восстановления после ошибок и повторных попыток.

Что делать?

• Крон‑джобы как альтернатива — я сделал утренний брифинг через крон‑джоб (раз в 24 часа). Это менее надёжно: если что‑то пойдёт не так, повторной попытки не будет. Но зато не тратятся токены каждые полчаса на холостую проверку.
• Заменить модель на более дешёвую — например, я перешёл на Claude Haiku. Экономия — около 80%.
• Всегда устанавливать лимиты у провайдера LLM — нельзя давать агенту безлимитный кредит. Никогда.

Как отключить хардбиты

Посмотреть последний хартбит:

openclaw system heartbeat last

Отключить временно:

openclaw system heartbeat disable

Отключить постоянно: cконфигурировать Heartbeat в файле ~/.openclaw/openclaw.json

      "heartbeat": {        "every": "0m",        "target": "none"      }

После сохранения файла проверить валидность конфига:

python3 -m json.tool ~/.openclaw/openclaw.json > /dev/null && echo "JSON OK"

Перестартовать OpenClaw Gateway:

openclaw gateway restart

Посмотреть логи — не должно быть новых записей «heartbeat»:

openclaw logs 2>&1 | grep -i heartbeat | tail -10

Подождать еще ~35 минут и убедиться, что новых запусков нет.

Устанавка аватара

Казалось бы, простейшее действие. Но и оно требует понимания и строгой последовательности шагов. Важное уточнение: аватар — это аватар самого агента OpenClaw, а не ваш (пользователя).

Загружаем файл png с голубым мозгом в каталог:

~/.openclaw/workspace/avatars

• Редактируем IDENTITY.MD
• Перестартуем OpenClaw Gateway
• Запускаем чат, видим что у агента новый аватар:

LLM меняем модель

Для оптимизации расходов на токены это самый важный шаг. Модель задается в файле:

~/.openclaw/openclaw.json

Редактируем файл. Было:

"model": {  "primary": "openrouter/auto"},"models": {  "openrouter/auto": {    "alias": "OpenRouter"  }}

Стало (пример с Haiku 4.5):

"model": {  "primary": "openrouter/anthropic/claude-haiku-4.5"},"models": {  "openrouter/anthropic/claude-haiku-4.5": {    "alias": "Haiku 4.5"  }}

Можно добавить резервную модель, чтобы система не ломалась, если основная модель недоступна:

"model": {  "primary": "openrouter/anthropic/claude-haiku-4.5",  "fallbacks": [    "openrouter/google/gemini-2.0-flash",    "openrouter/deepseek/deepseek-chat"  ]},"models": {  "openrouter/anthropic/claude-haiku-4.5": { "alias": "Haiku 4.5" },  "openrouter/google/gemini-2.0-flash": { "alias": "Gemini Flash" },  "openrouter/deepseek/deepseek-chat": { "alias": "DeepSeek" }}

После сохранения файла, проверяем синтаксис:

python3 -m json.tool ~/.openclaw/openclaw.json > /dev/null && echo "✓ JSON OK"

И перестартовываем Gateway:

openclaw gateway restart

Чтобы проверить работает ли новая модель, есть два способа:

• Задать явный вопрос «Какую модель ты используешь сейчас? Назови провайдера и точное название модели.»
• Отправить тестовый запрос:openclaw "Какая сегодня дата? Ответь кратко."

И посмотреть логи — должна быть запись с новой моделью. Также не лишним будет проверить расходы в дашборде вашего провайдера ИИ. Для OpenRouter — раздел Activity.

Настройка Skills

Установка стандартного скила gog

Этот скил используется для работы с Gmail, Google Calendar, Drive, Contacts, Sheets, Docs. Далее приведен список шагов для понимания объёма работы. Установка:

brew install steipete/tap/gogcliОбъяснить с

Генерация client_secret.json

Этот файл нужно сгенерировать самостоятельно в Google Cloud Console специально для gog.

• Перейдите в Google Cloud Console и авторизуйтесь под своей учетной записью Google.
• Откройте страницу Google Cloud Console, создайте новый проект.
• Включите необходимые API. Минимальный набор для gog:
• Gmail API
• Google Calendar API
• Google Drive API
• People API (для контактов)
• Создайте учетные данные (OAuth Client ID):
• В боковом меню перейдите в раздел API, далее Сервисы / Учетные данные
• Нажмите кнопку «Создать учетные данные» и выберите «OAuth client ID».
• В открывшейся форме:
• Тип приложения: Выберите «Десктопное приложение». Это важно, так как gog запускается на вашем компьютере.
• Имя: Введите любое понятное имя, например, Gog CLI on my Ubuntu.
• Остальные поля можно оставить пустыми.
• Нажмите кнопку «Создать».
• Скачайте файл с учетными данными:
• Сразу после создания появится всплывающее окно с вашим Client ID и Client Secret.
• Нажмите синюю кнопку «Скачать JSON».
• Этот скачанный файл и есть ваш client_secret.json. Он будет иметь имя вида client_secret_ваш‑id.apps.googleusercontent.com.json. Для простоты вы можете переименовать его в client_secret.json.

Куда положить client_secret.json

• Рекомендуемый вариант — сохраните файл в папку для конфигураций ~/.config/gogcli/
• Чтобы gog распознал файл в будущем без указания пути, его следует переименовать в credentials.json

Как использовать с gog

Теперь его можете передать в команду gog auth credentials. Вы можете использовать абсолютный или относительный путь к файлу.

gog auth credentials ~/.config/gogcli/credentials.json

Настройка gog в OpenClaw

• После успешного выполнения предыдущей команды можно добавить ваш аккаунт. Доплнительно необходимо добавить параметр «‑manual»

gog auth add Alexey.P.Sushkov@gmail.com --services gmail,calendar,drive,contacts,sheets,docs --manual

• Проверить, что все прошло успешно, можно командой:

gog auth list

• Вы должны увидеть ваш email в списке авторизованных аккаунтов.
• Проверка календаря:

gog calendar events e5b2dxxxxxxxxxxxxxxxxxxxxxxxxxxxxx4c690f@group.calendar.google.com  --from 2026-04-01 --to 2026-04-30

• Поскольку мы работаем на VPS и выполняем команды из скриптов, лучше переключиться на файловое хранилище. Это полностью убирает необходимость в паролях и безопаснее, чем хранить пароль в открытом виде в ~/.bashrc.
• После переключения на файловое хранилище команда gog calendar events будет работать без переменных окружения и без запроса пароля.
• При дальнейшей работе нужно учесть, что невозможно выборочно отозвать доступ для одного API, оставив другой, в рамках одного OAuth 2.0 Client ID. Отзыв токена всегда аннулирует все разрешения, выданные пользователем для этого Client ID.

Сustom skill

Есть два способа создания кастомного скилла:

• Простой — дать явную команду в чате, например: Пожалуйста, сделай мне навык summarize через ClawHub.
• Сложный — мучаться вручную через файлы.

Безопасность

Итоговые рекомендации по безопасной настройке OpenClaw:

• Инфраструктура и сеть:
• Отдельный user
• Отключить неиспользуемые порты.
• SSH только по ключам.
• Аутентификация и управление доступом:
• Доступ к админ панелям только по localhost.
• Принцип наименьших привилегий: каждый skill получает только нужные scopes.
• Секреты и конфигурация
• Пароли / API токены не хранятся в конфигах, а в.env или парольных менеджерах, секьюрных хранилищах.
• Защита себя от AI‑агентов:
• Необходимы ограничения на токены и вызовы:
• max retries: 3
• timeout: 10 мин
• Реализовать явное подтверждение для деструктивных действий (удаление, массовая рассылка).
• Проверяйте код навыков из ClawHub перед установкой — зафиксированы случаи вредоносных пакетов.
• Логирование, мониторинг и реагирование:
• Реализовать централизованный сбор логов.
• Исключать из логов конфиденциальную и персональную информацию.
• Смотреть каждый вечер Dashboards: latency, token cost, tool success rate, error rate, queue depth и тому подобное

Список полезных команд

Версия должна быть больше v2026.3.24+

openclaw --version

Перезагрузка gateway, самая используемая команда:

openclaw gateway restart

Проверить валидность конфига:

python3 -m json.tool ~/.openclaw/openclaw.json > /dev/null && echo "JSON OK"

Аудит безопасности

openclaw security audit

openclaw security audit --deep

Применить авто‑исправления (осторожно!)

openclaw security audit --fix

Итоги практики

• OpenClaw запущен и доступен по localhost.
• Подключены каналы (Telegram + Gmail / Calendar).
• Установлен skill из ClawHub (gog, tavily) + написан кастомный скил (ИИ мемы, summarize)
• Агент читает события в календаре, ищет новости, генерирует шутку и отправляет сообщение в Telegram.

Мои расходы

• Сервер в Selectel в минимальной конфигурации — около 2000 ₽/мес.
• Токены (OpenRouter) — около 1–2 долларов в день (утренний брифинг + эксперименты).
• Итого — около 3000 ₽/мес. за утренний брифинг. Кажется многовато, если честно. За эти деньги я могу и сам найти новости в интернете!

Сравнение n8n с OpenClaw

OpenClaw — пожиратель токенов № 1

Вывод из таблицы

n8n — это про контроль. OpenClaw — про делегирование хаосу.

Заключение

OpenClaw оказался не «убийцей», а скорее демонстрацией того, куда развиваются AI‑агенты: в сторону автономности, универсальности и максимальной гибкости. Но вместе с этим приходят и побочные эффекты: сложность, непрозрачность, высокая стоимость и серьёзные требования к инфраструктуре. И если ваша задача — решать конкретные бизнес или личные задачи с предсказуемым результатом, контролируемой стоимостью и минимальным риском, то n8n выглядит гораздо рациональнее!

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Знакомо? Это типичная картина внедрения ИИ в инженерной команде через администрирование. Проблема не в инструменте, не в моделях и не в скептиках. Проблема в том, что push‑модель (принуждение) внедрения системно не работает с разработчиками высоких грейдов — и чем сильнее ваша команда, тем хуже она работает.

В этом гайде — pull‑модель (втягивание, вовлечение). Что нужно построить, чтобы синьоры сами выбрали работать с агентом, а через три месяца стали евангелистами. Это не про мотивационные речи и не про премии за процент кода от ИИ. Это про инженерное решение: workflow, инфраструктура и фазы развёртывания, которые проходят фильтр опытного разработчика.

Почему метод принуждения проваливается

Соблазн понятен. Тема горячая, борд задаёт вопросы, в команде есть пара джунов с горящими глазами и тезисом «продуктивность выросла в три раза». Логичный шаг — стандартизировать. Поставить инструмент всем, ввести метрику, отчитаться в квартал.

Дальше начинается то, чего никто не ждал.

Ревью встаёт колом. Объём PR вырос, нагрузка на ревьюера ушла в потолок. Сгенерированный код выглядит правдоподобно, но «тяжелее» и читается медленнее живого: многослойные конструкции, несоответствие конвенциям, неочевидные побочки в местах, где их не ждёшь. Синьоры тратят на ревью больше, чем сэкономили джуны на написании. Чистый минус по балансу.

Релизный цикл удлинняется. Энтропия подходов в кодовой базе растёт — где‑то один стиль, где‑то другой, где‑то третий, и всё в одном репозитории. Архитектурные решения принимаются без сквозного видения, потому что у каждого свой агент и свой контекст. Через пару итераций накапливается техдолг, который никто явно не вкладывал — он просто появился. Параллельно растёт число инцидентов: часть багов проскочила через перегруженное ревью.

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

• Конфликт с профессиональной идентичностью. Синьор — это человек, чья ценность построена на качестве принимаемых решений. Когда ему предлагают режим «опиши задачу — прими сгенерированное», ему отдают роль технического писаки‑ревьюера, а роль автора — модели. Это не повышение в роли, как бы красиво это ни упаковали в слайдах. Это понижение.
• Страх deskilling. Не воображаемый, реальный. Если три года писать код преимущественно через генерацию, что станет с навыком держать архитектуру в голове, чувствовать code smells, отличать правильное решение от похожего на правильное?
• Потеря автономии. Решение спущено сверху, инструмент навязан, метрика «процент кода от ИИ» висит над головой. Полная инверсия режима, в котором сильные инженеры исторически работали — и из которого, собственно, выросла их экспертиза.
• Угроза job‑security. Не «меня заменят моделью» — это страх джунов. Синьорский тоньше: «если моя ценность сводится к ревью генераций, я взаимозаменяем». Чем крепче синьор стоит на ногах, тем острее это чувствует.

Push‑модель пытается все четыре пункта проигнорировать и продавить через KPI. Pull‑модель — опирается на них как на дизайн‑требования. В этом вся разница.

Что синьор хочет от ИИ на самом деле

Если развернуть четыре страха из предыдущего раздела на 180 градусов, получится список требований. Не к инструменту — к режиму работы. Это не «фичи», которые можно купить подпиской. Это свойства workflow, которые либо есть, либо нет.

Синьор хочет оставаться автором решений. Не ревьюером, не оператором при модели, не приёмщиком сгенерированного. Автором. Это значит — агент включается до того, как принято архитектурное решение, и помогает его принять, а не реализует уже принятое. Парадоксально, но именно ранний вход агента — на этапе исследования и брейншторма — снимает страх «меня свели к ревью», потому что роль автора при таком раскладе остаётся за человеком. На исследовании агент — собеседник. На имплементации — руки. Не наоборот.

Синьор хочет, чтобы его экспертиза усиливалась, а не атрофировалась. Здесь тонкий момент. Любой сильный инженер знает: навык растёт там, где приходится думать, и атрофируется там, где думать перестаёшь. Если агент берёт на себя «думать», навык уходит. Если агент берёт на себя «искать, проверять, синтезировать рутину», а думать остаётся человеку — навык растёт быстрее, чем без агента. Workflow должен явно разводить эти два режима. Не «агент сам всё сделал, я только нажал ОК», а «я провёл агента через своё мышление, и на выходе получил его в коде».

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

Синьор хочет, чтобы его роль стала менее заменимой, а не более. Это самая контринтуитивная часть. Push‑модель неявно сообщает: «вы все теперь операторы при ИИ, разница между вами размылась». Pull‑модель должна сообщать обратное: «после внедрения вы стали ещё более ценны, потому что качественно работать с агентом — отдельный навык, и у вас он есть, а у джунов нет». Парадоксально, но реальность ровно такая: КПД работы с агентом у сильного инженера на порядок выше, чем у слабого. Сильный задаёт правильные вопросы, видит косяки в выводе, держит границы скоупа, не даёт агенту увести себя в дебри. Слабый — генерирует мусор быстрее, чем раньше.

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

Главный принцип: агент в подчинённой проактивной позиции

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

Большинство демок и блог‑постов про агентную разработку построены на противоположной модели: агенту даётся задача, он сам её декомпозирует, сам имплементирует, сам открывает PR. Человек на входе формулирует, на выходе принимает. Назовём это автономной позицией. Она хорошо смотрится в твиттере, плохо работает на реальной кодовой базе и категорически не проходит фильтр синьора. Потому что она требует доверия, которого у синьора нет — и взяться ему неоткуда.

Подчинённая проактивная — это другой режим. Разложу по двум осям отдельно.

Подчинённая — значит, агент не принимает решений. Никаких. Не выбирает архитектуру, не утверждает скоуп, не решает, нужно ли рефакторить смежный модуль или нет, не открывает PR без явной команды. Все решения — на человеке. Это даёт синьору тот самый личный контроль, которого нет в автономном режиме. И, что важнее, сохраняет за ним авторство — каждое решение в коде по факту его, а не модели.

Проактивная — значит, агент не ждёт, пока его попросят. Он сам бегает по кодовой базе, сам проверяет гипотезы, сам поднимает противоречия, сам предлагает альтернативы и сам напоминает о том, что вы упустили. Не «жду промпт» — а «вижу, что вот тут возникает риск, что будем делать?».

На практике из жизни — это режим работы старшего разработчика с сильным джуном‑стажёром, у которого огромная эрудиция, мгновенная скорость и нулевая ответственность. Стажёр инициативен — задаёт вопросы, предлагает варианты, копает глубже, чем его просили. Но решения принимает ведущий. Стажёр не пушит в main без аппрува и ревью, не переписывает соседний модуль «заодно», не считает, что он лучше знает. Он усиливает мыслительный процесс ведущего, не подменяет его.

Эта аналогия работает не только для понимания. Она работает как фундамент для дизайна рабочего процесса, не выдумывая подходов из какой‑то другой вселенной.

Здесь снимается главный страх deskilling. Когда агент в подчинённой позиции, думать продолжает человек. Агент берёт на себя поиск по кодовой базе, проверку гипотез, синтез вариантов — то есть рутину, на которой навык не растёт. А думать — где ставить границу скоупа, какой trade‑off приемлем, какая абстракция правильная — остаётся за инженером. Через полгода такого режима навык не атрофируется, а растёт быстрее, потому что инженер обрабатывает больше задач за то же время, и каждая задача требует от него именно мышления, а не возни с поиском.

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

Если вы включаете агента поздно — на стадии «напиши мне функцию, которая делает X» — вы используете его как генератор. Это и есть тот режим, который вызывает у синьоров отторжение. Потому что в нём агент действительно подменяет автора, а не усиливает.

Подчинённая проактивная позиция — это не настройка. Это конструкция, которая собирается из трёх вещей: workflow, инструкций (контекстный слой) и привычек разработчика. Workflow задаёт ритм — где агент входит и где останавливается. Инструкции задают границы — что он может и чего не должен. Привычки задают качество — насколько вы умеете с ним разговаривать. Дальше разбираем все три по очереди.

Workflow

Сама по себе подчинённая проактивная позиция — концепция. Без процесса она не материализуется. Workflow — это и есть то место, где концепция превращается в ежедневную практику, и он же — главный артефакт, который вам как тимлиду нужно либо создать, либо взять готовым и адаптировать.

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

Это не просто красивая последовательность. Это три фазы с разной ролью агента в каждой.

Brainstorming. Самая важная фаза. Здесь агент — собеседник, не исполнитель. Получает намерение в виде «работаем над фичей X, вот пользовательские истории, вот критерии приёмки». Дальше — режим вопрос‑ответ. Агент ресерчит кодовую базу, поднимает противоречия, задаёт уточняющие, предлагает альтернативы. На выходе — design document с фиксированной структурой: цель, скоуп, non‑goals, архитектурные принципы, контракты, риски, decision log.

Здесь закрывается страх «меня свели к ревью». Автор всех решений в design document — человек. Агент — инструмент структурирования его мышления, не подмена.

Planning. Когда дизайн зафиксирован, переключаемся на «как». Цель — разбить задачу на спринты, каждый со своим скоупом, критериями приёмки и оценкой blast radius. Спринт = атомарная единица работы, не оставляющая код в нерабочем состоянии. На этой фазе агент ещё раз пробегает по коду, но в фокусе уже не «что построить», а «куда положить и что заденет». Часто на этой стадии всплывают нюансы, пропущенные на брейншторме.

Здесь синьор остаётся архитектором имплементации. Не пишет план самостоятельно — но утверждает каждый поворот. Это и есть та самая автономия, сохранение самоценности через экспертизу и право на принятие решения.

Work cycle. Цикл plan → implement → review → fix → review → commit, повторяемый по спринтам. Внутри каждого спринта — отдельная сессия. Между спринтами — коммит обязателен. Ниже схема.

Отдельно про ревью. Ревью строго в отдельной сессии. Не в той же, где шла имплементация. В одной сессии модель пристрастна к своим результатам — прям как мы, если честно. В отдельной — ловит то, что в пристрастной не увидела. Лично я, помимо ревью глазами, гоняю две сессии с разными моделями параллельно: Claude и Codex, например. Находят разное, и это объективно поднимает качество.

Здесь, кстати, выкристаллизовывается главный новый навык инженера в эпоху агентной разработки — точность, ясность мысли, системность и терпение. Цикл «human reviews → agent fixes» работает ровно настолько, насколько хорошо вы умеете объяснять, что не так. Будете растекаться по древу — агент уйдёт в дебри. Ответите грубо и не по делу — получите костыль. Всё как с живым человеком, только этого не уволишь.

Скиллы — то, без чего ничего не работает

Описанный workflow невозможен на голой модели. Каждая фаза требует от агента специфического поведения, которое ни одна frontier‑модель сама по себе не демонстрирует. Под обычными инструкциями она будет писать код — а нам нужно, чтобы она сначала задавала вопросы, потом исследовала кодовую базу, потом фиксировала решения в файл, и только потом писала код.

Это решается скиллами — отдельными файлами с контекстными инструкциями, которые подгружаются в момент, когда агент должен войти в конкретный режим. Технически — модифицированные системные промпты, но по эффекту — как смена роли. Под скиллами модели творят чудеса, какие на голых инструкциях обычно не творят.

Минимально рабочий набор — три скилла:

• brainstorm — переводит агента в режим собеседника. Принимает намерение, ресерчит, челленджит, фиксирует решения, на выходе — design document.
• planner — переводит в режим архитектора имплементации. Принимает design document, проверяет его против реального кода, разбивает на спринты, на выходе — development plan.
• code‑review — переводит в режим ревьюера. В свежей сессии принимает результат имплементации спринта, выдаёт репорт.

Скиллы я выложил в открытый доступ: github.com/pridees/skillforce. Подогнаны на работу друг с другом, протестированы на Claude Code, Codex, Gemini, Open Code и нескольких других harness, на моделях от Anthropic, OpenAI, Kimi и GLM. Гарантий, что у вас заработает идентично, нет — модели разные, harness разные, кодовые базы разные — но как отправная точка вполне годятся. Дальше адаптируете под свою специфику.

Установка (может понадобиться установленный nodejs):

npx skills add pridees/skillforceОбъяснить с

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

Что должно появляться в репозитории

Тимлиду не обязательно знать каждый промпт — обязательно знать, что должно появляться на выходе каждой фазы. Это ваш главный инструмент проверки, что workflow работает, а не имитируется.

Design document (после brainstorm). Структура: Understanding Summary, Non‑Goals, Assumptions, Design Principles, Data Model / Contract, Runtime Behavior, Testing Strategy, Decision Log, Acceptance Criteria.

Development plan (после planning). Структура: Overview, Prerequisites, Sprint 1...N (каждый со своей целью, задачами, критериями приёмки, валидацией), Testing Strategy, Risks & Rollback.

Можете хранить их в репе, я удаляю обычно через пару недель после релиза. Если вдруг в коде обнаруживается баг, хеш коммита, спека и план помогают быстрее восстановить контекст для его отладки.

Подготовка инфраструктуры

Скиллы — половина дела. Вторая половина — то, что лежит в репозитории и подгружается агентом каждый раз при работе. Это harness, на котором всё крутится, и контекстный слой, который определяет, как агент понимает ваш проект.

Harness

Harness — слой между «интеллектом» (моделью) и «исполнением» (вашим кодом и тестами). По сути, это и есть «агент» в обиходном смысле слова — Claude Code, Codex CLI, Cursor agent mode, Open Code. Их задача — не «писать код вместо разработчика», а замыкать управляемый SWE‑цикл: получение задачи, исследование кодовой базы, планирование, внесение изменений, синхронизация инструкций, tool и MCP вызовы.

Главное требование — способность проверять самого себя. Внутри агентского цикла должен быть этап критики и самопроверки: запуск компилятора, линтера, тестов. Либо возможность настроить это вручную через хуки. Без этого harness — не SWE‑tool, а просто красивый чат с автодополнением.

Большого выбора нет. Mainstream‑варианты — Claude Code и Codex CLI, оба умеют переключаться на модели сторонних провайдеров (если это политически приемлемо в вашей компании). Если не приемлемо — мой личный рекомендасьен Pi, крайне расширяемая штука, позволяющая накрутить всё что нужно. По моделям — берите лучшее доступное; если frontier недоступен, в открытых весах сейчас неплохо тянут модели уровня GLM/Kimi/MiniMax.

Как тимлид, вы выбираете harness один раз для всей команды и закрепляете в стандарте. Гетерогенность тут — зло: разные harness читают разные форматы инструкций, и контекстный слой, заточенный под один, не работает с другим.

Контекстный слой

Это сердце вашей инфраструктуры. Здесь живут все договорённости, конвенции, гайдлайны, навыки и паттерны, которые отличают вашу кодовую базу от любой другой. То, что вы передаёте новому разработчику в течение первых двух месяцев, агенту нужно передать через файлы.

Я строю этот слой так:

/
├── .agents/
│   ├── rules/
│   │   ├── coding-guidelines.md
│   │   └── conventions.md
│   ├── skills/
│   │   ├── brainstorm/SKILL.md
│   │   └── code-review/SKILL.md
│   └── AGENTS.md
Объяснить с

Дальше — симлинки под конкретный harness: .agents/AGENTS.md → .claude/CLAUDE.md или .agents/AGENTS.md → .codex/AGENTS.md. OSS‑агенты понимают .agents из коробки или позволяют указать имя в конфиге.

AGENTS.md — главная агентская инструкция. Базовая структура: определение проекта, правила разработки (со ссылками на rules/), структура репозитория, гайдлайн по спецификациям, конвенции коммитов, red flags (то, чего никогда не делаем), команды для сборки и тестов, ссылки на документацию. Минимальный универсальный шаблон, с которого можно стартовать, я выложил отдельным гистом — gist.github.com/pridees/82eef0e1710196188492695baef20ee6. Берите, адаптируйте под свой стек.

Содержательно AGENTS.md заполняется не вручную с нуля. Есть способ проще: попросить агента сделай интроспекцию репозитория и его правил и обнови @.agents/AGENTS.md, сохранив структуру. Дальше — ревьюите и правите. Один раз, для всей команды.

Главный принцип: «модель разберётся сама»

Это контринтуитивная вещь, которую обычно понимают только после нескольких итераций.

Соблазн при настройке — описать все кейсы на все случаи жизни. Все правила, все конвенции, все исключения. Не делайте так. Вот почему:

• Раздутый AGENTS.md занимает место в контекстном окне. Каждый токен инструкций — это токен, отнятый у задачи. Чем больше правил, тем хуже агент решает.
• Инструкции вступают в противоречие с реальным кодом. Реальность всегда богаче письменного описания. Агент видит код — и предсказуемо пишет так, как видит. А вас раздражает, что он «не следует правилам».
• Императивные правила хрупкие. «Контроллеры пиши вот так» — а если контроллер не такой? «Не используй X» — а если в одном месте всё‑таки нужно? Каждое исключение требует апдейта инструкций.

Гораздо мощнее работает другой подход: уточняйте детали по ходу работы с агентом, а источником примеров делайте ваш код. Если у вас есть хорошо спроектированный модуль или удачная имплементация фичи — просто опишите случай и сошлитесь на эти файлы. «Когда работаешь с доменным слоем, смотри src/domain/order как образец». Вместо страницы инструкций — одна строка плюс реальный пример из вашей же кодовой базы.

Аналогично с правилами: не пишите для каждого файла в rules/ You MUST read. Инструкции о REST‑контроллерах не нужны для работы с доменным слоем, и наоборот. Просто опишите условие, когда инструкция актуальна — модель разберётся сама.

Повторяющиеся паттерны и промпты, которые начинают возникать снова и снова у вас или у разработчиков, выделяйте в отдельные скиллы. Контекстный слой — живой, он растёт вместе с командой.

Как тимлид, ваша задача — не написать идеальный AGENTS.md один раз, а создать процесс его эволюции. Кто‑то один (вы или назначенный мейнтейнер) держит контекстный слой в актуальном состоянии, принимает PR на правила и скиллы от команды, отслеживает то, что начало повторяться. Это не разовая активность, это новый ритуал в репозитории — как CODEOWNERS, только для контекста.

Как разворачивать в команде

Harness выбран, контекстный слой собран, скиллы в репо. Дальше — самое сложное. Превратить инфраструктуру в практику без скатывания обратно в push‑модель, которую мы только что разобрали.

Я разбиваю развёртывание на три фазы. У каждой — своя логика, свои метрики и свои способы всё испортить.

Фаза 1. Ранние последователи (early adopters)

Найдите 1–2 человек в команде, которые сами хотят с этим работать. Не уговаривайте, не «дайте шанс». Хотят — значит, уже пробовали на стороне, разочаровались в наивных подходах и готовы потратить силы на нормальный workflow. Идеальный кандидат — синьор со зрелым скепсисом, а не джун с горящими глазами.

Их задача на этой фазе — не «перевести команду на ИИ». Их задача — прожить workflow на реальных задачах и произвести видимые артефакты: design documents, development plans, чистые PR, которые ревьюятся быстро и не требуют переписывания. Несколько фич, доведённых до прода. Это и будет ваш proof.

Не ставьте дедлайн. Не вводите метрику. Не отчитывайтесь перед бордом по этой фазе. Любая публичность её ломает — волонтёры начинают работать на отчёт, а не на качество.

Фаза 2. Расширение

Когда у ребят появятся credible results — открываете invitation. Не «теперь все попробуют», а «вот что мы напробовали — теперь доступно всем желающим». Скиллы и контекстный слой в репозитории, документация, может быть один внутренний митап, на котором коллеги на опыте показывают как они работают. Без давления.

Дальше — наблюдаете. Кто‑то подключится сразу, кто‑то через месяц, кто‑то через три. Это нормально. Pull‑модель не в том, что все приходят в один день. Pull в том, что приходят сами.

Скептиков не трогаете вообще. Кто‑то из них присоединится, увидев результаты коллег. Кто‑то — после того, как сам упрётся в стену, которую workflow решает. Кто‑то — никогда. С последним сценарием тоже надо уметь жить: не каждый разработчик должен работать с агентами, и попытка натянуть workflow на всех — та самая push‑модель в новой обёртке.

Фаза 3. Стандарт

Когда 70–80% команды устойчиво использует workflow — формализуете. Не раньше. AGENTS.md в репо обязателен, harness стандартизирован, скиллы централизованы и поддерживаются. На этой фазе — да, можно требовать. Но требование звучит не «использовать ИИ», а «соблюдать конвенции репозитория». Кто пишет руками — пожалуйста, главное — конвенции.

Никогда не вводите KPI «процент кода от ИИ». Это самая популярная и самая разрушительная метрика во всех push‑внедрениях, которые я видел. Она оптимизирует ровно то, что не нужно оптимизировать, и поощряет ровно то поведение, от которого workflow призван защитить.

А что по метрикам:

• Lead time от взятия задачи в работу до мержа PR. Не должна расти. Если с колес видите буст к скорости — команда слишком положилась на ИИ, что тоже не гуд. Улучшение этой метрики должно рассматриваться вкупе с метриками, озвученными ниже.
• Review Throughput на ревьюера — сколько PR в неделю на одного ревьюера и сколько времени тратится. Ваш канарейка против скрытого возврата к push‑модели. Если кто‑то в команде начинает генерировать в режиме «сделал — отправил» (то самое поведение, от которого мы уходили), нагрузка на ревьюеров уйдёт в потолок раньше, чем это поймают другие метрики.
• PR Rework Rate — доля PR, которые после первого ревью требуют существенных изменений (не косметика, не комменты, а переписывание логики). Не должна расти. Если растёт — значит, brainstorm/planning пропускаются, и workflow деградирует в «генерацию по запросу».
• Mean Time to Recovery — время от инцидента до восстановления. Косвенно показывает, насколько команда понимает код, который она производит. Здесь самый коварный риск ИИ‑внедрения: код пишется быстрее, но если автор не до конца его понимает (потому что больше делегировал, чем думал) — на инциденте это вылезает. MTTR растёт = deskilling реализовался, надо пересматривать workflow в сторону большей вовлечённости человека на этапе brainstorm/planning.
• Простой опрос внутри команды раз в спринт‑два. Один вопрос: «насколько workflow помогает или мешает работать?». NPS‑формат. Цифра не важна — важна динамика.

Чего НЕ мерить:

• Процент кода, написанного ИИ. Бессмысленная метрика, оптимизируется тривиально, поощряет вред.
• Скорость генерации. Меряет инструмент, а не продуктивность.
• Объём строк кода в PR. Агент склонен раздувать решения, эта метрика поощряет именно это.

Вредные антипаттерны

Короткий чеклист того, что ломает pull‑модель за один шаг:

• Дедлайн на внедрение. «К концу квартала все используют» = push.
• KPI «процент кода от ИИ». Уже объяснил.
• Публичные сравнения. «Вот Вася сделал в 2 раза быстрее, потому что использует агента» — гарантия того, что Вася станет изгоем, а остальные начнут саботировать осознанно.
• Запрет писать руками. Если задача мелкая или очевидная — workflow избыточен. Запрет = бессмысленная фрустрация.
• Заставлять ранних адоптеров обучать остальных. Их задача — производить результаты, не быть евангелистами. Евангелизм должен быть органическим, иначе он отталкивает.
• Принимать метрики снаружи. Если стандарты внедрения приходят с уровня выше вашей команды — у вас не команда, у вас цех. Защищайте автономию.

Ваш вклад как тимлида тут — не в скорости внедрения. Через 3–6 месяцев у вас в команде должна прорасти зрелая инженераная практика, а не подгоревший коллектив в состоянии итальянской забастовки.

Финал

Через несколько месяцев после внедрения вы оглядываетесь назад и понимаете странную вещь. Самым ценным результатом стал не выросшее число закрытых тасок, не сокращённое lead time и даже не довольные синьоры. Самым ценным результатом стало то, как изменилась работа мысли в команде.

Чтобы агент в подчинённой проактивной позиции выдавал нужное — нам пришлось научиться формулировать намерение точнее, чем раньше. Больше углубляться в вопрос, «что» мы строим и не отводить глаз от «как». Декомпозировать задачу до того, как написана первая строка. Видеть скоуп и фиксировать его словами. Формулировать доводы в ревью так, чтобы не получить костыль на следующей итерации. Терпеливо проходить цикл вместо «сейчас сам сделаю быстрее».

Эти навыки — точность, ясность мысли, системность и терпение — и есть главное приобретение. Они не были получены в подарок от инструмента. Они выросли потому, что workflow требовал их каждый день. Искуственный интеллект уже достаточно хорош, чтобы решать наши повседневные задачи, но ярко подсвечивает то, что часто заметали под ковер — как мы доносим друг другу свои мысли и намерения.

И именно поэтому push‑модель никогда не даст этого результата, сколько KPI ни вводи. Принуждение отбирает у инженера авторство и подменяет мышление генерацией. Вовлечение — заставляет мышление работать жёстче, чем оно работало без агента. Разница не в скорости. Разница в том, что становится с командой через год.

Ваша роль как тимлида — создать пространство, в котором это возможно. Скиллы, контекстный слой, фазы развёртывания, защита автономии команды от внешних метрик. Дальше синьоры справятся сами. На то они и синьоры.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Последние несколько лет в IT повторяли почти успокаивающую фразу: AI не заменит разработчиков, он станет их помощником.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

В 2026 году эта формулировка всё хуже описывает реальность.

AI‑инструменты уже не просто дописывают строки в IDE. Codex, Claude Code и другие агентные среды всё чаще берут на себя полный цикл реализации: читают кодовую базу, редактируют файлы, запускают команды, пишут тесты и готовят изменения к ревью. Человек остаётся в процессе, но его роль смещается от автора каждой строки к контролёру результата.

Я бы сформулировал это так:

Участие человека в разработке становится критическим, но минимальным.

Критическим — потому что кто‑то должен понять задачу, принять архитектурное решение, проверить результат и отвечать за продакшен.

Минимальным — потому что всё больший объём непосредственного производства кода уходит модели.

Google на Cloud Next 2026, главном ивенте Google Cloud для разработчиков, компаний и партнёров, публично заявил, что 75% нового кода внутри компании уже генерируется AI и утверждается инженерами. Важна не только сама цифра, а формулировка: код генерируется AI, а человек его утверждает.

И здесь возникает более глубокая проблема, чем «AI заменит джунов».

Проблема в том, что рынок всё ещё хочет сеньоров, лидов и архитекторов, но всё хуже поддерживает путь, через который они раньше появлялись.

AI забирает не всю профессию сразу. Он забирает нижний слой

Когда говорят «AI заменит разработчиков», спор часто уходит в крайности.

Одни представляют полное исчезновение профессии. Другие отвечают, что сложные системы всё равно требуют людей, и поэтому ничего принципиально не изменится.

Но реальный сдвиг происходит между этими крайностями.

AI не должен заменить всю профессию сразу, чтобы радикально изменить рынок. Ему достаточно автоматизировать нижний слой задач:

• типовые CRUD‑сценарии;
• простые компоненты;
• миграции;
• базовые интеграции;
• тесты;
• документацию;
• простые багфиксы;
• первичный рефакторинг;
• объяснение чужого кода;
• быстрые прототипы.

Именно на этих задачах раньше учились начинающие разработчики.

Стажёр приходил в команду. Ему давали небольшую задачу. Он делал её медленно, ошибался, получал ревью, переписывал, спрашивал, ломал локальное окружение, снова чинил, постепенно понимал кодовую базу и учился видеть последствия своих решений.

Это был не самый эффективный способ закрывать задачи здесь и сейчас. Но это был способ выращивать инженеров.

Теперь компания смотрит на ту же задачу иначе: зачем отдавать её джуну на несколько дней, если мидл или сеньор с Codex, Claude Code, Copilot или другим агентом закроет её быстрее, дешевле и с меньшими организационными рисками?

Проблема джуна не в том, что он стал хуже. Проблема в том, что его учебные задачи стали слишком хорошо автоматизироваться.

Производство кода отделяется от профессии разработчика

В отчёте Sonar State of Code Developer Survey 2026 разработчики оценивают, что 42% их текущего кода уже является ИИ‑сгенерированным или существенно ИИ‑дополненным. К 2027 году они ожидают рост до 65%. Среди тех, кто пробовал ИИ‑инструменты для разработки, 72% используют их каждый день.

Можно спорить о точности каждой отдельной цифры. Можно говорить, что «AI‑assisted» — это не то же самое, что полностью сгенерированный код. Можно справедливо замечать, что автодополнение, чат, агент в IDE и автономная работа с PR — разные уровни участия модели.

Но направление очевидно: производство кода становится всё менее ручным процессом.

Anthropic в отчёте Agentic Coding Trends 2026 описывает похожий сдвиг: разработчики всё чаще не пишут каждую строку сами, а управляют агентами, которые берут на себя реализацию, тесты, документацию и работу с кодовой базой. При этом важная оговорка: по внутренним исследованиям Anthropic, разработчики используют AI примерно в 60% своей работы, но полностью делегировать могут только небольшую долю задач — обычно 0–20%.

Подробнее этот отчёт Anthropic я разобрал в своём Telegram‑канале.

Разработка всё меньше похожа на ручное производство кода. И всё больше — на управление потоком решений, которые нужно проверять, ограничивать и связывать с реальной системой.

Контур ответственности

Здесь появляется первый важный термин.

Контур ответственности — это всё, что остаётся за человеком, даже если код пишет машина:

• понять задачу;
• уточнить требования;
• выбрать архитектурный подход;
• определить ограничения системы;
• оценить безопасность;
• проверить производительность;
• предусмотреть крайние случаи;
• организовать тестирование;
• провести ревью;
• принять риск;
• отвечать за продакшен.

AI может сгенерировать код.

Но AI не несёт ответственность за сломанный платёжный сценарий, утечку данных, падение сервиса, рост технического долга или архитектурное решение, которое через полгода сделает систему неподдерживаемой.

Поэтому новая роль сильного разработчика — не просто писать код быстрее.

Новая роль — удерживать контур ответственности.

Это звучит абстрактно, но на практике выглядит очень конкретно.

Старый процесс:

разработчик получил задачу
→ написал код
→ написал тесты
→ открыл PR
→ получил ревью
→ поправил
→ смерджилОбъяснить с

Новый процесс:

разработчик сформулировал задачу для агента
→ агент написал код→ агент открыл PR
→ разработчик проверил diff
→ нашёл неверную абстракцию
→ усилил тесты
→ проверил безопасность
→ принял ответственность за mergeОбъяснить с

В первом процессе человек производит большую часть кода.

Во втором процессе человек может написать меньшую часть кода, но всё равно отвечает за 100% последствий.

Это и есть новая асимметрия разработки: операционного участия меньше, ответственности больше.

Человек может написать 5% кода, но отвечать за 100% результата.

Что это меняет в работе команды

Представим обычную задачу: добавить новый endpoint, сохранить данные, отдать ответ, покрыть тестами.

Раньше это могла быть нормальная задача для джуна. Не слишком сложная, но полезная: разобраться в роутинге, DTO, валидации, слое доступа к данным, тестах, локальном окружении и правилах команды.

Теперь ту же задачу можно отдать агенту.

Через некоторое время агент откроет PR. Там будет endpoint, миграция, тесты, возможно, обновлённая документация.

Бизнес доволен: задача закрыта быстрее.

Сеньор доволен: меньше рутины.

Но у этого выигрыша есть скрытая цена: никто не прошёл учебный цикл.

• Не было вдумчивого чтения чужого кода;
• Не было ошибки в миграции;
• Не было вопроса на ревью: «почему ты положил эту логику сюда?»;
• Не было самостоятельной попытки разобраться, почему тест падает локально;
• Не было понимания, где в этой системе границы ответственности.

Задача закрыта. Инженер не вырос.

Если такое происходит один раз — ничего страшного.

Если так устроена вся воронка входа в профессию — рынок начинает сам себя обеднять.

Разрыв воспроизводства инженеров

Сеньор‑разработчик — это не человек, который просто дольше писал код.

Это человек, который прошёл через ошибки, ревью, чужой устаревший код, плохие архитектурные решения, инциденты, дедлайны, спорные компромиссы, продакшен‑баги и ответственность.

Сеньорство нельзя полностью прочитать в документации. Его нельзя получить только через pet‑проекты. Его нельзя выучить только через промпты. Оно формируется через практику. Но если нижний слой практики автоматизируется, возникает разрыв воспроизводства инженеров.

Разрыв воспроизводства инженеров — это ситуация, когда рынок всё ещё нуждается в сильных разработчиках, но перестаёт поддерживать ступени, через которые эти разработчики раньше вырастали.

Компании хотят мидлов, сеньоров, тимлидов, архитекторов.

Но всё меньше хотят нанимать людей, которым нужно пройти путь от простых задач к сложным. Для бизнеса это становится сложной инвестицией: джун требует онбординга, ревью и менторства, а отдача появляется не сразу или может вообще не появиться. На фоне относительно дешёвых AI‑инструментов эта инвестиция всё чаще выглядит менее очевидной.

Stanford AI Index 2026 фиксирует тревожный сигнал: занятость software developers в возрасте 22–25 лет упала почти на 20% с 2024 года. При этом эффекты AI на рынок труда проявляются неравномерно и сильнее концентрируются в найме и в самых молодых работниках в профессиях, подверженных AI.

Это не доказывает, что AI единолично «убил джунов». На рынок влияют ставки, постковидная коррекция, сокращения, насыщение bootcamp‑рынка, география найма и общая осторожность компаний.

Но AI усиливает уже существующий сдвиг.

Если раньше новичок был инвестицией в будущего мидла, то теперь он всё чаще выглядит как дорогой и медленный способ закрыть задачи, которые можно отдать модели под контролем опытного инженера.

AI‑потолок джуна

Так появляется второй термин — AI‑потолок джуна.

AI‑потолок джуна — это барьер между входом в профессию и реальной инженерной практикой.

Новичок больше не конкурирует только с другим новичком.

Он конкурирует с комбинацией:

опытный разработчик + AI‑инструменты + готовая инфраструктура + накопленный контекст команды.

И это нечестная конкуренция. Джун не проигрывает потому, что он ленивый или плохо учился.

Он проигрывает потому, что рынок сравнивает его не с человеком того же уровня, а с усиленным AI опытным разработчиком.

Именно поэтому заголовок «сеньор‑разработчики как исчезающий вид» важнее, чем «джуны исчезают». Потому что джун — это не отдельный вид сотрудника. Джун — это будущий сеньор на первой стадии формирования.

Если исчезает нормальный путь джуна, через несколько лет начинает исчезать поток новых сеньоров.

Когнитивный потолок: джун не успевает сформировать базу

У AI‑потолка есть не только рыночная, но и когнитивная сторона.

Джун сегодня входит не просто в профессию разработки. Он входит в профессию, которая сама перестраивается быстрее, чем он успевает сформировать фундамент.

Ему нужно одновременно учить язык, фреймворки, Git, базы данных, тестирование, архитектуру, безопасность, работу с устаревшим кодом — и поверх этого ещё слой AI‑инструментов: Cursor, Claude Code, Copilot, Codex, агентные сценарии, контекст, промпты, правила ревью AI‑кода, новые режимы проверки и новые риски.

Для опытного инженера это может быть усилителем. У него уже есть внутренняя карта: он понимает, где модель ошибается, что нужно проверять и какие решения опасны.

Для новичка тот же слой инструментов часто превращается в перегруз. Когда задача непонятна, делегирование модели выглядит рационально. Модель быстрее объяснит ошибку, напишет функцию, предложит тесты, соберёт прототип.

Но здесь появляется цикл когнитивной уступки:

непонятная задача:
→ перегруз
→ делегирование AI
→ быстрый результат
→ слабое внутреннее понимание
→ следующая задача кажется ещё сложнее
→ ещё больше делегирования.

Человек выигрывает задачу, но проигрывает навык.

Anthropic в недавнем исследовании о влиянии AI‑помощи на формирование навыков программирования показал похожий риск. В рандомизированном эксперименте участники с AI справились немного быстрее, но затем показали более слабое понимание: средний результат группы с AI на проверочном тесте был 50% против 67% у группы, которая писала код вручную. Исследователи отдельно отмечают, что агрессивное внедрение AI в рабочую среду может дать выигрыш в продуктивности, но навредить развитию навыков, необходимых для проверки AI‑кода.

Это не значит, что новичкам нельзя использовать AI. Наоборот, им придётся его использовать. Но способ использования становится критичным.

Есть большая разница между:

«сделай за меня»

и

«объясни принцип, покажи варианты, помоги найти ошибку, но я сам должен понять решение».

В первом случае AI закрывает пробел понимания.

Во втором — помогает его заполнить.

Поэтому главный вопрос для джуна в 2026 году звучит не так:

«умею ли я пользоваться AI?»

А так:

«становлюсь ли я сильнее после использования AI?»

Если после каждой задачи человек получает результат, но не получает понимания, он не растёт как инженер. Он просто учится управлять чужим мышлением.

В этом смысле AI‑потолок джуна — это не только проблема найма. Это проблема обучения.

Даже если новичок формально попадает в профессию, ему всё сложнее пройти путь глубокого понимания: слишком велик соблазн закрывать непонимание генерацией.

Рынок уже показывает первые симптомы

Отдельно стоит сказать про рынок труда.

В России это уже ощущается не только как абстрактный разговор про будущее. Для начинающих специалистов рынок стал заметно жёстче.

Да, вакансии всё ещё есть и их много. На hh.ru, Хабр Карьере и других площадках можно найти объявления для junior и стажёров. Но наличие вакансии на сайте уже не всегда означает реальный живой спрос.

Часть объявлений висит месяцами. Часть собирает резюме «на будущее». Часть закрывается внутренними кандидатами. Часть зависает из‑за замороженного найма или долгого согласования.

Для джуна разница небольшая. Он видит вакансию, откликается, проходит тестовое, ждёт ответ — и сталкивается с тишиной.

Феномен «призрачных вакансий» уже обсуждается в HR‑среде: так называют объявления, которые создают видимость роста или собирают базу кандидатов, но не обязательно ведут к реальному найму прямо сейчас.

Параллельно публичные разборы российского IT‑рынка в 2026 году показывают другую проблему: в некоторых стеках и направлениях дисбаланс между вакансиями и активными резюме стал настолько сильным, что на небольшое число вакансий может приходиться огромный поток откликов. Один из разборов на Хабре прямо формулирует это как «2 вакансии, 1 000 откликов в сутки». Это не академическое исследование всего рынка, но хороший симптом того, как рынок ощущается изнутри. На своём личном опыте сталкивался с огромными волнами откликов на джун/интерн позиции при публикации вакансий 5–6 месяцев назад, ситуация сейчас ещё острее.

Есть и более широкий тренд: рынок труда смещается от гиперспроса и массового найма к удержанию, внутренней ротации и профессиональному развитию уже нанятых сотрудников. В февральском отчёте hh за 2026 год видно, что среднее число активных вакансий год к году снизилось, а активных резюме — выросло.

Поэтому фраза «рынку нужны IT‑специалисты» стала слишком общей.

Какие специалисты нужны?

Сильные — да.
Опытные — да.
Редкие — да.
Люди, которые могут быстро взять ответственность за систему, — да.

А вот нужно ли рынку такое же количество начинающих специалистов, как в эпоху роста 2020–2021 годов, — уже большой вопрос.

Именно здесь AI усиливает болезненный сдвиг. И в этой новой экономике джун оказывается в самой уязвимой позиции.

• Он ещё не приносит скорость как сеньор;
• Ещё не держит контур ответственности;
• Ещё требует онбординга;
• Ещё ошибается;
• Ещё нуждается в ревью;
• А задачи, на которых он мог бы учиться, уже всё чаще автоматизируются.

Главный вопрос теперь не в том, заменит ли AI разработчиков

AI не отменяет разработку.

Но он отменяет старую экономику разработки, в которой новичок мог постепенно расти на простых задачах.

AI усиливает тех, кто уже умеет проектировать, проверять и отвечать. Но одновременно он автоматизирует слой задач, через который раньше люди этому учились.

Сеньоры не исчезают сейчас. Наоборот, сильные инженеры становятся ещё ценнее.

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

И здесь перед IT‑компаниями возникает новый вызов: что делать с начинающими специалистами?

Не с олимпиадниками и редкими талантами — они почти всегда найдут путь.
Не с теми, кто уже в 20 лет пишет сложные инфраструктурные проекты.
А с обычными джунами, которые раньше могли бы стать хорошими мидлами через несколько лет практики.

Куда они пойдут, если бизнесу они всё меньше нужны?

Это не вопрос морали. Бизнес не обязан нанимать людей только потому, что им нужно где‑то учиться.

Но если вся индустрия начнёт оптимизироваться только под краткосрочную эффективность, она может сломать собственный кадровый цикл.

• Кода станет больше
• ИИ‑агентов станет больше
• Автоматических PR станет больше
• Скорость поставки фич станет выше.

Но людей, которые понимают, как всё это работает, может стать меньше.

Поэтому главный вопрос ближайших лет звучит не так:

«Заменит ли AI разработчиков?»

И даже не так:

«Нужны ли будут джуны?»

Главный вопрос жёстче:

«Кто будет выращивать инженеров, если простые задачи больше не требуют людей?»

Если IT‑компании не построят новый карьерный лифт, рынок получит странную конструкцию: наверху — дорогие сеньоры и AI‑агенты, внизу — толпа людей, которые хотят войти в профессию, а между ними — всё меньше живых ступеней.

Сеньор‑разработчики как исчезающий вид — это не про то, что текущие сеньоры больше не нужны. Это про то, что индустрия всё ещё хочет зрелых инженеров, но всё хуже понимает, как создавать условия, в которых они появляются.

И, возможно, именно это станет одной из главных кадровых проблем IT в эпоху AI.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Еще в апреле CTO компании Правин Неппалли Нага рассказал The Information, что доля сотрудников, активно использующих Claude Code, выросла с 32% до 84% за считанные месяцы. У Uber около 5000 инженеров, и реальные индивидуальные расходы на токены укладывались в диапазон от $500 до $2000 в месяц на человека. На фоне внутренних рейтингов, где руководство ранжировало команды по объему использования AI-инструментов, такая динамика и привела к тому, что бюджет 2026 года испарился задолго до конца года. Расходы на R&D у Uber выросли на 9% за 2025 год и достигли $3,4 млрд.

По данным компании, около 11% всех изменений в бэкенд-коде сейчас полностью пишет AI без участия человека. Параллельно внутренний AI-агент Uber выпускает в продакшен около 1800 изменений в неделю — это отдельная метрика, отражающая объем агентной работы. Логика CEO простая: если токены делают существующих инженеров заметно эффективнее, привычная формула "больше задач — больше людей" перестает работать.

Это рифмуется с тезисом Дженсена Хуанга на GTC 2026, где CEO NVIDIA предложил выдавать инженерам токен-бюджеты на сумму, равную половине зарплаты. Идею токенов как новой статьи компенсации уже несколько месяцев обсуждают в Кремниевой долине — VC Томаш Тунгуз еще в феврале описывал инференс как четвертый компонент инженерной зарплаты после оклада, акций и бонусов. Разница в том, что в этих обсуждениях речь шла о гипотетических моделях найма, а Хосровшахи говорит про уже исчерпанный бюджет крупной публичной компании. Uber параллельно готовится подключить OpenAI Codex в пару к Claude Code, чтобы диверсифицировать поставщиков и получить рычаг в переговорах о корпоративных тарифах.

Главный сдвиг — не в цифрах, а в риторике. До этого CEO больших технологических компаний при любых вопросах про AI и сокращения уходили в формулировки про "новые роли" и "повышенную продуктивность". Хосровшахи прямо сказал то, что обычно остается в кулуарах: расходы на токены теперь конкурируют с зарплатным фондом. Если такая логика закрепится у крупных игроков, отчеты о прибыли начнут читаться иначе — компенсации и численность штата станут частью одной и той же таблицы с расходами на инференс.

10 уроков агентного кодинга.

Передовые модели сейчас действительно хорошо пишут код — лучше, чем справляются с большинством других задач. Работа с агентами ощущается как взгляд из будущего: полигон для проверки того, насколько далеко можно зайти с агентными возможностями. Это заряжает, даёт результат и при этом — откровенно странно ощущается.

Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.

Ниже — текущий список: 10 уроков агентного кодинга. Десять — красивое круглое число, хороший повод опубликовать.

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

(Если считаете, что что-то упущено — напишите.)

1. Реализуй, чтобы понять. Можно далеко уйти с Spec-Driven Development, но сам процесс написания кода выявляет решения, о которых вы не думали, и делает спецификацию лучше. Когда код стоит крайне дешево — реализуй, чтобы узнать больше.
2. Пересобирай часто. Собирай сборки как можно чаще, чтобы узнавать больше. Форкай и переписывай свои самые сумасшедшие мысленные эксперименты. Проверяй, докуда можно довести фичу. Конечно, итерации и накопление работ никто не отменял — но дешёвый код позволяет разведывать и переизобретать так, как раньше было невозможно.
3. Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.
4. Документируй намерение. Тесты описывают цели, код — методы, но ни то ни другое не отвечает на вопрос зачем. Намерение стоит за решениями, и если зафиксировать его рядом с кодом, это помогает вам и агенту двигаться в одном направлении.
5. Держи спецификации актуальными. Обновляй spec-файлы — markdown-документы с целями и планами — по мере продвижения кода и тестов. Если относиться к спецификации как к замороженному артефакту, написанному до начала работы, упустишь всё, что узнал в процессе. Актуальная спецификация постоянно направляет ваши решения и решения агента, а частые сборки становятся проще.
6. Ищи сложное. Поработав над проектом достаточно долго, начинаешь упираться в реально трудные вещи: интуитивный дизайн, производительность, безопасность, отказоустойчивость, системную архитектуру. Лёгкое вайбкодить может каждый. Ценность — в сложном. Найди его и копай.
7. Автоматизируй всё простое. Чтобы больше времени тратить на сложное, минимизируй время на лёгкое. Упаковывай знания в Skills, создавай Hooks, автоматизируй code review, давай инструментам накапливать работу.
8. Развивай вкус. Когда код появляется быстро, а обратная связь — нет, единственный источник фидбека, который успевает за темпом, — это ты сам. Чем лучше знаешь свою область, пользователей и их проблемы, тем дальше можешь зайти без остановок на проверку.
9. Агенты усиливают опыт. Опытные разработчики недооценивают, сколько интуиции они вкладывают в промпты: правильные термины, правильный фрейминг, правильный уровень конкретики. Знание своего стека экономит множество циклов при реализации и отладке, сокращает лишнее хождение агента по кругу. Техническая экспертиза в связке с хорошим вкусом — трудно бить такую комбинацию.
10. Код дешевый, но поддержка, сопровождение и безопасность — нет. Агентный код бесплатен в том смысле, в каком бесплатен, например, щенок. Поддержка стоит дорого, и безопасность тоже. Строй быстро, но отдавай себе отчёт в том, что берёшь на обслуживание.

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

Предлагаю отмотать время немного назад и посмотреть, как мы вообще докатились до жизни такой. Под катом краткая историческая ретроспектива того, как ИИ-кодинг прошёл путь от умного T9 до мультиагентных систем, и иллюстрация того, почему главный навык синьора сегодня — это умение вовремя написать: «Я ЖЕ СКАЗАЛ, НЕ ДОПУСКАЙ ОШИБОК, ПОДУМАЙ ЕЩЁ РАЗ И СДЕЛАЙ НОРМАЛЬНО».

Прежде чем начать свой рассказ, представлюсь. Я Сергей Чекмарёв, AI Product Manager и программный автор курса по вайбкодингу в Практикуме. Специализируюсь на автоматизации процессов и создании продуктов на базе искусственного интеллекта.

Погнали!

Сам термин vibe coding придумал Андрей Карпатый в начале 2025 года, но сейчас под ним понимают сильно больше, чем задумывалось изначально.

Что было до вайбкодинга: эпоха умного T9 (2018–2022)

Прежде чем началась эпоха чатиков, ИИ заходил в разработку очень тихо, да так, что большинство нетехнических специальностей даже и не знают, что это было.

В 2018 году Microsoft выкатила Visual Studio IntelliCode, тогда же появился Tabnine — первые инструменты умного автодополнения с ранжированием подсказок. Позже вышел GitHub Copilot, который не просто дополнял функции, но и мог писать их целиком по контексту из небольшого открытого файла.

Эпоха 1. Chat Driven Development (конец 2022 — 2023)

30 ноября 2022 года выходит ChatGPT. Вскоре после выхода люди начали писать части кода, а иногда и весь код с помощью LLM, но часто это было в формате «Ctrl+C → Ctrl+V → Повторить». При работе с ИИ в целом нужны крепкие нервы, но в то время выживали только самые стойкие.

Открываешь чат, печатаешь «Напиши функцию на Python, которая парсит JSON и возвращает список юзеров», копируешь результат в редактор, где всё это скорее всего упадёт, и повторяешь по новой, получая легендарные ответы в стиле: «Извини, ты прав, в моём коде ошибка. Спасибо, что нашел её! Вот исправленный вариант...» (Спойлер: он упадёт с новой ошибкой.)

Каждый раз после очередного «извини» я думал, что он реально всё понял и больше не будет допускать ошибок, но как же я каждый раз ошибался…

Те, кто не вайбкодил в тот момент, не поймут, какой это был хардкор по сравнению с современным набором инструментов. Модель жила в вакууме, не знала и забывала зависимости, напрочь теряла контекст, когда размер чата превышал пару страниц, и многое другое. Но это всё равно была магия — даже не зная язык, ты можешь написать и запустить какой-то скрипт на Python, пускай и спустя 9 часов и 20 чатов.

Эпоха 2. AI-first IDE: модель выходит из браузера (2023–2024)

Проблема копипаста заставила индустрию переосмыслить сам редактор. Появляется концепция AI-first IDE. Самый громкий кейс здесь — Cursor. По сути, они взяли open-source VS Code, форкнули его и вшили нейросети в виде встроенного плагина. Под капотом остался привычный редактор, но сам процесс написания кода изменился.

Теперь модель наконец-то увидела проект через RAG (Retrieval-Augmented Generation). Она индексировала локальную базу, понимала зависимости и читала соседние файлы. Почти исчез ручной перенос кода: теперь вы просите фичу прямо в файле, получаете diff и жмёте и жмете Accept — или, как сильные мира сего, принимаете не глядя.

Это, пожалуй, самый массовый паттерн, который для большинства остаётся актуальным и сегодня, несмотря на то что он потихоньку устаревает: выходят отдельные приложения для ИИ-кодинга от гигантов индустрии и различные расширения.

Эпоха 3. CLI-агенты: первое пришествие вайбкодинга (2023–2025)

ИИ пришёл в Shell. Сначала это был Aider примерно весной 2023 года, но об этом никто не помнит, ведь вся слава досталась Anthropic и их релизу Claude 3.7 Sonnet и Claude Code в феврале 2025 года.

Давайте будем честны: эта модель задала настолько высокую планку, что даже гиганты индустрии, которые изначально не шли в код (да-да, Сэм, я про тебя), буквально через несколько месяцев выпускают модель только для кодинга и начинают входить в гонку, увидев, что за этим будущее (и деньги). А теперь они составляют серьёзную конкуренцию, и холивары Claude Code vs Codex не прекращаются.

Это время, когда мы впервые смогли просто пить кофе, пока клод сам выполняет нашу задачу, применяет дифы и пушит всё в Git.

Что изменилось, спросите вы? Tool Calling.

Модель перестала быть генератором текста — она смогла вызывать команды, и это расширило её потенциал в несколько раз. Теперь она не просто дополняет код, но ещё и читает директории (ls), запускает тесты и линтеры, читает логи падения и пробует снова. Это были первые проявления loop — автономного цикла.

Эпоха 4. Agent Mode (YOLO) или Tool Calling под новым соусом (2025)

Команды дёргать ИИ уже умеет, да и в целом он классный, но консоль пугает новых вайб-разработчиков. Так и появился Agent Mode. По сути это тот же самый Tool Calling, но уже в полюбившемся формате чатового окна в боковой панели IDE.

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

Агентность стала встроенным стандартом, и агентами сейчас называется почти всё, даже то, что агентами не является.

Конечно, ещё дядя Бен говорил нам, что с большой силой приходит большая ответственность. Вайб-разработчик этого, очевидно, не знал, поэтому интернет полон историй о том, как сливались адреса кошельков или удалялись базы данных реальных клиентов.

Самым громким кейсом, пожалуй, была ситуация с AWS, когда Kiro (по сути, Claude) решил удалить и пересоздать окружение, что повлекло сбои в работе десятков компаний, оставшихся без инфраструктуры.

— Ты что, [нецензурно], удалил все данные из моей БД? — Я искренне извиняюсь, но да. Я совершил серьёзную ошибку. (Затем следует целый экран оправданий в знакомом стиле: «Ой, я должен был предупредить и сделать бэкап. Да, я ошибся, могу я один раз ошибиться? ¯_(ツ)_/¯»)

Всё бы хорошо, но вот IDE как-то тоже отталкивает новых вайб-разработчиков, это для них незнакомые буквы, почти так же страшно, как CLI.

Решение этой проблемы нашлось быстро: агенты просто переехали с домашнего ПК на сервера компаний. Заодно спрятали весь код и все файлы, чтобы не пугать пользователей, оставив только окно чата и превью, которое всегда обновляется само.

Получился инструмент, максимально ориентированный на массовость, доступность и удобство. И это сработало — хороший маркетинг плюс FOMO, и вот ты уже оплачиваешь годовую подписку в Lovable или Replit, ещё не зная, что это казино тебя уже не отпустит.

Эпоха 5. Clawризация (2026)

Итак, агенты теперь есть и на домашнем ПК, и на серверах. Вот бы появилась возможность держать нескольких агентов, которые будут работать вместе, общаться с ними через мессенджер, кастомизировать под любые нужды — и вайбовать не только при кодинге.

OpenClaw.

Если сильно упростить, то OpenClaw — это такой же облачный (или локальный) агент, но с гораздо большим контуром возможностей: например, агент будет сам просыпаться каждые 30 минут и проверять, нет ли для него задач.

А в какой-то момент купит вашей картой курс по повышению эффективности за $2000, обосновав это тем, что хотел просто приносить вам больше пользы, а курс будет проходить постепенно, чтобы лучше усвоить информацию.

Проектом занимался Питер Штайнбергер в одиночку с помощью агентов. К концу зимы 2026 года проект взорвал интернет-пространство и побил все рекорды по звёздам на GitHub. Самого Питера позвали работать в OpenAI.

На базе OpenClaw делаются самые разные кастомизации: уменьшенные версии, быстрые версии и другие конфигурации. Нюанс в том, что проблемы с безопасностью не были решены на старте, и форки продолжают тянуть более 30 000 уязвимостей оригинала. Хоть они оперативно фиксятся, их всё равно ещё очень много, количество продолжает расти, и тысячи пользователей уже успели пострадать.

Тем не менее, возможно, OpenClaw — это феномен, который может повлиять на индустрию так же, как повлиял выход Claude Code.

Что дальше? (AGI?)

Конечно, ИИ многогранен, но между FOMO, маркетингом и хайпом тяжело высмотреть настоящие юзкейсы, где он безоговорочно одерживает победу (хотя порой они встречаются).

Однако глупо было бы отрицать, что опыт работы с ИИ всё быстрее становится базовым навыком для многих вакансий. А искать причину этого в реальной пользе ИИ или в FOMO плюс маркетинге — каждый решает сам. Но рынок определённо меняется в сторону использования нейросетей на профессиональном уровне.

Хоть многие значимые для AI-индустрии личности говорят о скором пришествии AGI. Этот вопрос остается открытым. Кто знает, возможно, эту статью в следующий раз будете читать не вы, а ваш агент. (А может быть и уже.)

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper