Роман Кузнецов | Про технологии, ИИ, и не только

Прежде чем вайбкодить, попробуйте поискать

На «Стартапе наоборот» один из предпринимателей рассказал: ему нужны люди на небольшие разовые работы. Через готовый сервис найти работников за приемлемые деньги не получилось. Возникла идея — разработать похожий.

При этом, по его словам, сам сервис работает нормально. Только людей нет. И откуда они возьмутся в новом приложении, если условия работы останутся прежними?

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

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

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

Для нас в Mobecan это тоже вопрос до оценки разработки: что именно изменится для бизнеса, если мы это напишем? Нам важно, чтобы продукт рос и развивался вместе с бизнесом клиента.

В общем, может, хватит тратить токены и писать очередной велосипед? Сначала поискать, что можно применить. А потом уже делать.

Сначала клиент. Потом продукт: иду экспертом на «Стартап наоборот»

17 сентября буду в экспертной комиссии на встрече бизнес-клуба SOK в Петербурге. Григорий Стратов позвал разбирать реальные задачи предпринимателей.

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

Если продукт имеет смысл — предложим концепцию MVP, сроки и ориентировочный бюджет. Прямо в зале, за один вечер.

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

17 сентября, 18:30
SOK Достоевский, Санкт-Петербург
Щербаков переулок, 17/3, лит. А

Регистрация: https://sok.community/it-2026-09-17.html

Промокод KUZ8R4N — скидка 10% на билет, без ограничения числа билетов по промокоду.

Почта, задачи, CRM. Похоже, всем этим я буду пользоваться через ИИ

Идею этого поста я попросил ИИ сохранить в Reminders. В том же сообщении описал свою мысль и попросил найти исследования: проверить, не слишком ли я увлекся прогнозами. Ассистент создал задачу в списке «Блог» и принес источники.

У меня это работает в Codex через скил personal-assistant. В нем описано, где искать контекст по моим проектам, какими инструментами пользоваться и как действовать. Для задач он обращается к Reminders и YouTrack, для истории работы с клиентом к CRM, для подготовки текста к материалам проекта.

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

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

В опросе YouGov по заказу Zendesk за 2025 год 64% респондентов готовы доверить ИИ списки дел и календарь. Это пока готовность, но для такого сценария уже есть спрос.

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

В State of AI 2026 от Deloitte 85% опрошенных компаний рассчитывают адаптировать ИИ-агентов под свои задачи. Отказ от SaaS из этого не следует. Но запрос на «под нас» уже виден.

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

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

🧑‍💻 Кто вайбкодит по утрам, тот багфиксит вечером

⏩ С помощью ИИ сегодня можно быстро собрать лендинг, Telegram-бота или первую версию сервиса. Это удобно для проверки идеи, однако существует ловушка, в которую попадаются многие вайбкод-фаундеры: велик риск перепутать прототип с продуктом.

👤 Роман Кузнецов, участник форум-группы SPB Founders и фаундер студии разработки Mobecan, работает с проектами, где AI-идею нужно довести до финального запуска:

Проект для ресторана «В ритме Шума» начинался с простой задачи: сократить количество звонков и убрать ручной приём заказов. Но к релизу решение уже принимало заказы в Telegram, проводило онлайн-оплату и передавало данные в Saby.

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

🗂 Роман собрал чек-лист из 12 пунктов, который помогает понять, готов ли AI-прототип к запуску и какие места нужно проверить перед релизом.

👉 Чтобы получить чек-лист, напишите Роману в личку слово вайбкодинг.

PS: Ещё одна частая боль вайбкодеров – публикация в магазинах. Вывести приложение в App Store и Google Play стало сложнее: нужна нормальная карточка, тексты, скриншоты, privacy-разделы, тестовые доступы и прохождение модерации. Студия Mobecan уже много раз выводила клиентские приложения в сторы, и заранее подсветит места, на которых ваш релиз может застрять.

👉 Чтобы договориться о выходе в App Store и Google Play, напишите Роману в личку слово релиз-менеджмент.

Михаил позвал к себе в подкаст, классно пообщались с ним и с Дмитрием про ИИ и Вайбкодинг, обсудили насущные проблемы и рассказали, какие инструменты используем в работе

Бизнес-стейки у воды

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

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

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

#воскресныйгриль

Могут ли ИИ-агенты стоить дороже человека-разработчика? Могут.

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

Но вот в чем засада. ИИ продавали как дешевую замену разработчикам, а по факту компания может получить счета за подписки, API, токены, внедрение и контроль качества, которые уже вполне сравнимы с зарплатой инженера. А иногда и выше, что как-то не укладывается в изначальную идею.

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

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

Мы у себя это уже прошли на практике. Код и сложные правки удобнее отдавать Codex, но потом обязательно гонять тесты и делать review, никуда без этого. Для расшифровок лучше локальная GigaAM: там важнее данные и экономика, а не «самая умная» облачная модель. Если нужно второе мнение по тексту, можно дернуть DeepSeek. А где-то вообще хватает Qwen/Ollama локально, ну или просто обычного скрипта, без всякого ИИ.

Отдельная головная боль, агентные цепочки. Один агент дергает другого, контекст растет как снежный ком, промпты никто толком не оптимизирует. Формально все работает, все крутится. А по факту счетчик тикает, а пользы почти ноль. AWS, кстати, уже писала про runaway agent loops, когда агент зацикливается и начинает генерировать расходы сам по себе, без чьего-либо участия.

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

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

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

А без этого это просто новый счет. Который сначала выглядит маленьким.

AI-код, которому можно доверять. Контур приемки

У нас в Mobecan это стало видно довольно быстро. За один заход AI может поправить несколько файлов, добавить тест и уверенно сказать, что задача готова.

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

В нормальном варианте все начинается не с промпта, а с ожиданий. Что должно измениться и как мы это проверим. Где можно, это превращается в TDD. Сначала тест или проверяемый критерий, потом реализация. Где TDD избыточен, остаются acceptance criteria.

Дальше код проходит тестирование. Форматирование, analyzer, unit-тесты, widget-тесты. Если задеты внешние данные, отдельно проверяем авторизацию, схему или живое чтение. На этом этапе часто всплывают не большие архитектурные проблемы, а обычные мелочи, которые потом больно ловить руками.

Следующий слой - проверка кода. CodeRabbit смотрит diff, ищет потенциальные проблемы, баги, security-риски и странные места в логике.

И здесь важна не только сама проверка, а то, что ее делает отдельный процесс с другим контекстным окном. По сути, отдельный агент. Агент, который писал код, уже немного защищает свою логику. А review-агент смотрит на изменение свежее. Не как автор, а как проверяющий.

AI поправил код задачи. После unit-тестов мы делаем smoke-тест. Открываем реальный экран, создаем или меняем задачу и проверяем, что она действительно появилась или изменилась.

Если всплыла проблема, процесс уходит на исправление. И так несколько кругов, пока проверка не проходит чисто.

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

В итоге AI у нас не просто пишет код быстрее. Вокруг него появилась система приемки. TDD, автоматические тесты, review другим агентом, security-проверка, smoke-сценарии и честный финальный diff.

Так результат получается предсказуемее и не уходит в цикл бесконечных правок.

А как у вас устроена такая проверка?

Как я вовлек команду в ИИ без презентаций: просто показал, где сам экономлю время

На одном из созвонов в Mobecan я просто показал команде, что сам уже автоматизировал у себя в работе.

Не как презентацию про большое AI-будущее и не как лекцию на тему “всем срочно надо пользоваться нейросетями”. Скорее в рабочем формате: вот была задача, которую я раньше делал руками, а вот теперь часть этой рутины забирает автоматизация.

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

И реакция была интересная. Никто, конечно, не сказал: “Все, с понедельника живем в AI-first компании”. Но кто-то зацепился за одну штуку, кто-то за другую. Кто-то спросил, какую подписку купить, кто-то начал уточнять, что установить. Я порекомендовал поставить Codex и начать с простой вещи: взять свою рутину и попробовать снять с себя хотя бы кусок.

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

И следующие созвоны стали уже не про “зачем нам ИИ”, а про “как это применить вот тут”.

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

Я сам был скептиком вайбкодинга. Да и всей этой AI-темы тоже. Слишком много шума, слишком много красивых обещаний, слишком много людей, которые любую кнопку называют ИИ-агентом. Поэтому когда человек в команде скептически смотрит на очередной “новый подход”, я его вполне понимаю.

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

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

Похоже, ИИ в команду лучше заходит не через внедрение сверху, а через первую снятую рутину.

Один раз сэкономил время на своей задаче - и дальше уже сам начинаешь искать, что еще можно автоматизировать.

Недостаточно внедрить AI. Нужно собрать систему, которая окупается

У нас в Mobecan AI постепенно перестал быть одним чатом в браузере.

Я сначала думал про AI довольно просто: есть ChatGPT, есть Codex, есть Claude, есть локальные модели. Ну и дальше вроде вопрос только в том, что открыть под конкретную задачу.

Но чем больше мы это внедряем у себя в Mobecan, тем больше видно, что вопрос не в выборе одного инструмента.

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

Поэтому мы подняли локальную транскрибацию через GigaAM. Не потому что хочется поиграться в on-prem, а потому что в такой задаче это просто здравый смысл: данные остаются у нас, а экономика перестает зависеть от каждого запроса во внешний API.

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

У нас он начинает нормально работать не сам по себе, а когда вокруг есть понятный процесс: задача, репозиторий, тесты, smoke-проверки, возможность быстро посмотреть diff и понять, что именно изменилось.

То есть ценность дает не только модель. Ценность дает связка вокруг нее.

Похожая история с продажами. Мы оцифровали кейсы, коммерческие предложения, часть базы знаний, подключаем CRM. И смысл не в том, чтобы сказать "смотрите, у нас теперь AI в продажах". Смысл в более приземленной вещи: быстрее понять входящий лид, не вспоминать руками, делали ли мы что-то похожее, подобрать нормальные кейсы и подготовить основу для ответа клиенту.

И вот тут начинается самая неприятная часть.

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

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

А ему обычно нужно проще: вот здесь стало быстрее, вот здесь дешевле, вот здесь данные не ушли наружу, вот здесь меньше ручной работы, вот здесь можно проверить эффект.

Потом я наткнулся на статью Berkeley BAIR про compound AI systems и понял, что они нормальным языком описали то, к чему мы у себя приходим руками.

Не одна модель, которая все знает и все делает, а сборка под конкретный процесс.

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

Раньше у меня было ощущение, что LLM - это почти AGI: универсальный интеллект, которому можно отдать любую задачу, и он как-то сам разберется.

Сейчас это ощущение прошло.

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

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

Похоже, AI-проект может не окупиться не потому, что модель плохо отвечает.

А потому что все подряд отправили в самый дорогой внешний API, не посчитали поток данных, не встроили проверку и назвали это внедрением.

Недостаточно внедрить LLM.

Нужно собрать систему, которая окупается в реальной работе.

Нам больше не нужен ваш UI. Дайте MCP-сервер.

Сегодня подключил Bitrix24 к Codex через MCP-сервер и впервые нормально почувствовал: мне для части работы больше не нужен интерфейс Bitrix24. Не весь продукт, понятно. Данные, карточки, сделки, статусы - все это нужно. Но заходить в CRM, искать лид, кликать поля и вспоминать, куда они спрятали нужную кнопку, уже не всегда хочется. Раньше я делал это руками. Теперь можно просто написать или сказать задачу агенту, а он уже идет в Bitrix24 через MCP.

И тут смешной момент. Мы сейчас делаем трекер задач по личной стратегии. Сначала я через Figma MCP проектировал для него интерфейс: экраны, кнопки, структуру сервиса. Потом мы вместе с Codex накидали MCP-сервер для этого трекера.

То есть я сначала сделал UI с помощью MCP, а потом понял, что сам хочу работать с этим сервисом опять же через MCP.

Голосом добавить задачу. Попросить разобрать список. Посмотреть, что связано с личной стратегией. Обновить статус. Найти задачи, которые выпали из фокуса. Для этого мне не всегда надо открывать приложение и что-то там раскладывать руками.

Потом товарищ Эдуард подсказал посмотреть на Linear. У них это уже официальный сценарий: есть MCP-сервер, который можно подключить к Claude, Cursor, Codex и другим клиентам. Агент может искать, создавать и обновлять issues, проекты, комментарии.

И вот тут у меня вопрос стал шире.

А UI вообще останется основным способом работать с сервисами?

Понятно, что он никуда не исчезнет совсем. Где-то нужно посмотреть картину целиком, проверить глазами, настроить, поправить руками, разобраться в спорном месте.

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

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

Может оказаться, что UI останется для контроля, настройки и сложных случаев.

А основная работа с сервисами переедет в разговор с агентом.

И тут у меня закралась крамольная мысль (и я проснулся): а в светлом AI-будущем мы вообще будем управлять сервисами через UI?

Клиент пришел не с задачей. Он пришел с мнением ИИ о нашей смете

У нас уже несколько раз была похожая ситуация.

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

Дальше начинается интересное.

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

После этого клиент возвращается и просит прокомментировать уже не только ТЗ, а то, что ему выдала Ишка.

Получается странная коммуникация.

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

И это не единственный сценарий.

Был еще кейс: собственник сети авторемонтных мастерских собрал небольшую команду разработчиков и веб-кодеров и через нее двигает автоматизацию бизнеса изнутри.

То есть клиент уже не просто приходит к подрядчику с задачей. Он сам собирает вокруг себя маленькую продуктовую команду и двигает автоматизацию изнутри.

Похоже, это важный сдвиг.

Клиент больше не всегда приходит с пустого листа. Он может прийти с ТЗ от ИИ, мнением ИИ о вашей смете, внутренней командой, прототипом и уже готовым ощущением, сколько все должно стоить.

Для агентств это новая реальность, к которой придется привыкать.

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

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

Похоже, агентствам придется привыкать.

Наша работа все чаще будет не просто “разработать”, а сначала разобрать, что клиент уже успел придумать, проверить через ИИ или собрать своей маленькой командой.

Где там польза.
Где нормальная гипотеза.
А где уверенная ерунда, за которую потом все равно кто-то должен будет отвечать.

Почему у одних с AI получается продукт, а у других только красивая демка?

С AI сейчас странная история. Инструменты у всех примерно одни и те же. Cursor, Claude Code, Lovable, ChatGPT и так далее. Но результат почему-то сильно разный.

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

И дело, похоже, не в том, кто лучше пишет промпты.

Я все меньше верю в “просто навайбкодить продукт”. Накидать лендинг, экран, прототип или кусок логики можно. Иногда даже очень быстро и красиво. Но это еще не разработка продукта.

Разработка начинается там, где нужно отвечать за результат. Что именно строим, как оно устроено, где данные, какие роли, какая безопасность, как это потом поддерживать и что будет при следующем изменении.

У меня это хорошо проявилось при создании тасктрекера личных задач и личной стратегии.

Снаружи звучит просто - трекер стратегии. Но как только начинаешь раскладывать, там сразу появляются направления “Я / Семья / Мое дело”, линии развития, OKR, недельные спринты, задачи разных типов, ретро, recovery-сценарии, поддержка, календарь, пользователи, Supabase Auth, RLS.

Если просто сказать AI “сделай мне трекер стратегии”, он что-то сделает. Скорее всего даже красиво. Только это будет не тот продукт.

Поэтому я пошел другим путем. Сначала user-spec (что пользователь должен получить), потом tech-spec (как это технически устроить), потом декомпозиция на задачи, потом TDD (тесты до кода), проверки и контроль качества на каждом этапе.

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

И тут есть неприятный момент, про который легко забыть.

Я сам несколько раз ловил себя на мысли, что мне лень проверять спеку после правок ИИ. Хочется отдать это на откуп - ну он же умный, сам поправил, наверное нормально.

Один раз я уже на этом попался, поэтому теперь гоню эту леность от себя подальше.

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

Вот в этом месте и проходит граница.

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

Поэтому для меня “вайбкодинг продукта” звучит странно.

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

И вот тут уже важен не сам AI, а то, в какой процесс вы его встроили.