# Блок 15. Шаблоны и приложения - Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 15 из 15 - Автор: Юрий Кононов, CTO (https://ykononov.ru/) - Страница: https://ykononov.ru/ai-cto/shablony/ - Обновлено: 2026-10-12. Данные на 2026 год - Время чтения: 35 мин - Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено Здесь собраны рабочие документы, на которые ссылается курс. Каждый шаблон служит отправной точкой, поэтому подстраивайте его под свою компанию: готового ответа в нём нет. Это приложение будет дополняться. Все шаблоны и промпты курса собраны в репозитории-шаблоне [ai-cto-starter](https://github.com/yknnv/ai-cto-starter). Его можно взять за основу своего проекта: там уже лежат файл контекста, документы внедрения, шаблон спецификации и промпты. Набор сделан под Claude Code, но подходит и для других агентов. ## Модель окупаемости Это структура расчёта на квартал, заполняйте её своими числами. Подробный пример на команде из 10 инженеров с токенами, подписками и дефектами разобран в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/), здесь только форма и заполненный образец. | Строка | Как считать | Образец (10 инженеров, квартал) | Ваши числа | | --- | --- | --- | --- | | Р1. Подписки | инженеры × цена × 3 | 10 × 40 $ × 3 = 1 200 $ | | | Р2. Токены по API | для плана – ориентир (инженеры × 200 $ × 3), для отчёта – факт за квартал из данных инструмента | 10 × 200 $ × 3 = 6 000 $ | | | Р3. Своё железо | амортизация + люди, квартал | 0 (нет) | | | Р4. Платформенная работа | доля ставки × месяцы × месячная стоимость ставки | 25% × 3 × 5 000 $ = 3 750 $ | | | Р5. Обучение | инженеры × часы × стоимость часа | 10 × 8 × 30 $ = 2 400 $ | | | **Р. Итого расходы** | Р1 + Р2 + Р3 + Р4 + Р5 | **13 350 $** | | | Э1. Единиц поставки до | baseline, деплои за квартал | 50 | | | Э2. Единиц поставки после | факт за квартал пилота; если пилот короче квартала, пересчитайте на квартал | 60 | | | Э3. Расходы на команду до | люди + инфраструктура, без ИИ | 150 000 $ | | | Э4. Стоимость единицы до | Э3 / Э1 | 3 000 $ | | | Э5. Стоимость единицы после | (Э3 + Р) / Э2 | 163 350 / 60 = 2 722,5 $ | | | Э6. Экономия на поставке | (Э4 − Э5) × Э2; расходы на ИИ уже внутри Э5 | 277,5 × 60 = 16 650 $ | | | Э7. Дефектов на проде до / после | баг-трекер | 8 / 9 | | | Э8. Стоимость дефекта | часы разбора и исправления × ставка | 3 000 $ | | | Э9. Поправка на дефекты | (до − после) × Э8 | (8 − 9) × 3 000 = −3 000 $ | | | **И. Итог за квартал** | Э6 + Э9; Р второй раз не вычитаем | 16 650 − 3 000 = **13 650 $** (около 1,17 млн ₽ по курсу ЦБ на 9 октября 2026) | | Если И отрицательный через квартал, это нормально; через 2 квартала – повод пересмотреть подход. В веб-версии курса эта таблица интерактивная: заполняются только входные строки (Р1–Р5, Э1–Э3, Э7, Э8), остальные считаются сами. **Расходы:** лицензии и подписки (число инженеров × цена); токены по API (для плана – ориентир, для отчёта – фактический расход за период); своё железо, если есть (амортизация оборудования + люди на обслуживание, в пересчёте на квартал); платформенная команда (доля ставки × месяцы × месячная стоимость ставки); обучение (часы инженеров × стоимость часа). Всё вместе даёт итог расходов. **Эффект:** число единиц поставки за квартал до внедрения (baseline) и после него. Стоимость единицы поставки считается так: все расходы на разработку, включая расходы на ИИ, делятся на число единиц. Разница в стоимости единицы × число единиц = экономия или перерасход за квартал. Отдельно считается изменение числа дефектов на проде × средняя стоимость дефекта. **Итог:** экономия на поставке плюс поправка на дефекты. Расходы на ИИ уже вошли в стоимость единицы после, второй раз их не вычитают. Отрицательный результат через квартал считается нормальным, а через 2 квартала это уже повод пересмотреть подход. ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. Это тот же промпт, что в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/). ``` Ты – технический директор с опытом финансового планирования. Помоги мне собрать документ «Модель окупаемости ИИ в разработке на квартал» для финансового директора. Что нужно выяснить: - Был ли уже пилот, если это не ясно из ответа о текущем использовании ИИ. Если пилота не было, считаем план расходов и baseline, колонку «после» оставляем пустой и вопросы о «после» не задаём. - Расходы на ИИ за квартал – одним вопросом: лицензии и подписки; токены по API; своё железо (с учётом амортизации); платформенная команда и обучение. Если токенов ещё нет, предложи ориентир 150–250 $ на инженера с агентом в месяц и пометь его как оценку. - Число деплоев на прод за квартал до внедрения и после. Единица поставки – деплой: его считает система деплоя, а не человек. Пул-реквест и коммит не берём: с ИИ их становится больше сами по себе. - Расходы на команду за квартал до внедрения и после (зарплаты, инфраструктура, расходы на ИИ). - Дефекты на проде за квартал до и после. - Средняя стоимость 1 дефекта. - Что уже защищает от большого счёта – задай одним списком «да / нет»: лимит на сессию; лимит на инженера в день; лимит на команду в месяц; кэширование промптов; роутинг простых задач на дешёвую модель. Как считать: - Для плана до пилота бери ориентиры и помечай их как оценку. Для отчёта по итогам пилота бери только фактические числа. - Итог дай в долларах и в рублях по курсу ЦБ на дату расчёта. Если ты не знаешь курс на эту дату, спроси его последним вопросом. Если я назову другой курс, считай по нему. - Стоимость единицы = все расходы на команду за квартал, включая расходы на ИИ, делённые на число деплоев. - Эффект = (стоимость единицы до − стоимость единицы после) × число деплоев после − стоимость дополнительных дефектов. - Расходы на ИИ уже входят в стоимость единицы «после». Второй раз их не вычитай. - Покажи формулу и промежуточные числа. Если стоимость единицы не снизилась, не подгоняй цифры, а помоги объяснить, почему и что меняем. - Текст для финансового директора напиши сам: 2–3 фразы с цифрами, сроком первых достоверных данных и тем, что пока неизвестно. - Всего задай не больше 14 вопросов, включая вопросы о компании и уточнения. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: заголовок с датой «[дата]»; таблица расходов за квартал с итогом; таблица «Показатель | До | После | Изменение» со строками: деплоев в квартал, расходы на команду, стоимость единицы, дефекты; расчёт эффекта по формуле; список защит от большого счёта (есть / нет); текст для финансового директора. ``` ## Файл контекста для репозитория Это файл в корне репозитория, который ассистент или агент читает перед работой. У разных инструментов он называется по-разному (CLAUDE.md, AGENTS.md, .cursorrules), но содержание одинаковое. ``` # О проекте Что это за система, для кого она и какую бизнес-задачу решает. 2 или 3 предложения. # Архитектура Основные модули и за что они отвечают. Как они связаны. Где точки входа. # Договорённости Принятые и запрещённые библиотеки. Формат логов. Обработка ошибок. Правила именования и список того, что считается публичным интерфейсом и не меняется без согласования. # Как проверять Команда для запуска тестов. Команда для линтера. Что должно проходить до пул-реквеста. # Чего не делать Модули, которые нельзя трогать. Операции, для которых нужно подтверждение человека. Данные, которые нельзя использовать в примерах. # Типичные задачи 2 или 3 примера того, как здесь принято делать типовые вещи, со ссылками на образцовый код. ``` Файл должен быть коротким: модель читает его каждый раз, поэтому длинный файл дорого стоит ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)) и хуже работает. Так выглядит заполненный файл для пилотного сервиса Даниила – около 40 строк, и это нормальный размер: ``` # О проекте fees-service считает комиссии за переводы и операции по картам для розничных клиентов. Вызывается синхронно из transfers-service и cards-service, ответ нужен за 50 мс (p95). Ошибка в расчёте – это претензия клиента и отчёт регулятору, поэтому точность важнее скорости разработки. # Архитектура - api/ REST-контроллеры, точка входа FeeController - core/ правила расчёта, класс FeeCalculator – сердце системы - tariffs/ загрузка тарифов из справочника, кеш на 15 минут - persistence/ JPA-репозитории, схема в db/migrations (Flyway) - reporting/ выгрузки для регулятора, не трогать без согласования # Договорённости - Java 17, Spring Boot 3. Новые зависимости только из внутреннего реестра (см. allowed-deps.txt). - Деньги – только BigDecimal, округление HALF_EVEN, никогда double. - Логи в JSON через общий логгер, без номеров карт и счетов (только маскированные). - Ошибки – исключения из core/errors, коды из errors.yaml. - Публичный интерфейс: всё в api/ и схема базы. Меняется только через спецификацию. # Как проверять - ./gradlew test – модульные, должны проходить всегда - ./gradlew integration – интеграционные, нужен Docker - ./gradlew lint – линтер по стандартам банка До пул-реквеста: тесты и линтер зелёные, покрытие изменённых строк не ниже 70%. # Чего не делать - Не менять core/FeeCalculator и reporting/ без спецификации и ревью 2 сеньоров. - Не добавлять миграции схемы без подтверждения человека. - Не использовать реальные данные клиентов в тестах, только генератор fixtures/. - Не запускать команды деплоя и не трогать файлы в deploy/. # Порог спецификации Через спецификацию (specs/): изменение api/, схемы базы, core/, больше одного модуля. Без спецификации: исправление ошибки в одном модуле, тексты, тесты, рефакторинг внутри модуля. # Типичные задачи - Новое правило комиссии: по образцу core/rules/CrossBorderFeeRule.java, тест рядом. - Новый код ошибки: добавить в errors.yaml, затем в core/errors, см. коммит a81f2c. - Документация модуля: формат docs/MODULE_TEMPLATE.md. ``` Правила ИБ в этом файле не прописаны намеренно: они лежат в отдельном policies.md, пример которого есть в [блоке 05](/ai-cto/bezopasnost-politika-ii/). Из опыта со своим инструментом из [блока 03](/ai-cto/ii-agenty-i-podhody/) я вынес 2 правила, которые касаются любого файла контекста. Первое правило: держите в разных файлах сгенерированное из кода и написанное людьми (правила ИБ, архитектурные ограничения). Если они лежат вместе, одна перегенерация молча удалит правило безопасности и оставит после себя правдоподобный документ. Второе правило: если хотите, чтобы работа через спецификацию была правилом по умолчанию, запишите в файл контекста порог. Порог говорит, что идёт через спецификацию (изменение публичного контракта, схемы базы, больше одного модуля) и что идёт без неё (исправление ошибки, правка текста, рефакторинг внутри модуля). Правило без порога срабатывает на исправлении опечатки, поэтому через неделю его отключают. Готовые шаблоны спецификации, проектирования и задач для существующего кода лежат в репозитории этого инструмента (ссылка в [блоке 03](/ai-cto/ii-agenty-i-podhody/)), в папке templates. Там же есть профиль правил по 152-ФЗ в формате «триггер, требование, что должно быть в спецификации», который можно взять как образец для своих регуляторных правил. ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. ``` Ты – опытный техлид, который писал файлы контекста для ИИ-ассистентов и агентов. Помоги мне написать файл контекста для моего репозитория (CLAUDE.md, AGENTS.md или .cursorrules – название зависит от инструмента). Разделы файла: 1. О проекте: что это за система, для кого она и какую бизнес-задачу решает. 2 или 3 предложения. 2. Архитектура: основные модули, за что они отвечают, как связаны, где точки входа. 3. Договорённости: принятые и запрещённые библиотеки, формат логов, обработка ошибок, правила именования, что считается публичным интерфейсом и не меняется без согласования. 4. Как проверять: команды для тестов и линтера, что должно проходить до пул-реквеста. 5. Чего не делать: модули, которые нельзя трогать; операции, для которых нужно подтверждение человека; данные, которые нельзя использовать в примерах. 6. Порог спецификации: для каких изменений сначала пишется спецификация. 7. Типичные задачи: 2 или 3 примера того, как здесь принято делать типовые вещи, со ссылками на образцовый код. Что ещё нужно выяснить: - На каком языке и каких фреймворках написан сервис. - Каким инструментом с ИИ пользуется команда: от этого зависит название файла. Не проси вставлять код: мне достаточно назвать модули, команды и пути к файлам. Пиши коротко. Файл должен уместиться примерно в 40 строк: модель читает его каждый раз, длинный файл дорого стоит и хуже работает. Если раздел получается длиннее 6 строк, предложи, что вынести в отдельный документ и дать на него ссылку. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: текст файла в блоке кода, заголовки разделов через «#», без вступления и пояснений внутри файла. ``` ## Шаблон спецификации для ИИ ``` # Название задачи ## Зачем Бизнес-причина: что изменится для пользователя или системы. ## Что сделать Конкретное описание результата, без слов «улучшить» и «оптимизировать». ## Где Модули и файлы, которые затрагиваются. ## Ограничения Производительность, совместимость, безопасность, что нельзя менять. ## Критерии приёмки Список проверяемых утверждений в формате «когда X, система должна Y», желательно в виде тестов. ## Чего не делать Явные запреты: не трогать такие-то модули, не добавлять зависимости, не менять интерфейс. ## Открытые вопросы Что нужно уточнить у человека до начала работы. ``` Заполненный пример на задачу из банка (суточный лимит переводов) разобран в [блоке 06](/ai-cto/spec-driven-development/). Ниже – второй пример, короче и из другой среды: продуктовая компания Марии, выгрузка заказов в CSV (табличный файл, где значения разделены запятыми). Задача на один день, но спецификация всё равно нужна, потому что затрагивает публичный контракт. ``` # Экспорт отчёта по заказам в CSV ## Зачем Клиенты тарифа «Бизнес» выгружают заказы в бухгалтерию вручную, копируя таблицу. 5 обращений в поддержку за месяц, 2 клиента назвали это причиной ухода. ## Что сделать Кнопка «Экспорт в CSV» на странице /orders с учётом текущих фильтров. Файл формируется синхронно при объёме до 10 000 строк, при большем – отправляется ссылкой на почту в течение 10 минут. ## Где frontend: pages/orders/Toolbar.tsx; backend: api/orders/export.py (новый), общий модуль exports/ для фоновой генерации уже есть. ## Ограничения Кодировка UTF-8 с BOM (иначе Excel на Windows покажет нечитаемые символы). Разделитель – точка с запятой, как в остальных выгрузках. Суммы – с 2 знаками, разделитель дробной части – запятая. Не больше 1 экспорта в минуту на пользователя. ## Критерии приёмки 1. Экспорт 9 999 строк отдаёт файл сразу, 10 001 – письмо со ссылкой, ссылка живёт 24 часа. 2. Фильтры страницы (период, статус, менеджер) применяются к выгрузке. 3. Файл открывается в Excel и в Google Sheets без ручного выбора кодировки. 4. Второй запрос в течение минуты получает 429 и понятный текст. 5. Поля: номер, дата, клиент, сумма, статус, менеджер – в этом порядке, заголовки на русском. ## Чего не делать Не добавлять форматы XLSX и PDF (отдельная задача). Не менять существующие выгрузки в exports/. Не хранить файлы дольше 24 часов. ## Открытые вопросы Нужно ли включать отменённые заказы по умолчанию? (К продукту, ответ до старта.) ``` ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. Это тот же промпт, что в [блоке 06](/ai-cto/spec-driven-development/). ``` Ты – опытный системный аналитик. Помоги мне превратить задачу из трекера в спецификацию, по которой ИИ-агент сможет работать без догадок. Сначала задай 4 вопроса о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Если требования ИБ или регулятора есть, в поле «Ограничения» спроси, какие данные затрагивает задача. Затем попроси текст задачи, как он записан в трекере, и по очереди выясни: - Проект и задача: сервис, номер задачи, короткое название. - Зачем: какую проблему бизнеса или пользователя решаем. - Что сделать: поведение системы по шагам, включая граничные случаи. - Где: модули, классы, таблицы, которые затронуты. - Ограничения: производительность, запреты на изменения схемы, совместимость. - Критерии приёмки: проверяемые условия, лучше с числами. - Чего не делать: что агенту нельзя трогать. - Поведение при отказах: что происходит, если зависимость медленная, недоступна или отвечает неверно. - Влияние на контракты: кто из потребителей заметит изменение и что им нужно сделать. - Открытые вопросы: что не решено и к кому вопрос. Ищи решения, которые модель иначе приняла бы сама: часовой пояс, обработка ошибок, что попадает в журнал, что считать, а что нет. Задай не больше 5 таких уточняющих вопросов, остальное вынеси в «Открытые вопросы». Если я отвечаю «не знаю», тоже записывай вопрос туда и указывай, к кому он. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Поле | Содержание» с 10 полями выше. 8 полей совпадают с шаблоном спецификации (название задачи и 7 разделов), «Поведение при отказах» и «Влияние на контракты» добавлены для существующего кода. Под таблицей – список решений, которые мы приняли явно, хотя в исходной задаче их не было. ``` ## Политика использования ИИ Политика занимает 1 страницу и имеет такую структуру: 1. **Разрешённые инструменты:** список с названиями и тарифами. Всё остальное запрещено, а новый инструмент добавляется по заявке такому-то. 2. **Аккаунты:** только корпоративные. Личные аккаунты для рабочего кода запрещены. 3. **Что нельзя отправлять в модель:** секреты и ключи, персональные данные клиентов, код систем из списка (перечислить), внутренние документы с грифом. 4. **Ответственность:** за код отвечает тот, кто его смержил. Ссылка на ИИ как источник ответственности не снимает. 5. **Ревью:** код с участием ИИ проходит те же проверки, что и любой другой. Автор должен уметь объяснить, что делает код. 6. **Агенты и бюджет:** действия с внешней отправкой данных, удалением и деплоем требуют подтверждения человека. Лимит на расход токенов: при каком уровне уведомление и при каком остановка. 7. **Журнал и инциденты:** все запросы к модели пишутся в журнал с привязкой к сотруднику, журнал хранится у нас. Если отправили лишнее, нужно сообщить такому-то в течение такого-то срока. За своевременное сообщение санкций нет. 8. **Контакты:** к кому идти с вопросами. Так эта структура выглядит заполненной. Это политика банка Даниила на первый квартал пилота: 1 страница для инженеров, согласована с ИБ и юристами. Приложения для юристов со ссылками на положения Банка России входят в тот же документ, а уточнения проекта из [блока 05](/ai-cto/bezopasnost-politika-ii/) лежат отдельным файлом в репозитории. ``` ПОЛИТИКА ИСПОЛЬЗОВАНИЯ ИИ В РАЗРАБОТКЕ – версия 1.0, действует с 01.11.2026, владелец: технический директор, согласовано: ИБ, Юридический департамент 1. Разрешённые инструменты - Агент в IDE «<название>» корпоративной версии, модель отечественного поставщика по договору, данные хранятся и обрабатываются в России. - Чат-ассистент на той же модели по адресу ai.internal. Всё остальное запрещено. Новый инструмент добавляется заявкой в ИБ через форму SEC-AI-REQ; срок рассмотрения – 10 рабочих дней. 2. Аккаунты Только корпоративная учётная запись через единый вход. Личные аккаунты внешних сервисов для рабочего кода запрещены, в том числе с личных устройств. 3. Что нельзя отправлять в модель Секреты, ключи, токены, пароли; персональные данные клиентов и сотрудников; исходный код систем из перечня критичных (ledger, reporting, antifraud) целиком – допускаются фрагменты до 200 строк без конфигураций; документы с грифом «Для служебного пользования» и выше. 4. Ответственность За код отвечает тот, кто его смержил. Ссылка «это написала модель» ответственности не снимает. Автор пул-реквеста должен уметь объяснить каждое изменение. 5. Ревью и проверки Код с участием ИИ проходит те же проверки конвейера, что и любой другой (блок 09). В описании пул-реквеста обязательна отметка «ИИ: да/нет» и ссылка на спецификацию, если она требовалась по порогу из файла контекста. 6. Агенты и бюджет Действия агента с деплоем, удалением данных, отправкой данных за контур, изменением прав доступа и миграциями схемы выполняются только после подтверждения человека. Агент не имеет учётных данных продуктивных сред. Лимит на расход токенов задаётся на команду: при 70% – уведомление лиду, при 100% – остановка агентных запусков до решения технического директора. 7. Журнал и инциденты Все запросы к модели пишутся в журнал с привязкой к сотруднику и выгружаются в систему мониторинга ИБ (SIEM). Журнал хранится в контуре банка, срок хранения задаёт ИБ. Если в модель отправили лишнее, сотрудник сообщает в ИБ через канал #ai-incidents в течение 1 рабочего часа. За своевременное сообщение санкций нет. Сокрытие рассматривается как нарушение. 8. Контакты Вопросы по инструментам – платформенная команда (#ai-platform). Вопросы по правилам – ИБ (#security). Предложения по изменению политики – технический директор, пересмотр раз в квартал. ``` Важно, чего в политике нет: списка запрещённых задач по типам (это решает лид команды через файл контекста), требований к стилю промптов, обязательной отметки каждой строки кода. Политика на 1 страницу живёт дольше, чем регламент на 20 страниц. ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. Это тот же промпт, что в [блоке 05](/ai-cto/bezopasnost-politika-ii/). ``` Ты – технический директор, который уже согласовывал ИИ-инструменты с ИБ и юристами. Помоги мне написать «Политику использования ИИ в разработке» на 1 страницу, 8 пунктов, простым языком. Пункты политики: 1. Разрешённые инструменты: какие инструменты и модели можно использовать, где они работают (облако поставщика, отечественный поставщик, наш контур) и как добавить новый инструмент. 2. Аккаунты: только корпоративные. 3. Что нельзя отправлять в модель: секреты и ключи; персональные данные клиентов; код систем из закрытого списка; внутренние документы с грифом. Спроси, что ещё добавить. 4. Ответственность: за код отвечает тот, кто его смержил, а не ИИ. 5. Ревью: какие правила ревью для такого кода. 6. Агенты и бюджет: какие действия агента требуют подтверждения человека (внешняя отправка данных; удаление; деплой – спроси, что ещё); лимит на расход токенов и что происходит при его достижении. 7. Журнал и инциденты: что записываем в журнал запросов и где он хранится (в нашем шлюзе или у поставщика); что делать, если в модель ушло лишнее, и куда сообщать без санкций за своевременное сообщение. 8. Контакты: к кому идти с вопросами. Что ещё нужно выяснить: - Какие опасения ИБ уже озвучила. Пункты 2 и 4 – позиция по умолчанию. Если я предлагаю более слабый вариант (личные аккаунты, ответственность «на ИИ»), возрази и объясни риск. Если отдельной ИБ и юристов в компании нет, не останавливайся. Владельцем политики и согласующим запиши технического директора, в пункте 8 укажи, кто отвечает за вопросы безопасности. Вместо вопроса об опасениях ИБ спроси, какие риски я сам вижу сейчас. Пиши коротко: каждый пункт – 1–3 предложения без юридических оборотов. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: заголовок, дата «[дата]», 8 пронумерованных пунктов, внизу – кто согласовал (оставь места для подписи ИБ и юристов; если их нет – для технического и генерального директора). ``` ## Чек-лист для ИБ Это вопросы, на которые нужен ответ до согласования инструмента. - Обучается ли поставщик на наших данных? Есть ли это в договоре? - Где физически обрабатываются данные? Соответствует ли это 152-ФЗ и отраслевым требованиям? - Какой срок хранения запросов у поставщика? Можно ли его сократить до нуля? - Есть ли журнал действий с привязкой к сотруднику? Экспортируется ли он в нашу систему? - Как инструмент аутентифицирует пользователей? Интегрируется ли с корпоративным входом? - Какие права получает агент? Можно ли их ограничить по средам и репозиториям? - Как инструмент защищён от prompt injection? Какие действия требуют подтверждения? - Что происходит при потере доступа к поставщику? Есть ли план перехода? - Какие юридические гарантии даёт поставщик по сгенерированному коду? - Прошёл ли инструмент оценку уязвимостей и когда это было? Пример заполненного чек-листа по одному из инструментов, которые рассматривал Даниил. Третья колонка – вердикт ИБ, и именно она определяет, идёт ли инструмент в пилот. | Вопрос | Ответ поставщика | Вердикт ИБ | | --- | --- | --- | | Обучается ли на наших данных? | Нет, зафиксировано в договоре, пункт 7.3 | Принято | | Где обрабатываются данные? | Модель работает в дата-центре поставщика в России, по договору; данные об использовании уходят поставщику | Принято при условии отключения этой передачи или её прохождения через прокси ИБ | | Срок хранения запросов | Не хранятся после обработки, это зафиксировано в договоре | Принято | | Журнал действий с привязкой к сотруднику | Да, экспорт в формате JSON по API | Принято, нужна интеграция с SIEM (системой сбора и анализа событий безопасности) до старта | | Аутентификация | Единый вход (SSO, single sign-on) по протоколу SAML (стандарт, по которому системы передают друг другу данные о входе пользователя), поддерживается | Принято | | Права агента | Ограничиваются на уровне репозиториев и сред через конфигурацию | Принято, продуктивные среды исключить | | Защита от prompt injection | Фильтр входящего контента и список действий с подтверждением | Частично: список подтверждаемых действий расширить по политике банка | | Потеря доступа к поставщику | Инструмент перестаёт работать, пока доступ не восстановят | Принято, план перехода на открытую модель в контуре банка – в течение квартала | | Юридические гарантии по коду | Возмещение по претензиям о нарушении авторских прав в пределах стоимости договора | Передано юристам | | Оценка уязвимостей | Внешний пентест в марте 2026, отчёт предоставлен | Принято | 1 «частично», 1 «принято при условии» и 1 «передано юристам» – это нормальный результат. Инструмент пошёл в пилот с условиями, а не был отклонён: ИБ стала участником, потому что её вопросы были заданы до выбора, а не после. ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. ``` Ты – руководитель ИБ, который согласовывал ИИ-инструменты для разработки. Помоги мне заполнить чек-лист по 1 инструменту, чтобы прийти в службу ИБ с готовыми ответами поставщика. Вопросы чек-листа: 1. Обучается ли поставщик на наших данных? Есть ли это в договоре? 2. Где физически обрабатываются данные? Соответствует ли это 152-ФЗ и отраслевым требованиям? 3. Какой срок хранения запросов у поставщика? Можно ли его сократить до нуля? 4. Есть ли журнал действий с привязкой к сотруднику? Экспортируется ли он в нашу систему? 5. Как инструмент аутентифицирует пользователей? Интегрируется ли с корпоративным входом? 6. Какие права получает агент? Можно ли их ограничить по средам и репозиториям? 7. Как инструмент защищён от prompt injection? Какие действия требуют подтверждения? 8. Что происходит при потере доступа к поставщику? Есть ли план перехода? 9. Какие юридические гарантии даёт поставщик по сгенерированному коду? 10. Прошёл ли инструмент оценку уязвимостей и когда это было? Сначала спроси, какой инструмент мы рассматриваем и как он подключается: облако поставщика, отечественный поставщик, российский прокси или модель в нашем контуре. Потом иди по вопросам по одному. На каждый я отвечаю тем, что знаю от поставщика: из договора, документации или переписки. Если ответа поставщика нет, не подставляй свой: запиши «нет ответа» и сформулируй вопрос, который нужно отправить поставщику. Если ответ есть, но он общий («данные защищены»), скажи, чего в нём не хватает. Вердикт ставит служба ИБ, а не ты. В колонке «Вердикт ИБ» предложи черновик из 4 вариантов: «принято», «принято при условии …», «частично: …», «передать юристам». Отказ по 1 пункту не означает отказа от инструмента: предложи условие, при котором пункт можно закрыть. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Вопрос | Ответ поставщика | Черновик вердикта ИБ», под ней список вопросов, которые нужно отправить поставщику, и список условий, с которыми инструмент может пойти в пилот. ``` ## Дизайн пилота - **Цель:** 1–2, сформулированные через метрики из таблицы [блока 11](/ai-cto/metriki-dora-baseline/). - **Baseline:** значения этих метрик за 3 месяца до старта. - **Группа:** состав по правилам [блока 13](/ai-cto/komanda-roli-obuchenie/) (энтузиасты, средние инженеры, скептик, представитель ИБ). - **Сервис:** типичный, даже если есть более удобный. - **Задачи:** с чего начинаем (понимание кода, документация, тесты; миграции в корпорации – во второй волне) и что не трогаем. - **Инструмент:** один, согласованный с ИБ. - **Бюджет:** лимит на пилот с предохранителем. - **Срок:** минимум 6 недель данных. - **Метрики еженедельно:** 5 показателей на одной панели. - **Как отделим эффект ИИ:** контрольная группа, разнесение по времени или разбивка по этапам ([блок 11](/ai-cto/metriki-dora-baseline/)). - **Критерии успеха:** что должно произойти, чтобы перейти ко второй волне. - **Критерии остановки:** что должно произойти, чтобы пилот прекратить. Заполненный дизайн пилота с числами и календарь первых 2 недель есть в [блоке 14](/ai-cto/pilot-90-dney/), состав группы – в [блоке 13](/ai-cto/komanda-roli-obuchenie/). ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. Это тот же промпт, что в [блоке 14](/ai-cto/pilot-90-dney/). ``` Ты – технический директор, который уже запускал пилоты ИИ в разработке. Помоги мне составить «Дизайн пилота» на 90 дней. Первым делом спроси, есть ли у меня готовые документы: состав пилотной группы, baseline метрик, модель окупаемости. Если есть, попроси вставить их в чат и возьми данные оттуда; не переспрашивай то, что в них уже есть. Только после этого задай 4 вопроса о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Что нужно выяснить: - Цель: что изменится и на сколько, с числом. Метрика цели должна успеть измениться за срок сбора данных: если от постановки задачи до прода проходит больше месяца, за 6 недель изменения не увидеть – бери время от коммита до прода или отдельные этапы. Отдельно – какой результат будет полезен даже при неудаче. - Baseline: значения метрик за последние 3 месяца. Если baseline нет, спроси, можно ли выгрузить историю за 3 месяца из трекера задач, системы деплоя и баг-трекера: обычно это работа на несколько дней. Если истории нет, скажи прямо: пилот откладывается, сначала настраиваем сбор данных и копим их хотя бы месяц. Включи это в календарь и отметь в списке слабых мест, что сравнение с 1 месяцем слабее, чем с 3. - Группа: кто и сколько человек. - Сервис: какой и почему он типичный. - С каких задач начинаем: понимание кода, документация, тесты, миграции. И что точно не трогаем. - Инструмент: какой и где работает модель. - Бюджет на токены и предохранители: уведомление, остановка, лимит на сессию. - Срок: сколько недель подготовки и сколько недель сбора данных (не меньше 6). - Метрики, которые смотрим еженедельно. - Как отделим эффект ИИ от других изменений: контрольная группа, разнесение по времени или разбивка по этапам. Что ещё меняется за эти 90 дней (найм, новый процесс, автоматизация) и как это учтём. - Критерии успеха: при каких числах пилот удался. - Критерии остановки: при каких событиях или числах останавливаем пилот. Проверь, что критерии успеха и остановки сформулированы числами, а не словами «улучшится» или «не ухудшится». Напомни, что за 6 недель деплоев мало: 1 сбой сильно меняет долю сбойных изменений, поэтому критерии по ней задавай и в абсолютных числах. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: заголовок с датой «[дата]»; таблица «Поле | Содержание» со всеми пунктами выше; затем календарь подготовки на тот срок, который я назвал: «Дни | Что происходит | Результат». ``` ## Вопросы вендорам Вот что стоит спросить у поставщика инструмента до покупки. 1. Какие результаты вы можете показать именно на brownfield, без демонстраций с нуля? 2. Какие метрики использования и расхода мы увидим в вашей панели? Можно ли их экспортировать? 3. Как считается стоимость: подписка, токены, их сочетание? Что происходит при превышении? 4. Какие модели работают внутри и можно ли их менять? Что произойдёт при обновлении модели? 5. Можно ли развернуть в нашем контуре? С какими ограничениями? 6. Что вы гарантируете по лицензионной чистоте сгенерированного кода? 7. Как устроен аудит действий и в каком формате он отдаётся? 8. Какие права требует агент и как их ограничить? 9. Кто из ваших клиентов в нашей отрасли и можно ли с ними поговорить? 10. Что будет с нашими данными при расторжении договора? ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. ``` Ты – технический директор, который выбирал ИИ-инструменты для разработки. Помоги мне подготовиться к разговору с поставщиком и потом разобрать его ответы. Базовые вопросы: 1. Какие результаты вы можете показать именно на brownfield, без демонстраций с нуля? 2. Какие метрики использования и расхода мы увидим в вашей панели? Можно ли их экспортировать? 3. Как считается стоимость: подписка, токены, их сочетание? Что происходит при превышении? 4. Какие модели работают внутри и можно ли их менять? Что произойдёт при обновлении модели? 5. Можно ли развернуть в нашем контуре? С какими ограничениями? 6. Что вы гарантируете по лицензионной чистоте сгенерированного кода? 7. Как устроен аудит действий и в каком формате он отдаётся? 8. Какие права требует агент и как их ограничить? 9. Кто из ваших клиентов в нашей отрасли и можно ли с ними поговорить? 10. Что будет с нашими данными при расторжении договора? Работа идёт в 2 шага. Шаг 1, до встречи. Спроси, какого поставщика и какой инструмент мы рассматриваем и что для нас важнее всего: стоимость, безопасность, работа с существующим кодом или что-то ещё. По ответам переставь вопросы в порядке важности для нас и к каждому добавь 1 уточняющий вопрос на случай общего ответа. Собери список для встречи. Шаг 2, после встречи. Я вставлю ответы поставщика. По каждому вопросу отметь: ответ конкретный, общий или его нет. Общий ответ – это обещание без цифры, срока, пункта договора или имени клиента. Не оценивай поставщика по его маркетинговым материалам и не додумывай ответы за него. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: после шага 1 – нумерованный список вопросов с уточнениями. После шага 2 – таблица «Вопрос | Ответ поставщика | Оценка: конкретный, общий, нет ответа | Что запросить дополнительно» и под ней 3 главных риска, которые нужно закрыть до покупки. ``` ## Чек-лист самооценки Это полная версия списка из [блока 14](/ai-cto/pilot-90-dney/). Отвечайте «да» или «нет»: каждое «нет» становится пунктом плана. **Подготовка:** baseline снят за 3 месяца. Политика на 1 страницу подписана. ИБ согласовала инструмент и участвует. Бюджет ограничен предохранителями. Цели пилота сформулированы через метрики. **Пилот:** группа собрана по правилам, сервис типичный. Файлы контекста написаны. Обучение проведено на реальных задачах. Метрики смотрятся еженедельно. Участие ИИ в каждом изменении зафиксировано. **Результат:** стоимость единицы поставки посчитана и сравнена с baseline. Доля сбойных изменений не выросла. Время ревью под контролем. Использование подтверждено данными инструмента. Эффект ИИ отделён от других изменений. **Масштабирование:** вторая волна подтвердила результат пилота. Есть платформенная команда. Есть план на случай потери доступа к поставщику. Карьерная лестница и оценка инженеров пересмотрены. Каждое обещание из [блока 02](/ai-cto/zachem-vnedryat-ii/) подтверждено или открыто признано неподтверждённым. Пример: так чек-лист выглядел у Даниила в день 0, до начала подготовки. Каждое «нет» стало строкой календаря первых 2 недель из [блока 14](/ai-cto/pilot-90-dney/). | Пункт | Ответ | Что делаем | | --- | --- | --- | | Baseline снят за 3 месяца | Нет (есть только 2 показателя из 5) | Дни 2–5: выгрузка из трекера, системы деплоя и баг-трекера | | Политика на 1 страницу подписана | Нет | Дни 3–6: черновик по шаблону выше, согласование с ИБ и юристами | | ИБ согласовала инструмент и участвует | Нет | Дни 1–2: встреча, чек-лист для ИБ, назначение участника; дни 3–13: согласование инструмента | | Бюджет ограничен предохранителями | Нет | Дни 5–7: лимиты 70% / 100% / 15 $ на сессию | | Цели пилота сформулированы через метрики | Частично (есть «ускориться», нет чисел) | День 14: 2 цели в дизайне пилота | | Группа собрана по правилам, сервис типичный | Частично (есть энтузиасты, нет скептика и ИБ) | Дни 7–9 | | Файлы контекста написаны | Нет | Дни 8–12 | | Обучение на реальных задачах проведено | Нет | Дни 10–13 | | Метрики смотрятся еженедельно | Нет | День 14: панель из 5 метрик | | Участие ИИ в каждом изменении зафиксировано | Нет | Шаблон пул-реквеста с отметкой «ИИ: да/нет» | 10 пунктов, 8 «нет», 2 «частично» – и это нормальная стартовая точка. Опасна не она, а пилот, который начинается с такой таблицей без 2 недель на подготовку. **Небольшая компания:** из чек-листа можно вычеркнуть интеграцию с SIEM, участника от ИБ и формальное согласование инструмента, но нельзя вычеркнуть baseline, политику на 1 страницу, лимит на токены и файлы контекста. Это 4 вещи, которые одинаково нужны и банку на 200 инженеров, и стартапу на 5. ### Промпт для этого шаблона Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. ``` Ты – технический директор, который уже проводил внедрение ИИ в разработку. Помоги мне пройти чек-лист самооценки и превратить каждое «нет» в пункт плана. Пункты чек-листа: Подготовка: 1. Baseline снят за 3 месяца. 2. Политика на 1 страницу подписана. 3. ИБ согласовала инструмент и участвует. 4. Бюджет ограничен предохранителями. 5. Цели пилота сформулированы через метрики. Пилот: 6. Группа собрана по правилам, сервис типичный. 7. Файлы контекста написаны. 8. Обучение проведено на реальных задачах. 9. Метрики смотрятся еженедельно. 10. Участие ИИ в каждом изменении зафиксировано. Результат: 11. Стоимость единицы поставки посчитана и сравнена с baseline. 12. Доля сбойных изменений не выросла. 13. Время ревью под контролем. 14. Использование подтверждено данными инструмента. 15. Эффект ИИ отделён от других изменений. Масштабирование: 16. Вторая волна подтвердила результат пилота. 17. Есть платформенная команда. 18. Есть план на случай потери доступа к поставщику. 19. Карьерная лестница и оценка инженеров пересмотрены. 20. Каждое обещание из обоснования внедрения подтверждено или открыто признано неподтверждённым. Сначала спроси, на каком мы этапе: до пилота, в пилоте, после пилота или во второй волне. До пилота иди только по пунктам 1–5, в пилоте – по 1–10, дальше – по всем. На каждый пункт я отвечаю «да», «нет» или «частично». Если «да», попроси назвать, чем это подтверждается: документом, цифрой или датой. Если подтверждения нет, запиши «частично». Если «нет» или «частично», спроси, что мешает, и предложи конкретное действие со сроком. Если отдельной службы ИБ в компании нет, в пункте 3 спроси, кто отвечает за вопросы безопасности. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Пункт | Ответ | Что делаем | Срок», под ней строка с итогом: сколько «да», «нет» и «частично», и 3 пункта, с которых нужно начать. ``` ## Итоги курса Вы прошли курс. Надеюсь, он поможет вам внедрить ИИ в процессы разработки. Помните: цифры, подходы и данные курса служат ориентиром. Адаптируйте их под свою компанию. Если по какому-то блоку у вас сложилось своё мнение, доверяйте ему. Я хотел дать пищу для размышлений и хорошую базу для старта. Строгой инструкции здесь нет. Спасибо, что уделили курсу время. Буду благодарен, если вы оставите отзыв и расскажете о курсе коллегам и в соцсетях. **Подписывайтесь:** - [LinkedIn](https://www.linkedin.com/in/ykononov/) - [Телеграм-канал @ykononovmd](https://t.me/ykononovmd) **Пишите мне:** - Телеграм: [@ykononov](https://t.me/ykononov) - почта: [kononovpost@gmail.com](mailto:kononovpost@gmail.com) **Попробуйте мои сервисы:** - [aisuppy.com](https://aisuppy.com/): ассистент в Телеграме. За обратную связь даю месяц бесплатного использования. Просто напишите мне в Телеграм [@ykononov](https://t.me/ykononov). - [Brownspec](https://ykononov.ru/brownspec/): спецификации для существующего кода, плагин для Claude Code. Бесплатный. Идеи, вопросы и предложения о сотрудничестве присылайте в Телеграм или на почту.