ШІ в розробці ПЗ: поточний стан та перспективи
Перші кроки в розвитку доповнення коду були зроблені у 1957 році, зокрема, першими були спелчекери, що перевіряли правильність написання основних інструкцій (вікіпедія Code completion).
У 1996 році у MS Visual Studio була додана функція автоматичного доповнення коду. Хоча на Stack Overflow вказують, що деякі функції покращення коду також були присутні в Turbo Pascal через Alice, все ж можна вважати початком саме введення функції IntelliSense.
IntelliSense прискорює процес розробки програмного забезпечення, зменшуючи кількість введення з клавіатури та потребу в запам’ятовуванні назв. Вона також дозволяє користувачам рідше звертатися до зовнішньої документації, оскільки інтерактивна документація для багатьох символів (наприклад, змінних та функцій) у поточному контексті відображається динамічно у вигляді підказок.
(1) Автодоповнення блоків коду
Якщо говорити про ШІ, то 29 червня 2021 року GitHub оголосив про технічний попередній перегляд GitHub Copilot у середовищі розробки Visual Studio Code, далі JetBrains та Neovim. Повністю як платний сервіс для індивідуальних розробників відкрили 21 червня 2022 року.
Була використана базова велика мовна модель (LLM) Openai Codex, яка може генерувати кожен наступний токен, тобто за початком коду у файлі (це буде контекст) вона генерує продовження. На відміну від попередніх систем, тепер видаються цілі блоки коду.
Можна перемикатися між декількома варіантами. Для покращення точності можна написати коментарі, в яких буде вказано, що буде враховано при подальшій генерації.
Більш розширена версія (у Cursor має назву Copilot++) може генерувати доповнення як усередині рядка, так і у мультирядковому форматі.
Зазвичай використовується модель відносно невеликого розміру (близько 2-7 млрд параметрів) натренована на якісному коді, тому такий сервіс легко зробити. Також їх можна запускати локально.
Далі прийшли конкуренти:
- комерційні Tabnine, Codeium та інші (зазвичай не пишуть що за модель використовують)
- Tabby як опен-соурс та самостійно хостінговий проект (каталог моделей)
- плагіни VSCode які через локальний сервер ollama доповнюють код
(2) Чат-інтерфейс парного програмування
Після швидкого успіху ChatGPT (старт 30 листопада 2022 року) стало зрозуміло, що можна описати текстом те, що вам потрібно, і отримати відповідь у вигляді згенерованого коду. На початку 2023 року почали з’являтися плагіни для IDE, які вставляли бічний чат з моделлю GPT-3.5-turbo через ключ API OpenAI.
Тут ми виходимо за межі генерації блоків і відразу можемо просити створювати цілі файли з кодом (такі як модулі).
GitHub Copilot Chat як частина GitHub Copilot X був анонсований 22 березня 2023 року. У пості від 29 грудня 2023 року було повідомлено, що чат тепер тепер доступний для всіх та працює на GPT-4.
Можна задавати та отримувати відповіді на питання, пов’язані з програмуванням. Також чат-інтерфейс надає доступ до деяких команд автоматизованої розрозбки — генерація юніт-тестів на основі коду, пояснення коду та пропозиція покращень, пропозиція виправлень помилок у коді на основі опису помилки (з консолі) та оточуючого коду.
Сам підхід є розвитком ідеї парного програмування: я спілкуюсь з чатом звичайним текстом, а він створює або змінює код. Теж можу дописати код, потім ще питати чат, ітд.
Більшість функцій це просто текстові інструкції до моделі, які можна писати у чаті, але для спрощення під них створюють слеш-команди або кнопки. Деякі сервіси надають можливість користувачу створювати свої команди (тобто зберігати промти), а також писати “правила для ШІ”, які будуть додаватися до кожного запиту.
У GitHub Copilot це: doc (Додає коментарі до вказаного або виділеного коду), explain (Отримує пояснення коду), fix (Пропонує виправлення проблем у виділеному коді), generate (Генерує код для відповіді на вказане питання), help (Отримує довідку з використання Copilot Chat), optimize (Аналізує та поліпшує час виконання виділеного коду), tests (Створює юніт-тести для виділеного коду).
На GitHub Next був експеримент із “кистями” Code Brushes.
Є два напрями логіки вибору моделі: або максимально велика (зараз це GPT-4 чи Claude-3-Opus) через API доступ, або спеціально налаштована під код instruct/chat модель (CodeLlama, DeepSeekCoder та інш — в середньому розміру 34 млрд параметрів).
Приклад — плагін для VSCode від Phind, який використовує попередньо навчену модель для коду (fine-tuned CodeLlama-34B безкоштовно чи 70B) та візуально під чатом показує, що в поточному запиті буде використано як контекст — відкриті вкладки, а також фрагменти коду, а також де розташований курсор. Будь-що можна скасувати за допомогою хрестика. Відповідь від чату можна вставити у новий файл за допомогою кнопок, у місце курсора або навіть автоматично застосувати правки.
У Cursor це Apply From Chat, але мене дратує що кнопки у них згори коду, а не знизу.
Зараз багато сервісів інтеграції LLM чату до завдань программуваня:
- Cody, Double, Continue (тільки чат без автодоповлення), GitLab Chat, Codeium, Bito, blackbox AI, CodeGeeX, AskCodi та інш
- Tabby як опен-соурс та самостійно хостінговий проект, але для більших моделей краще вже GPU хостінг орендувати
Додатковий варіант — відкриття inline вікна для написання текстової інструкції прямо в редакторі. Cursor це найкращий приклад, він також може “слухати” додаткові уточнення після генерації відповіді та вносити правки на основі них. Окрім того результат відображається у вигляді DIFF двох кольорів, тому легко перевірити чи все ок.
Мені найбільше подобається цей підхід, оскільки не потрібно постійно відволікатися на чат і втрачати потік при роботі з кодом. При цьому ми не засмічуваємо наш код постійними коментарями, які були потрібні для генерації в першому методі. Крім того, не потрібно чекати декілька секунд, поки спрацює автодоповнення, а можна відразу відкрити вікно запиту і написати все, що хочеться.
Зараз, навесні 2024 року, ми знаходимося саме на хвилі появи таких систем. Все більше стартапів хочуть конкурувати з GitHub Copilot за зручність інтеграції LLM у середу розробки.
Деякі системи дозволяють не тільки запитувати модель про код, але й надавати їй доступ до інтернету та генерувати відповідь на основі результатів пошуку.
(3) Контекстне розуміння репозиторіїв
Наступна проблема, яку намагаються вирішити, полягає в тому, щоб ШІ система автодоповнення коду бачила не лише відкритий файл та вкладки, а знала весь код у репозиторії, а краще й весь код профілю мого чи компанії.
І це вже не така проста задача, і поки що існує мало рішень для її вирішення.
Рішення, яким йде Google, полягає в збільшенні контекстного вікна до 1М а потім до 10М токенів, а рішення, яким йдуть всі інші, це RAG, тобто перетворення коду на ембедінги у векторній БД та доповнення запиту відповідними частинами.
Наразі презентована 16 лютого 2024 модель Gemini 1.5 Pro від Google з великим контекстним вікном 1M (а буде й 10M) токенів знаходиться на етапі експерименту і поки що немає робочого продукту на її основі.
RAG. Такі системи дозволяють шукати та ставити питання щодо вищорівневих концепцій у коді власного проекту. З 29 грудня 2023 року GitHub Copilot через @workspace у чаті (контекст це всі файли у робочому просторі, за винятком файлів, які .gitignore та індекс пошуку коду GitHub, якщо робочий простір є репозиторієм GitHub та індексується для пошуку). У Cursor це Codebase Answers.
Презентований 27 лютого 2024 року GitHub Copilot Enterprise має знання на базі всіх репозиторіїв компанії, і якщо інші конкуренти зможуть, то вони також підтягнуться.
В Codeium також є функція пошуку по коду репозиторія, але у мене вона погано працювала. Cody побудований компанією, яка займається пошуком та автопатчингом коду Sourcegraph, але поки що як я розумію ці дві системи не дуже інтегровані.
Наразі актуальна задача для ШІ систем полягає в тому, щоб новий код генерувався не просто загально, а в контексті вже існуючого проекту, розуміючи його логіку та стилістику.
Я пошукав та затестив ряд незалежних стартап у форматі “чат з вашим репозиторієм”, і всі вони працюють так погано та виглядають так сиро, що навіть згадувати про них немає сенсу.
(4) Мрії про автономних агентів
На даний момент немає жодного продакшн-реді проекту. Проте вигляд та можливість таких систем стали відомі завдяки хайпу навколо Devin (сайт)— коли хитрі маркетологи “продали” ШІ розробника інвесторам маючи лише змонтоване відеодемо не з реального часу.
Розбір сумнівності цього є у відео від “Internet of Bugs”.
Відразу почали з’являтися відкриті клони і всі вони досить сирі: OpenDevin, Devika, Kevin, спеціалізований SWE-agent.
Мрії про агентів, які будуть працювати замість нас, з’явилися майже одразу після появи перших чатів на GPT-3.5-turbo, але вони не могли надати жодного зрозумілого результату. Після того з’явився GPT-4, і такі системи стали розв’язувати прості завдання, але вартість одного запуску становила приблизно 10–15 доларів за використання токенів по API. Пізніше з’явилася більш дешева версія GPT-4-turbo, та також люди навчилися краще оптимізувати використання токенів, тепер простий код вони можуть написати за 4–5 доларів.
У загальному, те, чого ми хочемо досягти, ми можемо побачити на цій діаграмі з презентації проекту metaGPT. Нам потрібно створити декілька кастомних LLM-агентів і розподілити між ними завдання — загального планування та архітектури системи, створення інтерфейсу, написання коду та його перевірку.
Якщо це працюватиме повністю автоматично, LLM повинні не допускати помилок взагалі, або нам потрібні додаткові агенти, які будуть перевіряти роботу цих агентів. І хто буде перевіряти тих агентів, які перевіряють?
Отже, нам все одно бажано мати присутність людини і такі проекти є більш життєздатними. Наприклад, це crewAI чи GPT Pilot.
Також нам потрібна дійсно швидка та більше дешева генерація токенів, як то вміє робити Groq LPU. Але вони поки що не розгорнули у себе тюнінгованих на коді моделей, тому тільки Llama3–70b більш менш працює ок з кодом.
Перевірка якості коду
Спрощена задача полягає в перевірці коду одним агентом, який був згенерований іншим — перевірити імпорти та версії бібліотек, надалі запустити код і, якщо є помилки в консолі, відправити їх моделі, щоб вона внесла правки, і так продовжувати, допоки код не працюватиме. Хоча, звісно, це не гарантує правильність його логіки.
Поки що я не бачу майбутнього у великих роях агентів, які генерують проекти з нуля, але для Enterprise думаю створять рої, які самі ходитимуть по всім репозиторіям, шукатимуть помилки, читатимуть тікети з багтрекерів, розгортатимуть проекти, перевірятимуть, що не працює, автоматично створюватимуть патчі та відправлятимуть людям пул-реквести на підтвердження. Ймовірно GitHub Copilot щось таке зробить.
Ця стаття написана для пабліка https://t.me/llms4coding, де я публікую новини з теми роботи LLM з кодом.
