Чому автономна розробка на Factory AI ламається на масштабі
На поодинокому завданні автономна розробка на Factory AI виглядає переконливо: агент отримує постановку, сам знаходить потрібні файли, вносить правки й проганяє перевірки.
Поки завдання йдуть по одному, вузьке місце зміщується в постановку — що точніше сформульовано результат, то менше ітерацій до прийнятої зміни.
На потоці картина інша. Кілька агентів паралельно торкаються спільних модулів: схем даних, спільних утиліт, конфігурації збірки.
Кожен бачить репозиторій у своїй версії, і конфлікти змін спливають не в момент правки, а на злитті — коли переписувати доводиться вже перевірене й прийняте рішення. Саме на цьому кроці автономна розробка на Factory AI перестає масштабуватися лінійно.
Далі підключається другий ефект — хибні спрацювання перевірок. Набір тестів розрахований на послідовну інтеграцію, і за паралельних гілок падіння приходять із чужих правок.
Агент читає червоний прогін як власну помилку й править те, що до завдання не стосується: обсяг зміни зростає, а розбір правок втрачає передбачуваність.
Черга завдань при цьому не розсмоктується, а зростає: до кожного завдання додаються перебазування, повторні прогони й розбір чужих падінь. Час проходження одного завдання збільшується нелінійно, і виграш від автоматизації з'їдається координацією.
Розбираємо, як це закривається — правилами черги, ізоляцією гілок і межами, у яких агент не виходить за своє завдання.
Вимірні ефекти: що змінюється після впровадження агентів
Пропускна здатність команди вимірюється не активністю агентів, а числом змін, що дійшли до основної гілки за цикл.
Після впровадження агентів цей лічильник зростає за рахунок того, що рутинні правки перестають конкурувати із завданнями, де потрібен досвід інженера: оновлення залежностей і типові зміни йдуть у фон і не займають рев'ю цілком.
Частка автономних завдань — друга метрика: скільки змін агент доводить від правки до прогону перевірок без проміжного втручання людини.
Factory AI закриває повторювані сценарії — оновлення залежностей, міграції за шаблоном, однотипні правки конфігурації, — а інженер підключається на етапі рев'ю та оцінки ризику, а не на кожному кроці.
Час відновлення скорочується за рахунок готового контексту: агенту доступні історія правок, логи збірки й результати перевірок, тому чернетка виправлення з'являється раніше, ніж інженер вручну відновить картину збою.
Відкат при цьому залишається керованим — зміни приходять невеликими порціями, які можна зняти окремо, не розгортаючи весь реліз.
Окремий наслідок — зникає клас відмов, пов'язаних із людським пропуском: забута міграція, розсинхрон конфігурації між стендами, незакрита гілка. Такі збої дорогі не складністю, а частотою, і агент знімає їх перевіркою за чек-лістом до того, як зміна йде далі середовищем.
Режими роботи агентів: порівняння підходів та обмежень
Режим роботи агента — це насамперед режим запису в репозиторій, і він задає клас ризиків, а не «рівень автономності». У Factory AI перемикання робиться на рівні завдання: та сама модель у режимі підказок і в автоматичному режимі дає різний результат щодо контролю над змінами. Нижче — три альтернативи, між якими реально обирають.
| Режим роботи агента | Коли підходить | Обмеження |
|---|---|---|
| Автономна робота з обов'язковою перевіркою людиною | Основна гілка, критичні модулі, незнайомий код | Кожна зміна чекає на рев'ю, швидкість упирається в доступність рев'юера |
| Повністю автоматичний режим на ізольованій копії | Масові однотипні правки, прогін тестів, оновлення залежностей | Копія розходиться з основною гілкою, на злитті потрібен автоматичний розбір конфліктів |
| Режим підказок без запису в основну гілку | Розбір архітектури, діагностика, чернетки рішень | Гіпотеза не перевіряється на живому коді, результат переноситься вручну |
Спільне обмеження автоматизації одне: агент бачить код і тести, але не бачить домовленостей, причин минулих рішень і вимог до даних.
Тому в будь-якому режимі залишається точка, де потрібна перевірка людиною — приймання змін на стику модулів, права доступу, робота з персональними даними.
Режим підбирають під завдання, а не під сервіс: для рутинних правок достатньо ізольованої копії, для ядра продукту — обов'язкового рев'ю.
Етапи впровадження: від аудиту завдань до передачі регламентів
Автономна розробка дає ефект не сама по собі, а як частина процесу зі зрозумілими межами: де агент працює сам, де потрібна людина, хто відповідає за відкат.
Тому впровадження Factory AI йде етапами — від аудиту завдань до передачі регламентів, і на кожному є перевірюваний результат.
- Аудит завдань і правил. Розбираємо, які роботи повторюються — типові правки, тести, оновлення залежностей — і яких правил команда вже дотримується: стиль, рев'ю, вимоги до покриття. На виході — список завдань для контуру й перелік того, чого він не торкається.
- Схема контуру. Визначаємо, де запускаються агенти, як отримують доступ до репозиторію і як результат потрапляє в основну гілку. Ізольоване середовище на кожне завдання — базова вимога.
- Налаштування ролей і доступів. Розмежовуємо права: читання, запис, де потрібна людина, що підтверджує. Ключі живуть у сховищі секретів і видаються на мінімальний термін.
- Пілот на вузькій ділянці. Один сервіс або один клас завдань, де результат легко виміряти. Дивимось частку прийнятих правок без доопрацювання і час від постановки завдання до перевіреної зміни.
- Перевірка якості. Звіряємо з очікуваннями команди: чи проходять зміни обов'язкові перевірки, чи не зростає частка відкатів, чи влаштовує рев'юерів читабельність. За просідання правимо правила й підказки, а не розширюємо охоплення.
- Передача регламентів. Після стабільного пілота підключаємо решту команд і віддаємо документацію: схему контуру, матрицю доступів, правила рев'ю, порядок відкату, розбір типових збоїв. Інженери ведуть контур самі.
Комплект постачання: конфігурації, політики доступу, документація
Впровадження не закінчується запуском: у команди замовника залишається робочий комплект, за яким систему можна розвивати й передавати іншим інженерам без нас.
Ми фіксуємо в ньому те, що зазвичай живе в листуванні — які файли налаштування за що відповідають, де проходять межі прав і в який момент у процес зобов'язана включитися людина.
- Конфігурації — файли налаштування середовища, правил запуску агентів і підключення до репозиторіїв, із поясненням, що змінюється і до чого це призводить.
- Схема інтеграції — як Factory AI пов'язаний із репозиторіями, гілками та чергою завдань: де ставиться завдання, де з'являється результат, де потрібне підтвердження.
- Політики доступу — матриця прав за ролями: що агент читає, куди пише, які операції виконує лише після підтвердження інженера.
- Ролі агентів — призначення кожної ролі (розробка, перевірка, розбір збоїв) та її межі в спірній ситуації.
- Правила перевірки — умови приймання зміни: обов'язкові перевірки, пороги, причини автоматичного відхилення.
- Регламенти чергування — дії чергового за зупинки черги завдань, порядок відкату невдалої зміни й точка ескалації.
- Документація — інструкції із запуску, типові збої та порядок їх розбору, журнал змін налаштувань.
Комплект залишається у вашому репозиторії й оновлюється разом із системою — саме це робить передачу знань відтворюваною, а не залежною від конкретного інженера.
Кейс впровадження Factory AI: метрики до і після
Впроваджували Factory AI на живому напрямі, де черга завдань трималася на кількох десятках: правки в API, міграції схеми даних, оновлення інтерфейсів.
Рахували три метрики — час проходження завдання від постановки до злиття, частку правок, закритих автономно, і частку повернень на доопрацювання. Заміри йшли два тижні до впровадження й стільки ж після — щоб порівняння не змастили разові сплески.
Як було до
Завдання йшло ланцюжком вручну: розробник читає постановку, шукає пов'язаний код, пише правку, ганяє тести, відповідає на зауваження під час перевірки.
На типовій зміні це 2-3 дні, і саме написання займало меншу частину — решта йшла на розбір контексту й перемикання між завданнями. Приблизно кожне п'яте завдання поверталося на доопрацювання: не покрито суміжний випадок, розійшлися контракти, зачеплено зайвий модуль.
Що змінили і що стало
Підготовчу частину віддали агентам: збір контексту за репозиторієм, чернетка правки, прогін тестів до перевірки людиною. Інженер затверджував план і приймав результат, правило злиття не змінювали — без зелених перевірок в основну гілку нічого не йде.
Час проходження завдання скоротився до 6-9 годин, частка правок, закритих автономно, зросла до чотирьох із десяти, повернення на доопрацювання впали з 21% до 7%.
Ефект тримається на типових змінах: завдання, що змінюють архітектуру, залишаються цілком за інженером — там агент прискорює розвідку кодом, але не рішення.
Чим автономний агент відрізняється від автодоповнення коду
Автодоповнення коду працює на рівні рядка: модель бачить відкритий файл і сусідні фрагменти, пропонуючи наступний вираз у момент набору. Воно не знає, яке завдання ви розв'язуєте, і не перевіряє, чи збереться проєкт після підказки. Прийняти її чи відхилити — рішення інженера на кожному кроці.
Автономний агент отримує завдання формулюванням — опис дефекту, вимоги до поведінки — і розгортає його в план правок. Він визначає, які модулі зачепити, у якому порядку вносити зміни, де потрібні нові тести і що потягне правка за собою.
Планування правок іде до першої зміни файлу, тому на виході зв'язний набір змін, а не розсип підказок.
Ключова відмінність — правила перевірки. Агент не може вважати роботу завершеною, поки не пройдуть тести, статичний аналіз і перевірка типів, задані обов'язковими. Перевірка, що впала, повертає вивід у цикл: агент читає помилку, править код і запускає прогін знову.
Число ітерацій обмежене, і за вичерпання спроб завдання повертається людині зі звітом, а не з мовчазним «наче працює».
У нашій практиці Factory AI підключали саме на цьому рівні: агент працював в окремій гілці, із забороною торкатися конфігурацій збірки й міграцій даних, а злиття залишалося за рев'юером.
Звідси різниця в призначенні: автодоповнення економить час на наборі, автономний агент скорочує шлях від завдання до перевіреної зміни — за умови, що правила перевірки та межі його роботи описані заздалегідь.
Технічні сумніви: обмеження, ризики, контроль
Автономна розробка не знімає інженерних обмежень — вона переносить їх у зону налаштування й контролю.
Нижче п'ять питань, які ставлять до старту впровадження Factory AI: доступ до секретів, ізоляція середовища, вимірювання якості, доля незакритих завдань і сумісність із правилами, вже розгорнутими у вашому репозиторії.
Агент отримає доступ до наших секретів?
У відкритому вигляді — ні. Йому видається окремий обліковий запис із правами лише на потрібні репозиторії та короткоживучими токенами: значення секретів підставляються в середовище виконання й не потрапляють ні в контекст завдання, ні в журнали, ні в коміти.
Відкликання доступу й ротація виконуються однією операцією, як для звичайного сервісного користувача.
Правки йдуть прямо в робочу гілку?
Робота йде на ізольованій копії — окремий контур, власні тестові дані, жодних звернень до бойових баз. Зміни потрапляють в основну гілку лише через перевірку коду й обов'язкові автоматичні перевірки, які вже налаштовані в проєкті.
Як ви вимірюєте якість результату?
Три метрики: частка шляхів, покритих автоматичними перевірками; частка змін, прийнятих без правок людиною; час від виявлення дефекту до відкату. Вони знімаються на кожному етапі, тому деградація видна до релізу, а не після.
Що відбувається із завданнями, які агент не закрив?
Робота не зникає: залишається гілка з історією, чернетка змін і журнал спроб. Завдання позначається й передається інженеру разом із контекстом — він продовжує з тієї ж точки, а не відновлює хід міркувань заново.
Це сумісно з нашими правилами й лінтерами?
Так. Налаштування лінтерів, шаблони комітів, схеми гілкування й уже розгорнуті правила читаються з репозиторію як є. Агент підлаштовується під наявний порядок роботи, а не вимагає переписати конфігурацію під себе.
Обговоримо завдання: розберемо ваш контур і повернемося з планом
Щоб оцінка термінів спиралася на факти, а не на середні по ринку, починаємо з вихідних даних про ваш контур розробки. Повний аудит не потрібен — достатньо описати поточний стан, і ми повернемося з планом впровадження Factory AI, розбитим за етапами.
- Як влаштовані репозиторії: мови, системи збірки, частка застарілого коду.
- Процеси рев'ю та релізів: хто погоджує зміни і які перевірки обов'язкові перед викладкою.
- Система трекінгу завдань і формат вимог — від них залежить, наскільки автономно зможе працювати агент.
- Тестовий контур: наскільки він близький до промислового і які перевірки запускаються автоматично.
- Обмеження щодо даних: що заборонено виносити за периметр, чи потрібна ізоляція всередині вашої інфраструктури.
- Критерії приймання та метрики: частка завдань без правок, час до релізу, покриття перевірками.
У відповідь ви отримуєте план впровадження: етапи, порядок підключення до вашого контуру, вимоги до доступів, склад пілотної групи завдань і терміни кожного етапу з точками звірки результату.
Щоб обговорити завдання, достатньо короткого опису контуру та ваших очікувань. Опишіть його — повернемося з оцінкою термінів і планом впровадження.
