На конференції Craft у Будапешті автор блогу The Pragmatic Engineer Герґей Орош розбирав, як великі компанії перебудовують розробку під AI. В одній з найцікавіших частин виступу він спирався на спостереження Лари Тачо, колишньої CPO в DX і нині керівниці напрямку developer experience в AWS, а також на приклад Spotify. Їхній досвід показує: ставка лише на «прискорення окремих девів» дає враження прогресу, але майже не змінює командний результат. Реальні зрушення приходять тоді, коли AI вбудовують у командні процеси як «агентні системи» з чіткою бізнес-метою.
Коли все виглядає швидшим, а команда — ні
Лара Тачо спостерігає однакову картину в багатьох компаніях: окремі розробники демонструють вражаючу продуктивність, але загальний вихід команди не росте. Організації «застрягають» у стані, де люди індивідуально користуються AI, але системний ефект майже не з’являється.
Причину вона формулює доволі жорстко: більшість думає про AI як про індивідуальний інструмент продуктивності для інженера, а не як про частину командної системи. Вона навіть дає цьому назву — «individual speed‑up juice». До цього класу вона відносить:
– автоматичні підсумки email
– дрібні автоматизації у Slack
– генерацію коду для конкретних задач
На папері все виглядає чудово: кожен дев швидше відповідає на листи, менше клацає в месенджері, за хвилини отримує скелет для нового модуля. Але на рівні команди зникають вузькі місця? Прискорюються релізи? Меншає переробок? Часто – ні.
Фактично виникає ілюзія прогресу: індивідуальні дії стають помітно швидшими, та без змін у потоці роботи команди це лише підсилює локальні оптимізації. Ланцюжок розробки й деплою, повний «хенд-офів», блокерів і пошуку інформації у хаотичних системах, від цього не стає кращим.
Компанії, які рухаються швидше, починають з бізнес-мети
Ті, хто дійсно бачить зміни на рівні команд, працюють інакше. Орош переповідає логіку, яку Тачо бачить у таких організаціях: вони починають не з «які AI‑фічі дати девам», а з конкретного бізнес-результату.
Типові формулювання виглядають так:
– «Ми хочемо швидше деплоїти в продакшен»
– «Ми хочемо виштовхувати більше фіч за той самий час, не втрачаючи якість»
– «Ми хочемо підняти якість продукту»
Саме від цього потім відмотують назад: які частини процесу гальмують ці результати, де найбільше ручних передач між людьми, де існує найбільше тертя у пошуку інформації, як саме AI може змінити саму систему, а не лише окремі кроки.
У цій моделі AI — не «тул для девів», а будівельний матеріал для нового процесу розробки. Він має скорочувати кількість хенд-офів, прибирати повторювані дії, робити знання в організації доступнішими в потрібний момент. І все це — під задану бізнес-мету, а не під абстрактну «продуктивність».
Spotify: «якість не має падати» як політика використання AI
На противагу агресивним підходам, Орош наводить Spotify як приклад компанії, що свідомо обрала консервативну стратегію впровадження AI. Під час неформальної розмови CTO Spotify сформулював їхній внутрішній бар’єр досить просто: якість має залишатися на тому ж рівні.
Це означає кілька речей.
По-перше, Spotify не женеться за миттєвим «стрибком продуктивності». За словами Ороша, там не бачать «величезного приросту аутпуту» від AI. Натомість вкладаються у внутрішні інструменти, які перевіряють якість результатів AI, і свідомо сповільнюють розгортання нових AI‑рішень.
По-друге, для Spotify прийнятність AI‑інтеграцій прямо прив’язана до контролю якості. Якщо неможливо гарантувати, що рівень якості не просяде, — AI‑ініціативу притримують, незалежно від обіцянок про економію часу чи коштів.
На фоні прикладів, де AI‑код, перевірений AI‑рев’ю, уже приводив до інцидентів, така позиція виглядає принциповим вибором. Це не історія про «максимізацію використання AI», а радше про те, що AI вбудовують у систему з чітко заданим обмеженням: не гірше, ніж зараз.
Цікаво, що Spotify при цьому все одно будує власні внутрішні інструменти навколо AI. Але ціль цих інструментів — не просто пришвидшити написання коду, а гарантувати, що кінцевий продукт не просідає за якістю. Виходить повільніше, але без «AI‑похмілля» у вигляді великої кількості латентних багів.
Що таке «агентна система» у розумінні Лари Тачо
Ключова відмінність підходу, який описує Тачо, – у тому, що AI розглядається як частина цілісної «агентної системи», а не як сукупність маленьких скриптів і автозавдань.
У її формулюванні бажана система:
– зменшує кількість хенд-офів між людьми
– робить пошук інформації простішим і швидшим
– прибирає тертя у повсякденних процесах
– при цьому зберігає існуючий рівень якості або піднімає його
«Підтримання якості» вона окремо виділяє як рідкісну рису: небагато компаній на практиці ставлять це як обов’язкову умову для AI‑ініціатив, навіть якщо декларують у стратегіях.
Агентна система в такому розумінні — це не просто «розумний бот», а низка узгоджених агентів і сервісів, вшитих у внутрішню інфраструктуру: від трекера задач до CI/CD, тестів, документації й репозиторіїв. Саме вони беруть на себе значну частину «сервісної» роботи, що раніше вимагала ручних передач між ролями.
Наприклад, замість того щоб дев вручну передавав контекст від QA до продакт-менеджера, система може автоматично збирати релевантні логи, документацію, тестові результати й формувати зрозумілу картину проблеми. Умовно той самий дев усе ще пише код, але набагато менше часу витрачає на «логістику» інформації.
Це не те саме, що «корисний чатбот у Slack» — останній зазвичай живе окремим шаром, до якого звертаються епізодично. Агентна система змінює самі потоки роботи.
Ментальна модель: від «автоматизацій для людей» до «агентів для команд»
Тачо пропонує ментальну карту, яку Орош переказує так: вона розділяє використання AI за двома осями. Перша — де відбувається застосування: на рівні індивідуального інженера чи на рівні команди. Друга — тип рішення: проста автоматизація чи повноцінна агентна система.
У цій координатній площині більшість компаній сьогодні опиняється в «нижньому лівому куті»: індивідуальне використання AI для простих автоматизацій. Тобто, умовно:
– кожен дев має свій автодописувач коду
– хтось налаштував собі автосамарі для листів
– хтось додав невеликий бот у Slack для дрібних задач
Це корисно й часто справді підвищує комфорт роботи. Але до квадранта, де є командні агентні системи, ще дуже далеко.
Саме туди «хочуть потрапити» більшість організацій: побудувати системи, в яких AI‑агенти взаємодіють із внутрішніми сервісами, керують частинами потоку задач, агрегують інформацію для всієї команди, автоматично зменшуючи кількість зайвих дій і затримок.
Однак дійти до цієї точки, за словами Ороша, вимагає того, що вже роблять гравці рівня Uber: значного інвестиційного циклу в інфраструктуру, інтеграцій та ітерацій. Неможливо просто «купити готовий продукт», навіть якщо це потужний AI‑редактор коду чи хмарний агент. Їх доводиться вбудовувати в унікальні процеси компанії.
Це означає:
– виділені платформи‑команди, які будують шлюзи й рантайми для агентів
– поступове підключення внутрішніх сервісів і систем до єдиної AI‑шини
– розробку власних критеріїв прийняття AI‑функцій у продакшен з огляду на якість
Тобто перехід від «джусу швидкості» для окремих людей до командних агентних систем — це не питання ще одного підписаного контракту з постачальником AI, а питання багаторічної еволюції внутрішньої платформи розробки.
Чому фокус на системі, а не на індивіді, стає критичним
На фоні історій про інциденти, пов’язані з AI‑кодом, і загального падіння якості софту, теза «застосовувати AI до системи, а не до індивіда» звучить не як теоретична порада, а як умова виживання.
Орош підкреслює: сьогодні більшість гравців застрягла саме на рівні індивідуальних автоматизацій. Саме тому не спостерігається драматичного приросту командної продуктивності, попри те, що окремі деви часто можуть показувати вражаючу швидкість. Без переосмислення процесів та чітко визначених бізнес-цілей AI залишається «турбо‑надбудовою» над старою системою, але не створює нову.
Водночас приклади на кшталт Spotify демонструють: можлива й інша траєкторія. Замість гонитви за максимальним використанням AI — жорсткий бар’єр якості й повільне будівництво внутрішніх інструментів, які не розвалюють існуючий рівень надійності. А досвід, описаний Ларою Тачо, показує ще один важливий зсув: від «ми дамо девам більше інструментів» до «ми змінимо спосіб, яким команда досягає бізнес-результату».
У підсумку «індивідуальний джус швидкості» — це швидкий, але обмежений виграш. Справжній, системний профіт від AI з’являється там, де компанії готові вкладатися в агентні системи на рівні команд, виходячи з чітких бізнес-мет і зберігаючи (або навіть піднімаючи) якість, а не жертвуючи нею заради короткострокового прискорення.
Джерело
Slow down to speed up: AI and software engineering — The Pragmatic Engineer