GitHub давно став синонімом спільної розробки, але поява потужних AI‑агентів радикально змінила саму структуру роботи над кодом. У GitHub Next — експериментальній лабораторії компанії, що займається ризикованими й дослідницькими проєктами, — над цим працює Меґґі Епплтон, staff researcher engineer і дизайнер за походженням. Її команда створює ACE (Agent Collaboration Environment) — дослідницький прототип нового типу середовища, де люди й агенти працюють разом у реальному часі, а не кожен у своєму ізольованому CLI.
ACE намагається відповісти на запитання, яке стає центральним у добу агентів: якщо написання коду вже майже «вирішена» проблема, то як зробити так, щоб команда взагалі будувала правильні речі — узгоджено, прозоро й без хаосу з десятків приватних сесій з агентами?
Від «один девелопер і дві дюжини агентів» до спільного середовища
Сучасна картина «продуктивного» розробника часто виглядає як стіна терміналів із десятком локальних AI‑агентів, що одночасно щось генерують. Ця модель обіцяє, що одна людина з флотом агентів зможе замінити цілу команду. Проблема в тому, що реальне програмне забезпечення ніколи не створюється в ізоляції однією людиною. Це командний вид спорту, де ключовим стає не швидкість набору коду, а узгодженість рішень.
Епплтон прямо формулює зсув: реалізація стає дешевою, швидкою й дедалі якіснішою; головним вузьким місцем стає не «як це побудувати», а «чи варто це будувати взагалі». Узгодження того, що саме має бути створено, перетворюється на основну проблему. При цьому більшість нинішніх інструментів — GitHub, Slack, Jira, Linear — проєктувалися для іншої епохи й не враховують агентні робочі процеси.
ACE народжується саме як відповідь на цю прірву між індивідуальними агентами й командною реальністю. Це не ще один «розумний» редактор коду, а спроба побудувати спільний простір, де планування, контекст, рішення й сама розробка відбуваються в одному середовищі — і для людей, і для агентів.
Сесія як канал і як комп’ютер: що таке ACE насправді
На перший погляд ACE виглядає знайомо: інтерфейс нагадує суміш Slack, GitHub, Copilot і хмарної IDE. Ліворуч — список сесій, кожна з яких поводиться як чат‑канал для команди. Усередині можна обговорювати роботу, кидати скріншоти, ставити запитання, тегати колег. Але сесія в ACE — це значно більше, ніж просто чат.
Кожна сесія підкріплена власною мікро‑віртуальною машиною (microVM) у хмарі, яка працює на окремій Git‑гілці. Це означає кілька важливих речей.
По‑перше, усі зміни в межах сесії ізольовані. Команда може розбити роботу на паралельні потоки — наприклад, одна сесія для редизайну інтерфейсу, інша для оптимізації бекенду, третя для експериментів з новою функцією. Кожна з них живе на своєму sandbox‑оточенні й гілці, не створюючи миттєвих конфліктів у спільному репозиторії.
По‑друге, перехід між цими потоками стає майже миттєвим. Немає потреби «stash‑ити» локальні зміни, перемикатися між гілками, синхронізувати робочі дерева чи розбиратися, що саме зараз запущено на чиїй машині. Достатньо клікнути по сесії — і користувач опиняється в тому самому середовищі, де працює колега, з тим самим кодом, терміналом і прев’ю.
По‑третє, кожна сесія — це не лише спільний комп’ютер, а й спільний канал взаємодії з агентом. Кодуючий агент ACE живе всередині цієї сесії, бачить повну історію розмови, усі попередні промпти, обговорення, уточнення й може використовувати це як контекст для наступних змін. У результаті агент стає не персональним асистентом одного розробника, а учасником командної дискусії.
Прозорий контекст: як ACE дає змогу «зайти в чужу голову»
Одна з головних проблем нинішніх агентних інструментів — локальні, закриті плани. Більшість код‑агентів генерують план дій у межах приватної сесії, яку бачить лише один користувач. Команда не знає, чому агент прийняв те чи інше рішення, які компроміси закладено, які варіанти відкинуто. Усе це з’являється вже у вигляді готового PR, коли змінювати щось пізно й дорого.
ACE намагається розвернути цю логіку. Коли член команди «заходить» у чужу сесію, він бачить не тільки поточний стан коду, а й повну історію спілкування з агентом. Уся послідовність промптів, уточнень, проміжних кроків стає спільним контекстом. Це важливо з кількох причин.
По‑перше, зникає типова ситуація, коли рецензент дивиться на diff у PR і не розуміє, чому саме так, а не інакше. В ACE можна буквально «перемотати» хід думок: які вимоги формулювалися, які обмеження обговорювалися, які альтернативи пропонувалися агентом.
По‑друге, це знижує вартість підключення нових людей до роботи над фічею. Новий учасник не змушений відновлювати контекст через десятки повідомлень у Slack, коментарі в Jira й розрізнені нотатки. Усе, що стосується конкретної задачі, зібрано в одній сесії: чат, код, термінал, прев’ю, історія взаємодії з агентом.
По‑третє, це створює умови для справжнього «мультиплеєра» з агентом. У межах однієї сесії кілька людей можуть по черзі або паралельно промптити ACE, обговорювати наступні кроки, а агент сприйматиме всю розмову як єдиний вхід. Наприклад, один учасник запускає сесію й формулює початкове завдання, інший пізніше додає: «ACE, давай додамо ще й teal‑тему», — і агент продовжує роботу з урахуванням усієї попередньої історії.
MicroVM, термінал і live‑прев’ю: чому ACE — це не «Slack з ботом»
Зовні ACE справді нагадує чат, але під капотом це повноцінне хмарне середовище розробки. Кожна сесія має свій microVM, де можна виконувати звичні термінальні команди. Розробник запускає, наприклад, bun install і bun dev, і в інтерфейсі ACE з’являється живий прев’ю застосунку в браузері, прив’язаний до цієї ж microVM.
Цей live‑прев’ю синхронізований із кодом, який змінює агент. Якщо попросити змінити колірну тему застосунку на фіолетову, оновлення миттєво відобразиться в прев’ю. Немає проміжного кроку у вигляді локальної збірки, пушу в гілку, деплою на тестове середовище — усе відбувається в одній сесії, у реальному часі.
Термінал у ACE — спільний. Кожен учасник сесії може запускати команди, бачити їхній вивід, перевіряти логи, перезапускати dev‑сервер. Це усуває класичне «у мене працює, у тебе ні»: усі буквально працюють на одному й тому самому комп’ютері в хмарі. Якщо дизайнер або продакт хоче самостійно «поклікати» нову фічу, йому не потрібно піднімати локальне середовище — достатньо відкрити сесію й скористатися тим самим прев’ю.
Окремий елемент інтерфейсу — компактний блок‑зведення в кутку, який показує останні зміни в сесії, незалежно від того, хто їх зробив: людина чи агент. Це допомагає не губитися в активних паралельних сесіях і швидко орієнтуватися, що саме відбулося останнім часом.
Усе це разом пояснює, чому ACE — це не просто «Slack із підключеним агентом». Slack, як підкреслює Епплтон, навряд чи коли‑небудь стане повноцінним інструментом розробки: у його бізнес‑моделі немає місця для таких примітивів, як дифи, термінал, керування гілками чи microVM. ACE, навпаки, спроєктовано саме як інструмент для розробки, де ці речі є базовими.
Автоматичні коміти й PR: як агент вбудовується в Git‑процес
ACE не намагається скасувати Git чи pull request, але змінює спосіб, у який агент взаємодіє з ними. Кодуючий агент у сесії може не лише редагувати файли, а й автоматично фіксувати зміни. Після виконання завдання ACE створює коміт із згенерованим повідомленням, яке описує суть змін. Розробник може відкрити дифи, переглянути, що саме було змінено, і за потреби скоригувати результат.
Далі агент може безпосередньо з ACE створити pull request у GitHub. У описі PR додається посилання назад на вихідну ACE‑сесію. Це важливий місток між новим середовищем і звичною інфраструктурою: рецензент, який бачить PR, може одним кліком перейти до повного контексту — чату, історії промптів, попередніх ітерацій, live‑прев’ю.
Такий підхід частково розвантажує сам PR як точку єдиного вирівнювання. Замість того, щоб намагатися втиснути всю дискусію, мотивацію й контекст у коментарі до PR, основна частина обговорення відбувається в ACE‑сесії, а PR стає радше формальним кроком інтеграції змін у головну гілку.
Водночас автоматизація комітів і PR не означає, що людина втрачає контроль. Навпаки, завдяки ізольованим microVM і гілкам, експерименти з агентом можна проводити агресивніше, знаючи, що вони не зламають основний репозиторій. А посилання з PR назад на сесію дає змогу відновити повну картину рішень, якщо щось піде не так.
Від девелопера до сапорту: чому ACE проєктують для всіх учасників команди
ACE задумано не лише як інструмент для розробників. Одна з ключових ідей — зробити агентні робочі процеси доступними для всіх, хто бере участь у створенні продукту: дизайнерів, продакт‑менеджерів, фахівців підтримки.
Це пов’язано з тим, де насправді живе критичний контекст для правильних рішень. Більшість важливої інформації не закодована в репозиторії. Вона існує в головах людей: бізнес‑цілі, фінансові обмеження, політична структура організації, бачення продукту, інсайти користувацьких досліджень, історія попередніх спроб і провалів. Жоден агент не може самостійно «відкопати» цю реальність у коді чи документації.
ACE намагається зробити так, щоб цей людський контекст природно потрапляв у спільний простір ще до того, як агент почне масово генерувати код. Дизайнер може зайти в сесію, подивитися live‑прев’ю, залишити коментарі щодо UX, попросити агента змінити колірну схему чи структуру сторінки. Продакт може сформулювати бізнес‑обмеження або уточнити сценарії використання прямо в чаті, знаючи, що агент прочитає це як частину промпту. Спеціаліст підтримки може принести реальні кейси користувачів і попросити змін, які відповідають їхнім болям.
Той факт, що інтерфейс ACE схожий на Slack, тут не випадковий. Знайома модель «чат‑каналу» знижує поріг входу для людей, які не живуть у Git‑гілках і терміналі щодня. Вони можуть сприймати ACE як ще один командний канал, але з тією різницею, що цей канал безпосередньо підключений до коду й живого середовища, а не лише до текстових обговорень.
У результаті агентні робочі процеси перестають бути «чорною скринькою» у руках окремих розробників. Вони стають спільною діяльністю, де різні ролі можуть безпосередньо впливати на те, що й як будується, а не лише заднім числом коментувати готові PR.
Новий цикл: коли планування й реалізація зливаються
Класичний процес розробки довгий час будувався як послідовність: планування, реалізація, рев’ю. У кожній фазі були свої точки вирівнювання: зустрічі, обговорення в Slack, коментарі в задачах, драфтові PR. Цей ритм працював, поки реалізація була відносно дорогою й повільною.
З появою потужних код‑агентів вікно реалізації різко звузилося. Час між створенням задачі й появою PR може вимірюватися хвилинами. Це створює ілюзію, що планування можна майже пропустити: «потім якось розберемося на рев’ю». Насправді ж час на рев’ю згенерованого коду зростає, і більшість точок узгодження зміщується на кінець процесу, коли змінювати щось уже складно.
ACE пропонує іншу модель: планування й реалізація більше не розділені фазами, а утворюють безперервний цикл усередині однієї сесії. Обговорення, уточнення вимог, запуск команд, зміни коду агентом, перегляд прев’ю, нові коментарі — усе це відбувається в одному просторі, у реальному часі, з доступом для всієї команди.
Ключова відмінність у тому, що інструмент спочатку спроєктовано як місце для спільного мислення й прийняття рішень, а вже потім — як середовище для виконання коду. Це контрастує з нинішніми інструментами, де планування розкидане по Slack, Jira й документах, а реалізація живе в окремих локальних середовищах і приватних сесіях з агентами.
ACE не скасовує потребу в формальних артефактах на кшталт PR, але намагається повернути основну вагу вирівнювання туди, де вона й має бути: до того, як код масово згенеровано й відправлено на рев’ю.
Висновок: ACE як лабораторія майбутнього командної розробки
ACE поки що залишається дослідницьким прототипом GitHub Next, який лише готується до технічного прев’ю й масштабнішого тестування. Але вже зараз у ньому проглядається чітка відповідь на виклики агентної епохи.
Замість того щоб намагатися втиснути агентів у старі форми — PR‑центричні процеси, локальні CLI‑інструменти, розрізнені чати — ACE пропонує нову базову одиницю роботи: сесію, яка одночасно є чат‑каналом, спільним хмарним комп’ютером, історією взаємодії з агентом і ізольованою Git‑гілкою. У цьому просторі можуть працювати разом розробники, дизайнери, продакти й сапорт, а агент стає не індивідуальним «турбо‑автокомплітом», а повноцінним учасником командної діяльності.
Чи стане саме така модель стандартом для індустрії, поки що невідомо. Але очевидно одне: якщо реалізація справді перестає бути головною проблемою, то інструменти майбутнього мають допомагати командам краще думати разом, а не просто писати більше коду швидше. ACE — одна з перших спроб побудувати таке середовище навколо агентів.
Джерело
Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub