Remote Agents у продакшені: від Jira до PR без участі розробника

Уявіть масштабний проєкт: 40 інженерів, рік роботи і 10 000 пул-реквестів. Саме так створювався новий редактор Wix Harmony. Але після релізу залишилася класична проблема — суттєвий беклог дрібних задач. Озброїти розробників сучасними ШІ-інструментами не допомогло б: практика показує, що рутинні мікрозадачі забирають забагато ресурсів, а тікети нікуди не зникають. Тоді в команди виникла ідея: що, як асайнити Jira-тікети напряму на автономного агента без залучення людей?

Данило Колесніков, Engineering Team Lead у Wix, поділився досвідом використання автономних ШІ-агентів у розробці. Під час виступу на конференції AI JavaScript fwdays'26 він розповів, як штучний інтелект може самостійно закривати Jira-тікети й генерувати готові Pull Requests без участі людини, а також про можливості методології Spec Driven Development (SDD). Публікуємо найважливіше з виступу.

Ремоут агенти та чому ми відмовилися від готових рішень

Remote agent — це автономний, event-driven агент, який запускається у власному ізольованому середовищі, має повний доступ до вашої кодової бази і виконує кодінг або дослідницькі задачі. Головна його фішка — принцип «no human in the loop», тобто абсолютна відсутність людини в цьому процесі.

Так виглядає схема найпростішої архітектури такого агента. Щоб його побудувати, вам потрібна віртуальна машина зі встановленим ШІ-агентом та вашим dev-середовищем. До цього прикручується REST API, який слухає запити і за певними івентами викликає агента в headless-режимі для виконання переданих промптів.

Тут виникає логічне запитання: навіщо піднімати власні сервери, налаштовувати інфраструктуру та писати кастомні скрипти, якщо на ринку вже повно готових і зручних рішень? Але є дві критичні проблеми:

1. Інфраструктура та VPN. У великих компаніях інфраструктура просто так недоступна ззовні. Навіть якщо вам вдасться обійти обмеження та клонувати репозиторій з GitHub на зовнішню віртуальну машину, ви все одно не зможете завантажити внутрішні корпоративні пакети або виконати збірку проєкту.

   
   

2. Безпека (Security & Privacy). Усі сторонні cloud-агенти працюють за принципом клонування репозиторію на свої сервери для виконання задач. З точки зору безпеки великої компанії — це погана ідея, оскільки ви втрачаєте контроль над тим, куди потрапляє ваш код.

   
   

Тому ми пішли власним шляхом і створили внутрішню інфраструктуру — продукт під назвою BCA (Background Coding Agents). Він базується на тій самій архітектурі віртуальних машин, але є значно складнішим сервісом. Головна його перевага в тому, що він працює виключно всередині нашої захищеної інфраструктури, що дозволяє безпечно делегувати агенту кодінг-задачі будь-якої складності.

Від One-shot до Spec Driven Development

Отже, ми маємо ізольовану інфраструктуру та агента, якому можна делегувати задачі. Що далі? Можна використати так званий ван-шот, коли ви кидаєте агенту промпт у стилі «пофікси мені цей баг», він думає і видає готовий Pull Request.

Але кожен, хто намагався серйозно використовувати цей підхід, знає: ван-шоти не працюють. Агент дійсно може згенерувати якийсь код і навіть створити PR, але що саме він наробив, часто залишається абсолютно незрозумілим. Код, написаний ШІ без контексту, дуже важко рев'ювити.

Ми почали шукати інший підхід. Спочатку еволюціонували від звичайного промптингу (написав промпт → отримав код → не сподобалося → пишеш новий промпт) до plan mode, коли агент спочатку генерує план дій, а вже потім ти натискаєш кнопку «build» і отримуєш код. Але і це не вирішувало проблеми повністю, адже згенеровані плани часто кудись зникали, а якщо код все одно не підходив, було неясно, що робити далі: знову промптити чи переписувати план.

Відповіддю на ці виклики стала методологія Spec Driven Development (SDD).

По суті, SDD — це підхід, який змушує вас (або вашого агента) спочатку документувати систему, а вже потім писати код. Завдяки LLM ця методологія отримала друге дихання, адже вона ідеально структурує «думки» штучного інтелекту.

Замість того, щоб одразу генерувати код, агент проходить три чіткі фази:

1. Бізнес-вимоги. Агент аналізує задачу, задає запитання, досліджує існуючі специфікації і намагається зрозуміти, що взагалі система має робити. Результатом цієї фази є артефакт — файл spec.md, який відповідає на питання «Що ми робимо?». На цьому і наступному етапі писати код суворо заборонено. 

2. Технічний дизайн. Агент аналізує середовище, оцінює ризики, трейдофи та пропонує варіанти реалізації. На виході ми отримуємо design.md, який відповідає на питання «Як ми це робимо?», а також детальний task-брейкдаун — розбивку на конкретні кроки для імплементації.

3. Імплементація. Лише тепер агент починає писати код, спираючись на попередньо створені специфікації та дизайн, суворо слідуючи згенерованим таскам.

Чому це працює значно краще за звичайний промптинг? У такий спосіб ми змушуємо агента збирати максимум контексту. Цей процес імітує класичний флоу живого інженера. SDD робить агента мудрішим: він не вгадує, а діє на основі фактів та зібраного контексту. Його наміри чітко зафіксовані в Markdown-файлах, де інженер завжди може їх перевірити та скоригувати до того, як буде написаний перший рядок коду.

Інструменти для SDD: OpenSpec vs Spec Kit

Чи потрібно писати пайплайни та скіли самостійно, впроваджуючи Spec Driven Development? На ринку вже є готові фреймворки. Найпопулярніші з них — це OpenSpec, Spec Kit від GitHub, а також Kiro від AWS. Ми найбільше працювали з OpenSpec та Spec Kit. Про їхні переваги можна прочитати у README-файлах, тому нижче — про їхні реальні недоліки.

OpenSpec: його головна проблема — відсутність вбудованого циклу рев'ю з коробки. Тобто ви не можете легко попросити агента проаналізувати його ж власні відкриті питання і перевірити, чи вони взагалі мають сенс. Крім того, інструмент не починає з глибокого ресерчу, а одразу видає пропозицію, а в самому форматі специфікацій відсутні класичні user stories. Хоча загалом свою роботу він виконує добре.

Spec Kit: тут інша крайність — якщо ви спробуєте створити таску через Spec Kit, ви можете отримати одразу 9 різних файлів (реквайрменти, дизайн, розбивка на задачі тощо). Це створює величезне когнітивне навантаження під час рев'ю: іноді простіше махнути рукою, заапрувити, не читаючи, щоби агент вже почав писати код. Крім того, Spec Kit має дуже жорсткі рейки методології. Він самостійно створює гілки з певною нумерацією і не дозволяє перестрибувати кроки — наприклад, ви не можете почати писати імплементацію, якщо не згенерували план. Ця жорстка дисципліна ідеальна, якщо ви тільки знайомитесь із Spec Driven Development, але для більш просунутого використання OpenSpec є гнучкішим.

Але виникає нове питання: що взагалі робити з усіма згенерованими MD-файлами? З одного боку, вони є важливою частиною Pull Request. Рев'ювити чистий код, коли є супровідні документи, які пояснюють мотивацію ШІ, чому він обрав саме такий трейдоф і які питання ставив — значно простіше. З іншого боку, в довгостроковій перспективі це стає проблемою. Уявіть команду з 40 розробників: якщо кожен генеруватиме по 10 специфікацій щодня, за місяць ви отримаєте тисячі файлів. Це відкрите питання для всієї індустрії. Хтось зберігає їх безпосередньо в репозиторії, ми ж зараз думаємо над створенням окремої Knowledge Base, куди автоматично зливатимуться ці специфікації.

Як оркеструвати скіли

Spec Driven Development (SDD) чудово працює локально, коли ви самі керуєте процесом. Щоби змусити ремоут-агента автономно проходити всі ці етапи, потрібно правильно оркеструвати SDD-скіли.

Для цього є декілька варіантів. Спочатку ми спробували піти найпростішим шляхом — створити так званий Master Skill. Це один великий пайплайн, який буквально наказує агенту: «Запусти proposal, потім зроби план, а потім імплементуй». Але на практиці під капотом запускається один агент, контекст якого дуже швидко перевантажується. У результаті він доходив до третього кроку і радісно рапортував, що все зробив, хоча насправді виконав лише два перші кроки. Тому ми змінили підхід і написали Bash-скрипт, який розбиває процес на чіткі стадії, де кожен крок — це окремий, ізольований агентський підпроцес, сфокусований виключно на своїй частині задачі.

Як виглядає цей автономний флоу під капотом:

1. Parse: він бере таску, йде в Jira або Slack, витягує весь необхідний контекст, розкладає його по поличках і передає на наступну фазу.

2. Propose: на цьому етапі формується сама специфікація.

3. Review: автономно змушуємо агента порев'ювити щойно створену ним же специфікацію. Просимо його перевірити, чи немає там логічних дір, чи є відкриті питання, і чи правильно він взагалі мислить.

4. Design & Code: генерується технічний дизайн і, нарешті, пишеться код.

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

Саме ця архітектура пайплайну і стала фундаментом для нашого головного ШІ-працівника на ім'я Nota. Життєвий цикл задачі для неї виглядає так: агент працює на основі подій — тригером може стати створення тікета в Jira або повідомлення у Slack-треді. Спочатку скрипт програмно (без залучення ШІ) збирає весь необхідний контекст та підключає потрібні API. Після цього запускається Nota, яка проходить усі етапи SDD: брейншторм, специфікація, дизайн і код. У фіналі Nota самостійно створює Pull Request у GitHub, залишає там зібрані артефакти (Markdown-файли з мотивацією та описом трейдофів) і відправляє повідомлення в Slack про завершення роботи.

Ціна питання, фейли та перемоги

Наразі у Wix щомісяця запускається близько 3000 таких remote-coding задач. Якщо говорити про вартість, то запуск одного пайплайну виконання обходиться приблизно у 40 центів. 

Щоб перевірити ефективність, ми взяли 10 звичайних задач і віддали їх на виконання Nota.

Результати:

• 2 задачі — ідеальні Pull Requests.

• 2 задачі — просто впали без результату (що теж буває, і це нормально).

• 3 задачі — провалили етап валідації. Це стало для нас важливим інсайтом: ми зрозуміли, що в пайплайні обов'язково має бути етап self-verification, щоб агент міг сам себе виправляти ще до перевірки на CI.

• 3 задачі — завершилися частковим успіхом. Це ситуації, коли агент згенерував необхідні артефакти, почав писати код, але фіча виявилася зробленою лише наполовину.

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

Звісно, у цього підходу є і свої мінуси. По-перше, ви платите часом: першого рядка коду можна чекати хвилин 30. По-друге, потрібна жорстка дисципліна. Якщо не використовувати фреймворки чи тули, які тримають вас у межах процесу, дуже легко здатися і скотитися назад у звичайний, хаотичний промптинг. Але якщо вибудувати правильний процес — інвестиції часу повністю себе виправдовують.

Отже, Spec Driven Development дійсно працює. Якщо ви досі не тестували цей підхід, раджу експериментувати з різними фреймворками та інструментами. Нам усім час переходити від простого написання промптів до фази справжнього AI Engineering. Якщо методологія SDD успішно запрацює у вас локально, ви без проблем зможете побудувати власного ремоут-агента, який буде автономно слідувати заданому флоу. Аналізуйте свою рутину, оркеструйте скіли та вибудовуйте пайплайни. Робіть своїх штучних помічників розумнішими та кращими.