GitHub: перший варіант коду дедалі частіше пише AI

Одиниця вимірювання — пропозиція змін

Octoverse охоплює відкриті й приватні репозиторії. Використання агентів, якого GitHub не може виявити, у цей підрахунок не потрапляє. Річний звітний період закінчується 30 вересня 2026 року. Це спостереження за активністю платформи, а не експеримент, у якому людям і агентам давали зіставні завдання.

Pull request збирає запропоновані зміни так, щоб інша людина могла перевірити їх до додавання в проєкт. GitHub показує поруч обговорення, історію редагувань, автоматичні перевірки й відмінності між файлами. Особливо корисний перегляд змін: у ньому видно додані та видалені рядки. Замість запевнення, що завдання виконано, є результат, який можна перевірити.

Тому перший варіант — це конкретний результат, переданий на перевірку. Рев’юер може простежити реалізацію, попросити виправлення або схвалити її. GitHub розрізняє коментар, схвалення та запит на зміни; репозиторій може вимагати перевірки перед злиттям. Делегування має видимий проміжний результат, який ще можна доопрацювати до його додавання у спільну кодову базу.

Джерела: GitHub [1] · GitHub Docs [2] · GitHub Docs [3]

GITHUB / OCTOVERSE

Дані, оприлюднені GitHub

Телеметрія GitHub; графіка з оригінального звіту.

Від розмови до змінених файлів

Актуальна документація Copilot описує сам механізм: агент може дослідити репозиторій, спланувати зміну, відредагувати файли й запустити тести у хмарному середовищі. Розробник може переглянути результат і попросити доопрацювання ще до створення pull request. Система отримує завдання й середовище для його виконання.

28 жовтня GitHub також відкрив новий хмарний інтерфейс користувачам платних планів Copilot з урахуванням політик організації. Сесію можна продовжувати у вебверсії, на телефоні й у локальних клієнтах. Це корисно, коли робота триває довше за одну взаємодію: розмова, запропоновані зміни й наступна вказівка залишаються в межах того самого завдання.

Самому завданню потрібне визначення успіху. У картці застосунку GitHub рекомендує чітко окреслені доручення з критеріями приймання та контекстом проєкту. Попросити функцію й пояснити, як перевірити її роботу, — це дві окремі частини інформації. Агент може підготувати правдоподібну реалізацію, але пропустити поведінку, яку мав на увазі замовник.

Джерела: GitHub Docs [4] · GitHub Docs [5]

Кілька моделей за одним завданням

Ще один реліз 28 жовтня додає до делегування новий рівень. Copilot Fusion вийшов із попереднього доступу й може добирати та координувати моделі в межах завдання. Серед описаних схем — пряма робота однієї моделі, передавання першої спроби потужнішій моделі після перевірки та доопрацювання чернетки після оцінки іншою моделлю. Користувач обирає рівень зусиль, а не призначає виконавця для кожного кроку вручну.

Сервіс тарифікує використані моделі за їхніми відповідними ставками. Автоматична додаткова перевірка стає частиною і плану виконання, і вартості. Реліз відбувся після виміряного періоду, тож не пояснює попереднього зростання.

Джерела: GitHub [6]

Що покаже завершена робота

Дослідники програмного забезпечення заперечували проти вимірювання продуктивності одним числом ще до поширення агентів для програмування. Методика SPACE, яку 2021 року розробили Ніколь Форсґрен із колегами, розглядає активність лише як частину ширшої картини. Сам великий обсяг змін не показує команді, чи створила вона корисне програмне забезпечення з меншими зусиллями.

Пулреквест — це пакет змін, а не стандартна одиниця праці. Виправлення на десять рядків і функція на тисячу можуть однаково додати одиницю до лічильника. Поширення агентів змінює те, хто може підготувати такий пакет. Щоб оцінити його вміст — чи програма тепер робить задумане і якою ціною, — потрібне інше вимірювання.

Джерела: Nicole Forsgren et al. / ACM Queue / Microsoft Research [7]