У світі розробки програмного забезпечення зараз відбувається тиха, але радикальна зміна: IDE перестають бути просто «редакторами з підказками» і перетворюються на середовища, де основну роботу виконують агенти. Один із найяскравіших прикладів цієї трансформації — Cursor, інструмент, над яким працює інженер з developer experience та продукту Ерік Закаріассон. Він активно «догфудить» Cursor у власній щоденній роботі, намагаючись підштовхнути розробку до вищих рівнів автономії — аж до концепції «software factory».
Сьогодні Cursor уже не просто «гостре автодоповнення» поверх VS Code. Команда повністю переписала продукт у вигляді окремого застосунку Cursor 3, запущеного всього за кілька тижнів до цієї розмови, і спроєктувала його навколо агент‑першого робочого процесу. Ця зміна архітектури та філософії безпосередньо пов’язана з ідеєю програмної фабрики — але водночас тверезо визнається: повністю «темної фабрики» ще немає, автономно працюють лише окремі підсистеми.
Від таба до агента: як народився Cursor
Початкова версія Cursor з’явилася приблизно у 2022–2023 роках і була типовим продуктом своєї епохи: VS Code‑базований редактор з «spicy autocomplete» — агресивнішим, контекстнішим автодоповненням, ніж звикли бачити розробники. Фактично це був еволюційний крок від класичних підказок коду до інструменту, який уже міг пропонувати цілі блоки логіки, а не лише завершувати рядки.
У цій парадигмі розробник залишався в центрі: він писав код, а модель допомагала. Це відповідало нижчим рівням автономії, які описують багато дослідників агентних систем: людина керує курсором, IDE лише підсилює її продуктивність.
З часом Cursor почав рухатися «вгору по сходах» автономії. Замість того, щоб просто підказувати наступний рядок, інструмент став брати на себе дедалі більші шматки роботи: від генерації цілих модулів до виконання складних рефакторингів. Але справжній злам стався тоді, коли команда вирішила, що VS Code як основа більше не відповідає амбіціям агент‑першого підходу.
Чому довелося вийти з тіні VS Code
Перепис Cursor у вигляді окремого застосунку — це не просто технічне рішення, а відображення зміни ролей між людиною та інструментом. Cursor 3, запущений лише за кілька тижнів до виступу Закаріассона, повністю відмовився від VS Code як фундаменту. Замість цього з’явився самостійний IDE, спроєктований «з нуля» під агент‑перший сценарій.
Класичний VS Code‑подібний інтерфейс — з панелями файлів, вкладками, численними сайдбарами — оптимізований для ручного редагування. Людина відкриває файли, переходить між ними, запускає термінал, керує тестами. Агенти в такому середовищі радше «гості», ніж повноправні учасники процесу.
Cursor 3 навмисно спрощує й «вирівнює» інтерфейс, щоб зробити його природним для агентів. Замість того, щоб підлаштовуватися під UX, створений для людини, команда будує UX, де людина дедалі більше нагадує менеджера, а не виконавця. Це означає інші пріоритети: менше мікроконтролю над кожним файлом, більше — над завданнями, цілями, перевіркою результатів.
Така архітектурна зміна відкриває шлях до сценаріїв, де IDE не просто допомагає писати код, а самостійно запускає дев‑сервери, досліджує репозиторій, пише тести, запускає їх і повертає людині вже перевірений результат. Саме під це й заточений Cursor 3.
Рівні автономії: від парного програмування до «чорної фабрики»
Щоб зрозуміти, де зараз знаходяться інструменти на кшталт Cursor, Закаріассон апелює до ідеї рівнів автономії в розробці ПЗ. У спрощеному вигляді ця шкала описує шлях від ручного програмування з підказками до повністю автоматизованої «software factory».
На нижчих рівнях розробник використовує агента як розумного співрозмовника: ставить питання, просить згенерувати фрагмент коду, отримує пропозиції. Це те, що сьогодні робить більшість користувачів AI‑інструментів: парне програмування з одним агентом, де людина залишається основним виконавцем.
Наступний крок — коли більшість коду вже пише агент, а людина стає рецензентом. Вона переглядає зміни, стежить за трасами виконання, коригує курс. Це все ще «розробник у циклі», але обсяг ручної роботи суттєво зменшується.
Закаріассон оцінює власну практику як приблизно четвертий рівень автономії для більшості проєктів: він намагається делегувати агентам максимум роботи, а сам зосереджується на постановці задач і перевірці результатів. Важлива деталь: перевіряє він насамперед не сирий код, а вихідні артефакти — поведінку системи, тести, кінцевий результат. До коду він усе ще іноді повертається, але це вже не основний об’єкт уваги.
Над усім цим висить ідея «software factory» — системи, яка працює як «чорна скринька» або «темна фабрика». У такій фабриці агенти самі планують, пишуть, тестують і постачають код, а людина лише задає наміри, цілі й обмеження. Закаріассон прямо говорить: до цього стану ще далеко, і сьогодні автономно працюють лише окремі частини продукту й компанії. Але саме під цю довгострокову мету й перебудовується Cursor.
Навіщо взагалі прагнути «програмної фабрики»
Ідея «фабрики ПЗ» звучить привабливо, але за нею стоять цілком прагматичні мотиви.
Перший — пропускна здатність. Агенти можна запускати цілодобово, у будь‑якій кількості, без обмежень, притаманних людям: сну, втоми, контекстних перемикань. Якщо вдається побудувати надійні «конвеєри» — послідовності кроків від задачі до готового коду — то обсяг виробленого ПЗ за одиницю часу зростає без лінійного збільшення людських ресурсів.
Другий — консистентність. Класична фабрика цінна не лише швидкістю, а й передбачуваністю: однакові деталі, однакові допуски, однакові процеси. У розробці ПЗ це означає стабільні патерни архітектури, єдині підходи до тестування, повторювані сценарії розгортання. Якщо «збірочні лінії» для коду налаштовані правильно, агенти можуть відтворювати ці патерни з високою стабільністю.
Третій — масштабування смаку й креативності. Людський смак — у дизайні API, виборі архітектурних компромісів, формулюванні продуктового бачення — залишається унікальним ресурсом. Фабрика дозволяє розмножити цей смак у коді, не змушуючи людину власноруч реалізовувати кожну ідею. Розробник перетворюється на креативного директора, який задає напрям, а не на «руки», що втілюють задум.
Водночас спроба побудувати таку фабрику швидко виявляє зворотний бік: без правильних обмежень агенти поводяться дедалі більш «ймовірнісно», втрачається відчуття детермінізму. Це сигнал, що потрібні кращі «огорожі» — структуровані кодові бази, чіткі правила, перевірювані системи.
Примітиви та патерни: як підготувати код до агентів
Ключ до агент‑першого IDE — не лише в інтерфейсі, а й у тому, як влаштований сам код. Закаріассон описує це як роботу з примітивами та патернами.
Під примітивами мається на увазі базова структура кодової бази. Чи є вона модульною? Чи зосереджені пов’язані частини поруч, чи розкидані по всьому репозиторію? Для агента, який «дивиться» на проєкт через файлову систему, це критично. Якщо, умовно, простий ls у директорії показує всі релевантні файли для певної задачі, агент може локалізувати роботу в межах одного модуля. Якщо ж логіка розмазана, йому доводиться «grep’ати» весь репозиторій, що збільшує хаос.
Це, до речі, однаково важливо і для людей: кодова база, в яку легко онбордитися людині, зазвичай так само дружня до агентів. Чіткі кордони модулів, зрозуміла структура директорій, передбачувані назви файлів — усе це знижує когнітивне навантаження для обох.
Другий шар — патерни використання. Чи є в проєкті стандартні способи аутентифікації користувача? Чіткі сервіси для роботи з даними? Уніфіковані скрипти запуску? Типові підходи до написання тестів? Якщо так, агентам можна показати існуючі приклади й попросити їх «відтворювати» ці патерни в новому коді. З часом це формує щось на кшталт внутрішньої «мови фабрики», яку агенти вивчають і наслідують.
Показовий приклад — демо‑проєкт «music agent», який Закаріассон зібрав повністю через агентів, не пишучи код вручну. Інтерфейс нагадує Ableton чи інше музичне ПЗ: таймлайни, кліпи, кнопки відтворення. Щоб агент зміг самостійно запустити дев‑сервер, йому достатньо було знайти package.json і стандартний start‑скрипт. Такі файли настільки «в розподілі» для сучасних моделей, що вони інтуїтивно шукають їх першими. Якщо проєкт дотримується цих звичних патернів, агент без додаткових підказок здогадується, як його запустити.
Інакше кажучи, «бути в дистрибуції» для моделей — означає будувати проєкти так, щоб вони виглядали як типові сучасні репозиторії, а не як унікальні експерименти зі структурою.
Правила як живий SOP: чому не варто ставити все одразу
Окрема вісь еволюції Cursor — система правил, яку інструмент читає з файлу agents.md у репозиторії. Це свого роду «інструкція з експлуатації» для агентів: що їм дозволено, чого слід уникати, які особливості має саме цей проєкт.
Разом із запуском цієї системи Cursor опублікував «каталог» правил — cursor directory — з прикладами для різних стеків, зокрема для Next.js. Логічною, але помилковою реакцією багатьох користувачів стало бажання «поставити все»: якщо є набір правил для мого фреймворку, чому б не підключити їх усі?
Практика показала, що це не найкращий шлях. Закаріассон описує інший підхід: правила мають виникати реактивно, як відповідь на конкретні збої поведінки агентів. Якщо агент «з’їжджає з рейок» у певному сценарії — наприклад, постійно чіпає чутливий модуль чи обирає неправильний шлях реалізації — саме тоді варто додати правило, яке це обмежує або спрямовує.
У цьому сенсі agents.md більше схожий на живий SOP (standard operating procedure), ніж на статичний конфіг. Він еволюціонує разом із проєктом, відображаючи реальні граблі, на які наступають агенти. Із покращенням моделей, які дедалі краще слідують інструкціям, така система стає ще ефективнішою: достатньо чітко сформулювати правило, і агент рідше виходитиме за його межі.
Важливий аспект правил — захист критичних зон. Є частини кодової бази, де помилка особливо дорога: шифрування, обробка чутливих даних, аутентифікація. Тут правила можуть прямо забороняти агентам вносити зміни без додаткових перевірок або людського втручання. Це компроміс між бажанням максимальної автономії та необхідністю контролю ризиків.
Перевірка й середовище: що потрібно агенту, щоб працювати самостійно
Навіть найкращі правила й патерни мало що варті, якщо агент не може перевірити власну роботу. Тому ще один фундаментальний блок у баченні Cursor — це «верифіковані системи».
Ідеальний сценарій виглядає так: агент отримує задачу, вносить зміни, запускає тести, аналізує результати й сам робить висновок, чи все працює. Людина підключається вже на рівні огляду поведінки системи, а не пошуку синтаксичних помилок.
Для бекенду це відносно просто: є чіткі контракти, API, інваріанти. Юніт‑тести й інтеграційні тести добре описують очікувану поведінку. Для фронтенду й UI‑шарів усе складніше: потрібно буквально «клікати» по інтерфейсу, перевіряти спінери завантаження, реакцію на події, візуальні стани.
У тому ж демо‑проєкті з музичним агентом для цього використовуються end‑to‑end тести на Playwright. Вони дозволяють агентам програмно взаємодіяти з UI: натискати кнопки відтворення, редагувати ноти, перевіряти, що інтерфейс поводиться як очікується. Це дає можливість не просто згенерувати код, а й автоматично довести, що він працює.
Не менш важливе питання — середовище виконання. Чи може агент самостійно запустити дев‑сервер? Чи достатньо йому сказати «start my project», щоб він, орієнтуючись на звичні патерни на кшталт npm start, підняв локальне середовище без участі людини? Якщо відповідь «так», це відкриває шлях до масштабування: ті самі сценарії можна запускати паралельно на безлічі окремих віртуальних машин.
Cursor 3 якраз і проєктувався з думкою про такі сценарії. Агент‑перший IDE має не лише редагувати файли, а й бути «оркестратором середовищ»: створювати, запускати, перевіряти, згортати їх без ручного втручання.
Життя на рівні 4: як виглядає щоденна робота з агентами
Оцінюючи себе як розробника, що працює на приблизно четвертому рівні автономії, Закаріассон фактично описує нову роль інженера в епоху агент‑перших IDE. Замість того, щоб писати більшість коду, він:
формулює наміри й задачі, які передає агентам;
стежить за тим, щоб кодова база залишалася «в дистрибуції» для моделей — структурованою, передбачуваною, з чіткими патернами;
реактивно додає правила в agents.md, коли агенти починають поводитися некоректно;
інвестує час у побудову верифікованих систем — тестів, які агенти можуть запускати самостійно;
перевіряє результати роботи насамперед через поведінку системи, а не через постійний ручний код‑рев’ю.
Це не означає повної відмови від читання коду. Але фокус зміщується: замість того, щоб бути «головним виконавцем», інженер стає менеджером фабрики, який налаштовує конвеєри, а не стоїть за верстатом.
Водночас важливо визнати: навіть у такому режимі «software factory» залишається радше орієнтиром, ніж реальністю. Автономно працюють лише окремі «лінії» — певні частини продукту чи внутрішніх процесів. Повністю «темної фабрики», де агенти безперервно планують, пишуть, тестують і постачають код без людського втручання, поки що немає.
Висновок: Cursor 3 як крок до фабрики, а не її фінальна версія
Еволюція Cursor — від VS Code‑базованого «гострого автодоповнення» у 2022–2023 роках до окремого агент‑першого застосунку Cursor 3 — добре ілюструє ширший тренд у розробці ПЗ. IDE перестають бути просто інструментами для людей і стають середовищами, де людина й агенти працюють як команда, а з часом — як менеджер і фабрика.
Перепис у вигляді самостійного застосунку дозволив команді Cursor переосмислити саму суть IDE: не як редактор файлів, а як оркестратор агентів, середовищ і процесів перевірки. Разом із цим змінилася й роль розробника: від «людини, що друкує код», до архітектора правил, патернів і тестів, які визначають, як працює програмна фабрика.
Закаріассон чесно визнає: повністю автономної фабрики поки що немає. Але вже сьогодні окремі частини продукту й компанії працюють досить автономно, а особистий робочий процес на рівні четвертого рівня автономії показує, що зміна ролей між людиною та інструментом — не теоретична, а практична реальність.
Cursor 3 у цій історії — не фінальний пункт призначення, а важливий етап. Він фіксує перехід від «IDE з AI‑фічами» до «IDE, де AI — перший класний громадянин». А далі все залежить від того, наскільки спільнота розробників буде готова мислити не лише в термінах файлів і функцій, а й у термінах фабрик, конвеєрів і рівнів автономії.
Джерело
YouTube: Building your own software factory — Eric Zakariasson, Cursor