Штучний інтелект уже не просто «ще один інструмент» у наборі розробника. Для дедалі більшої кількості команд він стає повноцінним учасником процесу розробки — у вигляді кодових асистентів, автономних агентів, бекграунд‑сервісів, що постійно проглядають монорепозиторій і пропонують зміни. Про те, як це змінює роль інженера, говорив Гергей Орос (Gergely Orosz) — колишній інженер Uber і Skyscanner та автор популярного ньюзлетера The Pragmatic Engineer, який уважно стежить за тим, як великі й середні компанії перебудовують інженерні практики під AI.

Сьогоднішня трансформація виходить далеко за межі «писати код швидше». Тестування, DevOps, продакт‑мислення, оркестрація AI‑агентів — усе це поступово зливається в нову конфігурацію ролі «програміста». І водночас стає очевидно: добре знати теорію моделей зовсім не означає вміти ефективно працювати з ними на практиці.
Теорія проти практики: чому знання про моделі не робить вас сильним AI‑користувачем
Одна з найпоширеніших помилок у нинішній AI‑хвилі — припущення, що глибоке розуміння архітектур, токенайзерів і тренувальних пайплайнів автоматично перетворює інженера на «AI‑силового користувача». На практиці це не так.
Гергей Орос прямо наголошує: розуміння теоретичних основ моделей не конвертується напряму в уміння користуватися AI‑інструментами. Успішна робота з ними більше схожа на ремесло, ніж на академічну дисципліну. Це постійне налаштування власного робочого процесу, експерименти з промптами, форматами задач, розбиттям роботи на кроки, комбінуванням кількох агентів.
Цю думку добре ілюструє досвід Саймона Віллісона, відомого інженера й блогера, який активно працює з AI‑інструментами з перших місяців після появи ChatGPT. Навіть через два роки щоденної практики він описує свій стан як «я все ще розбираюся, що працює, а що ні, і постійно змінюю свої робочі процеси». Це важливий сигнал для індустрії: немає «остаточної інструкції», як стати продуктивним з AI, і немає короткого шляху через просто вивчення теорії.
У цьому сенсі AI‑інструменти нагадують не нову мову програмування, а радше новий спосіб мислення про роботу. Вони вимагають:
– готовності відмовлятися від звичних патернів, якщо вони не дають результату з агентами;
– терпіння до ітерацій, коли перші спроби дають посередній або навіть гірший результат;
– уважності до контексту: те, що працює для однієї кодової бази чи типу задач, може бути марним в іншій.
Саме тому вміння «читати статті про LLM» і вміння «будувати з ними реальну продуктивність» — це дві різні компетенції. Перша корисна, але друга формується лише через практику.
Команди з низьким его: хто реально витискає максимум з AI
Ще одна спостережувана закономірність: найбільшу віддачу від AI отримують не ті команди, де найглибше розуміють внутрішню кухню моделей, а ті, де найменше его і найбільша готовність переглядати власні уявлення.
Гергей Орос описує типову картину: частина досвідчених інженерів спершу скептично ставилася до кодових асистентів і агентів, особливо на великих, історично складних кодових базах. Перші версії інструментів справді часто були «м’яко корисними» — не вміли нормально рефакторити, погано знаходили баги, плуталися в специфіці внутрішніх фреймворків. Логічна реакція досвідченого розробника: «Навіщо мені це, я й так зроблю швидше».
Але саме там, де команди були готові визнати: «Можливо, ми щось робимо не так, давайте спробуємо по‑іншому», — AI почав приносити відчутну користь. Це проявляється в кількох вимірах.
По‑перше, у готовності змінювати процеси під інструмент, а не лише намагатися втиснути інструмент у старий процес. Наприклад, розбивати задачі на дрібніші, краще формалізовані кроки, які легше делегувати агентам; або змінювати структуру репозиторію, щоб полегшити навігацію для внутрішніх AI‑сервісів.
По‑друге, у відмові від «культу індивідуального генія». Команди, які сприймають AI як «розумний автодоповнювач для сеньйорів», часто недооцінюють його потенціал для нетехнічних колег. Натомість там, де інженери свідомо допомагають продакт‑менеджерам, аналітикам чи дизайнерам користуватися кодовими агентами, організаційний ефект виявляється набагато більшим, ніж приріст швидкості окремого розробника.
По‑третє, у готовності визнавати помилки. AI‑агенти неминуче генерують хибні або небезпечні пропозиції. Команди з низьким его не намагаються «довести, що інструмент марний» після першого фейлу, а сприймають це як частину навчання: змінюють промпти, додають валідаційні кроки, обмежують зони відповідальності агентів.
У підсумку виявляється парадокс: найкраще з AI працюють не ті, хто найбільше про нього знає, а ті, хто найменше чіпляється за власну правоту.
Зниклі тестувальники й розмитий DevOps: як ролі зливаються в «продуктового інженера»
Паралельно з приходом AI‑агентів відбувається менш помітна, але не менш важлива трансформація: класичні інженерні ролі розмиваються. Дві тенденції особливо помітні.
Перша — зникнення окремої ролі тестувальника в багатьох компаніях. Те, що ще десять років тому було стандартом — окремі QA‑команди, ручні тестувальники, спеціалізовані інженери з автоматизації — дедалі частіше поглинається загальною роллю «software engineer». Від розробника очікують не лише написання фіч, а й проєктування тестів, побудови пайплайнів перевірки, роботи з інструментами, які генерують або підказують тести, у тому числі на базі AI.
Це не означає, що якість стала менш важливою. Навпаки, зростання складності систем і швидкості релізів робить її критичною. Але відповідальність за неї зміщується ближче до того, хто пише код. AI‑інструменти тут виступають як підсилювач: вони можуть генерувати тестові кейси, пропонувати property‑based тести, аналізувати покриття. Проте саме інженер вирішує, що з цього має сенс, а що — ні.
Друга тенденція — DevOps як окрема функція в багатьох VC‑фінансованих стартапах також частково розчиняється в ролі інженера. Замість окремих DevOps‑команд, які будують і підтримують інфраструктуру, дедалі частіше бачимо очікування, що кожен розробник зможе:
налаштувати CI/CD,
працювати з хмарними сервісами,
розуміти базові принципи спостережуваності й моніторингу,
розгортати й супроводжувати власні сервіси.
AI тут знову стає і каталізатором, і виправданням. З одного боку, інструменти можуть допомогти згенерувати Terraform‑конфігурації, Kubernetes‑маніфести чи скрипти для пайплайнів. З іншого — саме через це керівництво стартапів частіше очікує, що «один інженер з AI‑асистентом» впорається з тим, для чого раніше потрібна була окрема DevOps‑команда.
На цьому тлі з’являється ще одна цікава роль: «product engineer». За спостереженнями Ороса, деякі компанії почали цілеспрямовано наймати таких інженерів щонайменше з 2022 року. Йдеться не просто про «full‑stack» у технічному сенсі, а про розробників, які:
мислять продуктово,
готові брати участь у формуванні вимог,
розуміють бізнес‑метрики,
і водночас здатні самостійно пройти шлях від ідеї до продакшн‑релізу, включно з тестами й інфраструктурою.
AI‑агенти органічно вписуються саме в таку роль. «Продуктовий інженер» не просто пише код, а й оркеструє набір інструментів — від кодових асистентів до бекграунд‑агентів, що стежать за якістю й безпекою. Це вже не класичний «backend‑developer» чи «QA‑engineer», а радше універсальний оператор складної технічної системи, де частину роботи виконують люди, а частину — машини.
Від «двох піц» до «однієї»: як AI стискає команди й змінює менеджмент
Класична метафора «two‑pizza team», популяризована Amazon, довгий час була еталоном для організації інженерних команд: група настільки невелика, що її можна нагодувати двома піцами, але достатньо велика, щоб самостійно будувати й підтримувати сервіс. Тепер, за свідченням одного з віце‑президентів з інженерії в John Deere, ці команди фактично перетворюються на «one‑pizza teams» — частково завдяки AI‑інструментам.
Це не просто красива метафора. Якщо частину роботи, яку раніше виконували кілька людей, тепер стабільно й передбачувано роблять агенти, логічно, що для тієї ж функції потрібна менша кількість інженерів. Наприклад, бекграунд‑агенти можуть:
регулярно проглядати монорепозиторій на предмет застарілих залежностей,
пропонувати дрібні рефакторинги,
оновлювати конфігурації,
генерувати початкові варіанти документації.
У результаті команда може зосередитися на складніших, кросфункціональних задачах, а не на рутині. Але це змінює й роль техлідів та інженерних менеджерів.
Гергей Орос пропонує дивитися на оркестрацію AI‑агентів не як на «управління людьми», а як на специфічний різновид техлідської роботи. Тут доречна метафора, яку використовує Девід Хайнемайєр Ханссон (DHH): AI‑агенти — це радше «мехсют», екзоскелет, що підсилює одного інженера, ніж «команда підлеглих». Інший приклад — Мітчелл Хашімото, який працює одразу з двома AI‑агентами, один із яких постійно працює у фоні.
Оркестрування такої системи вимагає:
розуміння архітектури продукту, щоб правильно визначити зони відповідальності агентів;
уміння формулювати задачі так, щоб агенти могли їх виконати без постійного мікроменеджменту;
побудови захисних контурів — від тестів до політик доступу, — які не дозволять агентам «зламати продакшн».
Це ближче до ролі техліда, який координує складну технічну систему, ніж до класичного менеджера людей. Люди залишаються ключовими для прийняття рішень, пріоритизації, комунікації з бізнесом. Агенти — для виконання добре формалізованих, повторюваних або масштабних технічних задач.
Показово, що великі технологічні компанії — Uber, Airbnb, Intercom, Meta, Microsoft — уже інвестують у внутрішню AI‑інфраструктуру, яка робить таку оркестрацію можливою. У випадку Uber це, зокрема, власні бекграунд‑кодингові агенти, інтегровані в монорепозиторій і системи сервіс‑дискавері. Це не «плагін до IDE», а повноцінний шар інфраструктури, який розуміє структуру кодової бази й може діяти в ній автономно.
Для інженера це означає: дедалі важливішою стає не лише здатність писати код, а й уміння працювати з цілою екосистемою агентів — розуміти, що їм можна довірити, як перевіряти їхню роботу, як інтегрувати їх у пайплайни.
AI як колективний підсилювач: від індивідуальної продуктивності до організаційного ефекту
Окремий пласт змін стосується того, як AI впливає на продуктивність не окремого розробника, а всієї організації. Досвід різних компаній показує: приріст швидкості сеньйор‑інженера з AI часто менший, ніж очікується, зате ефект для нетехнічних колег може бути драматичним.
Один із практичних прикладів — коли інженер налаштовує кодових агентів для колег, які раніше не писали код. Продакт‑менеджери, аналітики, навіть фахівці з операцій можуть почати самостійно створювати невеликі серверлес‑функції, скрипти для обробки даних, інтеграції між сервісами. Вони перестають чекати, поки інженер знайде час на «дрібну, але важливу» задачу, і виконують її самі, спираючись на агентів.
У такій конфігурації роль інженера зміщується від «виконавця всіх технічних задач» до «архітектора й наставника», який:
визначає рамки безпеки й якості,
налаштовує інструменти так, щоб ними могли користуватися нетехнічні колеги,
допомагає їм формулювати задачі для агентів,
і втручається лише там, де потрібна глибока експертиза.
Це ще один вимір тієї самої трансформації: інженер стає оператором складної соціотехнічної системи, де люди й агенти працюють разом. І знову ж таки, ключовою рисою успішних команд тут виявляється низьке его й готовність ділитися владою над кодом з іншими — як з колегами, так і з машинами.
Висновок: нова норма — інженер як оркестратор
Якщо спробувати підсумувати, що саме змінює AI‑епоха в ролі програміста, вимальовується кілька стійких трендів.
По‑перше, теоретичні знання про моделі важливі, але не визначальні. Ефективність з AI‑інструментами народжується з практики, експериментів і готовності постійно змінювати власний робочий процес.
По‑друге, найуспішніші команди — це не обов’язково «найрозумніші» чи «найдосвідченіші» в класичному сенсі, а ті, де низьке его, висока гнучкість і готовність відмовлятися від старих уявлень про те, як «правильно» писати код, тестувати й розгортати.
По‑третє, традиційні ролі — тестувальник, DevOps, «чистий» backend‑розробник — поступово зливаються в ширшу роль інженера, який відповідає за весь цикл створення продукту. Звідси й поява «product engineer» як окремої категорії.
По‑четверте, AI‑агенти змінюють не лише індивідуальну продуктивність, а й структуру команд. «Дві піци» перетворюються на «одну», а роль техліда дедалі більше нагадує оркестрацію «мехсютів» — потужних, але вимогливих до налаштування інструментів, а не управління великою кількістю людей.
Усе це не означає, що класичні інженерні навички стають непотрібними. Навпаки, саме вони дозволяють безпечно й ефективно керувати AI‑агентами, будувати внутрішню інфраструктуру, інтегрувати інструменти в реальні продукти. Але центр ваги зміщується: від «я пишу код» до «я проєктую систему, де код пишуть і люди, і машини».
Для розробників це виклик і можливість одночасно. Ті, хто зможе прийняти нову роль — оркестратора, наставника, продуктового мислителя в «мехсюті» AI‑агентів, — опиняться в авангарді професії, яка стрімко змінюється.
Джерело
How AI is changing Software Engineering: A Conversation with Gergely Orosz, @pragmaticengineer