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