Новатор у сфері DevOps попереджає: впровадження AI-агентів вимагає змін на системному рівні, а не лише інструментів

Більше не виправляйте код, що генерує Agent, — виправляйте систему, яка генерує цей код.

Автор статті, джерело: InfoQ

Якщо розробник не може ефективно використовувати агента, проблема, можливо, не в розробнику, а в тому, що компанія взагалі не створила робочої системи для агента.

Багато компаній, які стверджують про свою AI-трансформацію, все ще обмежуються придбанням інструментів, таких як Cursor, Claude Code, для розробників, проведенням кількох тренінгів та залишають всіх на самоті зі самостійним вивченням. Якщо в кінці агенти не дають хороших результатів, вину знову перекладають на користувачів.

Але засновник терміну DevOps Патрік Дебуа вважає: «Розробникам потрібно зробити важливу зміну мислення: коли агент не виконує завдання так, як ви очікували, не треба змінювати код, який він згенерував, — замість цього потрібно покращити всю систему, а не лише запит».

За думкою Дебуа, це зміна, яка необхідна при переході програмної інженерії від детермінованих систем до недетермінованих, ймовірнісних систем і робочих процесів. Вона стосується не лише технологій, а й перетворює спосіб роботи розробників, команд і всієї організації. Але така зміна не може бути досягнута лише одним інженером або обмежуватися рівнем окремої команди. Як і DevOps, вона може бути реалізована лише після масштабування.

Суть питання полягає не лише в тому, чи зможуть розробники використовувати Agent, а в тому, чи зможе компанія перебудувати команди, платформу та способи співпраці навколо Agent.

Основні ідеї такі:

• Більше не виправляйте код, що генерує Agent, — виправляйте систему, яка генерує цей код.
• Якщо у вашій команді ще хтось використовує такі «дикі» підходи, як YOLO (спочатку запустити, а потім подивимося), ви повинні негайно їх припинити. Інженерні практики важливі не лише для підтримки вашої системи, а й для постійного покращення самого агента.
• Темна фабрика може бути не повністю темною, а лише зберігати трохи слабкого світла (dim factory), що означає, що вам потрібно вирішити, який ризик ви готові прийняти для кожної функції — не всі функції підходять для повної автономії.
• Те, кого ви шукаєте, — це той, хто може екстремально використовувати ІО, має міцну інженерну підготовку та готовий ділитися знаннями та співпрацювати.
• Ваша конкурентна перевага — це захоплення накопичених знань, тих бізнес-контекстів, які ви зараз вкладаєте в skill, Context і навіть обмеження Harness.

У 2009 році багато людей казали мені, що ідея безперервної поставки — це безглуздя.

Примітка перекладача: У 2009 році галузь загалом використовувала модель масового випуску великих версій раз на кілька місяців; всі вважали, що чим частіше випуски, тим вищий ризик. Крім того, існували жорсткі бар’єри між розробкою та експлуатацією, автоматизовані інфраструктури, такі як контейнери та хмара, ще не були досконалими, не існувало стандартизованих інструментів для конвеєрів, а традиційні механізми тестування та схвалення змін прагнули видалити всі дефекти до випуску. Натомість неперервна поставка запропонувала ідею частих, інкрементальних та миттєвих випусків, що повністю зруйнувало загальне уявлення про ризики та управління процесами при випуску програмного забезпечення. Тому для більшості компаній це здавалося неймовірним і дуже безрозумним.

А зараз Темна фабрика знову зіткнулася з такою ж самою перешкодою.

Примітка перекладача: Темна фабрика — це автономний модуль виробництва програмного забезпечення, що працює за допомогою ШІ, де люди вводять лише SPEC, а ШІ самостійно виконує кодування, тестування та запуск, не вимагаючи ручного перевірки кожного рядка коду, на відміну від традиційних програмних фабрик, які все ще вимагають великої кількості інженерів у процесі.

Я постійно чую одне й те саме: «Це не працює у нас». Але справжнє повідомлення, яке воно передає, не в тому, що технологія не працює, а в тому, що «ми ще не готові». Вони не проти реалізації цього, але зараз організаційна структура не підтримує таку модель.

Зараз багато хто говорить про те, як використовувати циклічну оптимізацію агентів, як налаштовувати Harness — це чудово. Але я хочу сказати, що рано чи пізно ми всі досягнемо цього рівня технологій, і колись вони перетворяться на звичайний товар, навіть можливо, будуть пакетовані як сервіс передовими лабораторіями. У той день технологічні бар’єри зникнуть. Справжня диференціація полягає в тому, як ваша організація перебудує способи співпраці навколо цього.

Тож я припускаю, що ми всі рухаємося у бік темних фабрик. Те, що я спостерігав у Tessl та інших компаніях, — це те, що коли люди починають використовувати ці технології, динаміка співпраці повністю змінюється. Якщо ви знайомі з законом Конвей, то знаєте, що існує взаємно формуюча зв’язок між організаційною структурою та інструментами — як ви організовуєте людей, такими й будуть системи, які ви створюєте. Але сьогодні я не збираюся розповідати, як зробити ваші агенти кращими; я збираюся розповісти, як це змінює динаміку вашої команди, вашу платформу та всю вашу організацію.

Я думаю, більшість з вас працюють у команді, а не самотужки, і командна робота — це зовсім інша річ, ніж сидіти самому й набирати код у Claude Code.

Зараз усі люблять говорити про таке твердження: розробники в кінцевому підсумку перетворються на диригента, на організатора агентів. Я вважаю, що це твердження не має нічого поганого — це саме той шлях, яким ми йдемо. Ми все більше стаємо менеджерами агентів, які мають справу з відносинами з агентами.

Але проблема в тому, що я чую, як багато розробників кажуть на власному досвіді: ми не вступали в цю галузь, щоб робити саме це, ми не уявляли, що будемо витрачати стільки часу на оптимізацію Prompt і написання кращих SPEC. Ми — інженери, ми працюємо з технологіями, і це створює у нас внутрішній конфлікт ідентичності: це справді та роль, яку я хочу виконувати?

Пізніше з’явився концепт під назвою «Context engineering», що стало певним виходом для розробників. Він стверджує, що це не просто виклик Prompt — вам також потрібно тестувати, оцінювати, розповсюджувати та оптимізувати Prompt, тому справді є певна інженерна складова. Але чесно кажучи, багато розробників все ще відчувають порожнечу від постійної роботи лише з Prompt і SPEC і вважають себе не інженерами, а «менеджерами підказок».

Але на практиці я спостеріг цікавий поворот. Коли ми почали впроваджувати Harness, цикли та навіть піднімали всю організацію на більш високий рівень автономії, відкрилася зовсім нова технічна траєкторія. Раптово розробникам знадобилося будувати інструменти для Agent — і це миттєво заново розпало інтерес у багатьох. Ті розробники, які раніше думали: «Це не моє», раптово зацікавилися. Вони сказали: «Так, ми можемо це зробити! Ми володіємо цими знаннями! Ми можемо покращити цю систему за допомогою програмування». Отже, це дуже цікаво: коли ми постійно говорили про «абстрагування, абстрагування, ще більше абстрагування», відчуття «ремесла» з’явилося знову, але в іншому місці, створюючи новий простір для більш глибоких інженерних завдань.

Мене часто питають: як упоратися з людьми, які скептично ставляться? Моя відповідь завжди така: ці люди — ваше скарбниця. У них є величезна кількість прихованого досвіду та суджень, які ви повинні втілити в агенті. Ви можете сказати їм: «Будь ласка, викладіть усю свою експертизу та критичність», — це зробить агента та Harness кращими. Якщо ви зустрінете тих, хто опірно налаштований і щодня скаржиться: «Цей інструмент генерує код поганої якості», — використовуйте їх як паливо: перетворіть цей гнів і скептицизм на джерело покращення системи.

Зараз я хочу дати пораду розробникам компанії: зробіть величезну зміну мислення — перестаньте виправляти код, який генерує Agent, і почніть виправляти систему, яка цей код генерує. Як кілька років тому хтось сказав: «Не будуйте цей предмет, будуйте те, що буде будувати цей предмет». Зараз ми саме на цьому рівні абстракції — створюємо «річ, що буде будувати речі», використовуючи Context, Harness і цикли. Тим, хто ще залишився на рівні «Human in the Loop», автодоповнення та налаштування Prompt, потрібно подумати, як піднятися до системного мислення.

Насправді ми маємо зробити так, щоб мінімізувати кількість втручань людини за допомогою добрих інженерних практик. На початку всі вважали, що «vibe coding» — це класно: дашь Prompt — отримаєш результат, і далі просто біжи. Але зараз все ясніше: ми не просто даємо агенту команди через Prompt, ми фактично кажемо: напиши код разом із тестами, онови документацію, дотримуйся стандартів кодування. Усе, що ми раніше казали хорошому інженеру, зараз ми кажемо агенту. Якщо у вашій команді ще хтось використовує такий «YOLO (спочатку зроби працюючим)» підхід для vibe coding, ви повинні негайно це припинити. Інженерні практики важливі не лише для підтримки вашої системи, а й для постійного покращення самого агента.

У деяких лідируючих командах я почав бачити новий ритуал: вони все ще проводять планувальні та оглядові зустрічі, але теми обговорень повністю змінилися. На оглядових зустрічах більше не кажуть «Що пішло не так з кодом?», а запитують: «Що пішло не так з системою?»

На плановій зустрічі я також помітив цікаве розділення. Завдання, які чітко визначені і мають достатньо конкретний діапазон, можна безпосередньо передавати агенту, оскільки Harness стає все кращим і здатний обробляти такі чіткі завдання. А ті завдання, де межі неясні і потрібні переговори, залишаються за людьми. Тому на плановій зустрічі виникло природне розподілення: ці картки йдуть прямо через потік агента, а ті картки ми обговорюємо самі.

Розробники зазвичай проходять цикл навчання: спочатку вивчають Prompt, потім кращі SPEC, далі Context, Harness, цикли — вся індустрія проходить через цей цикл. Але те, що може зробити лід команди, — це встановити темп і обмеження для цього процесу, наприклад, сказати їм: «Більше не налаштовуйте Prompt, зробіть Context повторно використовуваним». «Чудово, цей етап завершено, переходимо до наступного». Саме встановлення такого темпу — це цінність ліда команди; якщо ви просто кажете: «Самі розбирайтеся», це не працює.

Є також побічний ефект: коли продуктивність вашої команди почне різко зростати, люди внизу за ланцюжком, наприклад, ті, хто займається GTM (Go to Market), не зможуть за ними крокувати, навіть користувачі не зможуть. Тому вам потрібно використовувати автоматизацію, щоб допомогти їм — ваша система не повинна зупинятися на етапі кодування, вона повинна поширюватися й на них. Те саме стосується і вхідних вимог зверху: якщо вимоги надходять занадто повільно, команда застрягне — ці етапи також потрібно включити в цей новий робочий процес.

Зараз на ринку є велика кількість показників, таких як витрати на токени тощо. Але я все більше вірю у два справжніх показники продуктивності. Перший: порахуйте, скільки ще потрібно ручних втручань, щоб агент виконав завдання правильно. Це число має постійно зменшуватися. Чим краще ваша система, чим кращий контекст і чим чіткіші інструкції, тим нижче це число. Другий показник — це множниковий ефект, коли ви переходите від індивідуальної роботи до спільної системи. Ви виправляєте щось в одному місці — і всі користувачі отримують користь. Це не означає, що один людина стає в десять разів ефективнішою, а те, що одна оптимізація системи агентів створює множниковий ефект для всіх.

Ви можете почати з одного репозиторію або невеликої команди, поділитися контекстом і разом покращити Harness. Але те, чого ви справді хочете досягти, — це поширити цей ефект на всю організацію. Саме тоді ми змушені говорити про команди платформи.

Команда платформи є типовою спільною організацією, яка зараз, ймовірно, займається інфраструктурою, хмарними сервісами, шлюзами MCP тощо, а не звертає уваги на агентів. Але з’являється багато нових речей, які їм потрібно прийняти: реєстр навичок (не можна дозволити, щоб кожен самостійно винайшов ту саму навичку у своєму кутку), система оцінки контексту (чи має цей контекст взагалі значення? Чи можна його кількісно виміряти?), а також спеціалізовані механізми безпеки та управління ідентичністю для кодинг-агентів (від імені кого агент надсилає код? Де проходять межі повноважень?). Тож команді платформи потрібна підтримка, щоб допомогти їй перетворитися на центральну роль.

Це складно, і вам потрібен чіткий власник, який буде рухати це вперед. Але хто це має бути? Команда платформи? Команда досвіду розробників? Перша зазвичай не працює з речами на рівні розробки, а друга не працює з інфраструктурою, тому потрібен певний злиття, але воно не відбувається автоматично. Ви повинні забезпечити наявність відповідальної особи, яка буде просувати цю централізовану роботу, інакше ваша команда просто буде кружляти у своїй власній ділянці, і «Paved Road» не з’явиться.

Чому кожна команда має винайти власний спосіб інтеграції системи аутентифікації? Це спільний компонент, який слід помістити до реєстру. Чому кожен створює власний Harness? Якщо ми всі використовуємо один і той самий linter та однаковий набір інструментів для сканування безпеки, це стає пере використовуваним компонентом. Я вважаю, що це буде схоже на прокладання доріг для хмарної інфраструктури в минулому — поступово це зосередиться на платформовому реєстрі.

Але проблема в тому, що якщо будь-хто може довільно додавати щось до цього центрального сховища, це швидко перетвориться на хаос. Наприклад, хтось завантажив skill — хто його підтримує? Інша людина створила fork подібного skill — який з них вибирати? Тож повинен бути хтось, хто чітко відповідає за певну область і забезпечує, щоб цей елемент був тестованим і модульним, щоб інші могли розширювати Context або безпечну скануючу частину Harness. Це потрібно робити централизовано, а не просто передавати всередині організації.

Досягти консенсусу важко. Це не так відомо, як суперечка між tabs і spaces, але іноді відчувається майже так само. Якщо ви намагаєтеся змусити дві команди розробників домовитися про спосіб роботи, це вимагає величезної кількості комунікацій і посередництва. Тож на практиці ви, швидше за все, отримаєте не одну викладену дорогу, а три чи чотири, з яких вони зможуть вибрати. Якщо вони захочуть створити власну — це їхнє право, але за рахунок їхнього бюджету. Той шлях, який централізовано підтримується, є «легким шляхом», призначеним для того, щоб привабити всіх.

Якщо люди сліпо використовують ці спільні можливості, ви повинні показати їм витрати. Доки ви візуалізуєте витрати, вони природньо захочуть оптимізувати. Це обов’язок команди платформи — зробити витрати прозорими: скільки було витрачено? На скільки це допомогло? Якщо я зможу зменшити кількість ітерацій агента, це буде оптимізація. Але якщо я не бачу цього показника, а бачу лише кінцевий результат, я не зможу нічого зробити — візуалізація є передумовою будь-якої оптимізації.

Тож моя основна ідея полягає в тому, що ми маємо перейти від індивідуальних розробників до командного рівня зі спільним контекстом і спільними компонентами, а згодом — до «багатокористувацької системи» всередині всієї організації. Множниковий ефект вибухне саме там, бо у вас з’явиться летючий колесо, де покращення одночасно поширюються у кілька напрямків.

На рівні віце-президента інженерного відділу, як вони думають про це? Я майже можу передбачити історію, яка відбудеться у вашій організації: хакатон або ланч-шерінг, розповідь про успішні випадки, створення спільного каналу у Slack, запуск програми чемпіонів. Це універсальні підходи до трансформації. Колись так робили під час Agile-трансформації, так само і з DevOps — нічого нового.

З іншого боку, ми також знаємо, що стратегія «видавати ліцензії, проводити навчання, дозволяти всім вільно діяти, дозволити розквітнути тисячі квітів» ніколи не працювала. Результатом тисячі квітів зазвичай є тисяча бур’янів: багато квітів, але жодна не дає плодів. Тому я закликаю на стороні організації чітко надати повноваження командним лідерам та платформним командам, щоб вони це зробили. Це не може бути досягнуто лише за рахунок якогось суперіндивіда — хтось повинен бути офіційно уповноважений на просування цього.

Залучення допомоги також є дуже непростою справою. Сучасні назви посад — повна плутанина: інженер з AI-продуктів, forward deployed engineer, agentic engineer, інженер з AI… Ці терміни насправді не мають реального змісту. Ви не можете визначити рівень досвіду людини за її посадою, бо вся індустрія ще не дозріла. Однак, коли ви розміщуєте вакансію, ці слова дійсно передають певні сигнали і приваблюють людей із певними намірами, але це не означає, що кандидат обов’язково володіє необхідними навичками. Я також чув ще більш дивні історії: деякі кандидати під час співбесід використовували AI, який у реальному часі підсказував відповіді їм у вухо — коли співбесідник ставив питання, через AirPods надходила порада від AI.

Тож я все частіше чую, як компанії використовують такий підхід до співбесід. На першому етапі дають завдання, пропонуючи використовувати ШІ на повну — чим більше, тим краще. Якщо ШІ допомагає їм вирішити задачу, це саме й свідчить про їхню майстерність у використанні ШІ. На другому етапі просить пояснити власне рішення: «Чому саме цей підхід? Як ви перевірили, що воно працює?» — тут ви оцінюєте здатність до тестування та інженерне мислення. Перша частина перевіряє вміння працювати з ШІ, друга — глибину інженерних знань. Третій етап: спостерігайте, як вони співпрацюють, чи готові ділитися ідеями, чи є вони відкритими, чи схильні працювати самотньо. Деякі мають сильні технічні навички, але нічого не хочуть віддавати іншим — у епоху агентів саме такі люди стають обмеженнями.

Того, кого ви шукаєте, — це людина, яка може екстремально використовувати ІО, має міцну інженерну підготовку та готова ділитися та співпрацювати. Це не той, хто просто вивчав МЛ чи ІО, і не якийсь експерт з розшифровки, а певна суміш. Ви, ймовірно, не знайдете кандидата, який повністю відповідає всім трьом критеріям — і це нормально. Наприклад, один кандидат може бути дуже сильним у одному аспекті, але потребувати наставництва у іншому. Також не змішуйте ці навички, позначаючи їх як «початківець» або «профі» — це різні виміри навичок: людина може мати «профі» рівень використання ІО, але «початківець» рівень готовності до співпраці.

Відділ інженерії повинен звітувати вище. Ми купили стільки ліцензій — чи можемо ми довести віддачу від інвестицій? Швидкість доставки зросла? Можливо, є обіцянки, але важко це підтвердити. Якість покращилася? Також важко сказати. Але повернемося до двох показників, про які я вже згадував: ви можете показати, на скільки зменшилася кількість втручань, на скільки покращився результат і на скільки зросла частка повторного використання. Це набагато простіше й переконливіше, ніж порівнювати «продуктивність кодування з агентом і без нього».

Тож, коли хтось скаржиться, що агент занадто багато витрачає, і пропонує обмежити ліміт, ваша інтуїтивна реакція не повинна бути «зріжемо всі витрати», а «як ми можемо оптимізувати витрати». Найпростіший спосіб — правильно вибрати модель: не для всіх завдань потрібна найпотужніша модель, для деяких завдань достатньо дешевших. Навчайте розробників, яку модель використовувати в яких сценаріях, а ще краще — надавайте їм кращий контекст і інструменти, що допоможе агенту уникнути помилок і значно знизити витрати.

Ще одна тема — розмір команди. Ідеальна мрія — це універсальний фахівець, який робить усе сам. Але уважно розрахуйте: зазвичай такій особі потрібні доповнюючі навички, наприклад, продукт-менеджер чи дизайнер. Потім треба врахувати резервних людей (backup) — а що, як хтось піде у відпустку? І знову виходить три людини. А потім може знадобитися хтось, хто буде стежити за виробництвом і тікетами — якщо ви дійсно надзвичайно ефективні, то це можуть бути ті самі люди, що й додатково виконують ці завдання. Але як тільки ви починаєте виправляти баги, швидкість розробки нових функцій падає. І нарешті — новачки: вам потрібно прокласти їм шлях, щоб вони розуміли, що таке «добре». Тож я все ще вважаю, що в організації неможливо зробити кожну команду лише з однієї або двох осіб.

Нарешті, темна фабрика може бути не повністю темною, а лише трохи підсвіченою (dim factory), що означає, що вам потрібно вирішити, який рівень ризику ви готові прийняти для кожної функції — не всі функції підходять для повної автономії. Ви можете інвестувати більше в аудит, наприклад, відстеження походження: хто змінив код? Людина чи агент? Додайте перевірки, щоб переконатися, що код дійсно корисний, і інвестуйте в здатність розуміти контекст, коли автоматизовані процеси зазнають невдачі. Це цілий спектр від повного мікрокерування (кожен рядок коду перевіряється людиною) до повної автономної схвалення (припущення, що вихід агента завжди правильний). Ваше завдання — вибирати рівень автоматизації для різних типів змін залежно від рівня ризику.

А я вважаю, що ваша конкурентна перевага полягає у захопленні накопичених знань — тих бізнес-контекстів, які ви зараз вкладаєте в skill, Context і навіть обмеження Harness. Для мене це фактично перетворює безперервну поставку на безперервне навчання. Задайте собі питання: наскільки швидко ми можемо замінити нове в системі і вивести старе? Це ваша реакційна здатність. Якщо ви зможете постійно покращувати цю здатність, ключовим питанням більше не буде «Як зробити всю систему більш надійною?», а «Чи зможу я зберігати надійність системи, одночасно змінюючи все більше її частин?»

Якщо залишити лише одне речення, то воно має бути таким: переможцями не будуть ті, хто діє самотужки, а ті, хто розуміє, як покращити організацію на кількох рівнях.