Единица 1 / 12

Искусственный интеллект для команд разработчиков программного обеспечения: рабочая модель и ограничения

Прибыль:

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

День разработчика программного обеспечения редко тратится на «написание кода с нуля». Реальное время; Чтение кода, написанного кем-то другим, попытка воспроизвести ошибку, сканирование журнала (строки журнала, создаваемые приложением во время работы), написание тестов, написание PR (pull request — запрос на слияние, в котором изменение кода отправляется на рассмотрение команды), объяснение и обновление документации. Искусственный интеллект (ИИ) — это множитель скорости, который может затронуть почти все эти невидимые рабочие места. Но первое условие безопасного его использования – правильно понимать, что это такое, а что нет.

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

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

Что на самом деле делает помощник по кодированию?

Большинство помощников по программированию построены на большой языковой модели (LLM — ИИ, обученный на огромных объемах текста и кода, который предсказывает следующий наиболее вероятный «кусок»). Модель не «понимает» код, как человек; Он генерирует наиболее вероятное продолжение предоставленного вами контекста на основе шаблонов, которые он извлекает из огромного количества примеров. Этот, казалось бы, простой механизм на практике дает удивительно хорошие результаты, поскольку большая часть программного обеспечения состоит из повторяющихся шаблонов: HTTP-запрос, цикл, проверка на нулевое значение, тестовый шаблон.

Здесь решающее значение имеют три термина. Токен — это наименьшая единица, которую обрабатывает модель, разделяя текст; Это примерно несколько букв или часть слова. Контекстное окно — это количество токенов, которые модель может «видеть» одновременно; Ваш код, сообщение об ошибке и инструкция должны поместиться в это окно. Подсказка — это все инструкции и контекст, которые вы даете модели. Качество получаемого вами результата напрямую зависит от этих двух факторов: чем лучше контекст и более четкие инструкции вы дадите модели, тем лучший результат вы получите. Плохие входные данные приводят к плохим результатам, даже если это умная модель — классическое правило программного обеспечения «мусор на входе — мусор на выходе» также применимо к ИИ.

Карта сильных и слабых сторон

Чтобы направить ИИ на правильную работу, необходимо знать, где он блестит, а где спотыкается. Запоминание этой карты будет заставлять вас с каждой следующей миссией задаваться вопросом: «Должен ли я поручить эту работу ИИ или сделать ее самому?» Это позволяет ответить на вопрос за считанные секунды.

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

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

Тип миссии

Роль ИИ

роль мужчины

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

производит проект

Адаптируется, отзывы

Описание кода

Дает краткое резюме

Проверяет критическую часть кода

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

Случай предполагает

Подтверждает покрытие и точность

Критическая для безопасности логика

полезная идея

Решения и ответственность полностью лежат на людях.

Использование API/библиотеки

Генерирует образец

Проверяет существование и версию

архитектурное решение

Виды вариантов

Выбирает и защищает, зная контекст

Шаг за шагом: основной рабочий цикл

  1. Уточните задачу. Если вы не можете написать то, что хотите, в одном предложении, то и модель не сможет. Чем раньше неопределенность проникает во входные данные, тем больше она растет в выходных данных.
  2. Дайте контекст. Добавьте в приглашение соответствующий код, полное сообщение об ошибке, версию языка/фреймворка и ограничения. Не говорите «исправьте это», скажите «Python 3.11, FastAPI 0.110; эта функция выдает ошибку 500, она взрывается, когда тело запроса пусто».
  3. Роль и формат наложения. Структура типа «Вы старший разработчик Go; просто дайте код и обоснование в двух предложениях» фокусирует результат.
  4. Просите маленькое. Разбейте задачу на этапы, а не на один гигантский запрос; Проверяйте каждый шаг отдельно. Крупные изменения рискованны, поскольку их трудно проверить и они склонны к сокрытию ошибок.
  5. Проверять. Запустите, протестируйте, прочитайте визуально. Непроверенный код ИИ — это «набросок», а не «решение». Это самый необсуждаемый шаг цикла.

Три мини-кейса

Случай 1. Экономия времени реальна, но скромна. Когда команда скелетонировала новые конечные точки CRUD (создание-чтение-обновление-удаление) с помощью ИИ, время первого черновика сократилось примерно с 40 минут до 8 минут. Однако с учетом обзора и тестирования общее время составило 25 минут; так что реальный выигрыш составляет от 40 до 25, около 38%. Этот темп, измеряемый вместо ожидания «мы ускорились в 10 раз», является устойчивым достижением.

Случай 2. Галлюцинации обходятся дорого. Разработчик использовал предложенный ИИ вызов Request.get_json() без проверки; Не было такого метода (а именно response.json()). 20 минут было потеряно, когда код не компилировался. Простой вопрос: «действительно ли существует этот метод?» проверка сбрасывает потерю.

Случай 3. Хороший контекст удваивает результат. Для той же самой ошибки один разработчик просто написал «Я получаю сообщение об ошибке», а другой добавил полную трассировку стека, версию и образец входных данных. Последний получил правильное решение с первой попытки; Первый потратил три хода. Разница была не в модели, а во вводе.

Четыре копируемых шаблона

Мощная подсказка общего назначения при запуске:

Роль: вы опытный {{language}} разработчик. Задача: {{what_want}} Контекст: фреймворк/версия: {{framework_and_version}} ограничения: {{правила производительности, стиля, зависимостей}} правила: не используйте несуществующую библиотеку/функцию; Если вы не уверены, отметьте это как «проверить». - Сначала дайте краткий план, затем код, затем 2 предложения-обоснование. - Создание тестируемого рабочего кода.

Чтобы отфильтровать неопределенность обратно в модель:

Прежде чем решать приведенную ниже задачу, перечислите МИНИМАЛЬНО 3 пункта, которые кажутся вам пропущенными или неясными, в виде вопросов. НЕ пишите код, пока я не отвечу. Задача: {{task}}

Чтобы выполнить самопроверку вывода:

Вы создали следующий код. Теперь измените свою роль и оцените этот код: — Перечислите 3 случая (крайних случая), которые могут не работать. — Есть ли какие-нибудь API/функции, которые вы могли бы придумать? Отметить.- Укажите исправленную версию.Код:{{code}}

Чтобы разбить решение на варианты:

Предложите 2–3 подхода к решению {{проблемы}}. По каждому: краткое описание, плюс/минус, когда выбирать. Дайте в табличной форме. НЕ выбирайте за меня; просто уточните этот вариант.

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

Слабое: «Исправьте ошибку в этом коде». (Какая ошибка? Какой язык? Каково ожидаемое поведение?)
Сильный: «Python 3.11/FastAPI 0.110. Следующая конечная точка возвращает 500 с KeyError, когда тело запроса становится пустым; я хочу, чтобы она возвращала 400 и значимое сообщение в пустом теле. Сначала объясните причину, затем укажите исправленную функцию, затем напишите тест для этого сценария. [код]»

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

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

  • Доверие без проверки. Самая распространенная и самая дорогая ошибка. Не говорите «решено», пока код не будет скомпилирован и протестирован.
  • Задавать вопросы без контекста. Ответ без версии, текста ошибки и ограничений является общим и часто неверным.
  • Одна огромная просьба. Отсутствие возможности одновременно запросить и просмотреть производство из 300 линий делает ошибки незаметными.
  • Принятие уверенности модели в качестве доказательства. ИИ может уверенно сказать что-то не так; Тон не является показателем точности.
  • Случайная вставка секрета компании. Закрытые ключи, данные клиентов или закрытый исходный код не следует вводить в неутвержденные инструменты (мы углубимся в эту тему в модуле 10).
Совет: относитесь к каждому результату ИИ как к «это черновик». Эта единственная умственная привычка устраняет большинство рисков, с которыми вы столкнетесь на протяжении всего модуля.

В заключение

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

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

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

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

  • [ ] Я понял, что LLM создает шаблоны, а не «понимает» код.
  • [ ] Я могу объяснить понятия токена, контекстного окна и приглашения в одном предложении.
  • [ ] Я могу различать типы задач, в которых ИИ силен и слаб.
  • [ ] Я знаю, что такое галлюцинация, и единственное противоядие — это проверка.
  • [ ] Я адаптировал цикл «предложить, произвести, проверить» под свою задачу.
  • [ ] Я могу показать разницу между сильной и слабой подсказкой на конкретном примере.