Інженер Cursor Ерік Закаріассон працює на стику продукту та developer experience й описує себе як розробника, який уже більшість типових проєктів веде на рівні «автономії 4»: максимально делегує роботу агентам і переважно перевіряє не код, а результат. У межах воркшопу AI Engineer він розповів, що потрібно зробити з кодовою базою, аби вона стала справді «агент‑френдлі» — від системи правил до тестів, які дозволяють агентам самостійно підтверджувати свою роботу.
У центрі цієї розмови — не черговий «чарівний» інструмент, а дуже приземлені, але критично важливі речі: структура репозиторію, стандарти запуску, guardrails і автоматизована валідація. Саме вони визначають, чи зможе ваш умовний «софтверний завод» працювати без постійної ручної опіки.
Правила як операційний мануал для агентів
Cursor підтримує систему правил, яка конфігурується через файл agents.md у репозиторії. Це не просто ще один README, а фактично операційний мануал для агентів: як поводитися в цьому конкретному коді, що дозволено, що заборонено, які патерни вважати канонічними.
Ці правила діють поверх загальних можливостей моделей і стають локальним «законом» для кожної кодової бази. Агент, який працює в Cursor, читає agents.md так само, як новий розробник читає CONTRIBUTING.md чи внутрішній онбординг‑док.
Щоб знизити поріг входу, Cursor підтримує публічний «cursor directory» — каталог прикладів правил, заточених під конкретні технологічні стеки. Там можна знайти, наприклад, набір правил для Next.js‑проєктів і використати їх як шаблон або відправну точку. Це особливо корисно командам, які тільки починають будувати агентні процеси й не хочуть вигадувати структуру правил з нуля.
Однак підхід «взяти все й одразу» тут працює погано. Поширена інтуїція: якщо є каталог готових правил, варто просто встановити всі, що відповідають вашому стеку. На практиці це перетворюється на перевантажений, суперзарегульований простір, у якому агенту складно орієнтуватися, а команді — розуміти, що взагалі діє.
Закаріассон радить протилежну стратегію: додавати правила реактивно, у відповідь на конкретні збої поведінки агентів. Якщо агент «з’їжджає з колії» в певному сценарії — саме це і є сигналом сформулювати нове правило. Так agents.md еволюціонує як жива SOP‑документація: не теоретичний ідеал, а зафіксований досвід реальних помилок і виправлень.
Такий підхід має кілька наслідків. По‑перше, файл правил залишається компактним і релевантним, без зайвих заборон «про всяк випадок». По‑друге, моделі, які дедалі краще слідують інструкціям, отримують чіткі, конкретні орієнтири замість розмитих універсальних настанов. І по‑третє, команда бачить історію того, як саме агенти вчилися працювати з кодовою базою — це корисно і для людей, і для подальшого тюнінгу.
Guardrails: чому деякі файли мають бути недоторканними
Навіть найкращі правила не скасовують базового факту: є частини системи, де помилка агента може коштувати надто дорого. Йдеться про шифрування, аутентифікацію, платіжні модулі, критичні безпекові шари. Тут «трохи не так» означає не просто фейл тесту, а витік даних, фінансові втрати або серйозні вразливості.
Тому в системі правил Cursor важливу роль відіграють саме жорсткі guardrails — явні заборони на редагування певних директорій, файлів або типів логіки. У agents.md це може бути сформульовано як пряма інструкція: не змінювати код, пов’язаний із криптографією, токенами доступу, платіжними шлюзами, або робити це лише за участі людини.
Такі обмеження не суперечать ідеї автономії, а радше визначають її межі. Агент може вільно рефакторити UI, додавати нові фічі, писати тести, але не має права торкатися фундаментальних безпекових блоків. Це дуже схоже на реальний завод: робот може збирати корпус, але не перепрограмовувати систему безпеки цеху.
Важливий нюанс: guardrails працюють краще, коли вони конкретні й прив’язані до структури репозиторію. Заборона «не ламати безпеку» мало що означає для моделі, натомість «не редагувати файли в src/auth/**» — чіткий, машинно‑інтерпретований сигнал. У поєднанні з дедалі кращою здатністю моделей слідувати інструкціям це дозволяє суттєво знизити ризики.
«Ін‑дистрибуція» для агентів: стандартні патерни як ключ до автономії
Ще один фундаментальний принцип, на якому наголошує Закаріассон, — робити проєкти «in distribution» для агентів. Під цим мається на увазі не щось абстрактне, а дуже конкретна річ: використовувати ті патерни, які моделі вже добре знають із тренувальних даних.
Класичний приклад — package.json у JavaScript‑проєктах. Для сучасних моделей це один із найзнайоміших артефактів: вони «очікують» побачити його в корені репозиторію, знають, що там є scripts, і вміють шукати start чи dev, щоб запустити локальний сервер. Якщо проєкт дотримується цього патерну, агенту не потрібно вигадувати, як його запускати: достатньо прочитати package.json і виконати знайомий сценарій.
У демонстраційному музичному проєкті з інтерфейсом, схожим на Ableton, саме так і відбувається. Агент відкриває репозиторій, знаходить package.json, бачить start‑скрипт, запускає його й піднімає dev‑сервер на localhost:3000. Ніяких спеціальних інструкцій, лише стандартна структура, яка добре «лягає» в розподіл, на якому тренувалися моделі.
Цей принцип виходить далеко за межі JavaScript. У будь‑якому стеку варто запитати себе: чи відповідає мій проєкт типовим очікуванням інструментів і моделей? Чи є зрозумілий спосіб запустити застосунок однією командою? Чи логічно організовані модулі? Чи є очевидні точки входу для тестів?
Чим ближче кодова база до «канонічних» патернів свого екосистемного світу, тим легше агентам орієнтуватися, знаходити потрібні файли, запускати середовище й виконувати завдання без ручного мікроменеджменту. І навпаки, екзотичні структури, кастомні скрипти без документації та нетипові шляхи ускладнюють життя як людям, так і моделям.
Самоперевірка: чому агенти мають доводити, що їхній код працює
Як тільки агенти починають писати значущу частину коду, виникає очевидне питання: хто гарантує, що все це працює? Якщо відповідь — «людина, яка все вручну перевіряє», — це швидко стає вузьким місцем. Масштабування агентів без масштабування валідації перетворюється на пастку.
Закаріассон пропонує дивитися на це як на окремий клас систем — verifiable systems, у яких агенти можуть самі підтверджувати правильність своїх змін. Для цього потрібна не магія, а дисципліна тестування: юніт‑тести, інтеграційні тести й, особливо для фронтенду, UI‑тести.
Для бекенду все відносно просто: є чіткі контракти, API, очікувані відповіді. Агент може внести зміну, запустити тестовий набір, побачити, що всі тести зелені, і зробити висновок, що не зламав існуючу поведінку. Якщо ж тести падають, він має шанс самостійно локалізувати проблему й виправити її, перш ніж людина взагалі побачить PR.
З фронтендом складніше: тут важлива не лише логіка, а й поведінка інтерфейсу — чи з’являється лоадер, чи працює кнопка «Play», чи можна редагувати ноти в таймлайні. Саме для таких сценаріїв у музичному демо‑проєкті використовуються end‑to‑end тести на Playwright. Вони описують очікувану поведінку UI: натиснути кнопку, перевірити, що почалося відтворення, змінити ноту, переконатися, що зміна відображається.
Агенти в цьому проєкті не просто пишуть код інтерфейсу, а й запускають Playwright‑тести, щоб підтвердити, що все працює як задумано. Якщо тест проходить, це сильний сигнал, що зміна коректна. Якщо ні — агент отримує конкретний фідбек у вигляді впалого сценарію й може спробувати виправити проблему.
Ключова ідея тут у тому, що тести стають не лише інструментом контролю якості для людей, а й API валідації для агентів. Чим повніше покриття, тим більше завдань можна делегувати без страху, що кожну дрібницю доведеться вручну проганяти в браузері чи через Postman.
Як поєднати правила, структуру й тести в одну «фабрику»
Окремо взяті agents.md, стандартні start‑скрипти чи Playwright‑тести ще не роблять із проєкту «софтверний завод». Але разом вони формують середовище, у якому агенти можуть працювати майже як окремі співробітники з чіткими інструкціями, доступом до інструментів і можливістю самостійно перевіряти свою роботу.
Правила в agents.md задають рамки: куди можна лізти, а куди ні, які патерни вважати еталонними, як поводитися з чутливими зонами. Вони еволюціонують реактивно, у відповідь на реальні помилки, і з часом перетворюються на концентрат досвіду взаємодії з агентами саме в цьому репозиторії.
Стандартизована структура проєкту — від package.json до зрозумілих директорій — робить кодову базу «ін‑дистрибуційною» для моделей. Агенту не потрібно гадати, де шукати точку входу чи як запустити сервер: він слідує знайомим патернам, які вже «вшиті» в його тренувальний досвід.
Система тестів, від юніт‑рівня до UI‑енд‑ту‑енд, перетворює валідацію з ручної рутини на автоматизований протокол. Агенти можуть не лише писати код, а й самі доводити, що він працює, зменшуючи навантаження на людей і відкриваючи шлях до справжньої паралельної роботи багатьох агентів.
На цьому тлі guardrails для критичних зон виглядають не обмеженням, а необхідною страховкою. Вони дозволяють сміливо розширювати автономію агентів у «безпечних» частинах системи, не ризикуючи ключовими бізнес‑функціями.
У підсумку виходить не «темна фабрика», де людина взагалі нічого не бачить, а радше добре організований цех: менеджер формулює намір і цілі, агенти виконують більшість рутинної роботи, а система правил і тестів забезпечує передбачуваність і контроль.
Висновок: фабрика починається з дисципліни, а не з магії
Ідея «софтверної фабрики», де агенти цілодобово пишуть, тестують і деплоять код, звучить футуристично. Але шлях до неї виявляється дуже приземленим. Він проходить через ті самі практики, які й так вважаються ознакою зрілої інженерної культури: чітка структура репозиторію, стандартизовані способи запуску, хороше тестове покриття, продумані правила доступу до критичних зон.
Різниця лише в тому, що тепер ці практики потрібні не тільки для людей, а й для агентів. agents.md стає новим типом документації, «ін‑дистрибуція» — новим критерієм якості архітектури, а тести — каналом зворотного зв’язку не лише для розробників, а й для моделей.
Ті команди, які вже сьогодні починають будувати такі агент‑френдлі кодові бази, отримують не просто зручнішу інтеграцію з Cursor чи іншими інструментами. Вони закладають фундамент для того, щоб у найближчі роки перейти від «гострого автодоповнення» до справді автономних, масштабованих софтверних фабрик — із чіткими правилами гри й мінімумом сюрпризів.
Джерело
Building your own software factory — Eric Zakariasson, Cursor (YouTube)