Гендиректор сервиса по доставке еды DoorDash Тони Сюй говорит, что генерация кода с помощью ИИ — это лишь малая часть инженерной работы, которой недостаточно для реального прорыва в производительности разработчиков.
Гендиректор сервиса по доставке еды DoorDash Тони Сюй говорит, что генерация кода с помощью ИИ — это лишь малая часть инженерной работы, которой недостаточно для реального прорыва в производительности разработчиков.
По его словам, лишь часть дня софтверных инженеров уходит на написание кода — и здорово, что сегодня есть модели, которые делают это за них. Это помогает оптимизировать условно от четверти до половины времени, которое тратится на релиз кода. Однако огромную часть времени программисты тратят на продуктовые ревью, дизайн-сессии и согласование задач с другими командами. Чтобы получить ожидаемый прирост эффективности, ИИ должен проникнуть во все эти процессы.
«Если эта часть работы не изменится, вы просто не сможете получить тот прирост продуктивности, на который рассчитываете. Множество компаний в индустрии сейчас пытаются настроить эти процессы так, чтобы быть ИИ-нативными не только в разработке кода, но и во всей деятельности в целом», — пояснил глава DoorDash в подкасте Uncapped.
Сюй также подчеркнул необходимость внедрения физического ИИ в бизнес — от роботов для приготовления еды до беспилотного транспорта для доставки. При этом топ-менеджер сохраняет сдержанный подход: в мае он отмечал, что ИИ пока не изменил оргструктуру компании, хотя нейросети пишут от половины до двух третей всего кода DoorDash.
На ограничения нейросетей открыто указывают и другие ИТ-лидеры. Ранее СЕО конструктора сайтов Wix Авишай Абрахами заявил, что индустрия сильно переоценивает возможности искусственного интеллекта.
Даже автор термина «вайб-кодинг» Андрей Карпатый публично критиковал качество генерируемого кода. Он отмечал, что ИИ-код иногда «очень громоздкий, там куча копипаста и неуклюжих хрупких абстракций. Оно работает, но выглядит просто отвратительно».
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Скорость деливери фичей реально ограничена скоростью понимания фичей всеми участниками процесса - Design, Engineering, QA, Product, Support. Скорость понимания масштабируется только декомпозицией с наймом дополнительных Product и пр.
Восторг, что можно быстро сгенерить работоспособную демку (не тратя время на обсуждения с другими участниками процесса), разбивается о реальность, в которой для приложений в проде необходимость предварительно понять и согласовать каждую фичу в деталях никто не отменял.
В конечном счёте, самим пользователям не нужны новые фичи каждый день. Большинство продуктов и так за последние 10 лет превратились в комбайны из кнопок и множества фичей, из которых реально используются 10% возможностей.