Vladimir Tsymbal Dev

Попросил аналитиков собрать список наиболее частых запросов от пользователей, которые требовали ручного вмешательства разработчиков. Затем примерно оценил, сколько времени команда тратит на их обработку, и с этими цифрами пошёл к руководству. Основной аргумент был довольно простой: мы регулярно тратим время разработчиков на однотипные операции, которые можно автоматизировать. Один раз инвестируем время в инструмент, а дальше освобождаем ресурсы под те же продуктовые задачи. Плюс снижаем риск человеческой ошибки при работе с продом. Как я сказал, улучшение админки постоянный процесс. Если им принебрегать, люди будут выгорать и будет тратиться тонна времени впустую. P.S. Не работаю в данной компании уже несколько лет, не знаю, как дела дальше с админкой.

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

1. Почему предполагаете, что покупатель, воспользовавшись конструктором, совершит покупку именно на вашем сайте? Можно подобрать необходимые материалы на сайте производителя, а затем заказать товары на ozon или wb похожие, где привычнее оплачивать и отлажена быстрая логистика(и не надо думать кто все это поднимет на этаж). В таком случае можно инвестировать в разработку и поддержку сервиса, а продажа происходит на популярном маркетплейсе. Также, нередко, стоимость на маркетплейсе ниже чем у производителя, к примеру, много примеров с тем же амазоном.

2. Беспристрастны ли будут рекомендаций? Производитель заинтересован продавать собственную продукцию, а что произойдёт, если для конкретной задачи лучше подойдёт материал другого производителя или вообще не потребуется ничего покупать? Конструктор вряд ли будет рекомендовать такое решение.

3. Насколько можно доверять автоматическому расчёту? К примеру, площадь повреждения автомобиля сама по себе ещё не определяет технологию ремонта, также имеют значение характер повреждения и другие нюансы. Если пользователь введёт недостаточно информации, есть риск, что конструктор предложит неподходящие материалы. Можно получить тонну негативных отзывов.

В своё время покупал cmf watch pro. От Pro было только название, и непонятно где была версия не pro. Красивый дизайн, неплохой маркетинг, но само устройство оказалось довольно посредственным, а спустя примерно три месяца часы вообще сломались. Благо продавец вернул часть денег, а сами часы я в итоге продал на авито на запчасти.

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

Главная проблема подобных проектов является их распространение. Люди годами привыкают к определённому софту, его интерфейсу и возможностям, поэтому даже более интересное решение не так просто заставить их использовать. А если говорить о внедрении в организациях, особенно в бюджетных учреждениях, то всё становится ещё сложнее. Нужно не только переучивать сотрудников, но и учитывать существующие процессы и требования к ПО.
Сделать альтернативу Word — это одна задача, а убедить людей массово на неё перейти совсем другая. Идея с управлением через MCP мне нравится, кажется, за этим будущее.

Соцсети постепенно возвращаются к тому, с чего начинали: небольшие группы друзей, обычные моменты из жизни, никакой гонки за подписчиками, просмотрами и лайками. Все таки у меня есть один вопрос, не превратится ли необходимость снимать что-то каждый час в очередную обязанность? Раньше люди переживали, что давно ничего не публиковали в TikTok, теперь будут переживать, что забыли записать свои две секунды жизни. Да и кажется, будут снимать идеальные 2-секунды, вместо нефильтрованных секунд, кто захочет снимать себя сидя на унитазе(не сомневаюсь, что есть и такие, но их не так много кмк).

Также вижу следующие негативные эффекты:
Cтрах что-то пропустить. Если друзья регулярно делятся моментами своей жизни, может возникнуть ощущение, что нужно постоянно проверять приложение. Вроде что-то похожее было в south park.
ОКР. Привычка снимать видео каждый час может превратиться из развлечения в ритуалы.
Также может быть тревожность. Если все друзья активно публикуют видео, можно почувствовать давление из-за того что нужно тоже что-нибудь снять, даже когда не хочется.
И классическое СДВГ. Постоянное переключение внимания между повседневными делами, камерой и просмотром чужих видео.

Интересное исследование, спасибо. Но здесь стоит учитывать не только стоимость токенов, но и стоимость поддержки самого решения. Если ради экономии 15% мы добавляем отдельную модель для перевода, то получаем дополнительные запросы, а соответственно задержки, новые точки отказа и, судя по вышей статье, получаем ошибки перевода.
Может быть при больших объёмах такая оптимизация, оправданна. Интересно было бы увидеть расчёт, начиная с какого количества запросов экономия перекрывает дополнительные затраты на поддержку и обработку ошибок.
Постепенно приходим к тому, что оптимизация стоимости LLM становится отдельной задачей и эту задачу будут монетизировать.

Яндекс Пэй показывает, что сервис недоступен, но при этом оплата картой в магазине у меня проходила, а вот к вечеру перестало работать пополнение через СБП.
Настолько привыкли к тому, что всё просто работает, что даже не задумываемся, какая огромная инфраструктура за этим стоит. Инженерам, которые сейчас всё восстанавливают и пытаются быстро поменять конфигурацию серверов, желаю сил и громадной стрессоустойчивости, сам работаю в айтишке.

рукописи, если быть точным)

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

После таких событий на собеседованиях по system design могут появиться новые вопросы, к примеру, как спроектировать систему, которая продолжит выполнять критически важные функции при полной потере нескольких дата-центров.

Спасибо за ответ.

Есть мысли с которыми я не согласен, и которые путают людей которые только начали работать с ИИ:

«Речь не о том, чтобы уволить техдиректора и перевести на нейросеть высоконагруженный сервис. Речь о проверке гипотез и мелких внутренних задачах предпринимателя». В изначальной статье не подразумевается что речь исключительно о прототипах и небольших внутренних автоматизациях. Это более узкое утверждение, с которым я и не спорил. ИИ действительно позволяет значительно ускорить проверку гипотез и снизить стоимость mvp. Кажется, в этом комментарии вы изменили предмет обсуждения. Первоначальная статья продаёт идею замены разработчика, а ваш ответ говорит что вы имеели в виду ИИ только для mvp, может конечно вы считается что для mvp нужен только джун.

«Раньше на такую гипотезу нужно было искать человека и отдавать 50-100 тысяч за прототип». Подскажите, откуда взялись эти цифры. Прототипы бывают разными по сложности, к примеру, простой бот для telegram, парсер документов и интеграция с CRM разные задачи, и соответсвенно, разные по стоимости.Кроме того, для части перечисленных задач давно существуют готовые решения, к примеру, no-code-инструменты

«На практике агентные среды держат кэш контекста на уровне 70–85%. Соответственно, реальные затраты на порядок ниже». Тут у меня еще больше вопросов возникает. Во-первых, откуда статистика про 70–85%? Есть исследования или замеры именно вашей связки Codex + DeepSeek на наборе задач? Эффективность кэширования зависит от структуры запросов, повторного использования префиксов контекста и характера работы самого агента. Нельзя утверждать, что конкретный процент попаданий в кэш будет у каждого пользователя. Во-вторых, даже при 85% попаданий в кэш общие расходы не обязательно уменьшаются на порядок. Возьмём мой предыдущий пример: 2 млн входных и 500 тысяч выходных токенов за день. По тарифам deepseek-v4-pro в пиковые часы:
- Без кэширования: $4.62.
- При 70% попаданий входных токенов в кэш: примерно $2.83.
- При 85%: примерно $2.45.

Кэширование удешевляет входные токены, но не выходные, при этом генерация ответа и reasoning тоже тарифицируются. То есть при 85% попаданий в кэш экономия в данном примере составляет около 47%, а не 90%.

«Банально сделать лендинг, на который раньше бы ушло тысяч 30 и пару недель, теперь 17 минут и 17 центов». Что именно мы сравниваем? Если речь о генерации html + верстки по описанию, то вполне допускаю, что ИИ справился за 17 минут(и тут тоже зависит от модели). Но стоимость и время генерации файлов не равны стоимости и времени создания готового лендинга. Кто подготовил требования, тексты, а проверял ли кто-нибудь мобильную версию? Включены ли в эти 17 минут публикация и тестирование? Я не утверждаю, что каждый лендинг требует двух недель работы и 30 тысяч рублей. Я говорю о том, что для корректного сравнения необходимо одинаково определить конечный результат. При таких выводах получается, что разработчику мы считаем полный цикл работы, а в ИИ учитываем только время генерации.

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