Уявлення про «розробника майбутнього» сьогодні часто виглядає як одна людина перед стіною терміналів, де паралельно працює десяток чи два AI-агентів. Ця картинка обіцяє радикальне зростання продуктивності: один інженер із флотом агентів нібито здатен замінити цілу команду.
Меґґі Епплтон, staff researcher engineer у команді GitHub Next, яка займається експериментальними й ризикованішими проєктами всередині GitHub, пропонує на це зовсім інший погляд. На її думку, ми стрімко наближаємося до світу, де реалізація — майже розв’язана задача, а справжнім вузьким місцем стає зовсім інше: здатність команд домовлятися, що саме варто будувати й навіщо.
У своєму виступі на каналі AI Engineer вона розбирає, як агентні інструменти змінюють життєвий цикл розробки, чому класичні інструменти на кшталт GitHub, Slack, Jira та Linear погано працюють у такому середовищі й чому «соло-агентна» розробка загрожує командній узгодженості навіть більше, ніж здається на перший погляд.
Реалізація більше не головна проблема: вузьке місце змістилося в «що будувати»
Традиційно головним обмеженням у розробці вважався час і вартість написання коду. Планування, дизайн, обговорення вимог — усе це існувало, але левова частка зусиль ішла на власне імплементацію. Сьогодні ця картина стрімко змінюється.
Епплтон стверджує, що реалізація «швидко стає розв’язаною проблемою». Код пишеться швидко, стає дешевшим, а якість моделей зростає. Усе більше завдань, які раніше вимагали днів чи тижнів роботи інженера, тепер виконуються за хвилини завдяки кодогенерації й агентам.
У такому світі головне питання зміщується з «як це побудувати» до «чи варто це взагалі будувати». Коли виробництво стає дешевим, справжньою ціною стає втрачені можливості: кожна фіча, яку команда вирішує реалізувати, автоматично означає десятки інших, які не будуть зроблені.
Це робить узгодженість ключовим ресурсом. Команди мають постійно ставити собі запитання: чи ми працюємо над правильними речами? Чи це найкраще використання нашої обмеженої уваги й часу? Чи ця зміна справді наближає продукт до цілей бізнесу й потреб користувачів?
Парадоксально, але саме поява агентів робить стару проблему узгодженості набагато гострішою. Те, що раніше гальмувалося повільною реалізацією, тепер відбувається настільки швидко, що команда просто не встигає зупинитися й подумати.
Вікно імплементації стиснулося до хвилин — і це змінює все
Класичний процес розробки умовно складався з трьох фаз: планування, реалізація, рев’ю. Між ними було багато точок дотику: обговорення в Slack, зустрічі в Zoom, коментарі в задачах і драфтових pull request’ах. Ці проміжні кроки давали команді час і простір, щоб обмінятися думками, скоригувати курс, залучити експертизу старших колег, вчасно помітити помилки.
У результаті до моменту, коли код проходив рев’ю й потрапляв у main, більшість команди вже хоча б поверхово розуміла, що саме робиться й чому.
Агентні інструменти радикально стискають цю часову шкалу. За оцінкою Епплтон, вікно між створенням задачі й появою pull request від агента тепер вимірюється хвилинами. Логіка проста: якщо код можна згенерувати майже миттєво, навіщо довго планувати?
На практиці це означає, що значна частина ранніх точок узгодження просто зникає. Ніхто не встигає зібратися, обговорити підхід, поставити уточнювальні запитання. Рішення про те, що саме буде реалізовано, фактично приймається в момент написання промпта — часто поспіхом і без достатнього контексту.
При цьому час на рев’ю згенерованого коду, навпаки, зростає. Команди змушені ретельніше перевіряти те, що видають агенти, оскільки довіряти «чорній скриньці» без валідації небезпечно. Але тепер ця перевірка відбувається вже після того, як імплементація завершена.
Зусилля зміщуються з написання коду на його валідацію й узгодження постфактум. Усі ті розмови, які раніше відбувалися до й під час розробки, тепер концентруються в кінці — на етапі pull request’а. І це створює новий тип напруги: команда змушена або приймати неідеальні рішення, щоб не блокувати швидкий потік змін, або регулярно «викидати» вже зроблену роботу, коли виявляється, що вона не відповідає очікуванням чи контексту.
Pull request більше не витягує: старі інструменти не встигають за агентами
Цей зсув у часі оголює фундаментальну проблему: інструменти, якими користуються розробники, створювалися для іншої епохи. GitHub, Slack, Jira, Linear — усі вони проєктувалися під модель, де люди пишуть код, а зміни рухаються відносно повільно.
Епплтон прямо говорить, що в їхньому нинішньому вигляді ці платформи не пристосовані до агентного світу. Вони змушені приймати на себе величезні обсяги виходу від агентів, але їхні базові примітиви — задачі, треди, pull request’и — розраховані на інший темп і іншу структуру роботи.
Особливо це стосується pull request’ів. Усередині GitHub, за її словами, небагато людей вірять, що PR-и й задачі в їхньому класичному вигляді — це майбутнє розробки в агентному середовищі. Історично PR був інструментом для інкрементальних, відносно рідкісних змін, де рецензент має час уважно прочитати код, зрозуміти контекст і дати зважений фідбек.
У світі, де агент може відкрити PR за кілька хвилин після створення задачі, а таких PR-ів за день з’являються десятки, pull request перетворюється на вузьке горлечко. На нього звалюється все: технічна перевірка, архітектурна оцінка, узгодження з бізнес-цілями, виявлення дублювання роботи, виявлення конфліктів із паралельними змінами.
PR починає виконувати роль, для якої він ніколи не був задуманий: стати головним місцем, де відбувається узгодження. І, як підкреслює Епплтон, він погано з цим справляється.
Результат — знайомий багатьом розробникам хаос:
несподівані фічі, які ніхто не просив і які не розв’язують реальних проблем;
критичний фідбек, що приходить надто пізно й змушує викидати вже зроблену роботу;
болючі merge-конфлікти, коли агенти й люди одночасно змінюють ті самі файли;
дублювання зусиль, коли кілька людей і кілька агентів паралельно беруться за одну й ту саму задачу;
стоси PR-ів, на які ніхто не має контексту й часу.
Ключова думка: інструменти, які ми звикли вважати «інфраструктурою співпраці», насправді не дають командам спільного простору, де можна разом планувати, збирати контекст і працювати з агентами як із колективним ресурсом, а не як із приватним інструментом кожного розробника.
Локальні плани агентів і фрагментований контекст: коли кожен грає у свою гру
Ще одна малопомітна, але критична проблема сучасних кодових агентів — те, як вони планують роботу. Більшість із них мають так званий «local plan mode»: агент будує план дій локально, у межах сесії конкретного користувача, і цей план ніде не шариться з командою.
У такій моделі кожен розробник фактично веде свою приватну розмову з агентом. План, який агент пропонує, рідко стає предметом спільного обговорення. Часто його навіть не читають уважно: користувач просто тисне «go», і агент починає вносити зміни в код.
Це означає, що рішення про те, як саме буде реалізована фіча, приймається в тіні — без участі інших членів команди, без зіставлення з паралельними ініціативами, без урахування ширшої картини. Коли кілька людей і кілька агентів працюють над однією кодовою базою, контекст фрагментується: кожен бачить лише свій шматок історії.
У підсумку команда втрачає ще більше точок узгодження. Те, що раніше відбувалося у вигляді спільного планування, архітектурних обговорень, дизайн-сесій, тепер розчиняється в приватних промптах і локальних планах агентів.
Епплтон підкреслює, що це не просто незручність, а системна загроза узгодженості. Коли планування відбувається локально й непрозоро, команда позбавляється можливості вчасно впливати на напрямок роботи. Всі важливі розмови переносяться в кінець процесу — коли вже є готовий PR, і змінювати щось боляче й дорого.
У світі, де планування й реалізація зливаються в єдиний цикл, інструменти мають робити протилежне: виносити плани на світло, робити їх спільними артефактами, які команда може обговорювати, коригувати й використовувати як основу для колективних рішень. Натомість більшість сучасних агентів посилюють ізоляцію, перетворюючи план на приватний додаток до сесії одного користувача.
Найважливіший контекст живе в головах, а не в коді — і агенти самі його не знайдуть
Навіть якби інструменти ідеально показували всі плани агентів і всі зміни в коді, цього було б недостатньо для правильних рішень. Причина проста: більшість критично важливого контексту для розробки не живе в репозиторії.
Епплтон нагадує, що те, що визначає «правильність» технічного рішення, часто лежить поза кодом. Це бізнесові обмеження й фінансові ресурси, які визначають, що взагалі має сенс будувати. Це політична динаміка всередині організації — хто ухвалює рішення, хто може заблокувати реліз, які компроміси вже були досягнуті. Це продуктове бачення лідерів, інсайти з досліджень користувачів, історія попередніх спроб розв’язати ту саму проблему.
Усе це зазвичай зберігається не в README й не в коментарях до коду, а в головах людей. У пам’яті дизайнерів, продакт-менеджерів, інженерів, які давно працюють над продуктом. У неформальних розмовах, старих документах, Slack-каналах, що давно зам’ючені.
Агенти не можуть самостійно відкрити цей контекст. Вони не мають доступу до «політики» організації, не розуміють неявних домовленостей, не знають, які фічі вже провалилися в минулому й чому. Без цього вони можуть генерувати технічно коректний код, який абсолютно не відповідає реальним потребам бізнесу чи користувачів.
Звідси випливає важливий висновок: якщо ми хочемо, щоб агенти допомагали будувати «правильні речі», а не просто «будь-які речі», нам потрібні середовища, де люди можуть природно й рано ділитися цим контекстом. Не через додаткові бюрократичні процеси, не через ще одну форму чи шаблон, а в ході живої спільної роботи.
Епплтон наголошує, що інструменти майбутнього мають об’єднувати планування, збір контексту, ухвалення рішень і власне розробку «під одним дахом». Планування й побудова більше не можуть бути розділеними фазами; це має стати безперервним циклом, у якому агенти й люди працюють разом, спираючись на спільний, а не фрагментований контекст.
Від соло-продуктивності до колективної: що має змінитися в інструментах
Сьогоднішня хвиля агентних інструментів майже повністю зосереджена на масштабуванні індивідуальної продуктивності. Інтерфейси — переважно «single-player»: локальні CLI, приватні сесії, персональні агенти, які працюють на машині одного розробника.
Це логічно з точки зору короткострокового ефекту: легше продати обіцянку «стань у десять разів продуктивнішим» окремому інженеру, ніж перебудовувати командні процеси. Але в довгостроковій перспективі така модель впирається в жорстку межу: програмне забезпечення майже ніколи не створюється однією людиною в ізоляції.
Епплтон порівнює віру в те, що збільшення індивідуального виходу автоматично дає кращий продукт, із логікою «дев’ять жінок народять дитину за місяць». Є задачі, які принципово не масштабуються через додавання ресурсів, якщо не вирішені проблеми координації й комунікації.
У розробці це означає, що більше коду, більше PR-ів, більше агентів не розв’язують проблеми, які вимагають узгодженості. Навпаки, вони їх загострюють. Коли кожен розробник із власним набором агентів рухається «на повній швидкості» у своєму напрямку, команда втрачає спільний вектор.
Звідси випливає вимога до інструментів нового покоління: вони мають бути спроєктовані не як «турбо-двигуни» для окремих інженерів, а як середовища для колективної роботи з агентами. Місця, де:
люди різних ролей — розробники, дизайнери, продакти, сапорт — можуть одночасно бачити, що відбувається;
плани агентів прозорі й доступні для обговорення;
контекст бізнесу, продукту й історії природно вбудований у процес;
узгодження відбувається не раз на етапі PR, а постійно, паралельно з імплементацією.
GitHub Next, де працює Епплтон, уже експериментує з такими підходами в дослідницькому прототипі ACE (Agent Collaboration Environment) — мультиплеєрному середовищі для роботи з агентами, яке поєднує чат, спільний хмарний дев-середовище й можливість колективно керувати агентами в реальному часі. Але детальний розбір ACE — окрема тема.
У контексті цієї дискусії важливіше інше: сам факт, що всередині GitHub серйозно розглядають майбутнє, де класичні PR-и й задачі перестають бути центральними артефактами розробки, а на перший план виходять спільні сесії, живі розмови й прозорі плани агентів.
Висновок: швидкість без узгодженості — це просто швидше марнування зусиль
Агентні інструменти вже змінили розробку: вікно між ідеєю й реалізацією стиснулося до хвилин, а вартість написання коду стрімко падає. Але разом із цим стара проблема узгодженості вийшла на перший план і стала набагато дорожчою.
Якщо команди не встигають домовитися, що саме варто будувати, навіщо й у який спосіб, агенти лише прискорюють рух у неправильному напрямку. Замість «більше цінності за менший час» ми отримуємо «більше зайвої роботи за той самий час».
Меґґі Епплтон пропонує дивитися на це не як на технічну, а як на організаційну й інструментальну проблему. Реалізація поступово стає розв’язаною задачею; вузьким місцем стає здатність команд створювати й підтримувати спільний контекст.
Щоб агентна розробка справді працювала на користь продуктів, потрібен зсув фокусу: від соло-продуктивності до колективної узгодженості, від приватних CLI до спільних середовищ, від PR як головного місця для рецензії до безперервного циклу планування й реалізації, де агенти й люди працюють разом, а не паралельно.
У цьому сенсі головне питання для індустрії сьогодні звучить не «як зробити агентів ще розумнішими», а «як побудувати інструменти, які дозволять командам мислити разом із агентами, а не всупереч їм».
Джерело
Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub