Единица 1 / 12

Введение в дисциплину искусственного интеллекта и верификации в компьютерной инженерии

Прибыль:

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

Если посмотреть на день компьютерного инженера, то в большинстве команд картина схожая: понимание бизнес-запроса, проектирование, написание кода, чтение чужого кода, отладка (процесс выяснения, почему программа работает некорректно, и ее исправление), написание тестов, подготовка документации, ревью кода, посещение совещаний. Другими словами, время, посвященное реальному «инженерному суждению», то есть тому, является ли решение правильным, безопасным и устойчивым, сводится к повторяющейся работе. Именно здесь в игру вступает искусственный интеллект (сокращенно ИИ; программное обеспечение, которое работает с текстом и кодом с помощью большой языковой модели). ИИ не принимает решение за вас; Он подготавливает вас к принятию решения, создает скелет кода, сужает круг ошибок и предоставляет вам проработанный черновик. В этом модуле мы будем позиционировать ИИ не как «автоматического программиста», а как дисциплинированного партнера по парному программированию, результаты которого каждый раз компилируются, тестируются и проверяются.

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

Концепции: Галлюцинация: убедительное создание ИИ метода, библиотеки, API или поведения, которого на самом деле не существует. Контекст: данные, которые вы передаете ИИ (код, сообщение об ошибке, требование, ограничения). Верификация: Независимая проверка вывода (компиляция, тестирование, документация). Эти три концепции составляют основу всего модуля.

В каких сферах бизнеса используется ИИ-акселератор, в каких сферах это рискованно?

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

тип бизнеса

Вклад ИИ

Роль инженера

Скелет кода/шаблон

Быстрое создание повторяющейся структуры

Логический контроль и контроль состояния фронтов

отладка

Гипотеза и список возможных причин

Воспроизведение и подтверждение первопричины

написание тестов

Тестовый проект и создание сценария

Значимая проверка утверждений и области видимости

рефакторинг

Предложение по рефакторингу

Поддержание поведения посредством тестирования

Документация

Первый проект и структура

Проверка правильности кода

Архитектурное/безопасное решение

Список вариантов, плюсы и минусы

Окончательное решение и ответственность

Правило простое: риск выхода ИИ равен ущербу, который он понесет, если этот выход допустит ошибку. Неправильное предложение имени переменной безвредно; Неправильная аутентификация (проверка того, что пользователь действительно тот, за кого себя выдает) делает уязвимой всю систему. Итак, первый вопрос, который следует задать перед использованием вывода: «Что произойдет, если это неправильно, и кто это заметит и когда?»

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

Решения, которые следует оставить за инженером

Некоторые решения никогда не должны быть полностью автоматизированы; несет в себе технические, юридические и этические риски:

  • Утверждение в производстве: Выпуск кода в производство и ответственность за это.
  • Безопасность и архитектура: дорогостоящие решения, такие как аутентификация, авторизация, шифрование и модель данных.
  • Лицензия и авторские права: возможность использования созданного кода в коммерческом продукте и соответствие лицензии.
  • Работа с конфиденциальными данными: Операции с данными клиентов, секретами исходного кода и идентификационной информацией.
Предупреждение: даже если ИИ говорит «этот код безопасен и готов к производству», принимать это без тестирования безопасности, проверки кода и проверки под реальной нагрузкой недопустимо. В критически важных для безопасности работах результаты ИИ никогда не заменяют одобрение компетентного инженера; Любые выходные данные, которые приводят к принятию решения, должны быть независимо проверены и одобрены уполномоченным инженером перед внедрением.

Дисциплина проверки: трехуровневый контроль

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

  1. Компиляция и статическая проверка: действительно ли код компилируется/запускается? Есть ли ошибки типов, неиспользуемые переменные, несуществующие API? Что говорит инструмент статического анализа (инструмент, который проверяет код, не запуская его)?
  2. Независимое воспроизведение (тестирование). Запустите код с небольшими известными входными данными и посмотрите, получите ли вы ожидаемый результат. Попробуйте крайние случаи (нулевой, нулевой, отрицательный, огромный).
  3. Проверка источника: каждый API, версия библиотеки и языковая функция, которые использует ИИ, должны быть проверены на основе официальной документации.

Подсказка для проверки (облегчает проверку вывода): «Перечислите ВСЕ внешние библиотеки, методы и языковые функции, которые вы используете в своем коде. Для каждой укажите, в какой версии она доступна, и пометьте ее как «необходимо проверить из документации». Не создавайте никаких API-интерфейсов, в которых вы не уверены; если вы не уверены, четко напишите «не уверен». Также перечислите все крайние случаи, которые вы не рассмотрели, в отдельный список».

Критикуйте подсказку к своему собственному коду: «Посмотрите критически на код, который вы только что написали, как старший инженер, который вас нанял. Дайте конкретные пункты под этими тремя заголовками: (1) логические ошибки/крайние случаи, (2) риски безопасности, (3) проблемы с производительностью или читабельностью. Для каждого элемента напишите «почему возникла проблема» и «предлагаемое решение». Если проблемы нет, скажите «Я не смог найти проблему»; не пытайтесь приукрасить ее».

Слабая подсказка/Сильная подсказка

СЛАБЫЙ: «Напишите мне функцию аутентификации пользователя». (Результат: неясно, какой язык, какое правило, какое поведение при ошибке; общий код, часто небезопасный или вне контекста.) СИЛЬНЫЙ: «Напишите функцию проверки электронной почты для Python 3.11. пусто, без '@', двойное '@', содержит только пробелы».

Разница в контексте. Мощная подсказка; Он включает в себя язык, версию, контракт ввода-вывода, ограничения и ожидания теста. Эта единственная дисциплина значительно снижает риск галлюцинаций и небезопасного кода.

Мини-кейсы

Случай 1 — Надуманный метод. Разработчик слышит от ИИ, что в библиотеке дат есть метод date.addBusinessDays(5), и он уверенно ему объясняет. Заглянув в документацию, он видит, что такого метода нет, правильный путь — ручной цикл. Галлюцинация фиксируется до того, как она будет запущена в производство, с 10-минутной проверкой.

Случай 2 — Потеря пограничного состояния. ИИ производит функцию «вычисления среднего значения»; Он работает при тестировании с 1000 строками данных. Однако, когда список пуст, он дает ошибку деления на ноль. Поскольку инженер добавил пустой входной тест, он видит и исправляет ошибку до того, как она будет запущена. Проверка состояния одного фронта предотвращает подачу производственного сигнала тревоги в 3 часа ночи.

Случай 3 — Риск конфиденциальности. Эксперт собирается вставить файл с реальной строкой подключения к базе данных и ключом API в общедоступный инструмент. Помнит политику учреждения; Он заменяет секреты на <УДАЛЕНО>, сокращает код до репрезентативного примера и запрашивает его. Таким образом, помощь ему оказывается в течение 5 минут, но данные его личности не выходят наружу.

Принцип работы с секретным кодом и идентификационной информацией

Самая чувствительная часть программного обеспечения; секреты исходного кода, идентификационная информация (ключ API, пароль, токен) и клиентские/личные данные. Основной принцип: наведите порядок, прежде чем делиться, задавайте только суть проблемы, по возможности с репрезентативным примером.

Шаблон анонимного запроса: «В следующей функции произошла ошибка. Я заменил фактическую бизнес-логику и скрытые константы репрезентативными значениями (ключ API, имена таблиц, общие имена полей). Проблема: я получаю ошибку Y на входе X. Просто найдите логическую ошибку в этом репрезентативном коде и объясните исправленную версию. [репрезентативный код]»

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

Распространенные ошибки

  • Использование вывода без компиляции/тестирования. «ИИ написал» не является оправданием; Каждый фрагмент кода проверяется при его запуске.
  • Создание запросов без контекста. Если язык, версия, ввод-вывод и ограничения не указаны, код становится универсальным и часто небезопасным.
  • Делимся конфиденциальной информацией, не задумываясь. Ключ API, пароль и данные клиента не должны разглашаться без очистки.
  • Путают точный язык с точностью. Чем увереннее говорит ИИ, тем осторожнее вам следует быть; Уверенный тон не является доказательством.
  • Делегирование принятия решения ИИ. Решение о запуске в производство, безопасности и архитектуре остается за инженером; ИИ только производит материалы.

В заключение

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

Задача приложения

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

контрольный список

  • [ ] Я добавил в приглашение язык, версию и контракт ввода-вывода.
  • [ ] Я написал: «Не выдумывай, скажи мне, если не уверен» и ограничение области действия.
  • [ ] Я скомпилировал/запустил код, проверил наличие статических предупреждений.
  • [ ] Я тестировал как минимум три крайних случая.
  • [ ] Я проверил используемые API из официальной документации.
  • [ ] Я удалил все секретные коды/учетные данные или использовал корпоративный инструмент.
  • [ ] Я подтвердил, что решение о запуске в производство и безопасности остаётся за человеком.