Почему заменить программистов ИИ будет не так просто

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

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

В этой статье пойдет речь о взаимосвязи между требованиями и программным обеспечением, а также о том, что нужно ИИ для получения хороших результатов.

Это не баг, это фича... нет, подождите, это баг

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

Мне было поручено разработать динамические условия. Существовало условное словоблудие, которое зависело от типа приобретаемого товара, а также от того, в каком штате США находился заказчик в силу требований законодательства.

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

Я наивно спросил клиента: «Должен ли я удалить поле ввода, которое позволяло пользователю переопределить правильные положения и условия?» Ответ, который я получил, с тех пор запечатлен в моем мозгу. Его точные слова были сказаны с полной и абсолютной уверенностью;

“Этого никогда не произойдёт”

Это был старший руководитель, который проработал в компании много лет, знал бизнес-процессы компании и был выбран для наблюдения за программным обеспечением не без причины. Возможность переписывания условий по умолчанию была явно запрошена одним и тем же человеком. Кто я такой, черт возьми, чтобы допрашивать кого-либо, тем более старшего руководителя компании, которая платила нам деньги за создание этого продукта? Я отмахнулся от этого и тут же забыл об этом.

Несколько месяцев спустя, всего за несколько недель до запуска, тестировщик на стороне клиента обнаружил дефект, и его поручил мне. Когда я увидел подробности дефекта, я громко рассмеялся.

То беспокойство, которое я испытывал по поводу отмены условий по умолчанию, но то, что мне сказали, никогда не произойдет? Угадайте, что происходило? Угадайте, кого в этом обвинили и кого попросили это исправить?

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

ИИ прямо сейчас: шахматы против беспилотных автомобилей

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

ИИ был применен в шахматах еще в 1980-х годах. Широко признано, что ИИ превзошел возможности человека выигрывать в шахматы. Это тоже неудивительно, ведь параметры шахмат КОНЕЧНЫ ( но игра еще не решена ).

Шахматы всегда начинаются с 32 фигур на 64 полях, имеют хорошо документированные официально согласованные правила и, что наиболее важно, имеют четко определенную цель. В каждом ходе существует конечное число возможных ходов. Игра в шахматы — это всего лишь следование механизму правил. Системы искусственного интеллекта могут рассчитывать последствия каждого хода, чтобы выбрать наиболее вероятный ход, позволяющий захватить фигуру противника или занять позицию и в конечном итоге победить.

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

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

В сфере технологий стандартом доступности являются пять или даже шесть девяток — веб-сайт или услуга доступны 99,999% (или 99,9999%) времени. Стоимость достижения первых 99% не так уж высока. Это означает, что ваш веб-сайт или сервис могут быть недоступны более трех дней (87,6 часов) в году. Однако за каждые 9, которые вы добавляете в конце, стоимость достижения этой цели растет в геометрической прогрессии. К тому времени, когда вы достигнете 99,9999%, вы сможете допускать простой только на 31,5 секунды в год. Это требует значительно большего планирования и усилий и, конечно, дороже. Получить первые 99% может быть непросто, но пропорционально это намного проще и дешевле, чем последняя крошечная доля.

365 х 24 х 60 минут = 525 600 минут в год.

Доступность 99 % -> недоступна на 5256 минут, 87,6 часов Доступность 99,9 % -> недоступна 526 минут, 8,76 часов 99,99 % -> 52 минуты, менее 1 часа 99,999 % -> 5,2 минуты 99,9999 % -> 0,52 минуты, примерно 31,5 секунды

Независимо от того, насколько близок к тому, чтобы ИИ был достаточно хорош, всегда существует риск несчастных случаев и смертельных исходов. Эти риски и последствия происходят каждый день, когда люди за рулем. Я не знаю, какой уровень несчастных случаев и смертей будет приемлем для правительств, но вы должны думать, что оно должно быть по крайней мере не хуже чем для людей.

Причина, по которой так сложно достичь приемлемого уровня безопасности, заключается в том, что вождение автомобиля предполагает значительно больше переменных, чем шахматы, и эти переменные НЕ КОНЕЧНЫ. Первые 95% или 99% могут быть предсказуемыми и легко поддающимися учету. Однако после этих первых 99% существует очень много крайних случаев, и каждый из них может иметь некоторые общие черты, но каждый из них уникален; другие транспортные средства на дороге, управляемые другими людьми, перекрытие дорог, строительство, аварии, погодные явления. Сколько раз вы ездили после того, как дорога была заасфальтирована, но краска для разделительных линий на дороге не была нанесена. Гораздо сложнее заставить вашу модель искусственного интеллекта учитывать и распознавать эти аномалии и крайние случаи, и, что более важно, как правильно реагировать, не попадая в аварию. Каждый крайний случай может иметь некоторые общие черты, но они редко бывают идентичными, из-за чего ИИ сложнее определить подходящий способ реагирования.

ИИ не может создавать программное обеспечение, только код

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

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

Хуже того, требования меняются или игнорируются. Недавно меня попросили помочь команде создать что-то, что могло бы помочь людям получать информацию по вопросам здоровья, связанным с COVID 19. Приложение должно было быть предназначено для той части земного шара, где не было надежного WIFI. Команда хотела, чтобы я помог создать приложение, которое могло бы проводить опросы с помощью SMS — текстовых сообщений на телефоне. Поначалу я был рад принять в этом участие.

Как только я начал слышать, как команда описывает, чего, по их мнению, они хотят, я понял, что это будет проблемой. Одно дело, когда розничная компания спрашивает вас по шкале от 1 до 10, насколько вероятно, что вы снова будете делать покупки в их магазине. Совсем другое дело — задавать многоэтапные опросы с вопросами с несколькими вариантами ответов о симптомах, которые вы испытываете при возможной инфекции COVID. Я никогда не говорил «нет», но я упомянул все возможные точки сбоя в этом процессе и хотел, чтобы команда четко определила, как мы будем обрабатывать поступающие ответы на все вопросы. Будут ли это числа, разделенные запятыми, сопоставленные каждому ответу? Что произойдет, если отправленный ответ не соответствует ни одному из предложенных вариантов?

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

Является ли идея использования ИИ для создания программного обеспечения, позволяющего тем же заинтересованным сторонам напрямую общаться с компьютером для создания опроса на основе SMS? Собирается ли ИИ задавать наводящие вопросы о том, как справиться со всеми возможными проблемами сбора данных опросов через SMS? Будет ли он учитывать все, что мы, люди, можем делать неправильно на этом пути, и как справляться с этими ошибками?

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

За последнее десятилетие индустрия программного обеспечения перешла от каскадной методологии к гибкой. Waterfall точно определяет, что вы хотите, еще до написания кода, а Agile обеспечивает достаточную гибкость, чтобы вы могли вносить изменения по ходу дела.

Очень много программных проектов, использующих waterfall, потерпели неудачу, потому что заинтересованные стороны думали, что знают, чего хотят, и думали, что могут точно описать и задокументировать это, но были очень разочарованы, когда конечный продукт был готов. Предполагается, что agile должен стать противоядием этому процессу.

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

На самом деле ИИ может неплохо справляться с созданием программного обеспечения, используя водопадный процесс, который также ласково называют маршем смерти. Знаешь, кто ужасен в waterfall? Мы, люди. И дело не в той части, где подписанные документы передаются команде программистов для написания кода. Это все, что было до этого. Искусственный интеллект может делать необычные вещи, но он не может читать ваши мысли или подсказывать, чего вам следует хотеть.