Несущая сложность является уникальным конкурентным преимуществом разработчика

Несущая сложность - преимущество разработчика

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

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

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

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

• Как я использую ChatGPT в качестве инженера LLM для быстрого создания проектов
• 5 лучших начальных занятий (бесплатные курсы и инструменты искусственного интеллекта для начала работы)
• Как автоматически импортировать и объединить несколько файлов в R

Искусственный интеллект уже очень квалифицирован в решении большей части случайной сложности, с которой вы сталкиваетесь по пути. Мы должны использовать его насколько это возможно. Я знаю, что я посвятил три статьи экзамену Java OCP 17 (ссылка здесь на Часть 1, Часть 2 и Часть 3), но я верю (и надеюсь), что механическое знание тайных деталей уйдет в прошлое. ИИ заботится о идиоматическом использовании, он может соблюдать чистый код, хорошие соглашения об именах и даже писать исходную документацию. И он будет становиться все лучше и лучше в этом. Он даже может осуществлять полноценные миграции устаревшего кода на новые языки и версии фреймворков. Я только за это. Миграция гигантского приложения Java 4 EJB2 на Spring Boot 3 микросервисы вручную – это не мое представление о веселье.

Если через пять лет состояние искусства в области помощи в написании кода все еще не впечатляет вас, это, вероятно, не из-за какой-то случайной сложности, с которой машина не может справиться. Скорее всего, это основная сложность, с которой она не может справиться. Если ваш калькулятор ипотеки показывает ставку процента по ипотеке 45,4%, а второй пилот не предупреждает вас, что вы, вероятно, перепутали десятичную запятую, это потому, что у него никогда не было собственного дома, и он не заметит, что эта цифра на порядок слишком высока.

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

Возьмите, например, асимметричный обмен ключами, манящую проблему, которая мучила великие математические умы на протяжении десятилетий, если не веков. Алиса и Боб могут общаться с использованием неподдельного ключа шифрования, но если они не знают, что Ева перехватила его, все становится открытым. Если бы у нас была пара ключей так, что вы могли бы зашифровать сообщение с ключом A, но только дешифровать его с ключом B и нет практического способа вывести один ключ из другого. Если вы затем отдаете одну часть ключа каждому и защищаете другую часть своей жизни, вы решили проблему обмена ключами.

Это довольно просто сказать, куда вы хотите прийти, но это едва ли спецификация, с которой начинать кодирование. Это даже не задача программирования. Это поиск алгоритма, который может быть даже невозможен. В “Scrum Poker” вы бы взяли карту “бесконечность”. Алгоритмы, которые в конечном итоге разработали Уитфилд Диффи и Мартин Хеллман, помещаются на поговорочную салфетку. Переводить это в код было бы тривиальным по сравнению. Но они никогда не смогли бы прийти к решению постепенно за клавиатурой. Или прочитайте захватывающую историю о расшифровке шифра Энигмы командой в Блетчли Парке. Еще более сложная задача, потому что здесь действительно была война.

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

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