Одним из моих старых хобби было писать для независимых музыкальных журналов, таких как Spill Magazine (бесплатно распространяемый на музыкальных площадках) и DV8 (бесплатно распространяемый в парикмахерских). За прошедшие годы я увидел сотни неподписанных групп и усвоил важный урок: усиление делает все, что вы делаете, очень громким, но это не меняет фундаментально, хорошо или плохо то, что вы делаете.
Согласно отчету DORA «Состояние разработки программного обеспечения с использованием искусственного интеллекта», этот закон усиления в равной степени применим и к разработке программного обеспечения. ИИ — это усилитель, который увеличит объем ваших возможностей доставки программного обеспечения, как хороших, так и плохих.
И именно поэтому я нахожу выводы доклада о доверии такими обнадеживающими.
Мы не доверяем ИИ
В отчете говорится, что ИИ используется практически везде. Почти все (95%) используют ИИ в своей работе и считают, что это повышает их производительность (80%) и качество кода (59%). Но они этому не доверяют. Фактически, когда их спросили, доверяют ли они результатам, созданным ИИ, подавляющее большинство ответило сдержанным «в некоторой степени».
Это заставило многих людей задуматься о том, как мы можем повысить доверие к ИИ. Существует мнение, что если мы сможем заставить технических специалистов поверить в это, мы получим еще большую выгоду. Однако это не тот результат, к которому нам следует стремиться.
Одним из факторов, способствующих успешному внедрению ИИ, несомненно, является здоровый уровень скептицизма в отношении ответов, которые он дает. Поощрение людей к повышению доверия к ИИ может привести к снижению свободы воли, личной ответственности и бдительности.
Абсолютное доверие не требуется
Успешные разработчики программного обеспечения приобрели навыки критического мышления, которые позволяют им предвидеть потенциальные ловушки и предвидеть, как что-то может пойти не так. Когда вы создаете программное обеспечение, используемое в больших масштабах, часто возникают сценарии, которые вы считаете нетипичными.
Когда я работал над платформой, используемой мировыми автомобильными гигантами, мы обрабатывали более 4 миллионов запросов всего за пять минут. Мы работали над функцией, и я продумывал возможные сценарии сбоя и крайние случаи. Когда я подчеркивал потенциальную медвежью ловушку, деловые люди часто отмахивались от нее. «Шансы на то, что это произойдет, миллион к одному», — сказали они. Однако это означало, что это могло происходить более 1152 раз в день, поэтому нам пришлось это учитывать.
Когда у разработчиков скептическое мышление, это здорово. Они мыслят масштабно и предотвращают постоянную серию разрушительных событий. Моя команда следовала принципу «создал — сам запустил», поэтому у нас была сильная мотивация заставить пейджер замолчать, создав надежное программное обеспечение.
Хорошие разработчики могут думать наперед и предотвращать проблемы еще до того, как напишут хотя бы одну строку кода. Низкое доверие к результатам, генерируемым ИИ, является ключевым аспектом такого мышления.
Модель ИИ — это модель вопросов и ответов
Хотя ИИ часто считают революционным, обычно оказывается, что существующие модели можно (и нужно) применять. Те, кто этого не понимает, заново усваивают уроки небольших партий и ориентации на пользователя, поскольку ИИ только усугубляет проблему одновременного изменения слишком большого количества и чрезмерного инвестирования в идею функции, прежде чем понять, будет ли она полезна для пользователей.
Точно так же у нас есть существующая модель, которую мы можем применить к коду, сгенерированному ИИ. Модель вопросов и ответов.
Когда вы найдете ответ на Stack Overflow, вы не просто скопируете его и вставите в свое приложение. Ответы на этих сайтах часто содержат несколько важных строк кода, которые непосредственно отвечают на вопрос, а также множество дополнительных строк, дополняющих пример. Существует некоторый риск при выборе этих основных строк и даже больше при использовании оборачивающих.
Вы увидите случайные комментарии разработчиков, подчеркивающие опасность этих переносных строк, и, хотя они не ошибочны, ответы были бы менее полезными, если бы они содержали больше и лучший код в переносных строках.
Опытные разработчики используют ответ, чтобы понять, как решить свою проблему, а затем пишут собственное решение или вносят существенные изменения в код ответа. Мы должны применять те же самые оговорки ко всему коду, автором которого не были мы, будь то с сайта вопросов и ответов или от ИИ-помощника. Нет причин доверять коду, сгенерированному ИИ, больше, чем ответу на сайте вопросов и ответов, который, вероятно, изначально составлял часть обучающих данных.
ИИ предупредил вас
Скептицизм в отношении кода, сгенерированного ИИ, не должен быть спорной позицией. Сами инструменты выдают эти предупреждения, когда вы начинаете их использовать. Все, кто пользуется помощниками по кодированию и чатом с искусственным интеллектом, просматривали сообщение типа: «ChatGPT может допускать ошибки. Проверьте важную информацию».
С нашей стороны было бы глупо оказывать им большое доверие, и результаты были бы хуже, если бы мы это сделали.
Хотя ИИ-помощь является относительно новым явлением, опытные разработчики программного обеспечения применяют надежные модели обработки создаваемого им кода. Вот почему энтузиазм по поводу сокращения труда лучше всего поддерживается приглушенным уровнем доверия.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Стив Фентон — октонавт в Octopus Deploy, руководитель сообщества DORA и шестикратный обладатель награды Microsoft MVP с более чем двадцатилетним опытом разработки программного обеспечения. Он написал книги по TypeScript (Apress, InfoQ), Octopus Deploy и веб-операциям…. Подробнее от Стива Фентона.
