AI-редактор коду Cursor продовжує радикально переформатовувати власний інтерфейс і внутрішню архітектуру. Співзасновник і технічний лідер продукту Девід Гомеш на конференції AI Engineer розповів, як команда викинула тисячі рядків нативної реалізації Git work tree й перевела паралельні робочі гілки в площину “markdown як код” і slash-команд. За цим, однак, стоїть не лише спрощення коду, а й нова модель взаємодії з агентами, зміна гарантій ізоляції та довгостроковий курс на Cursor 3.0.
Від дропдаунів до slash-команд: як тепер працюють work tree в Cursor
Історично work tree в Cursor були глибоко вшиті в клієнт: окремий UI, складна логіка створення й менеджменту Git work tree, жорстка ізоляція агентів, підтримка setup-скриптів, cleanup-механізми. Усе це дозволяло запускати кілька агентів паралельно, кожен у власному Git work tree, і не боятися, що модель “втече” в основний checkout.
Нова версія працює інакше. Work tree тепер живуть не в окремому нативному модулі, а в шарі “skills/commands”, які фактично описані в Markdown і керуються з сервера. Для користувача це проявляється в тому, що замість дропдаунів з’явилися slash-команди.
Ключова зміна інтерфейсу: work tree тепер викликаються через /worktree. Користувач просто вводить команду в чаті, додає завдання — наприклад, “виправити typo у футері сайту” — і Cursor запускає агента в окремому work tree, де той виконує роботу, не торкаючись основного checkout. Паралельно з’явилася команда /bestevent (best-of-N), яка організовує змагання кількох моделей над одним завданням, кожна у власному work tree.
До цього набору додали ще дві службові команди: apply_worktree і delete_worktree. Перша переносить зміни з побічного work tree в основний checkout, друга прибирає тимчасову гілку й звільняє диск. Разом вони закривають повний життєвий цикл: створити ізольоване середовище, попрацювати, застосувати зміни, прибрати за собою.
Важливий нюанс архітектури: формально це не “user skills”, а серверні команди. Проте працюють вони майже так само: їхні промпти підвантажуються в контекст лише тоді, коли користувач явно викликає команду. Це дає Cursor можливість змінювати й покращувати поведінку work tree на бекенді без оновлення клієнта: наступний виклик /worktree автоматично отримає оновлену інструкцію для моделі.
Паралельна робота в кількох репозиторіях: multi-repo як стандарт
Один із найбільш практичних виграшів нової реалізації — підтримка multi-repo-сценаріїв. У попередній нативній версії work tree просто не працювали, якщо проєкт складався з кількох репозиторіїв, наприклад окремих frontend і backend. Функцію доводилося вимикати, і користувачі з реальними продакшн-архітектурами залишалися без паралельних агентів.
Slash-команда /worktree знімає це обмеження. Тепер Cursor, отримавши завдання в такій конфігурації, створює окремий work tree для кожного репозиторію, який входить у робочий простір. Якщо користувач просить відкрити pull request, система відкриває кілька PR — по одному на кожен репозиторій, де були зміни.
Фактично, multi-repo-підтримка стала “побічним ефектом” того, що логіка винесена в промпти й агентні сценарії. Замість того, щоб жорстко кодувати обмеження в клієнті, Cursor описує бажану поведінку в Markdown-інструкціях: створити work tree там, де є Git, запустити setup-скрипти, тримати агента в межах відповідного каталогу, а потім синхронізувати результат через PR. Для користувача це виглядає як природне розширення можливостей, але під капотом — суттєва зміна парадигми.
Ще одна важлива нова можливість — динамічне підключення work tree посеред діалогу. Раніше роботу в ізольованій гілці потрібно було конфігурувати наперед через UI: обрати режим, налаштувати параметри, запустити агента. Тепер користувач може вести звичайну розмову з агентом, а коли розуміє, що настав час “відокремити” зміни, просто ввести /worktree і продовжити роботу вже в ізольованому середовищі. Це знижує когнітивне навантаження: не потрібно планувати структуру сесії заздалегідь, достатньо викликати потрібну примітивну операцію в момент, коли вона стала доречною.
Від жорсткої ізоляції до “ізоляції через промпт”: нові ризики
Найбільша концептуальна зміна стосується безпеки й передбачуваності поведінки моделей. Стара нативна реалізація work tree забезпечувала “залізобетонну” ізоляцію: моделі фізично не могли торкатися файлів за межами свого work tree. Усі команди, лінтери, операції з файлами були обмежені відповідним каталогом. Навіть якщо модель “хотіла” вийти за межі, інфраструктура просто не дозволяла цього зробити.
У новій skill-базованій версії таких гарантій немає. Ізоляція тримається на промптах: Cursor агресивно інструктує модель залишатися в межах конкретного work tree, не змінювати файли в основному checkout і не “тікати” в інші гілки. Це дає величезну гнучкість — логіку можна змінювати, не торкаючись клієнтського коду, — але одночасно відкриває двері для помилок моделей.
Команда Cursor прямо визнає: утримати агента “на рейках” стало складніше. Якщо раніше вихід за межі work tree був технічно неможливим, то тепер усе залежить від того, наскільки модель слухняно виконує інструкції в промпті. У складних сценаріях, коли в контексті багато файлів, команд і підказок, модель може “забути” про обмеження й почати змінювати основний checkout.
Це не теоретична проблема. Cursor уже бачить у своїх eval-тестах, що менші моделі, зокрема Claude Haiku, частіше “виходять із work tree” і вносять зміни в основну копію репозиторію. Великі моделі краще дотримуються інструкцій, але й вони не ідеальні. У результаті користувачі отримують змішаний досвід: частина спільноти цінує нову гнучкість і можливість керувати work tree через slash-команди, інша частина шкодує за старим UI і жорсткою ізоляцією, яка давала більше впевненості.
Це відображається й у фідбеку: Cursor фіксує, що реакція на нову реалізацію work tree неоднорідна, і відкрито визнає, що не всі задоволені змінами. Для продукту, який позиціонує себе як інструмент для серйозної розробки, це не дрібниця: довіра до того, що агент не зламає основну гілку, критично важлива.
Як Cursor тестує поведінку моделей: headless CLI, Braintrust і RL
Щоб не покладатися лише на інтуїцію й окремі користувацькі історії, Cursor вибудовує системну перевірку того, як моделі поводяться в новій архітектурі work tree. Для цього використовується headless-версія Cursor CLI, яка дозволяє проганяти сценарії без графічного інтерфейсу, та eval-інфраструктура на базі Braintrust.
Суть підходу проста: команда формулює завдання, де агент має працювати виключно в межах певного work tree, і дивиться, чи не “просочуються” зміни в основний checkout. Такі тести запускаються на різних моделях, що дозволяє порівнювати їхню дисциплінованість. Саме завдяки цим eval’ам Cursor помітив, що менші моделі на кшталт Claude Haiku частіше порушують обмеження, тоді як більші поводяться обережніше.
Ці спостереження не залишаються лише діагностикою. Cursor планує покращувати промпти для work tree саме через цикл eval → зміна промпта → повторний eval. Але на цьому компанія не зупиняється: work-tree-сценарії вбудовуються й у reinforcement learning-пайплайн власної моделі Composer.
Composer — це внутрішня модель Cursor, яку команда тренує під задачі програмування. Тепер до RL-пайплайну додаються завдання, де модель має працювати в стилі work tree: створювати ізольовані середовища, не виходити за їхні межі, коректно застосовувати зміни. Ідея полягає в тому, щоб майбутні версії Composer “з коробки” краще розуміли концепцію ізольованих робочих гілок і менше покладалися на жорсткі технічні обмеження.
Таким чином, перехід від нативної реалізації до skill-базованої не просто перекладає відповідальність на промпти. Він змушує Cursor будувати повноцінну інфраструктуру для вимірювання й навчання поведінки моделей у складних багатокрокових сценаріях, де важлива не лише якість коду, а й дотримання операційних правил.
Agent-centric Cursor 3.0 і повернення “нативних” work tree в новому вигляді
Паралельно з перебудовою work tree Cursor готує масштабні зміни в інтерфейсі. Версія 3.0 рухається до більш “агент-центричної” моделі: з’являється окреме вікно агента, яке стає центральним місцем взаємодії з AI у процесі розробки. Це не просто косметичний редизайн, а спроба зробити агентів повноцінними “учасниками” робочого процесу, а не лише доповненням до редактора.
У цьому контексті work tree розглядаються як одна з базових можливостей, яку варто глибше інтегрувати в новий агентний інтерфейс. Cursor прямо говорить про плани побудувати більш повну, “нативну” реалізацію work tree всередині нового agent window. Тобто нинішня skill-базована версія — не кінцева точка, а радше проміжний етап, який дозволяє швидко експериментувати з поведінкою й промптами, поки формується нова UI-парадигма.
Водночас команда дивиться й ширше за межі Git work tree. Практика показує, що створення work tree може бути повільним, особливо на великих репозиторіях; вони споживають помітний обсяг дискового простору й працюють лише там, де є Git. Для багатьох сценаріїв паралельної роботи цього виявляється зайвим.
Тому Cursor досліджує локальні примітиви паралелізації, які не залежать ані від work tree, ані від Git загалом. Ідея полягає в тому, щоб надати агентам можливість працювати в кількох “гілках реальності” локально — наприклад, через легковагові копії файлів чи інші форми ізольованих контекстів — без повноцінного Git-оверлею. Це може виявитися критичним для проєктів, де Git використовується нетипово або взагалі відсутній, але потрібна паралельна робота кількох агентів над різними варіантами змін.
У результаті майбутнє work tree в Cursor виглядає як багаторівнева система: з одного боку, класичні Git work tree для тих, хто хоче інтегруватися з існуючими CI/CD-пайплайнами й PR-процесами; з іншого — легші локальні механізми паралелізації, які можуть бути швидшими й універсальнішими. Обидва шари мають бути доступні агентам через новий agent-centric інтерфейс.
Між гнучкістю й гарантіями: куди рухається інструментарій AI-розробки
Історія work tree в Cursor добре ілюструє загальну напругу, з якою стикаються розробники AI-інструментів. З одного боку, є спокуса “зашити” поведінку в жорсткий нативний код, який дає чіткі гарантії: моделі не можуть вийти за межі дозволеного, інфраструктура контролює кожен крок. З іншого — світ LLM змінюється настільки швидко, що підтримка тисяч рядків спеціалізованого коду стає тягарем, а гнучкість промптів і серверно-керованих skills дозволяє реагувати на нові можливості й моделі значно швидше.
Перехід Cursor до slash-команд /worktree і /bestevent, появи apply_worktree та delete_worktree, підтримки multi-repo й можливості перемикатися в work tree посеред чату — усе це кроки в бік більш гнучкої, агентно-орієнтованої архітектури. Але вони ж оголюють слабкі місця: моделі не завжди слухаються, менші моделі частіше порушують ізоляцію, а частина користувачів відчуває, що втратила звичну надійність старого UI.
Відповідь Cursor — не відкат до старої нативної реалізації, а інвестиції в інфраструктуру вимірювання й навчання: headless CLI, Braintrust-eval’и, RL-тренування Composer на work-tree-подібних задачах, а також розробка нових локальних примітивів паралелізації, які можуть доповнити або частково замінити Git work tree.
У підсумку work tree в Cursor перетворюються з “фічі в меню” на повноцінний дослідницький полігон для того, як мають поводитися AI-агенти в реальних розробницьких середовищах: як вони створюють ізольовані контексти, як дотримуються обмежень, як синхронізують зміни назад у основну гілку й як співіснують із людськими розробниками, які очікують від інструменту не лише креативності, а й дисципліни.
Джерело
YouTube: Replacing 12K LoC with a 200 LoC Skill — David Gomes, Cursor