Дисклеймер
Я понимаю, что аудитория Хабра по большей части технически подкованная, и если вам было бы интересно почитать о реальных провалах вайбкодинга с техническими деталями, то статья не про это. Однако, если у вашего руководителя подгорает от желания сделать дизрапт с помощью автоматизации с ИИ-ботом “вчера и дёшево” — киньте ему эту ссылку. В ней достаточно мало “как сделать технически”, но вполне себе достаточно “зачем вообще делать?”.
Ну и причем здесь IKEA?
Я не люблю сложных аналогий, поэтому когда вопрос коснулся того, как бы объяснить весь этот рынок быстрых AI-внедрений и продакт менеджеров, некоторые из которых продают себя как современных инженеров по AI-интеграциям, пока остальные тянутся в хвосте технологического прогресса, мне ничего не пришло в голову лучше, чем IKEA.
Кто такой инженер по AI-интеграциям в массовом понимании? Чаще всего так зовут себя люди, которые:
Сделали MVP для стартапа, SaaS или игрового сервиса.
Использовали ботов, агентов, вайбкодинг и Claude.
Искренне считают, что хакнули систему, потому что раньше для этого требовалась целая команда — разработчики, дизайнеры, проджект-менеджеры. А тут он один, за вечер, и всё работает.
И если посмотреть на это как обыватель, то да, это действительно очень круто.
Давайте теперь с аналогией от IKEA
Представьте, что человек заказал себе шкаф из IKEA. Он берёт коробку, в которой индустриальные дизайнеры уже всё продумали: плотность опилок, шаг отверстий, тип фурнитуры, даже порядок действий.
А в комплекте — пошаговая инструкция в картинках и универсальный шестигранный ключ. Человек крутит ключ, соединяет А с Б, ставит шкаф у стены.
Он настолько доволен своим результатом, что в резюме пишет: «Проектирую эргономичные пространственные системы хранения без затрат на сборщиков». Странно, правда? Но оставим пока этот момент.
Пойдем дальше. Что происходит, когда у этого шкафа отваливается дверца? Или стена в квартире оказывается кривой? Или, хуже того, инженеры IKEA ошиблись в расчёте нагрузки и через месяц полка провисает?
Тот самый сборщик-проектировщик встаёт в тупик. Он не знает физику материалов, не понимает распределение нагрузки, не умеет подбирать крепёж под конкретную стену. Он умеет только крутить шестигранник по инструкции. Так вот, то, что считалось самым сложным — «крутить шестигранник по инструкции» — теперь делает нейросеть.
И делает это за две минуты вместо часа. Это действительно ускорение по запросу. Но запрашивающий в этой схеме — просто биологическое приложение к шестигранному ключу. Понимаю, звучит обидно. Но такова суровая реальность.
И пока вы еще не оправились от такого, давайте сразу перейдем к главному вопросу, который поможет определиться с терминологией: Назвали бы вы человека, который собрал шкаф BILLY из IKEA по инструкции, индустриальным дизайнером?
И второй вопрос, который снимает все иллюзии: Доверили бы вы этому человеку проектирование вашего сложного, хаотичного, не-IKEA бизнес-процесса?
Откуда вообще растут ноги?
Раньше самая “недоступная” часть разработки заключалась в этапе «как сделать?». С этой проблемой бились несколько лет — начиная от революционных low-code/no-code решений в 2019 году и заканчивая современным вайбкодингом.
Раньше нужно было идти к (весьма дорогому) разработчику, который долго смотрел на вашу идею, требовал «четкое ТЗ», а потом две недели кодил. Теперь достаточно открыть Lovable, Replit или Cursor, попросить то, что вы хотите, и через 10 минут у вас есть «рабочий прототип». Без мам, пап и кредитов.
В чем здесь основной подвох? Поскольку именно эта часть — «перевод идеи в код» — раньше занимала 80% времени и была покрыта ореолом элитарности, кажется, что система хакнута. Но что же именно хакнуто? Та самая процедура “как”.
Если раньше нужно было изучить язык программирования (до начального уровня, где-то до года), разобраться, как работают серверы, инфраструктура, безопасность, архитектура (еще пару лет, плюс-минус), то сейчас вот интерфейс, вот ответ бота, вот работающий прототип (от 5 до 15 минут в зависимости от запроса). Этот хак создает ту самую иллюзию, что знать все то, что нужно было получать как базу раньше в течении минимум 3-ех лет — не обязательно.
Но вот в чем основная — и самая опасная ловушка. Вернемся обратно к примеру с IKEA, он достаточно прост и нагляден для понимания.
Человек, который собирает мебель IKEA видит перед собой полный, законченный шкаф, как только его собрал. Он может покачать его, проверить, не шатается ли, поправить ножку. В конце концов, просто сверить с визуальной картинкой на сайте или в инструкции. У него есть тактильная обратная связь.
У вайбкодера-с-шестигранником единственная обратная связь — это успешный ответ бота в чате.
Есть ряд критических моментов, которые он просто не видит:
Утечки памяти.
Троттлинг API (ограничения по частоте запросов, которые сломают систему при первых 10 пользователях).
SQL-инъекции, которые нейросеть «забыла» экранировать.
Галлюцинации, которые через месяц начнут выдавать клиентам юридически опасные советы.
Значит ли это, что есть плохие сборщики и хорошие инженеры?
Если бы мир был таким простым, то и вопроса бы не стояло. Здесь важно отметить следующее.
Самая большая проблема рождается тогда, когда человек без релевантных знаний, для получения которых потребовались бы несколько лет проб и ошибок, получив доступ к продвинутой технологии считает, что он теперь — гений, миллиардер, филантроп и плейбой.
Можно ли делать MVP на коленке быстро и дешево? Конечно.
Можно ли называть это “системной архитектурой от бога”? Нет.
Именно это создает иллюзию простоты и желание бизнеса сэкономить не только во времени (мы быстрее!), но и в деньгах (зачем мне это за 300 тысяч, когда можно за 30 тысяч?).
Использование искусственного интеллекта в своей работе не наделяет моментальной экспертизой и уж тем более не делает подготовленным для работы с комплексными проектами. Все, кто называют себя экспертом после видео на ютубе и написанного промпта рождают ту самую профанацию экспертизы.
Потому что экспертиза она во многом не в том, как много штампованных успешных проектов вы сделали. А в том, что вы вынесли из неуспешных и почему никогда больше так не сделаете.
Таким образом, профанация в эпоху ИИ — это когда человек начинает путать умение задавать вопросы нейросети с пониманием ответов, которые она даёт. Настоящий инженер всегда знает, почему нейросеть выдала именно такой ответ, и может объяснить это на пальцах. Да более того, он может сам сделать то, что выдает нейросеть, просто для этого ему бы понадобилось больше времени. Человек, который не знает, почему код пишется именно так, как пишется, просто рад, что ответ вообще пришёл.
Должен ли инженер уметь делать быстрые MVP на коленке для теста гипотезы? Обязательно.
Должен ли сборщик честно сказать, что его навыки здесь ограничены и когда дело касается более сложных вещей или выкатывания в прод, нужно позвать инженера? Обязательно.
Пытаться соединить два сразу — дешево и быстро, как у сборщика, но качественно и добротно, как у инженера — очень плохая идея.
И здесь кроется парадокс. Сборщик может быть крайне полезен, но только в том случае, если он осознаёт свои границы и готов вовремя передать эстафету. Самая страшная история — не когда сборщик делает плохо, а когда он не знает, что делает плохо, и считает это нормой. Именно в этот момент возникает та самая иллюзия контроля, которая убивает проекты.
Есть большая разница между разработкой в песочнице и продакшеном. Так вот, если вы хотите поиграться в песочнице с MVP до того, как выкатывать это на всех — вам вполне себе подойдёт и сборщик. Быстрый тест, который живёт 2 недели и затрагивает 5 пользователей — это дёшево и логично. Более того, это может стать хорошим подспорьем для будущего инженера — вы сможете ему показать результаты на коленке.
Основная проблема сборщика в том, что он не знает, когда тестовый вариант надо снести и начать строить полноценную конструкцию с учётом всех условий. Если вы хотите проверить гипотезу — сборщик вам в помощь. Быстро, дешево и можно думать, что делать (или не делать) дальше.
Что же делать? Как отличить того самого продавца скорости (если она вам категорически не нужна) от человека, который реально будет разбираться с проблемой?
Сейчас буквально из каждого угла на бизнес валятся предложения от «сборщиков мебели IKEA» от мира ИИ.
Схема работы простая и отточена до автоматизма:
Пишется пост в любую соцсеть, желательно профессиональную: «Вчера внедрил AI-агента одной команде! Раньше нужно было 5 человек, а теперь я один. Всё работает, и это настоящий успех. Если вы относитесь скептически — вы позади планеты всей». Чаще всего также проскочат “автономность” и “мне понадобилось 2 дня”.
Приходит уставший собственник или руководитель, который уже давно хотел “ускорить рутину”, клюнувший на позиционирование.
Внедренец за полчаса собирает бота по инструкции с YouTube, показывает демонстрацию и получает деньги.
Через пару недель бот начинает вести себя странно: путает клиентов, спамит, теряет данные или просто падает, потому что обновился API.
Внедренец разводит руками: «Ну, в инструкции так было написано, я не знаю, почему сломалось. Вы просто не умеете работать с ИИ».
И хорошо, если в этот момент собственник или управленец понимает: ему нужен не человек с шестигранным ключом, а инженер. Тот, кто точно знает, как распределяется нагрузка в системе, и который может сказать: «Этот отчёт вообще не нужен, давайте его совсем уберём». В этом случае вы получаете не просто продвинутую и современную функциональность, а масштабируемую отказоустойчивость. Скорость исполнения потихоньку отходит на второй план, потому что главным становится глубина экспертизы.
Цена вопроса: от MVP до катастрофы
Чтобы не закапываться сильно в детали, но проиллюстрировать (прямо как с IKEA), давайте посмотрим, как может теоретически развиваться ситуация на гипотетическом примере. Здесь не будет технической детализации, скорее дорожная карта последствий, которую должен видеть каждый принимающий решение об оптимизации старого процесса новым.
Этап 1 (MVP). Наконец-то перестали тащиться в конце и внедряем ИИ, чтобы “оптимизировать рутину”. Собрали бота, который общается с клиентами за место поддержки по рутинным вопросам вроде продления, оплаты и триала, ставит алерты на недовольные комментарии и генерит отчеты, которые раньше и так никто не читал, за 30 тысяч. Все счастливы, скорость внедрения — 1 день. Протестировали на 3 диалогах - летает быстрее всех.
Этап 2 (Масштабирование). А теперь этого бота сразу подключили к CRM, чтобы он мог не только задавать глупые вопросы, но еще парсить и тянуть данные о стоимости клиента, как долго он в системе, сколько тикетов было раньше и так далее. И тут вдруг он начал путаться. Сначала повесил алерт на клиента, с которым не происходило ничего страшного. Потом заспамил нерелевантными ответами тех, кто спросил про продление (там инструкция поменялась, но бота никто не обновил). Затем сгенерировал и разослал отчет с некорректной информацией, потому что в CRM было два одинаковых заполненных поля со страной, но один по факту использовался в системе, а второй просто дублировался и тянулся с формы регистрации. Благо никто не смотрит эти отчеты, но получилось, что количество людей из Казахстана резко превысило всех остальных. Здесь подсчитывать расходы пока рано, но они потихоньку начинают формироваться - из рабочего времени вовлеченных людей, которые находят эти курьезы и потенциальных репутационных рисков в будущем.
Почему это произошло? Потому что никому не пришло в голову, что у CRM есть своя логика настройки и своя внутренняя кухня, которую кто-то когда-то интегрировал и больше не трогали. Сборщик просто пропустил второе поле, потому что эта форма даже не пришла никому в голову (то самое legacy-наследние от того самого первого разработчика, ну вот это вот все). Инженер хотя бы спросил: “А откуда берутся эти данные? А давайте попробуем посмотреть, не разойдутся ли они и что мы можем с этим сделать.”
Этап 3 (Катастрофа). А потом, из-за того, что бот начал путаться в данных, он решил сделать выборку из 150 недавно запросивших триал клиентов и потребовать с них оплату. Здесь сложно подсчитать какие-то конкретные цифры, но только на одних планерках, где собирались по 3-5 человек со словами “Так, а делать-то что?” почти каждый день ушло до 300 тысяч рублей. Не говоря уже о потерянных клиентах, которые после такого агрессивного триала ничего не продлили. Дальше потеря репутации, недовольство ключевых клиентов, которым бот вдруг тоже решил прислать угрозы о неоплате и, не дай бог еще судебные разбирательства — там вообще все исчисляется миллионами. Плюс время топ-менеджмента на разбор полётов.
Вот она, реальная цена экономии на этапе «собрать подешевле». Сборщик сэкономил 270 000 рублей на разработке. Инженер бы сэкономил на отсутствии судебных исков и еще миллионы от ушедших от злости клиентов.
Как определить инженера по AI-интеграциям?
В следующий раз, когда вы услышите очередную историю успешного успеха про ускорение и оптимизацию, задайте кандидату три вопроса. Я не смогу дать вам «правильные ответы», потому что они будут зависеть от контекста. Но вот на что обязательно нужно обратить внимание.
Если кандидат:
с ходу даёт вам готовое решение, не спросив, что у вас и как;
не предлагает альтернатив и не задаёт вопросы;
не предлагает отказаться от каких-то процессов;
не сомневается в том, что у вас точно всё сработает;
не просит доступа к данным и не говорит о безопасности —
и собирает как минимум три пункта из этого бинго, то с большой вероятностью можно сказать, что перед вами не настоящий инженер, а тот самый продавец скорости на волне хайпа.
А теперь — те самые 3 вопроса, которые стоит задать потенциальному внедренцу.
Вопрос 1. «Расскажи, как ты подходишь к нестандартным ситуациям? Было такое, что ты посмотрел на задачу и сказал: “Давайте уберём этот отчёт, он никому не нужен”? Настаивал ли собственник всё равно на сохранении процесса? Как вы вышли из этой ситуации?»
Правильного ответа нет, но вот ключевые маркеры:
Человек, который знает реальность, не боится сказать «нет, это не будет так работать» и объяснит почему. Вы можете настаивать, что вы уже тысячу раз так делали, и инженер может с вами согласиться в итоге, но риск должен зафиксировать и проговорить.
Эксперт с опытом сначала подумает, стоит ли это делать.
Вопрос 2. «Какие риски мне стоит просчитать перед внедрением? И как их нивелировать? Как ты будешь измерять успех внедрения через месяц?»
Ключевые маркеры:
Инженер почти сразу будет говорить с вами о безопасности, нагрузках и галлюцинациях, потому что в это упираются основные проблемы для большинства. Чем больше деталей он узнает, тем более адекватное решение он сможет вам предложить (и оно не всегда будет дешёвым).
Он скорее всего предложит для критериев успеха конкретные показатели, которые важны для вашего бизнеса. И здесь самое главное — вы должны хорошо знать эти показатели сами.
Вопрос 3. «Есть ли план Б на случай, если процесс окажется убыточным или бесполезным?»
Ключевые маркеры:
У инженера скорее всего будет предложение и по плану Б, и по плану В. Проблематика и стоимость отката будет упираться в нюансы вашего текущего сетапа, но если вы дадите все детали, он сможет вам просчитать потенциальные убытки для оценки.
Инженер всегда проектирует откат.
Не спеши, а то успеешь
Технологии и годы разработки довели инструменты до такого состояния, что они сами уже могут выполнять рутинные операции, что создало целую армию людей, которые путают скорость исполнения с глубиной понимания проблемы.
Ответственного инженера по AI-интеграциям от продавца скорости отличает, помимо профессиональной этики, ещё ряд моментов, которые часто воспринимаются как «усложнения» или «торможение», но именно они помогут вам действительно сэкономить.
И не столько во времени, сколько в отсутствии головной боли и последующей жизни в иллюзии, что всё просто.
Потому что инженер по AI-внедрениям — это тот, кто:
Умеет говорить «нет», если идея нежизнеспособна.
Проектирует отказоустойчивость, потому что знает: нейросети могут ошибаться и без контекста выдавать ответ, который кажется наиболее релевантным.
Считает деньги, а не токены. Он понимает, что дешевле написать 20 строк кода вручную, чем дёргать LLM ради парсинга даты.
Сборщик AI-агентов будет продавать вам иллюзию экономии времени. Инженер же предлагает спокойствие в понимании того, что система работает по вашим правилам и на ваших условиях.
И пока бизнес не перестанет путать одно с другим, мы будем видеть бесконечные истории успеха, которые заканчиваются одним и тем же: «Помогите, наш ИИ-агент разослал всем клиентам письма с угрозами вместо счетов. Это было в 3 часа ночи. Многие пишут в недоумении, кто-то собирается уходить… Что делать?»
Так что сегодня вы можете выбрать, какую экономию вам нужно.
Сборщик сэкономит вам тысячи рублей на разработке и даст быстрый дофамин от того, что вы первый, а остальные отсталые. Инженер не даст потерять миллионы от ушедших от злости клиентов, когда не допустит угрозы вместо счетов.
Выбор, разумеется, за вами. Только помните: дешёвый сборщик выкативший все на прод сегодня — это потенциально дорогой инженер завтра, когда придётся всё переделывать.
А теперь максимально честно
А что делать, если тот самый крутой инженер, который нужен, стоит 300 тысяч в месяц? И вообще, может, не нужно это всё?
А вот это — настоящий управленческий риск, от которого можно было за годы хорошей ситуации на рынке отвыкнуть. Который нельзя переложить на кого-то, кто ткнёт пальцем в кого вам выбрать, чтобы было 100% правильно. А заодно можно было ответить: “А вот в инструкции мне сказали…”
Правильного ответа здесь нет. Но есть три сценария, которые первыми приходят в голову, и каждый из них — это выбор с соответствующей ценой.
Вариантов решения этой дилеммы несколько. Например, вы соглашаетесь проверить свою идею о том, что внедрение нужно, и нанимаете быстрого сборщика MVP. Но не даёте ему зелёный свет для того, чтобы масштабировать это дальше, а оцениваете вообще реализацию и потенциальные риски.
Или вы решаете, что вам нужен дорогой инженер, потому что процесс и правда сложный. И вы готовы отдать эти 300 тысяч за полноценно работающую систему, даже если сейчас это выглядит как “не по карману”, потому что вы знаете, что в эти деньги входит непотеря миллионов в следующий год.
Или вы решаете, что вам вообще ничего не нужно, потому что дорогой инженер сейчас ну совсем не по карману, но и растрачиваться на быстрые тесты, которые из-за сложных бизнес-процессов внутри не будут работать как надо, вы тоже не хотите.
Или… еще какой-то вариант, о котором знаете только вы и который только что пришел вам в голову?
Я не знаю, что вам нужно и как правильно. И не потому, что мне всё равно. А потому, что уникальность вашего кейса делает его особенным, а разбираться в нюансах каждого бизнеса в рамках одной статьи было бы странно. Поэтому я предлагаю вам следующее:
инструмент для мышления — как выбрать того, кто действительно принесёт результат для вашего бизнеса и какова цена этого выбора;
вопросы для понимания — как по максимуму увидеть и нивелировать возможные риски от принятого решения, сколько всё это может стоить и каковы последствия;
примеры для иллюстрации — чтобы увидеть ситуацию такой, какая она есть, без иллюзий.
А дальше — ваш выход.
P.S. Напоследок
Если по какой-то причине вы продакт, дочитали до конца, сами себя позиционируете как инженера по AI внедрениям, и этот текст вызывает у вас бурю негодования — я понимаю.
Я не призываю к отказу от быстрых внедрений и крутых инициатив, где вы один семерых укладываете. Я призываю к честности в том, что этот подход, хоть и выглядит как классный инфоповод для собственного позиционирования, имеет достаточно ограниченные возможности применения. Идеален для MVP и песочницы, но требует серьёзной доработки для масштабирования на (не всегда идеальные) бизнес-процессы компании. У меня только один вопрос… если бы вы не могли продать это быстрое внедрение потом как “успешный успех”, вы бы стали это всё равно делать? Если да, то хвала вашему энтузиазму. Просто, пожалуйста, всегда говорите о том, где конкретно заканчивается ваша зона ответственности.
А если вы руководитель — запомните главное: ИИ не лечит магическим образом сломанные процессы и не принимает решений. Он их ускоряет. Как хорошие, так и плохие, потому что вот ему действительно все равно. Если процесс сломан — ИИ покажет вам это очень быстро. Но решение всегда за вами. И ответственность за этот выбор — тоже только ваша.
