# Блок 03. Подходы и практики

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 3 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/ii-agenty-i-podhody/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 25 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

> Спор «нужен ли нам ИИ» уже закончен. Настоящее решение технического директора – сколько работы доверить машине и как ловить её ошибки.

Прежде чем решать, что именно внедрять и как считать эффект, нужна карта местности: какие вообще бывают способы работать с ИИ в разработке, что проверено, а что пока эксперимент, от чего вы становитесь зависимы, когда встраиваете модель в процесс. Блок обзорный: конкретные направления – в [блоках 06](/ai-cto/spec-driven-development/)–[10](/ai-cto/soprovozhdenie-monitoring/), экономика – в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/).

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

## Ситуация: Генеральный посмотрел на агентов

**Генеральный директор · четверг, 17:05:** Видел демо: агент сам взял задачу, сам написал код, сам прогнал тесты. Почему у нас люди до сих пор пишут руками? Давай отдадим агентам бэклог, а инженеры пусть проверяют. Что для этого нужно?

Что известно:

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

**Сколько автономии вы дадите ИИ в следующем квартале?** Здесь верный ответ зависит от типа компании (пометки – в блоке 01), исходы показаны для обоих.

- **A. Агенты сразу на изолированных задачах.** С первого дня агенты берут целиком миграции, тесты и новые сервисы по образцу, но только там, где тесты есть. Остальные работают как раньше, окружение достраиваете по ходу. Генеральный увидит агентов в работе уже в этом квартале, но на сервисах без тестов ничего не изменится.
- **B. Сначала окружение, агенты понемногу.** Ассистента с контекстом проекта получают все команды, агенты берут только мелкие дефекты и типовые правки на сервисах с тестами. Часть бюджета идёт на файлы контекста и эталонные задачи. Эффект ровнее по всем командам, но агентов генеральный увидит мало.
- **C. Самую сильную модель всем.** Купить лучшую модель на всех инженеров и не тратить квартал на окружение. Это быстро и понятно генеральному, все команды получают одно и то же. Что будет на сервисах без тестов, заранее не видно.

## Что происходит через квартал

Цифры условные, показывают направление без точной величины. Что измерять на самом деле и как снять baseline – в [блоке 11](/ai-cto/metriki-dora-baseline/).

### Вариант A: Агенты сразу – исход зависит от компании

**Корпорация.** Агенты начали с миграций и тестов на 5 сервисах с хорошими тестами. Через 3 недели ИБ спросила, куда уходит код и кто отвечает за изменения агента. Модель зарубежная, журнала нет, поэтому агентов остановили до согласования. До остановки агент на одном сервисе поменял контракт, которым пользовались 3 соседних сервиса: тесты сервиса этого не ловили, нашли на проде. К концу квартала агенты работают на 2 сервисах, остальные команды ничего нового не получили.

| Метрика | Было | Стало |
| --- | --- | --- |
| Задачи, закрытые агентами (миграции, тесты, типовые правки) | 0% | 4% |
| Сервисов, где работают агенты (медиана по пул-реквесту) | 0 | 2 |
| Время на ревью (медиана по пул-реквесту) | нет данных | +20% |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,0% |
| Время от коммита до прода (метрика DORA) | 6 дн | 6 дн |

**Вердикт:** В корпорации агенты упёрлись в ИБ и в проверки между сервисами, квартал ушёл на согласование. В небольшой компании тот же выбор дал самый быстрый результат из 3 вариантов: согласований нет, а агенты работали только там, где ошибку ловят тесты.

### Вариант B: Меньше, чем в демо, зато предсказуемо

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Время от коммита до прода (метрика DORA) | 6 дн | 5,4 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 4,1% |
| Задачи, закрытые агентами (мелкие дефекты и типовые правки) | 0% | 14% |
| Время на ревью (медиана по пул-реквесту) | нет данных | +8% |
| Дней до обнаружения просадки (после обновления модели, по эталонным задачам) | нет данных | 1 |

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

### Вариант C: Одна модель, 2 результата

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Расходы на ИИ (подписки и токены сверх лимита, план = 100) | 100 | 125 |
| Время от коммита до прода (команды с тестами) | 6 дн | 5 дн |
| Время от коммита до прода (команды без тестов) | 6 дн | 7 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,2% |
| Время на ревью (медиана по пул-реквесту) | нет данных | +25% |

**Вердикт:** Вы вложились в модель. Результат зависел от окружения вокруг неё – а его у вас не было.

## Пять уровней автономии и от чего вы зависите

### Ландшафт: от автодополнения до автономных агентов

Способы работы с ИИ удобно выстроить в один ряд – по тому, сколько работы человек отдаёт машине и сколько контроля оставляет себе. 5 ступеней: от той, где почти всё делает человек, до той, где почти всё делает машина.

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

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

### Spec-driven development (разработка от спецификации)

Spec-driven development – подход, при котором источником истины вместо кода становится спецификация: подробное описание того, что нужно построить. Человек пишет и утверждает спецификацию, а код из неё генерируется как производное. Если результат неверный – исправляют спецификацию, а не код.

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

Вокруг подхода уже сложились инструменты: [GitHub Spec Kit](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) (открытый набор от GitHub), [Amazon Kiro](https://kiro.dev/) (вышел в июле 2025), [Tessl](https://tessl.io/), [OpenSpec](https://github.com/Fission-AI/OpenSpec) (открытый набор от Fission-AI, лицензия MIT). Общий принцип один: сначала требования и план, потом генерация. Набор артефактов похож: требования, проектирование, задачи. Spec Kit и Kiro проще всего попробовать на новом проекте. При этом GitHub считает, что сильнее всего подход работает при доработке существующих систем, и даёт [руководство для существующих проектов](https://github.github.com/spec-kit/guides/existing-projects.html). Tessl сейчас развивается как платформа контекста и навыков для агентов в существующих репозиториях. OpenSpec сделан легче Spec Kit, рассчитан на существующий код и оформляет каждое изменение отдельной папкой: предложение, задачи, изменения спецификаций и, если нужно, проектирование.

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

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

### Уровни автономии: что проверено практикой и что остаётся экспериментом

Главный вопрос – не «использовать ИИ или нет», а «сколько автономии дать». Ответ зависит от того, насколько дорого стоит ошибка и насколько хорошо вы умеете её ловить.

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

- **Автодополнение и чат-ассистенты:** самый зрелый уровень. По [опросу Stack Overflow 2025](https://survey.stackoverflow.co/2025/ai), их используют или планируют использовать 84% разработчиков. Риск низкий – человек видит каждую строку.
- **Ассистент с контекстом проекта:** тоже норма, особенно для понимания чужого кода и генерации типовых кусков.

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

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

Вывод: начинать безопаснее с проверенных уровней, а агентов пробовать на задачах с низкой ценой ошибки, где результат легко проверить автоматически. Поэтому в [блоке 07](/ai-cto/ii-v-programmirovanii/) разбирается, где отдача высокая и предсказуемая, а где опасно.

### AI-DLC, AI-Disrupt PDLC и AI-PDLC как ориентиры

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

[AI-DLC](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/) (AI-Driven Development Life Cycle) представила в 2025 году AWS. Суть: ИИ выполняет основную работу на всех этапах, от замысла до эксплуатации, а люди задают направление, утверждают решения и отвечают за результат. Процесс делится на 3 фазы: замысел, создание, эксплуатация. На первых 2 решения утверждает человек, на эксплуатации команда ведёт надзор. Отдельный акцент – на документировании: планы, требования и проектные решения записываются по ходу работы, и по ним видно, откуда взялось изменение. По-моему, это удобно для регулируемых отраслей.

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

Авторы сравнивают свою методологию с AWS AI-DLC и отмечают, что делают обязательным то, что у AWS опционально: отдельный этап исследования перед спецификацией и сквозной контур проверки результата. По состоянию на публикацию Сбер оценивает собственный уровень как «контролируемую автоматизацию»: агентам отдана работа с небольшими дефектами и часть ревью. Независимых измерений эффекта в самом Сбере в документе нет – на это обращают внимание и [внешние разборы](https://habr.com/ru/companies/oleg-bunin/articles/1038588/).

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

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

### Окружение вокруг модели: почему оно влияет на результат не меньше самой модели

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

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

Данные подтверждают: главный вывод [DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) – ИИ усиливает то, что уже есть. У команд с хорошими процессами он ускоряет работу, у команд с хаосом усиливает хаос. Выигрыш даёт система вокруг модели, одна модель сама по себе его не обеспечит. Поэтому бюджет и внимание стоит вкладывать в окружение наравне с подпиской: в навигацию по коду, файлы контекста, автоматические проверки. Как это устроено – в [блоках 06](/ai-cto/spec-driven-development/) и 07. И не забываем про перестройку процессов разработки.

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

### Зависимость от LLM и её поставщика: риски и как их снижать

LLM (large language model, большая языковая модель) – сама модель вроде Claude или GPT, на которой работает ассистент. Когда вы встраиваете её в процесс разработки, вы становитесь от неё зависимы, и у этой зависимости несколько сторон.

- **Смена поведения:** поставщик обновляет модель, и то, что работало вчера, сегодня работает иначе. Промпты и файлы контекста, настроенные под старую версию, могут перестать давать прежний результат. Из гипотезы это уже превратилось в регулярную операционную проблему.
- **Цена и условия:** поставщик меняет тарифы или правила использования – меняется экономика вашего внедрения.
- **Доступность:** для российских компаний это особенно остро: доступ к зарубежным моделям может пропасть из-за санкций или блокировок, а оплата может оказаться невозможной.
- **Утечка данных:** отправляя код во внешнюю модель, вы доверяете его поставщику. Это тема [блока 05](/ai-cto/bezopasnost-politika-ii/).

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

### Модель на своём железе или от поставщика

2 принципиально разных пути, и выбор касается сразу технологии, безопасности и экономики.

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

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

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

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

Структура затрат тоже разная. У API – переменные расходы: платите за каждый запрос, начать легко, но при росте счёт растёт. У своего железа – крупные фиксированные вложения вперёд, которые окупаются только при большом и постоянном объёме. Как считать – в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/).

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

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

| Что запускаем | Примеры моделей | Железо | Цена (оценка, без поставки в РФ) | Кому хватит (ориентир) |
| --- | --- | --- | --- | --- |
| Малая модель, 20–35 млрд параметров | Qwen 3.8 27B, gpt-oss-20b, Devstral | 1 карта на 80 ГБ (H100) или рабочая станция с RTX PRO 6000 на 96 ГБ | 25–40 тыс. $ за карту H100; сервер на 4 карты 140–175 тыс. $ | до 50 инженеров: автодополнение и чат |
| Средняя модель, 80–120 млрд параметров (MoE, активны 3–5 млрд) | Qwen3-Coder-Next 80B, gpt-oss-120b | 1–2 карты H200 на 141 ГБ | 30–40 тыс. $ за карту | 50–150 инженеров: агент на типовых задачах |
| Большая модель, 600–750 млрд параметров (MoE) | GLM 5.x и другие модели этого размера | сервер 8×H200 в FP8 (1 128 ГБ) | 280–350 тыс. $ за сервер | 150+ инженеров: агенты на сложных задачах |

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

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

За 3 года сервер 8×H200 обходится в 700–800 тыс. $ с учётом электричества, площадки и людей, которые его обслуживают (оценка iternal.ai), то есть около 20 тыс. $ в месяц. Отсюда ориентир: своё железо окупается, когда расход на API устойчиво выше этой суммы. Это тот же порог, что и в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/). Считайте по своей модели расходов. Аренда такого же сервера в зарубежном облаке стоит 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](/ai-cto/shablony/)). Бесплатно, даёт больше всего.
2. Поиск по коду и документации (RAG): модель получает в запросе нужные куски вашего репозитория и вики. Неделя работы платформенной команды.
3. Дообучение адаптерами (LoRA, QLoRA) на вашем коде и комментариях из ревью. Учит стилю, внутренним библиотекам, терминам. Нужны тысячи примеров, 1–2 карты на несколько часов и проверка на эталонных задачах, что общие способности не просели.
4. Полное дообучение или дистилляция в меньшую модель. Для компаний с командой машинного обучения (ML), большинству не нужно.

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

**Корпорация:** для пилота арендуйте или возьмите 1 сервер со средней моделью, а большую покупайте после того, как измерен расход и согласовано с ИБ. Люди важнее железа: нужны 1–2 инженера эксплуатации моделей.

**Небольшая компания:** своё железо не окупится. Если контур обязателен, хватит 1 карты с малой моделью для автодополнения, остальное через API по договору с запретом обучения на ваших данных.

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

### Источники

- [DORA 2025, анонс Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [Stack Overflow Developer Survey 2025, раздел про ИИ](https://survey.stackoverflow.co/2025/ai)
- [AWS, AI-Driven Development Life Cycle (первоисточник методологии)](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/)
- [Сбер, AI-Disrupt PDLC: whitepaper, страница загрузки](https://sbertech.ru/whitepaper)
- [РИА Новости, Сбер представил обновлённую редакцию AI-Disrupt PDLC, 7 июля 2026](https://ria.ru/20260707/sber-2103264660.html)
- [Хабр, независимый разбор whitepaper Сбера](https://habr.com/ru/companies/oleg-bunin/articles/1038588/)
- [GitHub, spec-driven development и open source toolkit Spec Kit](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/)
- [GitHub Spec Kit, руководство для существующих проектов](https://github.github.com/spec-kit/guides/existing-projects.html)
- [Birgitta Böckeler на сайте Мартина Фаулера, обзор Kiro, Spec Kit и Tessl, октябрь 2025](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
- [AI-PDLC, бесплатный курс автора на 52 минуты](https://ykononov.ru/aipdlc/)
- [Brownspec, плагин автора для разработки от спецификации в существующем коде](https://github.com/yknnv/brownspec)
- [Vals AI, SWE-bench Verified leaderboard](https://www.vals.ai/benchmarks/swebench) – независимый замер, последнее обновление 1 сентября 2026, тест в архиве
- [SWE-bench Pro, сводка по моделям](https://www.morphllm.com/swe-bench-pro) – агрегатор данных вендоров и стенда Scale, сентябрь 2026
- [Iternal.ai, GPU Sizing for LLMs](https://iternal.ai/hardware-sizing-guide) – расчёт памяти, цены GPU и серверов, TCO на 3 года
- [Разбор самостоятельного размещения GLM 5.2](https://ofox.ai/blog/glm-5-2-self-host-vllm-hardware-cost-2026/) – конфигурации 8×H200, аренда и точка окупаемости
- [GPTunneL](https://gptunnel.ru/) – российский прокси к зарубежным моделям, документация API: [docs.gptunnel.ru](https://docs.gptunnel.ru/)
- [CodeGraph](https://codegraph.ru/) – российская платформа управления разработкой с ИИ, [описание графа кода](https://codegraph.ru/cpg.html)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

### После варианта A

**Даниил:** У нас бы до этого не дошло: в банке агент, который сам меняет контракт между сервисами, сразу становится вопросом аудита, а отвечать – мне. Но тягу понимаю: генеральный видел демо, а я показываю ему автодополнение. Я бы ответил так: агенты нужны, но только там, где ошибку ловит машина вместо человека на ревью. У нас таких мест пока мало – так я прямо и скажу генеральному.

**Мария:** Мы прошли ровно это в первый год. Агенты писали быстрее, чем мы успевали читать, поэтому ревью стало главным узким местом. Ограничивать агентов мы не стали, помогло другое: вложились в тесты и правила для агента – только после этого самостоятельная работа начала окупаться. Сейчас агенты берут задачи целиком, но только на сервисах, где автоматическая проверка ловит больше, чем человек.

- **Даниил:** Мария, ты правда даёшь агентам задачи целиком? У нас регулятор спросит, кто принял решение.
- **Мария:** Тот, кто утвердил спецификацию. Человек отвечает за намерение и проверку, за каждую строку он отвечать не обязан.
- **Даниил:** В банке это пока не работает. Проверяющий хочет видеть человека у каждого изменения.

### После варианта B

**Даниил:** Это ближе всего к тому, что я могу себе позволить. Но учтите: у нас даже ассистент с контекстом проекта уже вопрос к ИБ – модель видит весь монолит. Я бы начал с автодополнения и чата, а контекст проекта открыл после согласования. Так медленнее, зато пилот не остановят посреди квартала. Набор эталонных задач покажу ИБ первым: это хоть какая-то гарантия, что после обновления модели ничего не сломалось.

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

- **Мария:** Даниил, ты слишком осторожен: автодополнение без контекста проекта на монолите мало что даст.
- **Даниил:** Зато его согласуют за неделю. Контекст проекта – весь код банка в чужой модели.
- **Мария:** Тогда уровень автономии тут ни при чём: дело в том, где стоит модель, а это решается отдельно.

### После варианта C

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

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

- **Даниил:** Мария, слой для переключения поставщика тоже стоит денег. В первый год мне их никто не даст.
- **Мария:** Дадут после первого обновления модели, которое сломает работу. Лучше попросить раньше.
- **Даниил:** Или после такого обновления ИБ просто запретит всё разом. В банке так обычно и бывает.

## Промпт для документа: Выбранный уровень автономии и почему

Второй документ курса: какой уровень автономии вы даёте ИИ, на каких задачах и чем ловите ошибку. Готового ответа нет, это ваше решение, поэтому запишите и причину. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.

```
Ты – опытный технический директор. Помоги мне выбрать уровень автономии ИИ в разработке и записать решение в документ «Уровень автономии и почему».

Уровни автономии:
1. Автодополнение – модель подсказывает следующую строку в редакторе.
2. Чат-ассистент – отвечает на вопросы в отдельном окне, код человек переносит сам.
3. Ассистент в редакторе с контекстом проекта – видит кодовую базу и отвечает с её учётом.
4. Агент – сам читает файлы, пишет код и запускает тесты; человек ставит задачу и проверяет результат.
5. Автономный агент – долго работает без вмешательства, сам разбивает задачу и проверяет себя.

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

Что нужно выяснить:
- На каких задачах будем использовать ИИ и на каких точно не будем.
- Цена ошибки на этих задачах: низкая, средняя или высокая. Попроси пример ошибки и её последствий.
- Как ловим ошибку: автоматически (тесты и проверки), ревью человеком или пока никак.
- Что уже есть в окружении: файлы контекста и правила для модели; навигация и поиск по коду; агент может запускать тесты; набор эталонных задач; промпты и файлы контекста под версионным контролем; слой для переключения поставщика модели. Задай это одним вопросом: покажи список и попроси отметить, что есть.
- Какие данные или опыт есть у нас: опросы, статистика пилотов, внутренние замеры.
- Если уровень должен различаться по модулям, выясни, где какой.
- Когда пересмотрим решение: дата или событие.

Предложи уровень на основе ответов и объясни выбор. Не поднимай уровень выше, чем позволяют окружение и способ ловить ошибку. Опирайся на критерии:
- Агент (уровень 4) – только после того, как есть файлы контекста, набор эталонных задач и модель, согласованная с ИБ.
- В небольшой компании без отдельной ИБ агент возможен с первого дня на изолированных задачах, если есть тесты, которые агент запускает сам.

Правила работы:
- Задавай по 1 вопросу за раз и жди моего ответа.
- Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше.
- Если ответ размытый, попроси цифру или конкретный пример.
- Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня.
- Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть.
- Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым.
- Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть.

Формат документа: таблица «Поле | Ответ» со строками: Уровень автономии; На каких задачах; Где не используем; Цена ошибки; Как ловим ошибку; Что есть в окружении; Чего не хватает; Какие данные есть; Почему этот уровень (1 фраза); Когда пересмотрим. Если уровень различается по модулям, добавь в конце по строке на модуль: «Модуль – уровень – почему».
```

### Пример: какие документы получились у Даниила и Марии

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

| Поле | Даниил (банк, первый год) | Мария (продуктовая компания, второй год) |
| --- | --- | --- |
| Уровень автономии | Ассистент в редакторе с контекстом проекта | Агент; на платёжном ядре – ассистент с контекстом проекта |
| На каких задачах | Документация к существующему коду, юнит-тесты, объяснение незнакомых модулей | Миграции, тесты, рутинные доработки API, разбор инцидентов |
| Где не используем | Расчёт процентов по кредитам, регуляторная отчётность | Агента – на платёжном ядре (там только ассистент с контекстом проекта) и в изменениях схемы базы данных |
| Цена ошибки | Низкая | Средняя |
| Как ловим ошибку | Ревью человеком | Автоматически: тесты и проверки, плюс ревью на платёжных модулях |
| Что есть в окружении | Навигация и поиск по коду. Файлы контекста только в 2 командах | Файлы контекста и правила, агент запускает тесты, набор из 40 эталонных задач, промпты под версионным контролем |
| Чего не хватает | Набора эталонных задач, файлов контекста в остальных командах, модели, согласованной с ИБ | Слоя для переключения поставщика модели |
| Какие данные есть | Нет: пилота ещё не было, внутренних замеров нет | За год агент закрыл без правок 70% задач по миграциям и тестам, доля сбойных изменений не выросла |
| Почему этот уровень (1 фраза) | Без эталонных задач и файлов контекста агент в банке будет работать вслепую – сначала строим окружение | Окружение готово, цена ошибки на выбранных задачах ограничена тестами – агент окупается |
| Когда пересмотрим | В следующем квартале, когда появятся эталонные задачи | После подключения второго поставщика модели |
| Модуль – уровень – почему | Один уровень для всех модулей пилотного сервиса | Платёжное ядро – ассистент в редакторе с контекстом проекта – цена ошибки высокая, каждое изменение проходит ревью человеком |

Обратите внимание на строку «Уровень автономии» у Марии: уровень не одинаков для всей компании. Обычно он разный для разных модулей и зависит от того, что уже есть в окружении, а не от того, что умеет инструмент.

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

**Небольшая компания:** агент с первого дня на изолированных задачах (миграции, тесты, новые сервисы по образцу) – цена ошибки ниже, согласований нет, а выигрыш от агента заметнее, чем от автодополнения. Единственное условие – тесты, которые агент может запускать сам.

## Итог блока

- **После варианта A:** Для небольшой компании это правильный ответ: агенты на сервисах с тестами дали самый быстрый результат. В корпорации квартал ушёл на согласование, а проверки между сервисами не поймали сломанный контракт. Главное из блока: уровень автономии зависит от цены ошибки, от того, как вы её ловите, и от того, сколько согласований стоит между вами и агентом. Соберите документ по промпту и переходите дальше.
- **После варианта B:** Вы выбрали дозировать автономию – для корпорации это правильный ответ, хотя Мария права, что окружение даёт больше, чем кажется. В небольшой компании вариант рабочий, но медленнее A. Главное из блока: уровень автономии вы выбираете сами, а выигрыш даёт система вокруг модели, одна модель сама по себе его не обеспечит. Соберите документ по промпту и переходите дальше.
- **После варианта C:** Квартал прошёл не так, как хотелось: модель оказалась не главным. Главное из блока: одна и та же модель в хорошем и плохом окружении даёт очень разный результат, а зависимость от поставщика нужно снижать заранее. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.