Рано или поздно компьютер сбоит. Если мы отметаем механические причины, то приходим к выводу, что неправильно отрабатывает какая-то часть кода какого-то драйвера и так далее. А теперь представьте, что программы состоят из «самовосстанавливающегося кода», который не просто выдаёт ту или иную ошибку, но и устраняет эту ошибку, а также предотвращает любые вредоносные программы, пытающиеся внести изменения.

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

Другими словами, что если бы был код, который сам себя восстанавливает и улучшает? Это можно сравнить с автоматическим выключателем. Обычно автомат срабатывает при перепаде напряжения, что приводит к отключению электричества. Говоря программным языком, автоматический выключатель просто возвращает ошибку после срабатывания. А теперь представьте, что этот автомат может устранять перепад напряжения до того как сработает, чтобы не было отключения электричества. Самовосстанавливающийся код в идеале работает как такой автомат.

Когда просто рестарт не вариант

Управлять современной инфраструктурой продуктов и приложениями непросто, поскольку чем больше инфраструктура, тем сложнее операционные задачи. Что-то ломается, сервисы останавливаются, кластеры падают — не говоря уже о написании документов по анализу основных причин (RCA) и руководств по устранению той же проблемы в будущем. Если продолжить добавлять мониторинг, количество предупреждений и сбоев будет расти каждый день. Чтобы обеспечить доступность продукта по мере масштабирования, либо необходимо автоматизировать, либо выходить из игры. Здесь на помощь приходит самовосстановление.


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

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

Самый простой пример автоматического исправления — перезапуск службы (скажем, apache), когда она не работает. Представьте себе автоматизированное действие, которое инициируется системой мониторинга для перезапуска службы и предотвращения простоя приложения. Кроме того, создаёт задачу и отправляет уведомление, чтобы инженер мог найти первопричину в рабочее время, и не нужно было делать это посреди ночи. Кроме того, управляемую событиями автоматизацию можно использовать для помощи в устранении неполадок, поэтому, когда пользователь получает предупреждение, оно включает связанные журналы, показатели/графики мониторинга и т. д.

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

Рекурсия и логика

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

Одним из наиболее интересных аспектов больших языковых моделей является их способность улучшать результат за счёт саморефлексии. Если отправить языковой модели её собственный ответ, затем попросить её улучшить результат или выявить ошибки, у неё будет гораздо больше шансов дать более точный результат. Если попросить её решить проблему, шаг за шагом анализируя и демонстрирую свою работу, эти системы станут более эффективными, чем те, которые настроены только для того, чтобы найти «правильный окончательный» ответ.


Пример предложенной ML правки рефакторингов, разбросанных по коду

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

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

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


GPT-4 может значительно улучшить свою производительность, разработав и выполнив тесты для оценки собственной производительности

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

IT-руководители United Airlines, Johnson & Johnson, Visa, Cardinal Health, Goldman Sachs и других компаний говорят, что они в восторге от потенциала генеративного ИИ для автоматизации определённых частей процесса написания кода и ожидают, что это приведёт к значительному повышению производительности.

Разные предприятия находятся на разных этапах оценки и развёртывания таких инструментов, как Github Copilot, принадлежащий Microsoft, а также других инструментов от Amazon, International Business Machines и стартапов, таких как Tabnine и Magic AI. Эти инструменты обычно работают, предлагая новые фрагменты кода и тесты, а также предоставляя технические рекомендации внутри уже используемых разработчиками программ написания кода.

Замена программистов?

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

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

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

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


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

Способность LLM быстро создавать большие фрагменты кода может означать, что разработчики — и даже не разработчики — будут добавлять в кодовую базу компании больше, чем в прошлом. Это создает свой собственный набор проблем. Больше кода требует большего контроля качества.

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

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

Росомаха

Отладка неисправной программы может быть неприятной, так почему бы не позволить ИИ сделать это за вас? Это то, что сделал разработчик под ником BioBootloader, создав Wolverine, программу, которая может дать программам Python «регенеративные способности». Да, прямо как супергерой из X-Men.


BioBootloader объединил Python и GPT-4 для доказательства концепции самовосстанавливающихся скриптов Python. «Запускайте с его помощью свои сценарии, и когда они падают, GPT-4 редактирует их и объясняет, что пошло не так», — написал BioBootloader в твите, который сопровождал демонстрационное видео. «Даже если у вас много ошибок, он будет многократно перезапускаться, пока всё не будет исправлено».

GPT-4 — это мультимодальная языковая модель ИИ, созданная OpenAI и выпущенная в марте, доступная подписчикам ChatGPT Plus и в форме API для бета-тестеров. Модель использует свои «знания» о миллиардах документов, книг и веб-сайтов, извлеченных из Интернета, для выполнения задач обработки текста, таких как составление текстов, языковой перевод и программирование.


В демонстрационном видео для Wolverine BioBootloader показывает параллельное окно с кодом Python слева и результатами Wolverine справа в терминале. Он загружает собственный скрипт калькулятора, в который специально добавляет несколько ошибок, а затем выполняет его.

«Он запускает его, видит сбой, но затем идёт и обращается к GPT-4, чтобы попытаться выяснить, как это исправить», — говорит он. GPT-4 возвращает результат ошибок программы, показывает изменения, которые она пытается внести, а затем перезапускает программу. Увидев новые ошибки, GPT-4 снова исправляет код, а затем работает правильно. В конце концов, исходный файл Python содержит изменения, добавленные GPT-4.

Код доступен на GitHub, и разработчик говорит, что эту технику можно применить и к другим языкам программирования. Для использования Wolverine требуется ключ API OpenAI для GPT-3.5 или GPT-4, и за использование взимается плата. Прямо сейчас API GPT 3.5 открыт для всех, у кого есть учётная запись OpenAI, но доступ к GPT-4 по-прежнему ограничен списком ожидания.

Недавно в нескольких экспериментах с участием GPT-4 в рекурсивных циклах, таких как Auto-GPT и BabyAGI, была предпринята попытка дать GPT-4 больше «агентских» возможностей, которые позволили ему запускать больше экземпляров GPT-4 для одновременного выполнения нескольких задач или действовать автономно.

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