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

Разработчик просит ассистента написать функцию, которая проверяет, может ли пользователь загрузить отчет. Код компилируется. Тест "счастливого пути" проходит успешно. Запрос на слияние выглядит аккуратно. Две недели спустя коллега замечает, что функция проверяет, вошел ли пользователь в систему, но никогда не проверяет, принадлежит ли ему отчет.

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

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

Что такое обучение анализу кода, сгенерированного искусственным интеллектом?

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

Интересные факты

1. Опишите проблему с производительностью.

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

Исследование показывает, почему это требует целенаправленной практики. В исследовании GitHub Copilot Пирс и его коллеги сгенерировали 1,689 программ в 89 сценариях, выбранных для известных типов уязвимостей, и обнаружили, что около 40 процентов из них были уязвимы.Пирс и коллеги, 2021Это был один из первых инструментов и конкретная серия сценариев, поэтому не следует рассматривать эту цифру как показатель для современных помощников. В отдельном исследовании пользователям предлагалось написать код с использованием и без использования ИИ-помощника. Те, кто использовал помощника, написали значительно менее безопасный код и с большей вероятностью считали свой код безопасным.Перри и коллеги, 2023В том же исследовании было установлено, что участники, которые меньше доверяли помощнику и больше взаимодействовали с его подсказками, проявляли меньше уязвимостей.

Далее следуют два урока по разработке учебных материалов. Для получения правдоподобных результатов необходим активный критик. А уверенность не является доказательством, поэтому задание должно предполагать проверку, а не выражение мнения.

Сформулируйте описание производительности в одном предложении и попросите руководителя инженерного отдела проверить его: «При внесении изменений разработчик перечисляет риски безопасности, параллельного выполнения и эффективности, которые он видит, и для каждого из них описывает или пишет тест, который бы его продемонстрировал».

2. Диагностика пробелов в знаниях и контексте.

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

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

3. Подготовка и практика проектирования

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

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

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

Обратная связь. Свяжите это с принятыми решениями, а не с общим баллом. Фраза "Вы отметили цикл, но не гонку на общем счетчике, и ваш тест не обнаружил бы ее, потому что он выполняет запросы по одному" полезнее, чем "Найдено 2 из 3".

Ввод данных в режиме реального времени или асинхронная проверка? Ввод данных в режиме реального времени наиболее эффективен, когда риск неоднозначен, и разработчики учатся, слушая объяснения старшего инженера о причинах, по которым они могли бы заблокировать слияние. Асинхронного анализа достаточно для сравнения результатов, полученных разработчиком, с аннотированным экспертным обзором. Многие команды используют оба подхода: сначала самостоятельная подготовка, а затем обсуждение сложных случаев под руководством модератора.

4. Проработайте реалистичный пример.

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

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

Задача. Разработчик перечисляет каждый выявленный им риск, ранжирует их и описывает тест, который подтвердил бы каждый из них.

Первая попытка. «Всё выглядит нормально. Запрос параметризован, и тест пройден». Разработчик воспринял пройденный тест как доказательство и не поинтересовался, что именно тест не охватывает.

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

Более убедительная попытка. «Проверка сессии доказывает, кто звонит, а не то, что счет принадлежит звонящему. Я бы написал тест, в котором клиент А запрашивает идентификатор счета клиента Б и ожидает отказа. Счетчик увеличивается без синхронизации, поэтому два запроса одновременно могут привести к потере обновления. Я бы запустил параллельный тест и сравнил количество запросов. Сам запрос параметризован, поэтому я бы не стал тратить на него время». Обратите внимание, что в этом ответе риски ранжированы и каждому соответствует свой тест.

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

5. Оценить возможности и спланировать передачу.

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

Критерии оценки: 0 означает отсутствие или неподтвержденность, 1 — частичное выполнение с существенными упущениями, 2 — полное выполнение и обоснование в соответствии с согласованными критериями. Критические ошибки следует определять отдельно, например, утверждение кода с незащищенным путем доступа, чтобы общая оценка не могла скрыть такую ​​ошибку. Данная рубрика является предложением, а не утвержденным стандартом готовности: адаптируйте ее совместно с руководителем инженерного отдела и проведите пилотное тестирование. Наше руководство по разработка интерактивных методов обучения с полезной обратной связью показывает, как писать отзывы, которые связаны с принятыми решениями.

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

Где интерактивная доставка помогает

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

Измерьте, что изменилось.

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

Ограничения, которые могут остаться

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

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

Часто задаваемые вопросы

Что такое обучение анализу кода, сгенерированного искусственным интеллектом?

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

Является ли сгенерированный код менее безопасным, чем код, написанный человеком?

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

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

Предложите выполнить новое задание по написанию кода и оцените качество проверки и выявление дефектов в соответствии с согласованными критериями. Тест по правилам безопасного кодирования подтверждает только предварительные знания.

Для обучения вам нужна песочница для кода?

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

Когда начать

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

Чтобы узнать, как можно провести аудит в режиме реального времени с вашей командой и затем использовать его в удобном для вас темпе, ознакомьтесь с материалами AhaSlides.