Влияние LLM на людей, процессы, продукты и общество в разработке ПО: исследование с ранними пользователями

В начале марта вышло любопытное исследование от PhD студентов in Computer Science университета Северной Каролины: «Влияние больших языковых моделей на людей, процессы, продукты и общество в разработке программного обеспечения: комплексное исследование с ранними пользователями».

Исследование базируется на 16 глубинных интервью разработчиков – ранних адептов LLM. Структура организована вокруг четырёх измерений – разработчики, процессы, продукты и общество и посвященно влиянию больших языковых моделей (LLMs) — таких как ChatGPT, Gemini и GitHub Copilot — на разработку программного обеспечения.

В ответах представлены некоторые инсайты как LLM помогает в разработке (например, подходы внедрения LLM в производственный процесс). Так как это PDF на 40 страниц мелким убористым текстом, то мы прочитали это за вас и делимся самыми интересными идеями.

Дисклеймер:

Участниками опроса не использовались, ни IDE cursor.ai, ни модели Anthropic. То есть, по сути, статья уже устарела до выхода — такие уж теперь скорости в мире ИИ. Кроме того, один из выводов в статье звучит как “LLM не помогают в разработке документации”. Это явно противоречит нашим собственным наблюдениям, т.к. уже существенное количество документации мы пишием с применением LLM. Мы, если что, это команда ТГ канала для разработчиков, которые хотят быть в курсе как использовать LLM в работе – AI4Dev. Все остальное же звучит довольно любопытно, так что может быть найдете что-то интересное.

1. Разработчики

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

• Сокращения числа рутинных задач и синтаксических ошибок в коде

• Ускорение процесса поиска решений и подтверждения правильности гипотез

• Предоставления шаблонного кода и заготовок

• Объяснение кода

• Перевод (например с Python на JS) и оформления кода

• Повышение эффективности обучения за счет персонализации

• Ускорения настройки проектного окружения

• Обновления учебных материалов и проектной документации

• Упрощения доступа к информации и доменной экспертизе

• Саммаризация документации

• Поддержки внутренних коммуникаций в команде через повышение качества переписки, автоматизацию подготовки презентаций и отчетов

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

• Перепутывание языков программирования

• Противоречивые ответы

• Медленная генерация ответов

• Трудности с анализом неструктурированных данных

• Ограниченные возможности саммаризации и объяснения

В то же время указываются проблемы, которые, возможно, и не будут решены в ближайшее время:

• Галлюцинации и неполные ответы

• “Упрямые ответы” (когда LLM не хочет менять свои первоначальные ответы даже после получения дополнительных разъяснений)

• Ограниченные знания и наборы данных, на которых обучались LLM

• Ограниченные коммуникации с реальным миром

• Зависимость разработчиков от LLM

2. Процесс

Проводится анализ возможных применений LLM по Software Development Life Cycle (стадиям разработки) при гибкой методологии разработки:

Требования и планирование:

LLM помогают в:

• Выявлении недостающих компонентов в проектной документации

• Ускорении процесса прототипирования

• Уточнении и анализе требований

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

• Неспособность полностью заменить человеческое участие в процессе сбора требований

• Ограниченная детализация при анализе требований

Проектирование и генерация идей – LLMs требуют разбиения задач на более мелкие и управляемые компоненты, это связано с длиной контекста.

Реализация – процесс реализации с LLMs во многом схож с повторным использованием кода. Поэтому авторы приняли классификацию Россона и Кэролла, разделив процесс на три фазы:

1. Поиск решений и генерация кода:

Этот раздел описывает разработку промптов и процесс поиска релевантных ответов. Авторы предлагают такой подход:

• Начинать с коротких и общих промптов для поиска вариантов решений

• Итеративно повышать ясность с помощью дополнительных вопросов

• Когда способ реализации становится понятен, переходить к точным, хорошо специфицированным запросам, используя few-shot prompting и расширяя контекст

Описана стратегия добавления и удаления контекста с помощью символов ‘+’ и ‘-‘ в запросах, а также маркирование пунктов (например, A, B, C) для последующего обращения к ним.

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

Рекомендуется начинать новый диалог, если качество ответов начинает ухудшаться. Иногда проблему потери части контекста можно решить, добавив фразу “This is really important to remember”.

2. Оценка сгенерированного кода:

Проверка точности и полезности сгенерированных ответов проводится с помощью следующих методов:

• Построчное изучение кода вручную

• Анализ выполнения кода

• Просмотр логов консоли

• Ручное тестирование и сравнение с ожидаемым результатом

• Проверка ожидаемых значений возвращаемых функций

• Мониторинг предупреждений или ошибок в IDE

• Проверка шаблонов кода и решений

• Тестирование отдельных примеров

• Использование инструментов разработчика или интерактивных сред (REPL)

Авторы также предлагают использовать внешние фреймворки и инструменты тестирования, такие как Pi Test совместно с LangChain, для проведения автоматизированного тестирования, выявления ошибок и совместной проверки кода разными агентами.

Для проверки качества сгенерированного кода рекомендуется:

• Использовать внешние источники (например, Stack Overflow)

• Уточнять код через сгенерированные объяснения

• Проводить визуальную и логическую оценку кода

Для повышения читаемости кода можно добавить в промпт фразу: “apply the SOLID principles, follow Martin’s Clean code manual, a handbook of agile software craftsmanship and the programming language’s official documentation”.

Иногда для исправления ошибки в коде достаточно использования промпта для “самокоррекции”: “Hey? You made a mistake here. What was your mistake?”

3. Интеграция – добавление сгенерированного кода в существующую кодовую базу. Описаны случаи, когда LLMs не могли изменить определённые компоненты выходного кода, не затрагивая его полностью.

Тестирование и код-ревью  – рекомендуется использовать LLM для генерации unit тестов, поскольку они являются относительно простыми и формализованными. 

Отладка, рефакторинг и документирование – отмечено, что интерактивное взаимодействие с LLMs значительно сокращают время отладки, предоставляя быстрые решения или направляя их в правильном направлении. Особенно в части в устранении синтаксических ошибок. Примеры использования LLM в рефакторинге “I have [a method, a class, or something], give me an idea of how I can do that — refactor in a better way.’, ’This is the code I am writing for a for loop. Can you just convert it to the stream version?’ .

3. Интеграция:

Этот раздел рассматривает добавление сгенерированного кода в существующую кодовую базу. Авторы описывают случаи, когда LLM не могли изменить определённые компоненты выходного кода, не затрагивая его полностью.

Тестирование и код-ревью:

Авторы рекомендуют использовать LLM для генерации unit tests, поскольку они относительно простые и формализованные.

Отладка, рефакторинг и документирование:

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

Примеры использования LLM в рефакторинге:

• “I have [a method, a class, or something], give me an idea of how I can do that — refactor in a better way.”

• “This is the code I am writing for a for loop. Can you just convert it to the stream version?”

3. Продукты

Создание чистого, читаемого кода:

Авторы отмечают, что в большинстве случаев код, сгенерированный LLM для решения распространённых задач, является чистым, читаемым и систематизированным. Читаемость небольшого фрагмента кода можно улучшить с помощью промпта “improve the code in terms of readability”. Однако существуют проблемы при работе с уникальными задачами и быстроразвивающимися технологиями или API, когда отсутствуют актуальные данные, что приводит к устаревшим или нерелевантным предложениям.

Генерация кода с разумной сложностью:

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

Проведение анализа сложности:

LLM можно использовать в качестве инструмента для проверки сложности фрагментов кода, а также для объяснения преимуществ различных подходов. Пример промпта: “What’s the time complexity, and the space complexity of this problem? Explain why and explain the benefits of using this method versus that method by its complexity.”

Оптимальный сценарий использования:

Наиболее эффективно LLM решают небольшие задачи, особенно те, которые включают рутинные или стандартные процессы, такие как написание шаблонного кода. Авторы предлагают разбивать задачи на небольшие компоненты, например, написание коротких фрагментов кода или реализацию базовых функций.

Безопасность:

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

Общество

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

Авторы отмечают важность:

• Установления руководств по использованию LLM, особенно для организаций, работающих с конфиденциальными данными

• Разработки чётких правил для обеспечения безопасного использования LLM

• Создания библиотек шаблонов промптов для сотрудников

• Обучения сотрудников использованию LLM, промпт-инжинирингу и LLM-инструментам в IDE

• Освоения шаблонов проектирования и умения разбивать сложные проблемы на управляемые компоненты — это имеет решающее значение для максимального использования возможностей LLM

Авторы предлагают использовать RAG (Retrieval-Augmented Generation), чтобы включать артефакты, такие как документы проекта, репозитории кода и ветки обсуждений, в процесс генерации. Это повышает контекстную осведомлённость модели и помогает адаптировать ответы LLM под конкретные отрасли.

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

Улучшения в современных LLM:

Ряд проблем, таких как галлюцинации, противоречивые ответы, перепутывание языков программирования и трудности с неструктурированными данными, были частично устранены благодаря:

• Улучшенным возможностям рассуждений

• Большему контекстному окну

• Реализации возможности просмотра веб-страниц в реальном времени

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