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

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

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

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

Текущий ИИ гораздо лучше справляется с улучшением эффективности. Он может заменять альтернативы, взвешивать их относительные достоинства и предлагать комбинацию, которая приводит к наиболее эффективному решению. Но чем умнее становится ИИ, тем меньше мы должны ему доверять в спорных вопросах, требующих суждения. Потому что вещи могут принять пугающий оборот. Знаменитый максимизатор связок бумаг, сформулированный Ником Бостромом, является забавным мысленным экспериментом с важным предупреждением: ИИ будет оптимизировать все, что вы ему указываете. Если это, например, производство скрепок, и предоставлены бесконечные возможности и бесконечное самоотречение, то он будет разобрать целые галактики, чтобы изготовить больше бесполезных канцелярских принадлежностей.

Даже если бы ИИ стал самосознательным, с или без злых намерений, он все равно был бы чужим, и по определению таким (это в слове искусственный). Исаак Азимов предсказал, что создание с индивидуальным агентством, вероятно, должно иметь некоторые защитные меры. Его “три закона робототехники” появились за три года до “ЭНИАК”. Но он не мог предсказать злого гения, который добавил некоторые личные исключения к принципу “не наносить вред” с помощью хитрого обновления прошивки, как в первом фильме “Робокоп”.

• «Правила кибербезопасности SEC»
• Китай имеет новый план оценки безопасности генеративного искусственного интеллекта, и он полон деталей
• Как зарабатывать деньги с помощью TikTok Shop Dropshipping

Достаточно угрюмо заглянуть в палантир. То, что я предсказываю (не имея акций ни в одном из ведущих заинтересованных сторон), – это то, что искусство программирования превратится в искусство ясного и неоднозначного выражения того, что вам нужно. Разработчики станут опытными бизнес-аналитиками, знающими ИИ, привыкшими разговаривать с ИИ, используя конечный уровень языка программирования, а именно английский. Он всегда будет создавать рабочее программное обеспечение, и если мы повезём, оно даже будет полезным.

Рабочее программное обеспечение недостаточно хорошо

Не странно ли, что манифест Agile требовал рабочего программного обеспечения? Будто бы сломанное программное обеспечение когда-либо является приемлемой альтернативой! Не слишком ли много просить, чтобы код, сгенерированный с помощью промптов, также был полезным и ценным? Да, скорее всего, это слишком много просить. Разрыв между работающим и ценным программным обеспечением огромен, потому что ценность непредсказуема и нетривиальна. Идеально работающее программное обеспечение может потерять свою актуальность без вашей вины и способом, который никакое обновление исправить не может. Вот несколько примеров.

Это не первый раз, когда я упоминаю забытый проект ОС Chandler. Его трудный путь к версии 1.0 прекрасно описан в книге Скотта Розенберга “Dreaming in Code” 2007 года. Это постоянное напоминание о том, что лучшие намерения, команда выдающихся разработчиков и щедрый спонсор (Митч Капор, создатель Lotus 1-2-3) не являются гарантией успеха.

Chandler задал себе целью быть бесплатной альтернативой Microsoft Outlook и Exchange. Он обещал радикально иной пользовательский опыт. Он собирался изменить то, как мы обрабатываем сообщения, пункты повестки дня и списки дел. И он намеревался сделать это в приложении для рабочего стола, обмениваясь информацией через протокол пир-к-пиру. Все во имя людей!

Но команда сделала слишком много ошибок в своей архитектурной дорожной карте. Как Икар, они слишком близко подлетели к солнцу. Мир догнал их. Более мощные функции браузера сделали Python-основанное рабочее приложение плохим выбором. Дешевое и простое размещение собственного сервера устраняло необходимость в протоколе пир-к-пиру, а такое решение дизайна вызывало взрывную сложность. Сейчас, все это могло бы быть исправлено, если бы сообщество захотело. Но не захотело. Основная проблема заключалась в пользовательском опыте. Идеи были слишком радикальными. Это не то, что нужно обычному офисному работнику. Я не видел, чтобы какой-либо из них был реализован в других продуктах (но я с радостью поправлюсь, если что-то изменилось). Люди до сих пор используют электронную почту и повестки дня так же, как делали это в 1995 году, только теперь на своих телефонах и без скругленных углов.

Неожиданное устаревание GWT

Иногда отличный инструмент может стать устаревшим, потому что его первоначальный уникальный конкурентный преимущество больше не продается. Google Web Toolkit (GWT) предлагал привлекательное предложение в 2006 году. У настольных компьютеров было достаточно мощности для поддержки браузера в качестве платформы приложений. Вы могли делать свои налоги, не устанавливая ничего. Но несовместимости браузера были распространены, особенно для таких продвинутых функций, как перетаскивание или двойной щелчок. GWT позволял писать код для бэкэнда и фронтэнда в одном проекте, с общими объектами для передачи данных и проверки и развертывать их в одном веб-архиве. GWT компилировал Java в JavaScript, и вы даже могли отлаживать свой код на клиентской стороне Java с помощью локального сервера разработки. Мне это нравилось, и я заработал на этом немало денег некоторое время.

Но компиляция была известно дорогой. Производители браузеров примирились с собственными недостатками. Фронтэнд-платформы, такие как Angular и React, быстро созрели. Создание фронтэндов стало серьезной профессией, и эти разработчики, казалось, не стесняются использовать JavaScript в качестве платформы для программирования. GWT потерял свою актуальность, и ни одна ИИ не могла это предвидеть или исправить. Проблема заключалась не в коде, а в неподходящей окружающей среде.

Продолжайте писать код ради самого процесса

Тем не менее, ничто из этого не должно отговаривать вас от написания кода. Нет необходимости, чтобы серьезное программное обеспечение было эффективным в коммерческом смысле или имело какую-либо практическую выгоду вообще. Я говорю о любительском Open Source. Я написал программное обеспечение, на которое я горжусь, но у него не было бизнес-плана, дорожной карты и никакого другого мотива, кроме моего собственного образования и удовольствия. Оно было эффективным в том смысле, что научило меня новым концепциям, но я не хотел его использовать для себя. На GitHub много таких проектов. Я не хочу оскорблять. Я говорю из личного опыта. Нет ничего плохого в том, чтобы писать код ради самого процесса, но это похоже на игру в группе, которая никогда не выступает перед публикой: это сложно продолжать.