Будущее Ruby on Rails в эпоху искусственного интеллекта

Искусственный интеллект (ИИ) меняет способы создания, отладки и оптимизации кода, и все это происходит ошеломляющими темпами. Будучи разработчиком на Ruby on Rails со стажем, я с воодушевлением участвую в этом процессе развития: у меня есть свой стартап, я пишу новую книгу и веду соответствующие проекты с открытым исходным кодом.

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

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

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

Новая парадигма: разработка на основе промптов

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

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

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

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

Не позволяй пользователю изменять свою учетную запись или добавлять
нового помощника на основе ИИ, если статус подписки учетной записи не активен.

Обязательно уведомляй владельца учетной записи о результате запроса на изменение,
независимо от того, был ли он успешным.

В конце всегда вызывай функцию 'finished', чтобы сохранить
состояние запроса на изменение как завершенное.

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

Проблемы и возможности

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

Решающим фактором оказываются потенциальные преимущества: более быстрые циклы разработки, меньшее количество ошибок, более удобные для сопровождения и самодокументирующиеся кодовые базы. А благодаря выразительности и читабельности Ruby у нас есть возможность создавать управляемые промптами DSL (предметно-ориентированные языки), с которыми приятно работать. Это будущее, в котором роль разработчика переходит от низкоуровневого генератора кода к высокоуровневому составителю промптов.

История декларативного программирования и BDD

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

  • HYPERCARD  —  это интерактивная система, созданная в виде уникального информационного центра. В ней можно искать и хранить текст, пользовательскую графику и оцифрованные фотографии. В отличие от книги, которая имеет линейный формат (вы перелистываете страницу за страницей), интерактивные возможности HyperCard позволяют связать между собой любые фрагменты информации. Моделируя наши мыслительные процессы (ассоциации), HyperCard позволяет найти то, что вам нужно знать, самым простым и, следовательно, быстрым способом. Отрывок из статьи в журнале Music Technology, январь 1988 года.

Так, в 1980-х годах был создан язык HyperTalk, используемый в визуальной среде HyperCard компании Apple. Он должен был сделать программирование более доступным за счет использования команд, напоминающих английский язык. Совсем недавно предпринимались похожие попытки: достаточно вспомнить Inform 7  —  язык программирования для создания интерактивной художественной литературы, использующий подмножество английской грамматики.

  • Inform  —  это язык программирования для создания интерактивной художественной литературы, использующий синтаксис естественного языка. Ориентируясь на естественный язык и опираясь на идеи лингвистики и корректного программирования, Inform широко применяется как средство создания литературных произведений, как инструмент прототипирования в игровой индустрии, а также в образовании  —  как на школьном, так и на университетском уровне. В последнем случае Inform часто используется в качестве материала для курсов по цифровому повествованию. Несколько раз он входил в топ-100 самых влиятельных языков программирования по индексу TIOBE. Inform был создан в апреле 2006 года, а в апреле 2022 года стал языком с открытым исходным кодом.

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

В середине 2000-х годов начал набирать обороты новый подход к разработке программного обеспечения: поведенческая разработка (Behavior-Driven Development, BDD). BDD возникла как эволюция разработки посредством тестирования  —  Test-Driven Development (TDD), но с одним ключевым отличием: вместо того чтобы фокусироваться на тестировании отдельных единиц кода, BDD сосредоточилась на определении желаемого поведения системы с помощью языка, понятного всем заинтересованным сторонам, включая нетехнических специалистов.

Я и мои коллеги из Thoughtworks были воодушевлены концепцией BDD, и этот энтузиазм привел к созданию таких инструментов, как RSpec, Cucumber и Pickle, которые позволили разработчикам определять поведение приложения с помощью структурированной формы естественного языка. Синтаксис Gherkin от моего друга Аслака Хеллесоя напоминает английские предложения, разбитые на отдельные сценарии и шаги. Например:

Given I am on the home page
When I click on the "Login" button
Then I should see the login form

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

Такой подход оказал значительное влияние на процесс разработки, особенно в сообществе Ruby, где он зародился. Он позволил командам преодолеть разрыв между бизнес-требованиями и технической реализацией. Бизнес-аналитики, менеджеры по продукции и даже клиенты могли участвовать в написании этих сценариев, обеспечивая команде разработчиков общее и четкое понимание того, что нужно было создать.

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

Проблема заключалась в следующем: хотя BDD и такие инструменты, как Cucumber и Pickle, представляют собой значительный шаг на пути к использованию естественного языка в разработке программного обеспечения, они по-прежнему требуют определенной структуры и конкретики в написании сценариев. Также следует помнить о расширенной реализации шагов:

Given("I have entered {int} into the calculator") do |number|
@calculator = Calculator.new if @calculator.nil?
@calculator.enter(number)
end

When("I press add") do
@result = @calculator.add
end

Then("the result should be {int} on the screen") do |expected|
expect(@result).to eq(expected)
end

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

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

Человек: Когда пользователь нажимает на кнопку входа, он должен попасть на страницу входа, где может ввести свое имя пользователя и пароль. Если пользователь вводит правильные данные, он должен войти в систему и его следует перенаправить на его панель управления. Если пользователь вводит неверные данные, он должен увидеть сообщение об ошибке.

ИИ: Поддерживаем ли мы вход на основе стандарта Oauth?

Человек: Конечно, но пока только для Google.

ИИ: И как мне его оформить по стилю?

Человек: Покажи мне несколько вариантов, основанных на нашем типичном гайде по стилизации.

И так далее, и так далее…

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

Несомненно, инструменты типа Cucumber и Pickle были новаторскими в свое время и широко используются до сих пор. И все же в будущем разработка ПО на основе искусственного интеллекта обещает вывести концепцию программирования на естественном языке на совершенно новый уровень. Это захватывающая перспектива. Сообщество Ruby, имея за плечами опыт внедрения инновационных подходов к разработке ПО, имеет все возможности для изучения и реализации такого потенциала. Мы практически стояли у истоков BDD.

“Вплетение” ИИ в среду Ruby и Rails

На данный момент я работаю с Ruby on Rails почти каждый день на протяжении почти 20 лет. Поэтому считаю, что плотное внедрение ИИ в систему Ruby и Rails на фундаментальном уровне должно стать неотъемлемым шагом на пути к волшебному будущему, описанному выше. В конечном итоге LLM можно будет использовать в самом интерпретаторе Ruby для создания потрясающего опыта  —  “умного” определения имен методов и аргументов, гладкого соединения разрозненных сервисов и API, а также оптимизации кода в реальном времени. Но, прежде всего, я планирую усилить интеграцию ИИ в строительные блоки, которые использую для создания приложений на Ruby on Rails.

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

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

Прокладываем путь в будущее

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

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

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

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

Давайте строить будущее вместе

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

Читайте также:

Читайте нас в Telegram, VK и Дзен


Перевод статьи Obie Fernandez: The Future of Ruby and Rails in the Age of AI

Предыдущая статьяКак компания Airbnb стала лидером в UX дизайне
Следующая статьяТоп-10 заданий по написанию кода для собеседования по React.js в 2024 году