Інженер Cursor Ерік Закаріассон працює на стику продукту й developer experience і відкрито говорить: повністю автономної «темної фабрики» ПЗ ще немає, але окремі її конвеєри вже працюють. Cursor, який кілька років тому стартував як «пікантний автодоповнювач» у VS Code, сьогодні перетворюється на середовище, де тисячі агентів паралельно пишуть, тестують і перевіряють код. Ключ до цього — не лише моделі, а й інфраструктура: ізольовані хмарні віртуальні машини, повноцінний віддалений UI‑інтерфейс Glass та автоматизовані петлі зворотного зв’язку навколо pull‑реквестів.
Ця стаття розбирає, як саме Cursor масштабує роботу агентів до рівня фабрики: від архітектури хмарних агентів до системи Bugbot, «agentic code owner» та автоматизацій, які вчать агентів на реальних помилках.
Від одного агента до тисяч: чому спільний dev‑env більше не працює
Поки більшість розробників живе в парадигмі «я + один AI‑пейр», Cursor уже щодня запускає «множинні тисячі» хмарних агентів на копіях свого основного репозиторію. Це не просто масштабування кількості запитів до LLM — це масштабування повноцінних робочих середовищ.
Класичний підхід до агентів у розробці виглядає так: є один dev‑environment — локальний або віддалений, — у ньому по черзі працюють люди й агенти. Поки агентів мало, це терпимо. Але щойно з’являється десяток чи сотня паралельних процесів, спільне середовище стає джерелом хаосу. Файлова система засмічується тимчасовими артефактами, конфігурації роз’їжджаються, залежності конфліктують, а відтворити конкретний збій стає майже неможливо.
Cursor відповідає на це радикально: оновлені хмарні агенти запускаються кожен у власній віртуальній машині. Замість того, щоб ділити один dev‑env, кожен агент отримує окремий, відтворюваний простір, де він може:
- розгорнути копію кодової бази;
- встановити залежності;
- запустити dev‑сервер;
- виконати тести;
- залишити артефакти для аналізу.
Це не просто питання «чистоти» середовища. Ізоляція дає дві критичні властивості: масштабованість і детермінованість. Якщо кожен агент стартує з однакового образу VM і однакових інструкцій, його поведінка стає набагато передбачуванішою. Те, що спрацювало вчора, з великою ймовірністю спрацює й сьогодні, а будь-який збій можна відтворити, піднявши таку саму VM з тим самим кодом.
Ерік прямо рекомендує: коли мова заходить про «багато агентів», варто відмовитися від ідеї спільного dev‑середовища. Спільний простір неминуче «псується» — і для людей, і для моделей. Ізольовані хмарні VM перетворюють кожен агентський запуск на контрольований експеримент, а не на ще один крок у бік ентропії.
Відтворювані середовища як основа фабрики ПЗ
Ізольована VM — лише контейнер. Справжня цінність з’являється тоді, коли всередині неї можна швидко й надійно відтворити робоче середовище. Cursor будує хмарних агентів так, щоб кожен із них умів самостійно підняти повноцінний dev‑env у хмарі.
Це означає, що агент не просто читає код і генерує патчі. Він:
- клонує або отримує копію репозиторію;
- орієнтується в структурі проєкту;
- знаходить стандартні точки входу, на кшталт
package.jsonізstart‑скриптом; - запускає сервер розробки;
- виконує тести, включно з end‑to‑end, якщо вони є.
У демонстраційному музичному проєкті з інтерфейсом на кшталт Ableton агент самостійно читає package.json, знаходить start‑скрипт і піднімає локальний сервер на localhost:3000. Це показовий приклад того, що Ерік називає «бути в дистрибуції моделей»: якщо проєкт дотримується поширених патернів (типові скрипти, стандартні структури), агентам набагато легше його зрозуміти й запустити.
Відтворюваність середовища тут критична. Якщо кожен агентський запуск — це окрема VM з однаковим способом старту, можна:
- паралельно запускати тисячі агентів без конфліктів;
- відтворювати будь-який сценарій, який привів до бага;
- будувати на цьому автоматизовані конвеєри, де агенти не просто пишуть код, а й самі його тестують.
Фактично, Cursor перетворює «запуск агента» на аналог CI‑джоби, але з набагато ширшим діапазоном дій: від рефакторингу до UI‑регресії.
Glass: повноцінний віддалений комп’ютер під контролем агентів
Навіть добре налаштовані тести не завжди покривають поведінку інтерфейсу. Особливо, коли йдеться про складні UI‑взаємодії: анімації, лоадери, drag‑and‑drop, гарячі клавіші. Для людини очевидно, чи «відчувається» інтерфейс правильно. Для агента, який бачить лише DOM і API, це вже складніше.
Щоб скоротити цей розрив, Cursor дає хмарним агентам доступ до повноцінного віддаленого комп’ютерного інтерфейсу під назвою Glass. Це не абстрактний headless‑браузер, а керований агентом «десктоп», де він може:
- відкривати застосунок або веб‑інтерфейс;
- клікати по елементах;
- вводити текст;
- взаємодіяти з UI так, як це робить людина.
Ключова деталь — Glass уміє записувати відео цих сесій. У результаті кожен автономний прогін агента може залишати не лише логи й результати тестів, а й візуальний артефакт: як саме агент клікав, що бачив, як поводився інтерфейс.
Це вирішує одразу кілька проблем.
По‑перше, верифікація змін. Якщо агент вніс правки в UI, запустив застосунок у Glass і «проклікав» сценарій, команда отримує відео, де видно, чи справді кнопка тепер працює, чи з’явився лоадер, чи не зламався флоу.
По‑друге, дебаг поведінки агентів. Коли агент «робить щось дивне» у UI, це важко зрозуміти лише з текстових логів. Відеозапис взаємодії в Glass дозволяє побачити, де саме він «заблукав»: не впізнав кнопку, неправильно інтерпретував стан, зациклиться на кроці.
По‑третє, це ще один рівень автоматизованої перевірки. У поєднанні з unit‑, інтеграційними та e2e‑тестами Glass додає шар «людиноподібної» взаємодії, яку можна запускати масово й паралельно, не залучаючи реальних користувачів.
У музичному проєкті, який Ерік зібрав повністю через агентів, UI‑перевірки виконуються за допомогою Playwright‑тестів: агенти перевіряють, чи працює кнопка Play, чи можна редагувати ноти. Glass розширює цей підхід до повноцінного віддаленого комп’ютера, де агент може не лише запускати тести, а й самостійно «програвати» сценарії.
Автоматизований рев’ю‑конвеєр: Bugbot і «agentic code owner»
Якщо агенти пишуть і тестують код у тисячах ізольованих середовищ, наступне вузьке місце — рев’ю. Людський час обмежений, а фабрика ПЗ втрачає сенс, якщо кожен дрібний PR блокується на ручному перегляді.
Cursor будує навколо цього окремий автоматизований конвеєр. Один із його елементів — Bugbot, внутрішній інструмент, який переглядає GitHub‑pull‑реквести й повертає фідбек. Bugbot виступає як перший фільтр якості: аналізує зміни, шукає потенційні проблеми, формує коментарі.
Але справжня інженерія починається далі — з системи, яку в Cursor називають «agentic code owner». Вона поєднує ідею класичних code owners із агентською автономією.
Система оцінює ризик кожного PR. Якщо зміни невеликі, локалізовані й не торкаються критичних ділянок, PR може бути автоматично затверджений без участі людини. Це дозволяє пропускати через фабрику велику кількість низькоризикових змін, не перевантажуючи команду рев’ю.
Якщо ж PR зачіпає складні або чутливі частини кодової бази, «agentic code owner» маршрутизує його до конкретних людей — тих, хто раніше редагував відповідні файли. Це важливий нюанс: замість абстрактного «хтось із команди має подивитися», система знаходить найрелевантнішого експерта за історією комітів.
У підсумку виходить багаторівневий конвеєр:
- агенти генерують зміни в ізольованих VM, тестують їх і формують PR;
- Bugbot робить первинний автоматизований рев’ю;
- «agentic code owner» оцінює ризик і або автоапрувить PR, або відправляє його на таргетований людський перегляд.
Це не «темна фабрика» в чистому вигляді — люди залишаються в ланцюгу для високоризикових змін. Але для великого класу задач рев’ю вже перетворюється на автоматизований сервіс, а не на вузьке місце.
Особисті автоматизації: як агенти беруть на себе статус‑трекінг і навчання
Фабрика ПЗ у Cursor — це не лише про кодову базу компанії. Ерік активно використовує ті самі механізми для власної роботи, фактично делегуючи агентам частину особистого менеджменту.
Один із прикладів — щоденний огляд активності. Автоматизація в Cursor збирає інформацію з Slack і GitHub, підсумовує, над чим він працював, які PR створював або переглядав, які обговорення вів. Агент формує з цього дайджест, який замінює ручне ведення статус‑нотаток. Це звільняє когнітивний ресурс: замість того, щоб згадувати, що саме робив учора, можна просто прочитати зведення.
Інша автоматизація працює поверх коментарів до вже злитих PR. Вона читає фідбек колег, відфільтровує «високосигнальні» зауваження — ті, де є реальні корекції або важливі застереження, — і використовує їх як навчальний матеріал для агентів. Таким чином, людські коментарі перестають бути одноразовими: вони перетворюються на дані, які формують майбутню поведінку системи.
Це підводить до ще одного важливого елемента фабрики — «continue learning»‑автоматизації. Cursor регулярно проглядає минулі транскрипти роботи агентів, шукає в них місця, де люди виправляли помилки або уточнювали інструкції, і перетворює ці корекції на нові правила. Фактично, кожен промах агента стає сировиною для покращення:
- агент зробив щось неправильно;
- людина втрутилася, пояснила, як треба;
- автоматизація витягла цю корекцію;
- на її основі сформовано нове правило або уточнення;
- наступні агенти вже стартують із урахуванням цього досвіду.
Це замкнений цикл: виконання → фідбек → екстракція знань → оновлення правил → нове виконання. На відміну від класичного ML‑тренування, тут не потрібно чекати великого релізу моделі — поведінка агентів еволюціонує разом із кодовою базою й процесами команди.
Від правил до середовищ: як усе це замикається в одну систему
Усі описані елементи — ізольовані VM, Glass, Bugbot, «agentic code owner», особисті автоматизації — працюють лише в поєднанні з більш базовими речами, про які Ерік говорить окремо: структурою кодової бази, правилами для агентів і можливістю верифікувати їхню роботу.
Cursor використовує файл agents.md у репозиторії як джерело правил для агентів. Це не статичний набір директив, а живий документ, який еволюціонує разом із проєктом. Ерік підкреслює: правила краще додавати реактивно, коли агенти «з’їжджають з рейок», а не намагатися встановити всі можливі з колекції Cursor Directory наперед. У цьому сенсі «continue learning»‑автоматизація — просто систематизація того, що й так відбувається в зрілих командах: помилки перетворюються на політики.
Не менш важливе питання — середовище, в якому агенти працюють. Якщо проєкт не можна запустити однією командою, якщо немає стандартних скриптів, якщо тести відсутні або ненадійні, жодна кількість агентів і VM не перетворить його на фабрику. Саме тому в демонстраційному музичному проєкті так багато уваги приділено стандартним патернам: package.json із start‑скриптом, Playwright‑тести, зрозуміла структура.
На цьому тлі Glass і хмарні VM виглядають не як «магія», а як логічне продовження: якщо код структурований, середовище відтворюване, а правила чіткі, агенти можуть не лише писати й тестувати код, а й самостійно запускати повноцінні UI‑сценарії, залишаючи відео й логи для людей і наступних агентів.
Висновок: фабрика ПЗ вже працює — але як набір конвеєрів
Cursor ще не живе в світі повністю «темної фабрики», де люди лише задають наміри, а агенти невидимо будують і розгортають системи. Але окремі конвеєри вже функціонують: тисячі хмарних агентів щодня працюють у копіях основного репозиторію, тестують свої зміни в ізольованих VM, взаємодіють із UI через Glass, проходять через Bugbot і «agentic code owner», а їхні помилки перетворюються на нові правила через автоматизовані петлі навчання.
Ключовий урок із цього досвіду — фабрика ПЗ починається не з моделі, а з інфраструктури й процесів. Ізольовані середовища, відтворювані dev‑конфігурації, стандартизовані патерни запуску, автоматизовані рев’ю й систематичне перетворення людського фідбеку на правила — усе це робить можливим світ, де один розробник може керувати не одним агентом‑пейрінгом, а цілим парком агентів, що працюють паралельно.
Для команд, які сьогодні лише експериментують із AI‑помічниками, досвід Cursor дає орієнтир: шлях від «спеційного автодоповнювача» до фабрики лежить через ізоляцію, верифікацію й замкнені цикли навчання. Агенти вже вміють писати код. Завдання інженерів — побудувати для них правильний завод.
Джерело
YouTube: Building your own software factory — Eric Zakariasson, Cursor