Из-за всех этих статей о том, насколько потрясающ прогресс ИИ, у многих возникло отчаяние в связи с возможностью скорой замены разработчиков ПО искусственным интеллектом. Люди представляют, что руководители и исследователи продуктов передадут всю работу по созданию ПО искусственному интеллекту. Так как я уже пятнадцать лет пишу ПО по спецификациям, созданным этими людьми, то не могу воспринимать серьёзно подобное беспокойство.
Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде. Если освоить синтаксис, логику и методики, то процесс оказывается довольно прямолинейным. Настоящие проблемы обычно связаны с тем, что ПО должно делать. Самое сложное в создании ПО — не написание кода, а создание требований, а требования к ПО по-прежнему определяют люди.
В этой статье я расскажу о связи между требованиями и ПО, а также о том, что необходимо ИИ для создания хороших результатов.
▍ Это не баг, а фича… хотя постойте, всё-таки баг
В самом начале моей карьеры меня подключили к уже разрабатываемому проекту, чтобы повысить скорость команды. Основная задача ПО заключалась в конфигурировании произвольных продуктов на сайтах электронных продаж.
Мне поручили генерацию динамических условий договоров. Это было условное пустословие, зависящее от типа приобретаемого продукта, а также от того, в каком штате США находился покупатель.
В определённый момент я подумал, что нашёл потенциальный изъян. Пользователь мог выбрать один тип продукта, и при этом генерировались соответствующие условия договора, однако в дальнейшем он мог выбрать другой тип продукта с уже заданными условиями. Это нарушало одну фичу, которую чётко указали в бизнес-требованиях, и под которой стояла подпись клиента.
Я наивно спросил у клиента: «Нужно ли мне удалить входные данные, позволяющие пользователю переопределить правильные условия договора?» Его ответ запомнился мне навсегда. С полной уверенностью он сказал:
«Этого никогда не может случиться».
Это был руководитель высшего звена, работавший в компании много лет, он знал бизнес-процессы компании и его осознанно выбрали для контроля разработки ПО. Возможность переопределения стандартных условий договора в явной форме была запрошена тем же человеком. Да кто я такой, чтобы подвергать сомнению чьи-то слова, особенно важного руководителя из компании, которая платила нам за создание этого продукта? Поэтому я пожал плечами и вскоре забыл об этом.
Несколько месяцев спустя, всего за пару недель до релиза ПО, тестировщик на стороне клиента обнаружил проблему, решение которой поручили мне. Когда я прочитал описание этой проблемы, то громко рассмеялся.
Это была та самая проблема со стандартными условиями договора, про которую мне говорили, что она никогда не возникнет. Как думаете, что произошло? Как думаете, кого в этом обвинили и кому сказали всё исправить?
Устранить проблему было довольно просто, а последствия бага оказались незначительными, но этот опыт стал сквозной темой в моей карьере разработчика ПО. Я общался со многими коллегами-разработчиками, и знаю, что я такой не один. Проблемы стали больше, сложнее в решении и более затратными, но источник проблемы обычно был одинаков: нечёткие, несогласованные или ошибочные требования.
«Чтобы заменить программистов искусственным интеллектом, клиенты должны чётко описать, чего они хотят. Мы в безопасности.»
▍ Современное состояние ИИ: шахматы против беспилотных автомобилей
Концепция искусственного интеллекта существует достаточно давно, однако современный прогресс вызвал беспокойство в медиа и в конгрессе США. ИИ уже достиг большого успеха во многих областях. Первое, что приходит на ум — это шахматы.
ИИ начали использовать в шахматах ещё с 1980-х. Общепризнанно, что ИИ превзошёл человека в способности побеждать в шахматах. Это и неудивительно, ведь параметры в шахматах КОНЕЧНЫ (но игра пока ещё не решена).
Шахматы всегда начинаются с 32 фигур на 64 клетках, имеют хорошо задокументированные официальные правила, а самое важное — чётко определённую цель. На каждом ходу есть конечное количество возможных вариантов перемещения фигур. Играя в шахматы, мы просто выполняем движок правил. Системы ИИ могут вычислить последствия каждого хода, чтобы выбрать ход, который с наибольшей вероятностью приведёт к взятию фигуры противника, захвату позиции или окончательной победе.
Есть и ещё одна сфера, в которой ИИ развивается очень активно — беспилотные автомобили. Автомобилестроители уже довольно давно обещают нам их выпустить. Некоторые машины имеют определённые возможности беспилотного вождения, но есть и изъяны. Во многих ситуациях автомобиль требует активного контроля; водителю может понадобиться взять руль в свои руки — функция беспилотного вождения не полностью автономна.
Как и шахматные ИИ-программы, беспилотные автомобили активно используют для принятия решений движки на основе правил. В отличие от правил шахматных программ, правила поведения в каждой возможной ситуации определены нечётко. Есть тысячи крошечных факторов, которые водители принимают в расчёт при избегании пешеходов, объезде припаркованных автомобилей и поворотах на развязках. От правильной интерпретации этих факторов зависит, доберётесь ли вы в супермаркет безопасно или окажетесь в больнице.
В мире технологий стандартом является доступность уровня пяти или даже шести девяток, то есть когда веб-сайт или сервис доступен в течение 99,999% (или 99,9999%) от всего времени. Затраты для достижения первых 99% не так высоки. Это значит, что ваш веб-сайт или сервис может быть офлайн в течение более чем трёх дней (87,6 часа) в год. Однако при добавлении в конец каждой новой девятки затраты растут экспоненциально. Если вы достигнете 99,9999%, то даунтайм будет составлять всего 31,5 секунды в год. Это требует существенно больше планирования и усилий; и, разумеется, это гораздо дороже. Достичь первых 99% может быть непросто, но в соотношении это гораздо проще и дешевле, чем эта последняя крошечная дробная часть.
365 X 24 X 60 минут = 525 600 минут в год
Доступность 99% -> даунтайм 5256 минут, 87,6 часа
Доступность 99,9% availability -> даунтайм 526 минут, 8,76 часа
Доступность 99,99% -> 52 минуты, меньше одного часа
Доступность 99,999% -> 5,2 минуты
Доступность 99,9999% -> 0,52 минуты, приблизительно 31,5 секундыНеважно, насколько близок ИИ беспилотного вождения к достаточному качеству, всегда есть риск несчастных случаев и смертей. Эти риски и последствия ежедневно возникают у сидящих за рулём людей. Не знаю, какая частота несчастных случаев и смертей приемлема для государства, но стоит считать, что она должна быть хотя бы не хуже, чем у живых водителей.
Приемлемого уровня безопасности так сложно достичь, потому что при вождении автомобиля задействуется гораздо больше переменных, чем в шахматах, и эти переменные НЕ КОНЕЧНЫ. Первые 95% или 99% может быть легко предсказать и учесть. Однако после первых 99% есть так много пограничных случаев, каждый из которых может иметь некие общие признаки, но при этом быть уникальным; другой транспорт на дороге, управляемый другими людьми, перекрытые дороги, ремонт, ДТП, погодные условия. Как часто вы ездили по дорогам, которые асфальтированы, но разметка на которых отсутствовала? Существенно сложнее заставить модель ИИ учитывать и распознавать такие аномалии и пограничные случаи, и ещё более важно правильно реагировать на них, не попадая в аварии. У каждого пограничного случая могут быть некие общие черты, но они редко бывают одинаковыми, из-за чего ИИ сложнее определить правильную реакцию.
▍ ИИ не может создавать ПО, только код
Создание и поддержка ПО гораздо ближе к вождению, чем к игре в шахматы. В нём задействовано гораздо больше переменных, а правила основаны на субъективных решениях. Вы можете добиться желаемого результата при разработке ПО, но маловероятно, что он будет столь же простым, как в шахматах. ПО редко бывает завершённым; в нём добавляются фичи и устраняются баги; это постоянный процесс. В отличие от ПО, после победы или проигрыша в шахматах всё заканчивается.
В разработке ПО есть инструмент, приближающий архитектуру ПО к жёстко контролируемому движку правил шахмат: технические спецификации. В лучшем случае, спецификации описывают ожидаемое поведение пользователей и потоки исполнения программ. Вот как пользователь покупает сэндвич онлайн: нажимает на кнопку, создаёт эту структуру данных, запускает этот сервис. Однако мы редко такое получаем. Очень часто нам выдают списки с пожеланиями спецификаций фич, черновики и документы с нечёткими требованиями, а потом говорят полагаться на здравый смысл.
Ещё хуже то, что требования меняются или игнорируются. Недавно меня попросили помочь команде создать систему, помогающую людям получать информацию о проблемах со здоровьем, связанных с COVID 19. Приложение предназначалось для той части мира, в которой не было надёжного WIFI. Команда попросила помочь меня создать приложение, способное выполнять опросы через SMS. Поначалу я с восторгом взялся за проект.
Но как только услышал описание желаемой системы, я осознал, что это станет проблемой. Одно дело — спрашивать, какова по шкале от 1 до 10 вероятность того, вы снова посетите сетевой магазин. Это сильно отличается от многоэтапных анкет с вопросами, имеющими много вариантов выбора, о симптомах, испытываемых при вероятном заражении COVID. Я не отказывался от работы, но указал на все возможные точки отказа в этом процессе и попросил команду чётко определить, как мы будем обрабатывать поступающие ответы на все вопросы. Будут ли это разделённые точками с запятой числа, соответствующие каждому ответу? Что, если отправленный ответ не соответствует ни одному из вариантов?
После всех этих вопросов команда пришла к тому же выводу. Мы решили, что лучше за это не браться. Верьте или нет, но я считаю это удачным решением. Было бы хуже, если бы мы потратили время и ресурсы, двигаясь вперёд без чёткого решения всех потенциальных проблем с отправкой недопустимых пользовательских данных.
Заключается ли идея поручения искусственному интеллекту разработки ПО в том, чтобы позволить руководству напрямую попросить компьютер создать систему SMS-анкетирования? Будет ли ИИ задавать вопросы о том, как обрабатывать все возможные проблемы сбора данных опросов через SMS? Учтёт ли он всё, то люди могут сделать в процессе анкетирования, и сможет ли справиться с ошибками?
Чтобы создать функциональное ПО при помощи ИИ, вам нужно знать, чего вы хотите, и чётко описать это. Иногда бывает так, что я пишу ПО просто для себя и не осознаю некоторых сложностей и проблем до того, как не приступлю к написанию кода.
За предыдущее десятилетие отрасль разработки ПО перешла от каскадной модели к agile. В каскадной модели чётко задаётся желаемое до того, как написано код, а agile обеспечивает достаточную гибкость для внесения изменений по ходу движения.
Очень многие программные проекты провалились, потому что их руководители считали, что точно знают, чего хотят, и думали, что могут точно описать и задокументировать это, но очень разочаровывались, когда видели готовый продукт. Разработка ПО по модели Agile должна была стать противоядием для этого процесса.
Наверно, ИИ лучше всего подходит для переписывания уже имеющегося ПО для его применения на новом оборудовании или на более новых языках программирования. Всё ещё есть много организаций, в которых ПО написано на COBOL, но всё меньше программистов хочет его осваивать. Если вы точно знаете чего хотите, возможно, вам удастся заставить ИИ создавать ПО быстрее и дешевле, чем командой живых программистов. Я считаю, что ИИ может создавать уже созданное ПО быстрее, чем живые программисты, но причина этого в том, что в процессе первоначальной разработки люди уже поняли, что должно делать это ПО.
Наверно, ИИ может неплохо справляться с разработкой ПО по каскадному процессу, который имеет грозное название «марш смерти». А знаете, кто плохо совместим с каскадной моделью? Мы, человеческие существа. И не из-за той части, когда подписанные документы передаются команде разработчиков, чтобы они могли начать писать код. Причина во всём том, что происходит до этого. Искусственный интеллект способен на чудеса, но не может читать мысли или говорить вам, чего вам нужно хотеть.
Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали? 🚀
Автор:
ru_vds
