Сосредоточьтесь на том, что действительно важно
Прямая трансляция
«Некоторые используют ИИ, чтобы писать больше кода. Я использую ИИ, чтобы сделать свой код более правильным». Закрепленный пост Предрага Груевского отлично описывает его подход к использованию ИИ в разработке на Rust. Предраг работает над перспективными системами в OpenAI, а также создал cargo-semver-checks и Trustfall. В его работе практически нет права на ошибку. Тем не менее, большую часть инженерных задач он решает с привлечением ИИ, а планка качества при этом выросла. Но как?
Мы хотели узнать, как это выглядит на практике, поэтому пригласили его на прямую трансляцию RustRover. Его выступление стало частью нашей серии трансляций «ИИ и Rust», организованной совместно с Rust Foundation, где рассматриваются реальные варианты использования, успехи и неудачи на стыке Rust и ИИ. Эта статья посвящена самым практическим советам Предрага: что проверять, как писать промпты для ИИ-агентов, как верифицировать их работу и что делать, если они ошибаются.
Вы можете посмотреть запись полной трансляции здесь 👇
Какой код на Rust заслуживает наибольшего внимания при использовании ИИ?
Прежде чем передать что-либо ИИ-агенту, оцените объем работы с точки зрения цены возможной ошибки. Не каждая строка кода одинаково важна. Некоторые строки заслуживают в 1000 раз больше внимания, чем другие. Когда вы набирали каждую строку самостоятельно, написание 10 строк небезопасного (unsafe) кода на Rust и 10 строк обычного кода занимало примерно одинаковое время. Теперь ИИ справляется с обычным кодом, так что вы можете перераспределить это время на строки, где ошибки обходятся слишком дорого.
Представьте свой код по шкале риска. На одном конце — ошибка, которую дешево обнаружить и исправить. На другом — та, что может оставаться скрытой месяцами и нанести серьезный ущерб. Вот три точки на этой шкале:
Код с низкими рисками. Хороший пример — рабочий процесс GitHub Actions. Вы знаете, что он должен делать, агент прочитал документацию, поэтому позвольте ему написать этот воркфлоу и протестировать его. Если bash-скрипт CI ломается, а вопросы безопасности при этом не затрагиваются, просто попросите агента исправить его.
Логика, от которой зависят другие люди. Инструмент cargo-semver-checks обнаруживает несовместимые изменения до того, как они попадут в релиз, и теперь он запущен в собственном CI языка Rust. За пять лет до его добавления он мог бы предотвратить около полудюжины случайных мажорных изменений в релизах Rust, потребовавших бэкпортов. С другой стороны, если его логика ошибочна и он говорит кому-то, что его изменение ломает совместимость, хотя это не так — это очень серьезная проблема. Поэтому при подготовке инструмента для CI в Rust Предраг попросил ИИ создать дополнения к стандартной библиотеке, которые вызывали бы ложные срабатывания. Такая проверка выявила ложные срабатывания, которые могли бы затронуть и обычные библиотеки. Код вроде этого заслуживает гораздо больше вашего времени.
Небезопасный (unsafe) код. Ошибка здесь может означать нарушение безопасности памяти, проблемы с безопасностью или «хайзенбаг» (Heisenbug), который проявляется один раз на миллиард. Это звучит как редкость, пока вы не запустите код в дата-центре. Там повреждение данных в 0,0000001% случаев означает, что это происходит постоянно. В одном реальном случае проблема подобного рода была вызвана всего 20 строками в блоке unsafe. Именно этот код стоит читать построчно или даже писать вручную. Четыре часа — вполне оправданная цена за 100 строк небезопасного кода.
Как составлять промпты для ИИ-агентов, чтобы писать надежный код на Rust?
Опишите, что именно вам нужно, как это должно быть сделано и что означает «достаточно хорошо». Не ограничивайтесь фразой «пожалуйста, напишите эти десять строк кода». Одна задача может потреблять миллиарды токенов, создавая гораздо больше кода, чем вы когда-либо прочтете, поэтому вся инженерная работа должна происходить на этапе промпта. Чтобы написать хороший промпт, нужно сделать три вещи:
Набросайте дизайн
Дайте агенту вводную так, как будто вы объясняете задачу очень квалифицированному и старающемуся коллеге, у которого нет вашего контекста. Возле маркерной доски вы бы нарисовали квадратики и стрелки. Вы бы объяснили, как работают типы, какие функции и поля вам нужны и какие данные куда передаются. Это те самые несущие элементы. Поместите их в промпт и позвольте агенту развить их.
Сделайте то же самое для тестов. Имена переменных внутри тест-кейса гораздо менее важны, чем структура самого теста. Покрывают ли тесты все основные сценарии? Происходит ли правильное действие в нужный момент времени? Опишите эту структуру в промпте.
Укажите, какие допущения допустимы
Если вы скажете модели быть тщательной и тестировать все подряд, вы получите тесты на падение метеорита во время отключения электроэнергии. Для программного обеспечения самолетов это правильный уровень заботы. Для большинства кода — это пустая трата усилий. Подскажите агенту, какие допущения допустимы, и попросите его проверить, может ли сценарий произойти на самом деле.
Будьте точны
На вопросы о Rust часто бывают условные ответы. Спросите, является ли конкретное изменение ломающим совместимость, и точным ответом может быть: «да, с шестью оговорками». Это зависит от того, существовал ли трейт (trait) раньше, был ли он реализован для уже существовавшего типа, был ли этот трейт закрытым (sealed) и так далее. Ваши промпты должны обладать такой же степенью точности в отношении того, что вам нужно, а что нет.
Все это требует времени, но оно того стоит. Чтобы найти способы ускорения в компиляторе Rust и стандартной библиотеке, Предраг потратил 45 минут на написание одного промпта для Codex. Он указал агенту, где искать: «горячий» код, который никто давно не оптимизировал. Он указал, каким изменениям отдать предпочтение: небольшим, которые повторяют идеи, уже успешно сработавшие в других частях проекта. И он описал, как проводить бенчмаркинг: чередующиеся прогоны с улучшением среднего геометрического как минимум на 1%.
В одном PR Предраг удалил всего одну строку в новом решателе трейтов (trait solver). Эта строка заново вычисляла то, что код уже посчитал на 40 строк раньше. Ее удаление ускорило новый решатель трейтов почти на 7,5%. Как только кто-то указывает на это, все соглашаются, что строку нужно убрать, но ее поиск потребовал больших инженерных усилий и размышлений.
«Очень легко воспринимать ИИ просто как более быструю лошадь. Это пример того, что он не просто более быстрая лошадь. В принципе, всю эту работу мы могли бы проделать вручную. Просто на поиск этих оптимизаций ушло бы пять лет».
«Очень легко воспринимать ИИ просто как более быструю лошадь. Это пример того, что он не просто более быструя лошадь. В принципе, всю эту работу мы могли бы проделать вручную. Просто на поиск этих оптимизаций ушло бы пять лет».
Предраг Груевский, инженер-программист команды Frontier Systems в OpenAI
Как верифицировать сгенерированный ИИ код на Rust?
Сосредоточьте свое внимание на дизайне и на том, как тестируется код. Как только агенты начали надежно следовать инструкциям, чтение каждой строки перестало приносить пользу Предрагу. Поэтому он перешел к вопросам более высокого уровня. Хорошо ли спроектирован API? Тестируем ли мы его всеми правильными способами?
Почему продвинутое тестирование внезапно стало практичным
Покрытие кода, покрытие ветвлений, мутационное тестирование и детерминированное моделирование были доступны всегда, но они требовали слишком больших усилий для регулярного использования. Агент, который надежно следует процессу, все меняет. Опишите процесс в промпте, а всю тяжелую работу выполнит агент.
Процесс верификации, который можно поручить агенту
Допустим, вы создаете компонент с конечным автоматом внутри. Каждый шаг должен выявлять то, что мог пропустить предыдущий:
- Протестируйте структуру. Набор тестов, проверяющий каждое состояние и каждый переход, показывает, что все они ведут себя корректно.
- Проверяйте покрытие для важной логики. Инструмент покрытия показывает, какой код выполняют тесты. Убедитесь, что в него включена вся нетривиальная логика.
- Проверяйте, что тесты ловят баги. Простое выполнение строки кода не доказывает, что тесты проверяют её работу. cargo-mutants намеренно внедряет баги в ваш код и проверяет, сможет ли какой-либо тест их поймать. Каждый выживший мутант — это повод выяснить, не пропустили ли тесты важное поведение. Добавляйте тест-кейсы до тех пор, пока код не будет зафиксирован во всех нужных местах.
- Запускайте небезопасный код под управлением Miri и санитайзеров. Поручите агенту продумать важные сценарии и протестировать их в Miri и санитайзерах вроде ASan. Эти инструменты работают в паре с тщательным анализом инвариантов безопасности, которые по-прежнему заслуживают вашего пристального внимания.
В качестве подсказки этот процесс может выглядеть следующим образом:
Что делать, если ИИ-агент ошибается?
Рано или поздно агент выдаст результат, который вам не понравится. Подойдите к проблеме с пониманием. Разберитесь, почему агент выбрал именно такой подход и что ему нужно было знать, чтобы принять другое решение. Если вы не можете понять это сами, спросите его.
Затем добавьте ответ в свою конфигурацию. Если агент продолжает тестировать нереалистичные сбои, например падение метеорита, добавьте строчку в файл инструкций вашего агента (например, AGENTS.md). Скажите ему делать прагматичные допущения относительно сбоев в реальном мире. Вы также можете обновить промпт персонализации или скорректировать свои навыки. В следующий раз агент примет более правильное решение.
Никто не рождается мастером работы с ИИ-инструментами. Чтобы научиться хорошо ими пользоваться, могут потребоваться миллиарды токенов, и все мы еще учимся.
Как узнать, достаточно ли хорош созданный ИИ код для релиза?
Это зависит от того, что вы создаете. Вайб-кодинг вполне разумен для таких задач, как прототипирование, когда вам просто нужно узнать, работает ли подход вообще, и он также хорош в приложениях, которые вы создаете для себя. Если штука, которая включает у вас свет в 7 вечера, сломается — так сломается. Для этого вайб-кодинг подходит отлично.
Продакшн-код требует более высоких стандартов. Используйте ИИ, чтобы достичь уровня, которого вы не смогли бы достичь в одиночку.
Чтобы добиться этого, идите от обратного. Подумайте, как бы вы убедили кого-то еще в том, что созданное вами приложение или код хороши, даже если этот человек не разбирается в вашей предметной области. При работе над компилятором Rust доказательством служили несколько строк кода, более быстрые бенчмарки, успешно пройденный набор тестов и изменения, которые любой может прочитать и понять. Как только вы поймете, как выглядит доказательство, настройте свой рабочий процесс так, чтобы его получать. Вы довольно быстро поймете, что тем человеком, которого вы убеждаете, можете быть вы сами.
Каждый фрагмент кода, который вы отправляете в репозиторий, несет вашу подпись. Он буквально поступает из вашего Git-клиента. Используйте ИИ, чтобы убедиться, что это код, которым вы будете гордиться в реальном мире.
Хотите больше? Посмотрите полную беседу выше. Чтобы узнать о другой стороне Rust и ИИ, прочитайте нашу статью о создании LLM-приложений с помощью Rig.
Полезен ли ИИ для разработки на Rust?
Да, особенно когда вы используете его для повышения планки качества, а не только для написания большего объема кода. Агент делает практичными методы, которые раньше требовали слишком много усилий, такие как мутационное тестирование, полное покрытие состояний автоматов и проверка небезопасного кода под Miri. Они также могут изучить историю Git, чтобы найти «горячий» код, который никто давно не оптимизировал.
Нужно ли читать каждую строку сгенерированного ИИ кода на Rust?
Нет. Соотносите уровень проверки с рисками. Для кода с низкими ставками, такого как скрипт CI, обычно достаточно протестировать его работоспособность. Логика, на которую полагаются другие люди, заслуживает гораздо большего внимания, а небезопасный код на Rust стоит читать по строчкам или писать вручную.
Могут ли ИИ-агенты кодирования писать небезопасный Rust?
Могут, но небезопасный код на Rust требует наибольшей осторожности среди всего кода, с которым вы работаете. Поручите агенту продумать важные сценарии и протестировать их в Miri и санитайзерах вроде ASan, а сами проверьте инварианты безопасности.
