{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Андрей Крисанов: заметки с тегом ИИ", "_rss_description": "Блог Андрея Крисанова о разработке в эпоху ИИ: прикладной ИИ, инфраструктура ИИ, ИИ-нативные продукты и управление инженерными командами.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/agenticeng.ru\/tags\/ii\/", "feed_url": "https:\/\/agenticeng.ru\/tags\/ii\/json\/", "icon": "https:\/\/agenticeng.ru\/pictures\/userpic\/userpic@2x.jpg?1775503436", "authors": [ { "name": "Андрей Крисанов", "url": "https:\/\/agenticeng.ru\/", "avatar": "https:\/\/agenticeng.ru\/pictures\/userpic\/userpic@2x.jpg?1775503436" } ], "items": [ { "id": "8", "url": "https:\/\/agenticeng.ru\/all\/genai-cost\/", "title": "Сколько на самом деле стоит GenAI в продакшене", "content_html": "

Когда обсуждают стоимость внедрения генеративного ИИ, разговор часто сводится к цене за токен или цене за арендуемый GPU. Это удобно — одно число. Но в реальном продакшене такая оценка почти всегда обманчива.<\/p>\n

Стоимость GenAI-системы — это не только сколько стоит вызвать модель. Это инфраструктура, эксплуатация, безопасность, наблюдаемость, разработка, интеграции, поддержка пользователей и постоянные изменения вокруг моделей. Именно поэтому «мы поднимем open-source модель сами, будет дешевле» часто оказывается правдой только на первом слайде презентации.<\/p>\n

Из чего складывается стоимость GenAI в продакшене<\/h3>\n

Типовая GenAI-система состоит не из одной модели. Даже если бизнес-задача звучит просто, например, сделать Q&A чат-бота по документам, внутри быстро появляются:<\/p>\n

поддержка пользователей и команд, которые интегрируются с этим сервисом<\/li>\n<\/ul>\n

Пока всё работает в демо-режиме, это кажется избыточным. Но как только сервис начинает использоваться внутри компании, особенно в задачах с персональными данными, документами, юридическими текстами, финансами или внутренними знаниями, нужна архитектура и практики.<\/p>\n

Цена за токен — заметный, но не единственный расход<\/h3>\n

Если использовать Yandex Cloud AI Studio<\/a>, стоимость зависит от режима работы модели и количества токенов: входных, исходящих, кешированных и токенов инструментов. Это уже важная деталь: один и тот же пользовательский сценарий может стоить по-разному в зависимости от длины промпта, длины ответа, истории диалога и использования tools.<\/p>\n

Например, в синхронном режиме YandexGPT Pro 5.1 стоит 0,8 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов с НДС. YandexGPT Lite стоит 0,2 ₽ за 1000 входящих и 0,2 ₽ за 1000 исходящих токенов. DeepSeek V3.2 в AI Studio стоит 0,5 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов.<\/p>\n

Допустим, у нас есть внутренний ассистент, который обрабатывает 1 млн запросов в месяц. Средний запрос:<\/p>\n

1000 входящих токенов<\/li>\n

500 исходящих токенов<\/li>\n<\/ul>\n

Тогда примерная стоимость генерации:<\/p>\n\n\n\n\n\n
Модель<\/b><\/td>\n Расчёт на 1 запрос<\/b><\/td>\n 1 млн запросов в месяц<\/b><\/td>\n<\/tr>\n
YandexGPT Lite<\/td>\n 0,2 ₽ + 0,1 ₽<\/td>\n 300 000 ₽<\/td>\n<\/tr>\n
YandexGPT Pro 5.1<\/td>\n 0,8 ₽ + 0,4 ₽<\/td>\n 1 200 000 ₽<\/td>\n<\/tr>\n
DeepSeek V3.2<\/td>\n 0,5 ₽ + 0,4 ₽<\/td>\n 900 000 ₽<\/td>\n<\/tr>\n<\/table>\n
На этом этапе возникает соблазм сказать, что Lite дешевле Pro в 4 раза и нужно брать эту модель. Но если Lite отвечает хуже, чаще требует повторных запросов, хуже следует инструкциям, хуже работает с длинным контекстом или создаёт больше ошибок для пользователей, реальная стоимость может быть выше. Дешёвый токен может привести к дорогому бизнес-процессу.<\/p>\n
Покупка GPU vs оплата за токены<\/h3>\n
Другой популярный подход — поднять open-source модель самостоятельно на своей инфраструктуре. Например, через vLLM, TGI или другой serving-стек.<\/p>\n
В Yandex DataSphere конфигурация g2.8 с 8 GPU A100 стоит 4 401,83808 ₽ в час. При расчёте 720 часов в месяц это примерно:<\/p>\n
4 401,84 ₽ × 720 ≈ 3 169 323 ₽ \/ месяц<\/code><\/pre>Конфигурация g2.1 с 1 GPU A100 стоит 550,22976 ₽ в час<\/i>, а g1.1 с 1 GPU V100 — 341,52192 ₽ в час<\/i>. Цены DataSphere для региона Россия указаны с НДС.<\/p>\n На первый взгляд, 8×A100 за ~3,17 млн ₽\/месяц может выглядеть конкурентно, если у вас большой объём трафика. Но это только compute. Дальше нужно добавить:<\/p>\n \nKubernetes или другой runtime<\/li>\n хранилище для моделей и образов (container registry)<\/li>\n observability стек (наблюдаемость)<\/li>\n сетевую инфраструктуру<\/li>\n инженерную команду<\/li>\n<\/ul>\nа также процессы вокруг:<\/p>\n \nобновления моделей<\/li>\n тестирования качества<\/li>\n безопасности<\/li>\n работу с деградациями и инцидентами<\/li>\n<\/ul>\nDataSphere отдельно тарифицирует хранение моделей, Docker-образов, дисков, датасетов и других артефактов; например, хранение модели внутри DataSphere сверх бесплатных лимитов стоит 13,08 ₽ за 1 ГБ в месяц.<\/p>\n То есть self-hosting может быть дешевле на большом масштабе. Но он редко бывает дешевле сам по себе. Он становится выгодным, когда у компании уже есть сильная инфраструктурная команда, понятный объём нагрузки и реальная потребность контролировать serving, latency, безопасность и модельный стек.<\/p>\n Главный скрытый расход — ФОТ<\/h3>\nВ России стоимость инженерной команды ниже, чем в США, но она всё равно быстро становится одной из основных категорий расходов. По данным Dream Job, средняя зарплата ML Engineer в России в 2026 году — 185 000 ₽ на руки, типичный диапазон — 140 000—230 000 ₽, а в Москве среднее значение указано как 260 000 ₽. Другой обзор по рынку ML-инженеров указывает ориентиры по грейдам: Middle — около 160 000—200 000 ₽, Senior — 280 000—350 000 ₽, Lead — 360 000—450 000 ₽ в зависимости от региона и формата работы.<\/p>\n Но для продакшен GenAI вам обычно нужен не один ML Engineer. Минимальный состав может выглядеть так:<\/p>\n\n\n\n\n\n\n\nРоль<\/b><\/td>\n Зачем нужна<\/b><\/td>\n<\/tr>\n Backend Engineer<\/td>\n API, бизнес-логика, интеграции<\/td>\n<\/tr>\n ML \/ LLM Engineer<\/td>\n выбор моделей, промпты, evals, качество<\/td>\n<\/tr>\n Platform \/ DevOps Engineer<\/td>\n Kubernetes, GPU, CI\/CD, observability<\/td>\n<\/tr>\n Security \/ InfoSec<\/td>\n доступы, данные, аудит, compliance<\/td>\n<\/tr>\n Product \/ Analyst<\/td>\n сценарии, метрики, приоритизация<\/td>\n<\/tr>\n<\/table>\nДаже маленькая команда из 2—3 сильных инженеров может стоить компании заметно больше, чем API-вызовы модели. Особенно если считать не только зарплату на руки, а полную стоимость сотрудника: налоги, оборудование, менеджмент, найм, отпуска, простои, коммуникации и стоимость ошибок.<\/p>\n Именно здесь часто ломается наивная математика: API стоит 1 млн ₽ в месяц, а self-hosting на GPU — 3 млн ₽. Значит API дешевле<\/i>.<\/p>\n Или наоборот: GPU стоит 3 млн ₽ в месяц, а API при нашем объёме стоит 5 млн ₽. Значит self-hosting дешевле<\/i>.<\/p>\n Обе оценки неполные. Нужно считать людей, эксплуатацию, риски и качество.<\/p>\n Доступ к LLM через API vs self-hosting<\/h3>\nУпрощённо выбор выглядит так.<\/p>\n Доступ к LLM через API<\/h3>\nВыгоднее если вы только запускаете продукт, нагрузка непредсказуема, команда маленькая, а главная задача — быстро проверить гипотезу. В этом случае YandexGPT, DeepSeek или другие модели через API позволяют не строить всю инфраструктуру с нуля.<\/p>\n Плюсы:<\/p>\n \nбыстрый старт<\/li>\n не нужно управлять GPU<\/li>\n проще масштабироваться на раннем этапе<\/li>\n меньше эксплуатационной нагрузки<\/li>\n проще считать стоимость на уровне токенов<\/li>\n<\/ul>\nМинусы:<\/p>\n \nзависимость от провайдера<\/li>\n ограничения по моделям и настройкам<\/li>\n меньше контроля над latency (временем отклика)<\/li>\n сложнее оптимизировать serving под свой сценарии и тип нагрузки<\/li>\n возможные ограничения по данным и комплаенсу<\/li>\n<\/ul>\nSelf-hosting моделей<\/h3>\nВыгоднее если у вас большой и стабильный объём запросов, есть инфраструктурная команда, нужны строгие требования по данным, есть желание контролировать модели, serving-стек, batching, маршрутизацию и стоимость на большом масштабе.<\/p>\n Плюсы:<\/p>\n \nбольше контроля<\/li>\n можно оптимизировать serving<\/li>\n можно выбирать open-source модели<\/li>\n можно строить собственный роутинг и механизмы кэширования<\/li>\n потенциально ниже стоимость за токен на большом объёме<\/li>\n<\/ul>\nМинусы:<\/p>\n \nвысокая сложность<\/li>\n нужен опыт с GPU-инфраструктурой<\/li>\n нужны SRE-практики<\/li>\n нужно самим решать инциденты<\/li>\n нужно самим обновлять модели<\/li>\n нужно самим строить evals и release gates<\/li>\n<\/ul>\nСкрытые расходы, о которых забывают<\/h3>\n Наблюдаемость<\/h3>\nДля обычного backend-сервиса достаточно latency, error rate, throughput и логов. Для LLM-системы этого мало.<\/p>\n Нужно понимать:<\/p>\n \nсколько токенов потребляется<\/li>\n какие промпты дают плохие ответы<\/li>\n где растёт latency<\/li>\n где модель галлюцинирует<\/li>\n какие пользователи повторяют запросы<\/li>\n какие инструменты вызываются<\/li>\n какие документы попадают в контекст<\/li>\n как меняется качество после обновления модели<\/li>\n<\/ul>\nБез этого система становится чёрным ящиком: деньги тратятся, пользователи жалуются, а команда не понимает, где проблема.<\/p>\n Обновление моделей<\/h3>\nМодель — это не статичная библиотека. Провайдеры обновляют версии, меняют поведение, добавляют новые режимы, снимают старые версии с поддержки.<\/p>\n Каждое обновление требует:<\/p>\n \nрегрессионного тестования<\/li>\n сравнения качества<\/li>\n проверки промптов<\/li>\n проверки latency<\/li>\n проверки стоимости<\/li>\n коммуникации с пользователями<\/li>\n rollback-плана<\/li>\n<\/ul>\nЕсли этого нет, можно обновить модель и сломать upstream-команды.<\/p>\n Безопасность<\/h3>\nВ корпоративном контексте вопрос не только в том, где дешевле токен.<\/p>\n Нужно отвечать на вопросы:<\/p>\n \nкакие данные уходят в модель<\/li>\n логируются ли запросы<\/li>\n где хранятся трейсы запросов<\/li>\n можно ли отправлять персональные данные<\/li>\n как работает маскирование PII и других данных<\/li>\n кто имеет доступ к истории запросов<\/li>\n можно ли использовать внешние tools<\/li>\n как аудитить действия агента<\/li>\n<\/ul>\nЭто не бесплатная часть системы. Её кто-то должен проектировать, внедрять и поддерживать.<\/p>\n Качество<\/h3>\nСтоимость плохого ответа может быть выше стоимости токенов.<\/p>\n Например, если модель помогает бухгалтерии, юристам, поддержке или инженерам, ошибка может привести к:<\/p>\n \nпотере времени<\/li>\n неправильному решению<\/li>\n ручной перепроверке<\/li>\n недоверию пользователей<\/li>\n отказу от продукта<\/li>\n инциденту безопасности<\/li>\n<\/ul>\nПоэтому более дорогая модель иногда дешевле в реальности, если она снижает количество ошибок и повторных запросов.<\/p>\n Как посчитать полную стоимость GenAI-системы<\/h3>\nХорошая формула выглядит не так:<\/p>\n TCO = цена токенов<\/code><\/pre>где TCO — это Total Cost of Ownership, т. е. полная стоимость владения<\/b>.<\/p>\n А примерно так:<\/p>\n TCO =\n стоимость inference\n+ стоимость инфраструктуры\n+ стоимость хранения\n+ стоимость сети\n+ стоимость разработки\n+ стоимость эксплуатации\n+ стоимость observability\n+ стоимость безопасности\n+ стоимость обновления моделей\n+ стоимость ошибок<\/code><\/pre>Для managed API основная переменная часть — токены. Для self-hosting — GPU, инфраструктура и команда.<\/p>\n Практический подход:<\/p>\n \nПосчитать ожидаемый объём запросов.<\/li>\n Разделить входные и исходящие токены.<\/li>\n Посчитать стоимость для 2—3 моделей.<\/li>\n Добавить RAG: embeddings, хранилища, поиск.<\/li>\n Добавить observability и логи.<\/li>\n Оценить стоимость команды.<\/li>\n Оценить стоимость поддержки и инцидентов.<\/li>\n Сравнить API и self-hosting не на демо, а на горизонте 6—12 месяцев.<\/li>\n<\/ol>\nПример: внутренний AI-ассистент<\/h3>\nДопустим, компания хочет сделать внутреннего ассистента для сотрудников.<\/p>\n Параметры:<\/p>\n \n1 000 активных пользователей<\/li>\n 30 запросов на пользователя в месяц<\/li>\n 30 000 запросов в месяц<\/li>\n 1 500 входящих токенов<\/li>\n 700 исходящих токенов<\/li>\n<\/ul>\nДля YandexGPT Pro 5.1:<\/p>\n Вход: 1500 \/ 1000 × 0,8 ₽ = 1,2 ₽\nВыход: 700 \/ 1000 × 0,8 ₽ = 0,56 ₽\nИтого: 1,76 ₽ за запрос\n\n30 000 × 1,76 ₽ = 52 800 ₽ \/ месяц<\/code><\/pre>Для YandexGPT Lite:<\/p>\n Вход: 1500 \/ 1000 × 0,2 ₽ = 0,3 ₽\nВыход: 700 \/ 1000 × 0,2 ₽ = 0,14 ₽\nИтого: 0,44 ₽ за запрос\n\n30 000 × 0,44 ₽ = 13 200 ₽ \/ месяц<\/code><\/pre>На таком масштабе стоимость токенов почти наверняка не будет главным расходом. Главным расходом будет разработка, интеграция, поддержка, безопасность и внедрение в бизнес-процессы.<\/p>\n Но если это уже не 30 000, а 3—10 млн запросов в месяц, математика меняется. Тогда имеет смысл отдельно смотреть на кэширование, роутинг запросов, batch-режимы, более дешёвые модели для простых задач и self-hosting.<\/p>\n Вывод<\/h3>\nГлавная ошибка при оценке GenAI систем — сравнивать только цену токена или часа за аренду GPU.<\/p>\n Для прототипа это нормально. Для продакшена — нет.<\/p>\n Managed API может быть дороже на единицу inference, но дешевле по TCO (полной стоимости владения), если экономит месяцы разработки и эксплуатации. Self-hosted open-source модель может быть дешевле на большом объёме, но только если у вас есть команда, инфраструктура и зрелые процессы.<\/p>\n Правильный вопрос звучит не так:<\/p>\n \nКакая модель дешевле?<\/p>\n<\/blockquote>\n А так:<\/p>\n \nКакая архитектура даёт нужное качество, время отклика, безопасность и управляемость при минимальной полной стоимости владения?<\/p>\n<\/blockquote>\n И почти всегда ответ зависит не от одной цены в прайсе, а от масштаба, команды и зрелости компании.<\/p>\n", "summary": "Разбираемся, сколько на самом деле стоит GenAI-система в продакшене: токены, GPU, Yandex Cloud, self-hosted модели, зарплаты инженеров, эксплуатация и полная стоимость владения.", "date_published": "2026-04-27T21:55:46+03:00", "date_modified": "2026-04-27T22:01:07+03:00", "tags": [ "LLM", "ИИ", "инфраструктура ИИ", "стоимость" ], "_date_published_rfc2822": "Mon, 27 Apr 2026 21:55:46 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "8", "_e2_data": { "is_favourite": false, "links_required": [ "highlight\/highlight.js", "highlight\/highlight.css" ], "og_images": [] } }, { "id": "7", "url": "https:\/\/agenticeng.ru\/all\/go-and-coding-agents\/", "title": "Go как язык программирования в эпоху агентов", "content_html": " На дворе 2026 год, и любые рассуждения о разработке с AI-агентами рискуют устареть быстрее, чем мы допишем README.md в нашем репозитории. Тем не менее некоторые вещи уже начинают выглядеть не как временный шум, а как новые инженерные практики.<\/p>\n Одна из таких вещей — изменение отношения к языкам программирования.<\/p>\n Раньше мы часто выбирали язык программирования по тому, насколько на нём удобно писать человеку. Насколько он выразителен или позволяет быстро накидать прототип. Насколько приятно читать написанный код через полгода, когда ты уже забыл, зачем вообще всё это делал.<\/p>\n AI меняет картину. Если заметную часть кода пишет не человек, а агент, то удобство языка остаётся важным для нас, разработчиков, но перестаёт быть единственным критерием при выборе языка программирования для нового проекта. Внезапно оказывается, что язык должен быть удобен ещё и для агентного цикла: сгенерировал код, собрал проект, прогнал тесты, получил ошибку, исправил, повторил.<\/p>\n И в таком цикле Go выглядит неожиданно хорошо.<\/p>\n Так ли критичны недостатки Go<\/h3>\nGo всегда был немного странным языком в глазах людей, привыкших к более выразительным альтернативам. Он простой, иногда слишком. Многословный и без особой магии, с ручной обработкой ошибок. С кодом, который часто выглядит так, будто его писал очень дисциплинированный, но слегка потерявший интерес к программированию разработчик.<\/p>\n Примерно так:<\/p>\n data, err := os.ReadFile(path)\nif err != nil {\n return fmt.Errorf("read config %q: %w", path, err)\n}<\/code><\/pre>Никакой поэзии — зато всё понятно.<\/p>\n Такая многословность иногда раздражает. Писать однотипную обработку ошибок руками — удовольствие так себе. Генерировать обвязку, тесты, HTTP-ручки, конфигурацию, простые клиенты к API — тоже не самая вдохновляющая работа.<\/p>\n Но AI-агентам для написания кода всё равно. Они не страдают от кучи похожего кода, не закатывают глаза на очередной if err != nil<\/i>. Они просто генерируют код, а потом получают от компилятора и тестов обратную связь.<\/p>\n В этот момент недостатки Go перестают быть такими уж серьёзными. А старые достоинства — простота, явность, единообразие — становятся гораздо важнее.<\/p>\n AI любит предсказуемость<\/h3>\nЧем больше в языке и экосистеме вариантов сделать одно и то же, тем выше шанс, что модель выберет не тот вариант.<\/p>\n В экосистемах вроде JavaScript или Python это видно особенно хорошо. Исторически там накопилось много способов собрать проект, управлять зависимостями, писать асинхронный код, строить веб-приложения, описывать конфигурацию и раскладывать файлы по директориям.<\/p>\n Для опытного разработчика это пространство выбора. Для модели — пространство для галлюцинаций.<\/p>\n Go устроен иначе. В нём меньше вариантов, меньше магии, меньше стилистической свободы. Типичный Go-код часто похож на другой Go-код, и это не баг, а фича. У языка есть стандартный форматтер, понятный набор инструментов, быстрый компилятор, простая модель сборки и достаточно единообразная культура написания кода. Это делает Go удобным не только для людей, но и для AI-агентов.<\/p>\n Модель лучше работает там, где меньше случайности. Go как раз про это.<\/p>\n Хороший агентный цикл важнее синтаксиса<\/h3>\nВ разработке c AI-ассистентами и агентами не надо верить, что модель сразу напишет идеальный код — это завышенное ожидание. Скорее всего, не напишет. Или напишет почти правильно, что иногда даже хуже.<\/p>\n Нормальный процесс выглядит иначе: план → генерация кода → сборка → тесты → исправления → ревью<\/i>.<\/p>\n И чем проще этот цикл, тем лучше:<\/p>\n gofmt -w .\ngo test .\/...\ngo vet .\/...\ngolangci-lint run<\/code><\/pre>Ошибки компилятора обычно конкретные. Тесты запускаются просто. Форматирование единое. Линтеры можно встроить в CI. Сборка проекта не требует сложного окружения и скриптов. Во многих случаях на выходе получается один бинарник, который легко положить в контейнер и отправить в продакшен.<\/p>\n Такие скучные вещи делают AI-разработку безопаснее. Промптами можно объяснить агенту многое, но не всё. А вот компилятор, тесты, линтеры, контракты API и CI-проверки не интерпретируют задачу творчески, как это могут делать модели. Они просто говорят: вот здесь сломано, чини.<\/p>\n Такие инструменты гораздо надёжнее, чем надеяться на длинный промпт в духе «пожалуйста, пиши хороший код».<\/p>\n Go как язык для разработки с кодинговыми агентами<\/h3>\nAI не отменяет инженерную дисциплину. Скорее наоборот: он делает её важнее.<\/p>\n Когда в проекте появляются агенты, цена плохих тестов, слабого CI, неясных контрактов и хаотичной структуры кода растёт. Агент может быстро написать много кода. Но если среда не умеет этот код проверять, мы просто быстрее получим больше проблем и технического долга.<\/p>\n В этом смысле Go интересен не сам по себе, а как пример правильной экосистемы для новой реальности:<\/p>\n \nменьше магии, больше явности<\/li>\n быстрый feedback loop<\/li>\n хорошие инструменты из коробки<\/li>\n простая сборка под любую архитектуру и ОС<\/li>\n<\/ul>\nНе самый красивый язык, не самый выразительный и не самый модный. Но очень удобный для мира, где код всё чаще пишется в паре с машиной.<\/p>\n И, возможно, именно поэтому Go сейчас выглядит сильнее, чем несколько лет назад. Не потому что он изменился, а потому что изменился контекст вокруг него.<\/p>\n", "summary": "Как AI-агенты меняют критерии выбора языков программирования и почему простота, предсказуемость и хороший набор инструментов снова делают Go сильным вариантом для разработки продакшен-систем.", "date_published": "2026-04-24T23:09:06+03:00", "date_modified": "2026-04-24T23:10:05+03:00", "tags": [ "go", "golang", "агенты", "ИИ" ], "_date_published_rfc2822": "Fri, 24 Apr 2026 23:09:06 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "7", "_e2_data": { "is_favourite": false, "links_required": [ "highlight\/highlight.js", "highlight\/highlight.css" ], "og_images": [] } }, { "id": "2", "url": "https:\/\/agenticeng.ru\/all\/vnedrenie-ii-v-produktovyh-komandah\/", "title": "Внедрение ИИ в продуктовых командах", "content_html": " За последние несколько месяцев мне довелось пообщаться с тремя компаниями по поводу роли руководителя кросс-функциональной команды или CTO в зрелом бизнесе. У каждой были свои ожидания от роли и свои цели на год. Но одна задача повторялась почти у всех: внедрить ИИ в команды разработки и за счет этого повысить их эффективность<\/b>.<\/p>\n Контекст обычно был примерно такой. Есть устоявшаяся команда, есть зрелый продукт, но, по мнению менеджмента, разработка идет слишком медленно. ИИ-инструменты и кодинговые агенты внутри команды либо почти не используются, либо используются точечно, каждым по-своему, без общего подхода. Иногда их уже пробовали, но результат оказался слабее ожиданий. А на рынке в это время появляются истории о том, как CEO или CPO за ночь собирают прототипы с помощью Codex или Claude Code.<\/p>\n Выслушав такой запрос, я начинал задавать не вопросы про модели и инструменты, а совсем другие:<\/p>\n \nкак сейчас выглядит delivery-процесс от появления идеи до релиза<\/li>\n как команда оформляет бизнес- и системные требования<\/li>\n как работает с макетами и передает контекст между участниками<\/li>\n как разработчики превращают требования сначала в архитектуру, а потом в код<\/li>\n как команда контролирует качество на разных этапах<\/li>\n<\/ul>\nНа этом месте можно возразить: «А какое вообще отношение процессы разработки имеют к внедрению ИИ?» На мой взгляд — самое прямое. Чтобы объяснить почему, представим себе две команды.<\/p>\n Первая команда<\/h2>\nУ первой команды процессы более-менее выстроены. Люди умеют фиксировать мысли в текстовом и визуальном виде и передавать контекст друг другу. Типичная цепочка выглядит так:<\/p>\n идея → бизнес-требования и макеты → системные требования → архитектура → задачи на разработку<\/p>\n В такой команде разработчики не ждут, что аналитик, менеджер или кто-то еще полностью упакует контекст за них. До того как задача попадает в работу, команда уже думает про качество, риски, архитектуру и критерии приемки. В результате заранее появляются артефакты, которые сильно упрощают реализацию.<\/p>\n Обычно такие команды неплохо умеют работать асинхронно. Люди пишут документы, оставляют после себя след в виде решений, описаний и ревью-комментариев. Это помогает не только людям, но и ИИ.<\/p>\n Вторая команда<\/h2>\nВо второй команде тоже может быть формальный Scrumban, но по факту работа устроена иначе. Задачи сразу падают в таск-трекер. Требования, если и пишутся, то вперемешку: бизнес-логика, технические детали и допущения лежат в одном месте. Критерии приемки толком не продуманы. Архитектура рождается уже после того, как задачу взяли в работу. О рисках вспоминают позже. Фичи выкатываются быстро, а инциденты тушатся ситуативно.<\/p>\n Снаружи может казаться, что команда движется быстро. Но внутри там обычно много недосказанности, устного контекста и зависимости от конкретных людей.<\/p>\n В какой команде ИИ взлетит быстрее<\/h2>\nТеперь представим, что мы хотим внедрить ИИ в обе команды. Условный критерий успеха простой: команда должна делать больше тем же составом, без выгорания и без просадки по качеству.<\/p>\n Допустим, разработчику выдали доступ к ChatGPT, Claude Code или другому ассистенту. Внутри такого инструмента — большая языковая модель. Она генерирует ответ, опираясь на тот контекст, который ей передали.<\/p>\n И вот здесь возникает ключевой вопрос: какая из двух команд быстрее получит реальную пользу от ИИ?<\/b><\/p>\n Очевидно, первая.<\/p>\n Почему? Потому что у нее уже есть зафиксированный контекст: требования, ограничения, архитектурные решения, стандарты разработки, критерии приемки. Разработчик может взять эти артефакты, явно обозначить границы задачи и начать работать с агентом почти сразу.<\/p>\n Пример запроса может выглядеть так:<\/p>\n \nТы — опытный backend-разработчик. В приложенном документе описаны бизнес- и системные требования для фичи обработки банковских выписок. В RFC-123 зафиксирована текущая архитектура. Предложи вариант реализации нового метода API GET \/bank-statements\/. Также учти наши стандарты разработки: стиль кода, подход к REST API и требования к автотестам. Сначала предложи план реализации, затем список изменений по слоям системы и набор тест-кейсов.<\/p>\n<\/blockquote>\n То есть разработчик из первой команды за несколько минут собрал хороший контекст и получил шанс на действительно полезный результат.<\/p>\n Во второй команде тот же разработчик, скорее всего, останется один на один с агентом и начнет вручную восстанавливать недостающий контекст: что именно нужно сделать, какие ограничения есть у системы, какие договоренности приняты в команде, какие риски важны, как вообще здесь пишут код. Даже если в итоге что-то получится, путь будет долгим, а вероятность хорошего результата — заметно ниже.<\/p>\n Вывод<\/h2>\nИз этого следует простой вывод: внедрение ИИ зависит не только от интереса к технологии, но и от зрелости производственных процессов.<\/p>\n Context is king — и в общении с людьми, и в работе с ИИ.<\/b><\/p>\n Если команда не привыкла фиксировать решения, оформлять требования и создавать артефакты, на которых потом строится работа, ей будет трудно быстро получить заметный эффект от ИИ. В такой ситуации лиды начинают выгорать: сверху ждут роста эффективности, снизу люди пробуют агентов, но результат не совпадает с ожиданиями.<\/p>\n Поэтому, когда меня спрашивают про внедрение ИИ в продуктовой команде, мой ответ обычно один и тот же: сначала выровняйте delivery-процесс, а потом уже системно внедряйте ИИ<\/b>.<\/p>\n Современные модели и агенты действительно могут сильно ускорять работу. Но в хаотичных и плохо оформленных процессах они гораздо менее эффективны. ИИ хорошо усиливает уже существующую инженерную дисциплину. Если дисциплины нет, он редко становится волшебной таблеткой.<\/p>\n", "summary": "Почему внедрение ИИ в продуктовых командах часто не дает результата? Разбираемся, как delivery-процессы, требования, архитектура и рабочий контекст влияют на эффективность AI-инструментов и кодинговых агентов.", "date_published": "2026-04-08T18:40:09+03:00", "date_modified": "2026-04-08T18:40:06+03:00", "tags": [ "delivery-процессы", "LLM", "ИИ", "управление разработкой" ], "_date_published_rfc2822": "Wed, 08 Apr 2026 18:40:09 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "2", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1", "url": "https:\/\/agenticeng.ru\/all\/llm-and-foundation-models\/", "title": "Прикладной ИИ: LLM и Foundation модели", "content_html": " В декабре 2025 года, еще работая в ПланФакте, я начал рассказывать командам о прикладном ИИ и о том, как его можно внедрять в продукты. Через несколько недель мое сотрудничество с компанией завершилось, и я решил полностью сосредоточиться на системах искусственного интеллекта.<\/p>\n На новом месте быстро появилась та же задача: помогать разработчикам, пользователям GenAI-платформы и менеджменту лучше понимать большие языковые модели (LLM), их возможности и ограничения. В итоге это выросло в серию лекций, часть которых я могу опубликовать.<\/p>\n Первая лекция — «LLM и foundation-модели». Это вводный материал для тех, кто хочет понять:<\/p>\n \nчто такое AI Engineering и чем он отличается от подхода «просто взять и использовать ChatGPT»<\/li>\n что такое foundation-модели и как они работают<\/li>\n как устроен Transformer без математики и лишней теории<\/li>\n<\/ul>\nЛекция может быть полезна разработчикам без опыта в ML\/AI системах, QA, а также менеджерам, тимлидам и продактам, которым важно понимать основы, чтобы принимать взвешенные решения.<\/p>\n Ниже — запись.<\/p>\n \n