Подходы и практики: от ассистента до ИИ-агента

• Ступень 1. Автодополнение: модель подсказывает следующую строку или блок кода прямо в редакторе. Человек пишет, ИИ предугадывает продолжение. Так работает GitHub Copilot в своём первоначальном виде.
• Ступень 2. Чат-ассистент: отдельное окно, где можно спросить про код, попросить объяснить ошибку или сгенерировать функцию. Человек ставит задачу, ИИ отвечает, потом человек сам переносит результат.
• Ступень 3. Ассистент в редакторе с контекстом проекта: то же, но модель видит вашу кодовую базу и отвечает с её учётом. Сюда относятся Cursor и подобные среды.
• Ступень 4. Агент: модель сама выполняет шаги, одним ответом дело не ограничивается: читает файлы, пишет код, запускает тесты, исправляет ошибки. Человек ставит задачу и проверяет результат. Так работают Claude Code, Cursor в агентном режиме, Amazon Kiro.
• Ступень 5. Автономный агент: агент работает над задачей долго и без вмешательства, сам разбивает её на части и сам проверяет себя. Человек только задаёт цель и принимает итог.

Чем выше ступень, тем больше работы делает машина. Вместе с этим растут скорость и риск: человек всё меньше понимает, что именно она сделала. На какой ступени остановиться – решаете вы. Как – в разделе про уровни автономии дальше.

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

Вокруг подхода уже сложились инструменты: GitHub Spec Kit (открытый набор от GitHub), Amazon Kiro (вышел в июле 2025), Tessl, OpenSpec (открытый набор от Fission-AI, лицензия MIT). Общий принцип один: сначала требования и план, потом генерация. Набор артефактов похож: требования, проектирование, задачи. Spec Kit и Kiro проще всего попробовать на новом проекте. При этом GitHub считает, что сильнее всего подход работает при доработке существующих систем, и даёт руководство для существующих проектов. Tessl сейчас развивается как платформа контекста и навыков для агентов в существующих репозиториях. OpenSpec сделан легче Spec Kit, рассчитан на существующий код и оформляет каждое изменение отдельной папкой: предложение, задачи, изменения спецификаций и, если нужно, проектирование.

У корпорации есть своя задача, с которой я столкнулся сам: код уже есть, и его много. Там 60 сервисов, потребители, которых писали другие люди, а ещё изменение, которое должно выйти и ничего не сломать. Для этого случая я написал Brownspec – открытый плагин для Claude Code. В нём те же 3 артефакта, но вокруг них всё устроено иначе. Договорённости проекта (как здесь обрабатывают ошибки, как логируют, где лежат слои, включая места, где код противоречит сам себе) выводятся из существующего кода, с нуля их никто не задаёт. Проектирование включает радиус поражения изменения: кто вызывает, кто импортирует, кто потребляет контракт. Правила организации лежат в отдельном файле, который инструменту запрещено перезаписывать. Есть необязательный профиль по 152-ФЗ: 7 правил про персональные данные в формате «триггер, требование, что должно быть в спецификации». Инструмент только маршрутизирует и вердиктов не выносит: на выходе «это изменение затрагивает такое-то правило, покажите ИБ», но никогда «соответствует закону».

Упоминаю инструмент в качестве иллюстрации того, чего не хватает готовым инструментам для корпоративного кода. Если начинаете новый проект – берите Spec Kit или Kiro, если внедряете спецификации в уже живущий код – OpenSpec. Область молодая, устоявшихся практик мало, но направление важное, поэтому мы вернёмся к нему в блоках про требования и тестирование.

Что уже проверено практикой – массово используется, есть данные о результатах и понятный способ внедрения:

• Автодополнение и чат-ассистенты: самый зрелый уровень. По опросу Stack Overflow 2025, их используют или планируют использовать 84% разработчиков. Риск низкий – человек видит каждую строку.
• Ассистент с контекстом проекта: тоже норма, особенно для понимания чужого кода и генерации типовых кусков.

Что пока на стадии эксперимента – хорошо выглядит в демонстрациях, но данных о результатах на реальных проектах мало:

• Агенты, работающие долго и без вмешательства: данных о них мало. Даже агентов вообще, по опросу Stack Overflow 2025, используют только 31% разработчиков, из них 69% отмечают рост продуктивности. Перспективный инструмент, но массовым пока не стал.
• Несколько агентов, работающих вместе: пока в основном демонстрации и пилоты.

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

AI-DLC (AI-Driven Development Life Cycle) представила в 2025 году AWS. Суть: ИИ выполняет основную работу на всех этапах, от замысла до эксплуатации, а люди задают направление, утверждают решения и отвечают за результат. Процесс делится на 3 фазы: замысел, создание, эксплуатация. На первых 2 решения утверждает человек, на эксплуатации команда ведёт надзор. Отдельный акцент – на документировании: планы, требования и проектные решения записываются по ходу работы, и по ним видно, откуда взялось изменение. По-моему, это удобно для регулируемых отраслей.

AI-Disrupt PDLC Сбер представил в мае 2026 года на ЦИПР (конференция «Цифровая индустрия промышленной России») и обновил в июле 2026 года. PDLC – Product Development Life Cycle, жизненный цикл разработки продукта. Он шире SDLC (Software Development Life Cycle, жизненный цикл разработки ПО), потому что включает этап исследования до разработки и эксплуатацию после. 3 центральных сдвига: первый – ИИ-агент становится исполнителем, а человек отвечает за намерение. Второй – качество результата определяет среда работы вокруг модели, от самой модели оно зависит меньше. Третий – контур управления (правила, аудит, ограничения) встраивается в каждый шаг, а не накладывается в конце. Центральный инструмент – разработка от спецификации, о которой шла речь выше. Для российского читателя важно, что в документе есть часть про регуляторный контекст, ландшафт поставщиков и локализацию.

Авторы сравнивают свою методологию с AWS AI-DLC и отмечают, что делают обязательным то, что у AWS опционально: отдельный этап исследования перед спецификацией и сквозной контур проверки результата. По состоянию на публикацию Сбер оценивает собственный уровень как «контролируемую автоматизацию»: агентам отдана работа с небольшими дефектами и часть ревью. Независимых измерений эффекта в самом Сбере в документе нет – на это обращают внимание и внешние разборы.

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

Термином AI-PDLC я пользуюсь как общим названием этого класса подходов без привязки к конкретному поставщику. Под этим названием у меня есть бесплатный курс «AI-PDLC: как меняется процесс создания продукта с использованием ИИ»: 9 коротких модулей о том, чем процесс отличается от привычного, что меняется в деньгах, людях и контроле. Он написан для всей производственной команды и для руководителей без технического опыта – его можно дать коллегам, которым нужно понять суть без глубины этого курса.

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

Данные подтверждают: главный вывод DORA 2025 – ИИ усиливает то, что уже есть. У команд с хорошими процессами он ускоряет работу, у команд с хаосом усиливает хаос. Выигрыш даёт система вокруг модели, одна модель сама по себе его не обеспечит. Поэтому бюджет и внимание стоит вкладывать в окружение наравне с подпиской: в навигацию по коду, файлы контекста, автоматические проверки. Как это устроено – в блоках 06 и 07. И не забываем про перестройку процессов разработки.

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

• Смена поведения: поставщик обновляет модель, и то, что работало вчера, сегодня работает иначе. Промпты и файлы контекста, настроенные под старую версию, могут перестать давать прежний результат. Из гипотезы это уже превратилось в регулярную операционную проблему.
• Цена и условия: поставщик меняет тарифы или правила использования – меняется экономика вашего внедрения.
• Доступность: для российских компаний это особенно остро: доступ к зарубежным моделям может пропасть из-за санкций или блокировок, а оплата может оказаться невозможной.
• Утечка данных: отправляя код во внешнюю модель, вы доверяете его поставщику. Это тема блока 05.

Как снижать риски: первое – не завязывать весь процесс на одну модель и там, где возможно, использовать слой, который позволяет переключать поставщика. Второе – держать у себя набор эталонных задач с известными правильными ответами (golden set), чтобы при смене модели быстро проверить, не стало ли хуже. Третье – хранить промпты и файлы контекста как версионируемые артефакты, иначе они остаются в личных файлах у отдельных людей. Четвёртое – для критичных процессов рассматривать модель на своём железе.

Модель от поставщика по API (API – программный интерфейс, через который ваши инструменты отправляют запросы модели поставщика) даёт доступ к самым сильным моделям, обслуживать ничего не нужно, платите за фактическое использование. Минусы: код уходит наружу, вы зависите от цен, условий и доступности поставщика. Для российских компаний добавляется риск потери доступа: крупные зарубежные поставщики официально в России не работают (блок 05).

Зарубежная модель через российский прокси – разновидность первого пути. Прокси-сервис (например, GPTunneL – на мой взгляд, самый известный и надёжный из российских: сервис включён в реестр российского ПО и работает с юрлицами по договору) заключает договор с вашей компанией в России, а запросы передаёт зарубежному поставщику. Для разработки важно, что такие сервисы повторяют формат API поставщика. Claude Code, Cursor и другие инструменты начинают работать после замены адреса и ключа, код менять не нужно.

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

Модель на своём железе (открытая модель в вашем контуре, например DeepSeek V4, GLM, Qwen или Kimi K3) оставляет код внутри периметра, снимает зависимость от чужих тарифов и санкций, даёт предсказуемость службе безопасности. Минусы: нужны вложения в оборудование и в людей, которые его обслуживают, а открытые модели обычно слабее лучших коммерческих.

Структура затрат тоже разная. У API – переменные расходы: платите за каждый запрос, начать легко, но при росте счёт растёт. У своего железа – крупные фиксированные вложения вперёд, которые окупаются только при большом и постоянном объёме. Как считать – в блоке 04.

Что это значит на практике: железо, модели, качество, настройка

Какое железо нужно. Память видеокарт складывается из 2 частей. Первая – веса модели: 1 байт на параметр при хранении в FP8 (8-битный формат чисел, в 2 раза компактнее обычного 16-битного). Вторая – KV-кэш, память под контекст каждой активной сессии. Он растёт с длиной контекста и с числом одновременных сессий: у агентов с длинным контекстом на команду он может занять столько же, сколько сами веса. Для 1–2 сессий закладывайте 30–50% сверху, для команды проверяйте объём нагрузочным тестом. MoE (mixture of experts, «смесь экспертов») – модель, у которой на каждый токен работает только часть параметров: она быстрее, но в памяти лежит целиком. Отсюда 3 типовые конфигурации:

Число инженеров в последней колонке – грубый ориентир. Ёмкость сервера задают число одновременных сессий и длина их контекста: агенты с длинным контекстом нагружают карту сильнее, чем то же число людей с автодополнением. Перед покупкой проверьте нагрузочным тестом.

Самые большие открытые модели в эту таблицу не входят: DeepSeek V4 Pro (1,6 трлн параметров) и Kimi K3 (2,8 трлн) не помещаются на 1 сервер 8×H200 даже в FP8, им нужно 2 сервера и больше.

За 3 года сервер 8×H200 обходится в 700–800 тыс. $ с учётом электричества, площадки и людей, которые его обслуживают (оценка iternal.ai), то есть около 20 тыс. $ в месяц. Отсюда ориентир: своё железо окупается, когда расход на API устойчиво выше этой суммы. Это тот же порог, что и в блоке 04. Считайте по своей модели расходов. Аренда такого же сервера в зарубежном облаке стоит 30–50 $ в час, то есть 21–36 тыс. $ в месяц при круглосуточной работе; в РФ считайте по тарифам местных облаков с видеокартами (GPU). Правило простое: сначала арендуйте и измерьте реальную нагрузку, покупайте только под подтверждённый расход.

Какие модели обычно берут. Открытые модели с лицензией, разрешающей коммерческое использование: DeepSeek V4 (MIT), GLM 5.x (MIT), Qwen 3.x и Qwen3-Coder (Apache 2.0), gpt-oss от OpenAI (Apache 2.0). У Kimi K3 своя лицензия, читайте её. Для кода чаще всего берут Qwen3-Coder и DeepSeek: у них больше всего готовых сборок под vLLM и SGLang (серверы для запуска моделей). Из российских: T-Pro от Т-Технологий с открытыми весами; GigaChat и YandexGPT поставляются в контур по договору с вендором. Публичных замеров по коду для российских моделей мало, поэтому проверяйте их на своём наборе эталонных задач.

Насколько они хуже топовых подписок. SWE-bench Verified (задачи из реальных репозиториев GitHub) почти насыщен. По независимому замеру Vals AI на 1 сентября 2026 года лучшая открытая модель DeepSeek V4 Pro решает 96,4% задач, лучшая закрытая Claude Opus 5 – 97% (более новую Opus 5.5 на этом тесте уже не прогоняли), открытая модель на 27 млрд параметров (Qwen 3.8 27B) – 86%. Тест перенесён в архив, и новые модели на нём больше не прогоняют. На более сложном SWE-bench Pro разрыв виден: DeepSeek V4-Pro-Max – 55,4% и V4-Flash-Max – 52,6% по данным вендора, GLM – 62,1% по замеру третьей стороны, Claude Opus 5.5 – 89,9% по данным вендора. Цифры вендоров и независимые замеры напрямую не сравнивают. Практический вывод: на типовых задачах (тесты, миграции, документация, код по образцу) большая открытая модель в контуре почти не уступает подписке. На длинных многошаговых задачах в незнакомом коде отставание есть, и чем меньше модель, тем оно заметнее. Единственный надёжный способ узнать разрыв для себя – набор эталонных задач из вашего кода, о котором сказано выше.

Как настроить модель под компанию. 4 способа, от дешёвого к дорогому:

1. Файлы контекста и правила (блок 15). Бесплатно, даёт больше всего.
2. Поиск по коду и документации (RAG): модель получает в запросе нужные куски вашего репозитория и вики. Неделя работы платформенной команды.
3. Дообучение адаптерами (LoRA, QLoRA) на вашем коде и комментариях из ревью. Учит стилю, внутренним библиотекам, терминам. Нужны тысячи примеров, 1–2 карты на несколько часов и проверка на эталонных задачах, что общие способности не просели.
4. Полное дообучение или дистилляция в меньшую модель. Для компаний с командой машинного обучения (ML), большинству не нужно.

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

Для банка или компании с жёсткими требованиями регулятора своё железо часто становится обязательным условием. Для небольшой компании – почти всегда избыточно: контур окупается от 80–130 инженеров, которые активно работают с агентами (блок 04). Проще начать с API и разрешённого набора инструментов.