В эпоху повального увлечения AI кажется, что достаточно взять OpenAI API, найти проблему, написать сложненький промпт и готово — ваш следующий единорог уже на подходе. Однако реальность, как всегда, оказывается намного сложнее и это мираж технологической простоты. В этой статье — рассуждения о том, почему базовая технология или стек целиком — это лишь верхушка айсберга в создании успешного продукта, и почему даже имея доступ к самым передовым технологиям, создать по-настоящему ценный продукт остается сложной задачей.

Мираж технологической простоты

Современные LLM-модели и агенты действительно впечатляют своими возможностями. Они могут писать код, генерить осмысленные голосовые ответы в реальном времени, накидывать прототипы приложений и многое другое. И кажется, что технологический барьер входа в AI-стартапы становится все ниже: вот вам мощнейшие открытые LLM-модели, такие как Qwen, Mistral и Llama (топовые версии которые попробуй еще разверниツ). Нет железа или неохота их разворачивать под продакшн — берем OpenAI API для готовых решений, агенты — LangChain, боты — Rasa или Dialogflow, и так далее и далее. Почти все core-технологии уже открыты и ждут своего применения.

Однако эта доступность создает опасную иллюзию простоты. Да, собрать прототип на связке Python + OpenAI API можно за пару дней. Но превратить его в продукт, который будут реально использовать по любви и за который даже будут платить — совсем другая история.

Классические проблемы технического стека

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

Недоинжиниринг проявляется в подходе «вроде все работает». На первый взгляд всё выглядит прекрасно, но при ближайшем рассмотрении оказывается, что система полна скрытых и плавающих проблем. Отсутствие обработки ошибок при вызовах LLM API приводит к молчаливым падениям у самых первых пользователей, а захардкоженные прямо в код промпты и прямой вывод ответа модели могут привести к неожиданным результатам. Логов нет, метрик нет, качество ответов модели никто не отслеживает, а отсутствие бизнес-ограничений на токены (rate limiting) приводит к неожиданному их исчерпанию в самый неподходящий момент или к непрогнозируемым тратам.

Сюда же — «недопромптинг». Это когда ответ уже похож на нужный (или отвечает правильно, но иногда галлюцинирует, а люди очень чутко понимают, когда что-то не так и это не прощают), значит надо запускаться, а доработаем потом. Но «доработаем потом» может привести к тому, что нужный ответ танцами с промптом уже не получить, а гарантия качества вообще недостижима без больших изменений.

На противоположном полюсе находится переинжиниринг — стремление к «идеальной» архитектуре или непреодолимое желание переписать всё заново и теперь уж точно правильно. В реальности это часто начинается с категоричных технологических стереотипов типа: «Мы знаем PHP/Python, но это несерьезно, нам нужен Go», «монолит уже не модно, надо на микросервисы», «Rust быстрее, значит лучше».

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

При этом реальность такова, что большинство стартапов вообще не доживает до стадии, когда они действительно упираются в технологические ограничения какого-то ими выбранного стека. Из того же PHP при грамотном проектировании можно выжать впечатляющую производительность — Facebook начинался как PHP-проект и смог масштабироваться до миллиардов пользователей, создав при этом свой собственный движок для оптимизации производительности.

Когда речь идет о существующем проекте, первым шагом должна быть попытка выжать максимум из текущих реалий. Вместо слепой веры в чужой успех, важно понимать реальные потребности проекта и возможности команды. Условный монолит с правильно выстроенной архитектурой, грамотным кеш-слоем и хорошо продуманной БД может работать намного эффективнее и надежнее, чем модная распределенная система на микросервисах, где каждый компонент становится потенциальной точкой отказа, усложняет разработку и требует дополнительного мониторинга. Повторюсь, микросервисы — это хорошо, если они уместны, а не как мессия, которая всех спасет.

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

Ну а новый проект — если нет требований свыше, то надо брать то, с чем умеешь работать и то, что подходит под конкретную задачу. Она у каждого своя, и я искренне не понимаю технологических холиваров. «Мне нравится X, а мне Y, давай спорить что круче» — так у вас условия и проекты разные, об чем спор? У каждого проекта есть собственные требования и вагон собственной специфики (начиная от бизнесовой и заканчивая доступным железом и навыками людей), и потому выбор и опыт у всех может быть очень разный. «Сделать все плохо» — от стека вообще не зависит, со «сделать хорошо» посложнее, но у всех всегда все равно упирается в собственную специфику.

Успешные проекты обычно находят золотую середину, и такой инженерный баланс — важная веха в развитии проекта.

Анатомия успешного продукта

В реальной жизни базовая AI-технология составляет лишь 5-15% успеха продукта. Это всего лишь фундамент, на котором строится всё остальное.

Настоящая продуктовая магия, составляющая ~40-60% успеха, заключается в глубоком понимании проблем пользователя, тщательно проработанном UX и правильной подаче им результатов работы AI. Именно качественная обвязка вокруг хорошей базовой технологии делает продукт по-настоящему ценным.

Мы как пользователи любим когда «все красиво» и это касается как UI, так и решения. «Красиво решить» задачу это важно, но это требует труда, внимания к деталям и итеративных улучшений. Можно прицепить самую мощщщную LLMку, наделать самых мощщщных агентов, можно выучить лучшие практики проектирования, заморочиться над UI/UX, но без «стиля» продукт рискует остаться просто хорошим и функциональным, но не вызывающим того самого вау-эффекта, который отличает великие продукты от просто хороших.

Но успешные продукты не только просто работают и не останавливаются в развитии («сделал чат-бота и в закат» не прокатывает) — они обвешаны десятками различных метрик, которые постоянно отслеживаются и анализируются. Например, в случае AI-чатбота это не просто логи запросов и ответов. Это анализ всей цепочки диалогов, длины фраз и точек прерывания, скорости ответа, правильности ответа, удовлетворенностью ответа и многое другое.

На основе этих данных регулярно выдвигаются гипотезы: например, что после определенных ответов пользователи прерывают диалог, а что-то регулярно требует уточнений. Без A/B-тестов не обойтись: изменяются промпты, настраиваются параметры модели, даются оценки, корректируются сценарии. Этот процесс итеративен и порой кажется бесконечным, но именно так оно и работает.

Не менее важна операционная инфраструктура, на которую приходится 30-40% успеха. Если продукт уже работает, даже есть пользователи, но «юнитка не сходится», то долго такой продукт не протянет. Операционка — самая неприятная инженерам часть в проекте, но без нее, увы, никак.

А почему бы не просто склонировать?

Часто можно услышать: «А давайте сделаем как X, только для Y». Например: «Свой ChatGPT, но для юристов» или «Notion AI, но для маркетологов». Однако такой подход редко приводит к успеху, и на то есть веские причины.

Многие продуктовые решения в успешных продуктах возникли не просто так, а как ответ на специфические проблемы именно их пользователей. Эти решения нельзя просто «пересадить» в другой контекст — они работают именно в той среде, для которой были созданы. За кажущейся простотой успешного продукта часто стоят месяцы или годы итераций и доработок, сложные технические решения, скрытые под простым интерфейсом, и глубокое понимание предметной области. Можно слепо копировать успешных, но залезть им в голову и объяснить почему что-то сделано именно так — невозможно, это магия на кончиках пальцев.

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

В качестве выводов

Создание успешного AI-продукта — это намного больше, чем просто интеграция чего-либо с LLM или другой core-технологией. Это сложный процесс, требующий глубокого понимания проблем пользователей, талантливой и разносторонней команды, существенных ресурсов на разработку и поддержку, а также постоянных итераций и улучшений.

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

Спасибо!

Мои другие статьи:

Как LLM меняют архитектуру систем: от простых дата-пайплайнов к интеллектуальным автономным агентам

Как оценивать ваш RAG-пайплайн и валидировать качество ответов LLM

Нам нужен RAG, вам нужен RAG: как встроить LLM туда, где она не нужна