Ко мне пришёл запрос, который я слышу всё чаще. Компания делает клиент‑серверные продукты. В ней три продукта, три владельца продукта, технический и продуктовый директор. Задача звучит так: «нужно практическое внедрение ИИ в процессы создания и сопровождения продуктов». И дальше — конкретный список того, чего от меня ждут: набор инструкций по использованию нейросетей, готовые промпты, стартовые скилы. Для менеджеров — прототипирование и работа с гипотезами. Для разработки — генерация кода, тестирование, баги, рефакторинг.
Для девопсов — CI/CD и диагностика.
Звучит как хорошо подготовленный, ответственный запрос. В нём есть и анализ, и разбиение по ролям, и даже готовый список инструментов. Не хватает только одного — ответа на первый вопрос, без которого всё остальное — движение вслепую.
Этот вопрос: в чём цель внедрения ИИ?
Начать с конца — значит вводить в эксплуатацию без ТЗ
Я понимаю, откуда берётся такой запрос. Руководство смотрит вокруг: все внедряют ИИ, боятся отстать. Они находят человека, который давно работает в компании, у которого есть и авторитет, и знания, и поручают ему «внедрить ИИ». Человек подходит ответственно: проводит анализ, находит лучшие инструменты, разбирается в них, разворачивает, выдаёт инструкции.А коллеги этими новыми инструментами не пользуются. И смотрят как‑то не очень дружелюбно.
Знакомая картина? Если да — значит, работа началась с конца. На языке, который понятен каждому инженеру: пытались ввести продукт в эксплуатацию до тестирования, до разработки и до написания технического задания. Никто не будет строить приложение, не поняв, какую боль оно снимает и как мы поймём, что оно работает. С внедрением ИИ — ровно то же самое. ИИ — это не волшебная кнопка, а новый инструмент. Инструмент вставляется в процесс. А процесс можно улучшить или сломать.
Два вопроса, с которых начинается любое изменение
Прежде чем приносить сверху набор инструкций и новых программ, нужно ответить на два вопроса.
Первый: понимаем ли мы, каков конвейер зарабатывания денег у этой фирмы?Второй: есть ли метрики, привязанные к этому конвейеру?
Чаще всего честный ответ — «нет». И это не упрёк, а диагноз. Без этих двух ответов любое изменение процессов — гадание. Мы не знаем, куда вставляем инструмент, и не знаем, как потом доказать, что от него стало лучше.
Даже если сегодня руководство не спрашивает, как окупаются затраты на «ИИ‑зацию», завтра оно спросит непременно. И вот тогда прийти придётся не с рассказом о том, сколько инструкций написано и сколько скилов развёрнуто, а с цифрами. А цифр не будет, потому что их некому было снять.
Между молотом и наковальней
Любое «внедрение изменений» ставит человека между двумя силами. С одной стороны — руководство, которое ждёт результата. С другой — сотрудники, которые будут сопротивляться изменениям до тех пор, пока изменения не станут выгодными им самим.
И здесь кроется причина, по которой инструкции сверху не работают: выгода со стороны фирмы и выгода со стороны сотрудника — вещи зачастую противоположные.
Пример, который слышали все, кто когда‑либо внедрял инструменты. Сотруднику говорят:«При помощи этой красивой тулзы ты будешь делать презентации в десять раз быстрее!»А сотрудник слышит совсем другое:«То есть теперь вместо одной презентации я должен делать десять за те же деньги?»Он прав. Пока ускорение не даёт ему личной выгоды, новый инструмент для него — это просто увеличение нагрузки.
Ускорение узла и что за ним стоит
Обратите внимание: пример с презентациями — ещё хороший случай. В нём ускорение узла приводит к увеличению работы. Это значит, что узел действительно был узким местом — на него был спрос, он сдерживал поток. Ускорили — работы стало больше, потому что раньше она упиралась в это место.
А вот если ускорение узла не приводит к увеличению работы, значит, мы вообще не то ускоряли. Это не узкое место, и ускорение ничего не изменило.
Есть и третий, самый неприятный для людей сценарий: ускорение ведёт к оптимизации. Вместо десяти делателей презентаций теперь нужен один. С точки зрения фирмы — выгода. С точки зрения девяти человек — потеря работы. И эти изменения тоже не встретят радости. Люди пойдут с вилами на того, кто эти изменения принёс, — если только сначала не продать саму идею перемен снизу.
Продать идею снизу, а не спустить сверху
Сопротивление людей — не глупость и не лень. Это рациональная реакция на изменение, в котором они не видят своей выгоды. Поэтому первая работа — не разворачивать инструменты, а перевернуть вектор: сделать так, чтобы интересы сотрудников и интересы фирмы смотрели в одну сторону.
Как это выглядит на практике. Руководство говорит:«Если окупаемость продукта выйдет на пять иксов — всем двадцать процентов премии».
Это меняет всё. Теперь ускорение — не «больше работы за те же деньги», а «больше денег за ту же работу». Сотрудник начинает смотреть на новый инструмент не как на врага, а как на способ дойти до премии.
Но чтобы сказать такое — и, главное, выполнить — нужны метрики, привязанные к конвейеру зарабатывания денег. Без них «пять иксов» — пустой звук, и сотрудники это почувствуют мгновенно. Обещание без цифр не продаёт идею, а добивает доверие.
Ине забываем про руководство: оно тоже боится перемен, потому что это тоже люди. Директор, который запустил «внедрение ИИ» из страха отстать, так же уязвим перед неизвестностью, как сотрудник, который боится потерять работу. Разница только в том, с какой стороны молота и наковальни каждый стоит.
С чего начинать на самом деле
Чтобы привязать метрики к конвейеру, конвейер нужно сначала понять, а потом описать. И описать не «как хотелось бы», а как есть сейчас. Это и есть то самое техническое задание, с которого начинается любое настоящее внедрение.
Порядок такой:
Понять конвейер зарабатывания денег: какая последовательность дел неизменно приводит фирму к деньгам.
Описать его как есть — без приукрашивания, со всеми переделками, задержками и обходными путями.
Найти узкое место — этап, на котором поток стоит или даёт больше всего брака.
Привязать к этому месту метрику — простую, которую можно снять за день.
Придумать максимально простое изменение улучшающее метрику.
Описать изменение руководству. Если руководство предлагает «не торопиться» — оно не готово к каким бы то ни было переменам.
Спросите сотрудника, чья работа поменяется: «Что изменится лично для тебя, когда это заработает?» Если ответа нет — идею ещё не продали.
Сколько нужно сотрудников, чтобы внедрить ИИ?
Достаточно одного, но только если организация готова меняться:‑)
А с чего вы начали внедрении ИИ?
Комментарии (26)
WaRLoC
30.10.2026 22:45Тоже охренел с начала. "Внедрите нам ии!" ... Ага щас. Обычно первый вопрос это: нахрена он нам нужен за эти конские деньги?
mckeenly15
30.10.2026 22:45Очередной "специалист по внедрению ИИ", публикующий ИИ-сгенерированную статью про внедрение ИИ.
ИИ тоже будет ИИ внедрять?
JuryPol
30.10.2026 22:45А вот эти перечисленные и пронумерованные пункты, это то, что должна обеспечить сторонняя компания, прежде чем к вам обратиться за внедрением у них ИИ?
amazingname
30.10.2026 22:45Как внедрять AI:
1. Выдать сотрудникам лимит на самую лучшую из всех доступных моделей эквивалентный 20-30% их зарплаты, сказать что AI это хорошо и поощряемо.
2. Подождать месяца три пока люди естественным образом глядя друг на друга перелезут на кодинг, создание тесткейзов и прочее с помощью AI.
3. Немного подтолкнуть ключевых сотрудников для коллективных экспериментов со всякими BMAD и прочим и вообще поиска путей переложить максимум работы на AI.
4. Посмотреть что на этот момент происходит с AI, как это влияет на экономические показатели компании и что дальше.
Почему именно так: потому что возможности моделей растут с невероятной скоростью и правильного способа внеднения AI не знает никто, ни звезды из Антропика, ни сам господь бог.
Фактически как только мы начинаем понимать что могут а что не могут модели и начинаем кристаллизовать какие-то процессы разработки, возможности моделей растут и мы все снова занимаемся экспериментами.На самом деле даже хуже тото - стоимость кода решающего проблемы заказчика, как основного продукта девальвируется с невероятной скоростью и вы понятия не имеете чем будет зарабатывать ваша компания через год и в чем будет ее конкурентное преимущество на рынке.
Любые специалисты по внедрению AI - это переносчики знаний а не их генераторы, а переносить пока нечего - все меняется раньше чем они эти знания изучат и донесут. Поэтому они все бесполезны.
ToxaBes
30.10.2026 22:455. Прочитать утром новость как Антропик банит россиян по паспорту и осознать, что вся работа в компании только что встала.
6. Выключить телефон, разместить свое резюме на hh.ru
Чет вспомнил, Григорий Остер - "Вредные советы". Ваш список из той же оперы.
amazingname
30.10.2026 22:45Я не из России. Учитывая что Хабр таки русскоязычный я и написал "из доступных". При этом на китайских моделях вы конечно будете отставать на пол года - год от компаний силиконовой долины, но тут уж кто вам поможет.
ToxaBes
30.10.2026 22:45Я внедрял ML и в US, и в EU, и в MENA (ME часть). И я прекрасно помню как компании в Северной Европе внедряли "полный хохотач" в виде корпоративной Антропик подписки, увольняли большую часть программистов и менеджеры начинали писать код.
А потом Антропик два раза за две недели забанил корпоративный аккаунт. Каждый раз его восстанавливали, тк компания белая и пушистая, но осадочек остался. Потом начался "рыжий дизастер" и все резко заговорили о том, что хватит использовать американские модели, где там наш Мистраль и почему он не на гос уровне внедряется. Т.е. они медленно, но верно начинают разворачиваться в сторону on-prem решений.
У нас же ситуация еще интереснее, использование американских моделей стало фактором риска и неопределенности. Большинство компаний требуют использовать только модели созданные в дружественных странах. Сейчас это Китай и Иран (у них внезапно есть отличные CV решения). Из вопроса качества это стало вопросом безопасности.
вы конечно будете отставать на пол года - год от компаний силиконовой долины, но тут уж кто вам поможет.
Вы вряд ли сможете обосновать зачем использовать самую мощную фронтир модель для решения ежедневных задач если более слабые модели с ними справляются. Например, у меня локально работают модели уровня Opus 4.8-5 (не 5.5!) и мне их полностью достаточно. Сила модели не только в ней, но и в ее обвязке. И это хорошо понимают провайдеры фронтир моделей.
У вас есть заблуждение, что тот же Fable 5 это одна модель. Это не так.
Во-первых, у них несколько десятков моделей разного качества и скорости под этим именем и разные пользователи в разных задачах работают с разными моделями из этого семейства. Наиболее опытные замечают, что иногда модель резко деградирует на 1-2 дня и потом восстанавливается на тех же самых задачах. Они просто попали на a/b тест новой модели из этого же семейства.
Во-вторых, Антропики сильны инфраструктурой. У них очень сильный роутинг и контекстная подгрузка по доменам знаний и они очень быстро его переключают на нужную модель из семейства. Сейчас новые GPT модели пытаются также делать, но лаг пока что заметен.
В-третьих, те цифры бенчмарков, которые они пишут в отчетах - не воспроизводимы. Это касается не только Антропиков, все так делают, включая Alibaba (Qwen). Поэтому когда будете смотреть на красивые числа в отчете по модели помните что в реальной работе вы будете сталкиваться не с ней.
amazingname
30.10.2026 22:45Вы вряд ли сможете обосновать зачем использовать самую мощную фронтир модель для решения ежедневных задач если более слабые модели с ними справляются.
Пока вы будете решать ежедневные задачи на слабых моделях ваши конкуренты найдут новое поле возможностей доступное только для сильных моделей.
К примеру, пару месяцев назад наш менеджмент осознал что дни продукта как он есть сочтены. Пользователь больше не хочет включать мозг изучая виджеты, инструменты, вьюхи, экранные формы, он желает просто писать в окошке и получать все что ему хочется. Это значит "все пишем MCP". И сроки - недели а не месяцы при кодовой базе в несколько миллионов строк.
В итоге на опусе 5.5 примерно с два месяца мы уже не вайбкодим - по ощущениям мы лепим продукт из кода как тесто. Модули на сотню тысяч строк рождаются за две недели в один прогон BMAD. Модули которые писались годами переписываются с нуля за 3 дня. На прошлой неделе оптимизировал с эвалами MCP тулы для поиска метаданных, это был не знакомый мне код, но к моменту достижения успеха понял, что переписал вообще весь код. Чем это закончится - хаосом или совершенством неизвестно. Но вы не будете в этом месте в это время со слабыми моделями.
ToxaBes
30.10.2026 22:45Пока вы будете решать ежедневные задачи на слабых моделях ваши конкуренты найдут новое поле возможностей доступное только для сильных моделей.
Вот это вот заблуждение про "доступное только для сильных моделей" я и писал выше.
он желает просто писать в окошке и получать все что ему хочется.
Я это уже проходил. В итоге один и тот же отчет у двух разных менеджеров имел разные цифры потому что они написали немного разные запросы. И оба отчета были верны. Могу просто удачи вам пожелать с этим подходом.
Это значит "все пишем MCP". И сроки - недели а не месяцы при кодовой базе в несколько миллионов строк.
Аналогично, это и не фронтир может если у пользователя есть опыт.
В итоге на опусе 5.5 примерно с два месяца мы уже не вайбкодим - по ощущениям мы лепим продукт из кода как тесто. Модули на сотню тысяч строк рождаются за две недели в один прогон BMAD. Модули которые писались годами переписываются с нуля за 3 дня.
Вы пока находитесь на стадии очарования ИИ, я десятки раз подобное видел. Пара месяцев это не срок, вернемся к этому вопросу через год-полтора, когда вы осознаете, что мало написать систему, ее еще нужно поддерживать во времени. И вот в этом фронтир общего назначения далеко не самое лучшее решение.
Не пытаюсь вас переубедить, вы сами до этого дойдете, со временем.
amazingname
30.10.2026 22:45Естественно мы пишем с агентами не первый год. Я написал про то как это выглядит последний месяц. Поэтому о каком именно очаровании вы говорите не понятно.
Вы пока находитесь на стадии очарования ИИ, я десятки раз подобное видел.
Опус 5.5 вышел в сентябре. У вас не было возможности десятки раз увидеть что можно делать с текущими моделями.
ToxaBes
30.10.2026 22:45Вы не поняли о чем я написал, ну и ладно.
amazingname
30.10.2026 22:45Вы пока находитесь на стадии очарования ИИ, я десятки раз подобное видел. Пара месяцев это не срок, вернемся к этому вопросу через год-полтора, когда вы осознаете, что мало написать систему, ее еще нужно поддерживать во времени. И вот в этом фронтир общего назначения далеко не самое лучшее решение.
Врядли кто-то что-то осознает, поскольку это не я. Это 150 программистов в средней паршивости американском энрерпрайз продукте идущий по стандартному для подобных компаний пути.
Возможно я не понял о чем вы. Возможно вы просто по роду деятельности не успеваете попробовать все что могут новые модели.
ToxaBes
30.10.2026 22:45Возможно вы просто по роду деятельности не успеваете попробовать все что могут новые модели.
С точностью до наоборот.
ShIV03
30.10.2026 22:45А у меня, статья вызвала другую ассоциацию: "Идеология".
Любопытно, что впервые. Раньше - "Маркетинг (втюхивание)" (когда внедрял не я).Может что-то Автор "рассказал по новому"?.
Скорее "удалось сжать десяток книг/методик/концепций по Менеджменту и Управлению (производственными) процессами, в одну популярную статью". И то хлеб.
Для кого (стейкхолдеров, сотрудников, внедренцев)?
Перечитал статью - А не указано.
(риторически) Ну вот, что это за Идеология?PS: или это и есть специфика идеологий.
ToxaBes
Не с попытки саморекламы на Хабре отредактированным нейрослопом.
Это видно не только по используемым конструкциям, но и по "шагами внедрения", которые нейронка вам накидала "по учебнику". ML внедрение как раз та тема, в которой нейронки не обучались на том как это реально происходит. И именно на этом палятся многие вкатывальщики в ML отрасль без реального опыта внедрений.
Вайбкодинг ТГ-бота я за внедрение не считаю.
Задача звучит так примерно никогда. Во всяком случае у реальных клиентов.
Ваше желание вкатится понятно, но картинку в голове вы нарисовали слишком идеализированную. Требовать описание всего "конвейера зарабатывания денег" в большинстве случаев закончится тем что с вами попрощаются, т.к. этот конвеер зачастую является частью коммерческой тайны.
В ML сфере рулят прототипирование, PoC и MVP, т.е. делают буквально от обратного. В большинстве случаев вам вообще не нужно досконально знать конвейер зарабатывания денег в компании.
В реальности все происходит следующим образом:
Делается EDA за 1-5 дней, предлагается архитектура и точки внедрения, считается примерный CAPEX/OPEX и целевые метрики. Предлагается PoC за пару недель или сразу MVP за 1-2 месяца, по обстоятельствам. Затем уточняем метрики и стоимость владения, дорабатываем и катим в прод. Это если очень коротко.
Если проект большой (B2B), то все это может дополнительно оборачиваться RFI, RFP и RFQ.
В ~85% случае проблема у клиента типовая и сводится к одному из 15-20 кейсов, которые давно (по меркам отрасли) изучены, проработаны и комбинируется исходя из требований. Вне зависимости от отдела и отрасли, в которой работает компания. Со временем меняются только некоторые модели и подходы к их доработке.
Остальные 15% это настоящий R&D с комбинированием ансамблей моделей, прочесыванием мелким гребнем препринтов на ArXiv и собственными экспериментами.
DemNataV Автор
И каков итог?
Кейсики внедрены, деньги попилины... Дальше что?
Работа с изменениями изучена и описана еще в прошлом веке (Голдрад, Деминг и тд) и начинается с понимания процесса и замеров.
Я понимаю что сейчас многие консалтинги переобулись, подружились с небольшим аутсорсерами и погнали зарабатывать на внедрении 15-20 продуктов предоставляемые этими аутсорсерами.
А потом уходят.
Пользуются ли этими продуктами?
Стала ли фирма зарабатывать больше денег или что-то экономить?
Да кому какое дело до этой дурацкой эффективности
AlekseyPraskovin
А дальше ничего и не должно быть. Цель-то достигнута)
ToxaBes
Работающая система, которую могут обслуживать специалисты компании, тот же девопс. Правильно внедренная ML система для девопса ничем не отличает от того же сервера БД.
К попилам относится ваш подход, с первым пунктом в виде выяснения "конвеера зарабатывания денег" компании. Зачем нужно это узнавать, например, у строительной компании при внедрении IDP в бухгалтерии для автоматического распознавания первички или при построении корпоративной RAG-системы вы ответить не сможете, и нейронка вам притянуть за уши не поможет, потому что на самом деле это буквально попытка конкурентной разведки.
Теперь по поводу того что дальше. Дальше начинается внедрение ML в следующем месте/отделе/процессе компании, там, где это оправдано. Обычная комплексная автоматизация давно автоматизировала явные места в бизнес-процессах. ML-автоматизация позволяет автоматизировать не явные (а что так можно было?), не детерминированные места, а также стыки бизнес-процессов.
Вот такие места и автоматизируются с помощью машинного обучения, бесшовно интегрируясь с существующей системой. Тут важно не сломать, внедрение ИИ ради внедрения ИИ это путь в никуда.
Если существующей системы нет или она окончательно деградировала, тогда разные ML системы собираются в общую, обычно не на базе ИИ, а на шине данных и других детерминированных подходах.
Казалось бы все, но нет. Постоянно выходят новые модели, например, вчера Xiaomi выпустила новую OCR, мне нужно ее проверить, сравнить с конкурентами, тем же PaddleOCR, понять какой выигрыш она может дать клиентам у которых стоят предыдущие OCR. Если он значимый, перевести это в язык KPI и прибыли и показать клиентам. Мол можно улучшить, займет 3 дня, даст +10% скорости обработки, на вашем обороте это столько то миллионов прибыли. Т.е. ML-автоматизация не заканчивается на внедрении системы и клиент не бросается с ней один на один.
Самое забавное вы сейчас сейчас пишете о себе. У вас в резюме на Хабр карьере прямо так и написано:
11+ лет в IT: прошла путь от инженера по тестированию до руководителя отделов иконсультанта по бизнес-процессам.Я не отношусь к консалтингу, чтобы в этом убедиться достаточно заглянуть ко мне в резюме.
Я и есть небольшой аутсорсер и специализированных кейсов под отрасли у меня больше сотни (в 18 отраслях). 6 лет реальной практики в ML это не просто пустые слова.
И знаете что поменялось за 6 лет, например, в том же RAG? Из наивного он стал контекстуальным и добавилось несколько новых типов моделей (VL эмбеддинги, Guard и тд). И все, глобально, внутри самой системы, ничего не поменялось. Тоже самое ASR, там вообще только модели меняются. В CV в прошлом году RF-DETR появился как конкурент YOLO и все. Снаружи системы все меняется каждый месяц, внутри системы эти изменения зачастую не видны, эндпоинты те же, протокол данных тоже.
Я 6 лет уже занимаюсь ML внедрениями в качестве ИП, в том числе в международных проектах и никуда уходить не собираюсь. Судя по всему, в ML вы начали пытаться заходить в этом году. Тут как бы большой вопрос кто еще уйдет.
Конечно, и добавки просят.
А иначе какой смысл был в автоматизации? Я понимаю, что сейчас на рынке очень много различных проходимцев, инфоцыган от консалтинга и тех кто без опыта старается заскочить в этот поезд, тк в их сфере их прижало или уволили. И тут ситуация следующая: вы пытаетесь меня отнести меня к этой когорте будучи сами из нее. Это так не работает.
DemNataV Автор
Ладно, я резко реагирую)
Ты в основном прав.
Но менять процесс не понимая как он устроен, я думаю, очень неправильно.
Фирмы до 100 человек быстро пересели на ботов и ту же работу теперь делают 10ром. Потому что процесс был понятным и обозримым, практически линейным без зависимостей.
А вот фирмы побольше внедряют ИИ где попроще и руководство видит горстку пепла бабла, недовольных сотрудников и сломаный процесс. По крайней мере, я не могу вспомнить большой фирмы которая бы стала зарабатывать больше пересев на ии.
ToxaBes
Нормально вы реагируете. Постарались сделать грамотный заход на аудиторию Хабра, но не учли, что тут могут тоже сидеть специалисты. И коса немного нашла на камень. Ничего страшного, сделаете выводы и адаптируетесь. Ну или нет.
В этом я с вами полностью согласен. Вот только выяснение конвеера зарабатывания денег компании к нему не относится. В подавляющем случае ML-автоматизация направлена не непосредственно на конвеер денег, а на конвеер времени.
Понимать бизнес-процессы предприятия нужно, но вам их никто не расскажет, готовьтесь к тому что вы получите ответы на 20 вопросов из них 8 будут неверны (не по злому умыслу, а по недостаточной или неправильной информированности отвечающего), а предоставленные образцы документов не будут отражать весь спектр проблем.
Тут помогут только прокаченные навыки EDA. Без них никуда.
Попробуйте посмотреть не на внедрение ботов. Я в последнее время вообще ими не занимаюсь, это не та точка приложения усилий в компании, которая даст больший выхлоп. Конечно, банки/провайдеры и тд получили прибыль от внедрения ИИ-помощников первой линии, глупо это отрицать, но в массе своей компаниям внедряют не это.
SER_26
Спасибо за комментарий. Гораздо интереснее самой статьи.
Вопрос, вероятно, чего хотеть и какие права иметь. Находясь внутри компании и внедряя AI, я бы через процессы компании пошёл (что автор тут к продаваемой фразе "конвейер зарабатывания денег" привязывает). Но да, всё равно через "прототипирование, PoC и MVP", так как строить сразу огромную систему очень сложно выйдет (внедрял как-то ERP так, поддерживая внешних "внедренцев" - очень тяжелый и дорогой был процесс).
Или Вы имеете в виду, что через процессы Вы всё равно идёте, просто быстро, и переделывается при этом не вся система целиком, а точечно, и что Вы не только указанные Заказчиком кейсы конкретные закрываете?
ToxaBes
Это. Опыт комплексной автоматизации предприятий в доmlную эпоху у меня есть поэтому понять что-куда проблем не вызывает.
Другое дело, что довольно часто предприятиям ML вообще не нужен или не нужен там где они думали что нужен.
У меня регулярно бывают ситуации когда я трачу время на составление аналитической записки почему ML им тут не нужен и проще своими силами поправить пару моментов. И делаю это бесплатно, такой вот я загадочный зверь, могу себе позволить.
На самом деле, расчет тут простой, внедрение ИИ ради ИИ это тупик, а честность в отношениях с клиентам всегда окупается в долгосрок. Всегда. У меня был случай кода через 5 лет ко мне возвращались и внедряли ML там где это уже стало необходимым.
SER_26
Спасибо. Тогда всё логично в Вашем подходе. Самое смешное, что для меня это и есть самое близкое к пониманию "конвейера зарабатывания денег". Просто "конвейер" не в виде неких детально по расписанных процессов (в зачастую бесполезных, зато дорогих, описаниях), а в виде системного понимания, где прибыль увеличится от ML, а где нет.
У меня вообще ощущение из статьи конденсируется после Вашего анализа, что автор просто взял свои знания чего-то вроде бизнес-реинжиниринга и "приклеил" к ним ИИ, как маркировку "новый и улучшенный" на стиральный порошок, так как пишут же, что внедряя ИИ надо все процессы пересмотреть. Вот только это "все процессы" к разработке относится, как понимаю, а не ко всему, что под руку подвернётся.