Як штучний інтелект змінює роботу інженерних команд — і що може піти не так?

З появою потужних LLM-моделей дедалі більше компаній намагаються інтегрувати ШІ у повсякденну роботу команд. Але чи завжди це йде на користь? Що відбувається, коли впровадження йде зверху вниз, без глибокого розуміння потреб розробників? І як зробити це по-розумному — без зайвої бюрократії, але з реальним впливом?

Ці запитання ставить Ґреґор Ойстершек, автор популярного ньюзлетера Engineering Leadership. У своїй публікації він ділиться практичними висновками, спостереженнями та порадами щодо впровадження ШІ в командах: від помилкових очікувань менеджменту до культивування правильного підходу в середині інженерної організації. HBJ переказує найцікавіше з публікації.

Чи довіряють інженери ШІ-інструментам?

Згідно з опитуванням StackOverflow за 2024 рік, 76% розробників заявили, що вже використовують або планують використовувати ШI у своїй щоденній роботі. Проте це не означає, що інженери беззастережно покладаються на ці інструменти.

Станом на квітень 2025-го ця цифра, скоріше за все, ще зросла — судячи з розмов із техлідами та інженерами з різних команд, які я мав останнім часом. Особливо на фоні зростання популярності Cursor — редактора, який виявився надзвичайно корисним для пришвидшення рутини та генерації рішень під час написання коду. Багато техлідів підтверджують: інструмент справді заощаджує час і зменшує навантаження на команду.

Ще одна технологія, яка викликала інтерес, — це Model Context Protocol (MCP). Вона дозволяє ШІ-асистентам підключатися до зовнішніх інструментів, баз даних і внутрішніх систем. На мій погляд, MCP має потенціал суттєво впливати на загальну продуктивність команд.

Усе це супроводжується гучними заголовками:

• «Розробників більше не потрібно наймати»

• «ШI замінить мідл-розробників»

• «ШI підвищує ефективність у 100 разів і має бути впроваджений по всій компанії».

  
  

Але, що відбувається, коли інженерним командам нав’язують використання ШI згори? І чи варто впроваджувати ШI «по команді зверху» в інженерні процеси?

Нещодавно у відкритому доступі з’явився внутрішній меморандум від CEO Shopify Тобіаса Лютке. Було цікаво прочитати, як такі компанії, як Shopify, підходять до ШI-інтеграції. І з багатьма тезами я погоджуюсь. Бо якщо використовувати ШI з розумінням — результат може бути справді відчутним.

Але є нюанси, які при неправильному підході можуть зашкодити культурі. І навіть призвести до токсичних сценаріїв на кшталт спроб «переграти систему».

Чи справді ШI може підвищити продуктивність?

За підсумками моїх розмов із техлідами різних компаній протягом останнього місяця, реальний максимум — це десь у районі 5x. Але в більшості кейсів — від 0.3 до 1x. У великих і складних проєктах на цей момент ШI допомагає не так сильно, як хотілося б. Він чудово підходить для прототипів, шаблонного коду та простих задач.

Наприклад, я сам використовував його під час створення Engineering Leadership Endless Runner Game. Але всі, хто мав справу зі складними системами, чудово розуміють: довіряти ШI повністю ще зарано.

Застосування ШІ до KPI та оцінки ефективності

Усе частіше чую, що деякі компанії розглядають ідею впровадження так званих «таблиць лідерів»: хто з розробників використав найбільше LLM-кредитів або хто зробив найбільше комітів коду, згенерованого за допомогою ШІ.

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

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

Що справді варто оцінювати:

• Продуктивність команди > Продуктивність окремого розробника

• Допомога іншим > Фокус лише на власних тасках

• Якість рішень > Кількість зробленого

  
  

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

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

Чи правильно нав’язувати ШІ та контролювати його використання?

Компанії однозначно мають досліджувати шляхи впровадження ШІ у всі процеси — він реально підвищує продуктивність і буде лише вдосконалюватись.

Водночас жорсткий директивний підхід і зобов’язання «всім використовувати ШІ» можуть мати зворотний ефект, якщо не враховувати людський фактор. У результаті співробітники можуть імітувати використання ШІ заради високих оцінок у performance review.

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

Основні виклики впровадження ШI

Серед головни труднощів, з якими мені доводилося стикатися особисто або які часто звучать у розмовах з інженерами та тімлідами:

1. Розрив між очікуваннями керівництва та інженерних команд

Нерідко буває так, що топменеджмент не має чіткого уявлення про щоденну рутину розробників. Це призводить до розбіжностей у баченнях і створює непотрібну напругу. Скажімо, керівники вважають, що певну задачу можна легко закрити за допомогою ШI, хоча насправді це неможливо через технічні або процесні обмеження.

2. Невизначеність у відповідальності за ШI-ініціативи

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

3. Нереалістичні очікування щодо продуктивності

Навіть попри те, що є спільне бачення використання ШI, очікування від результатів можуть сильно розходитись. Менеджмент розраховує на різке зростання продуктивності, а інженери цього не відчувають. Це породжує напругу. Натомість потрібна прозорість і взаємоповага в комунікації.

4. Відсутність вимірюваного ефекту

У багатьох випадках ШI ще не приносить того рівня ROI, на який сподіваються в компаніях. Вони інвестують ресурси, час, зусилля — а натомість отримують поки що сирі рішення, які не готові до продакшену. Типовий приклад — Microsoft Copilot. Потенціал у нього чималий, але в реальних умовах він ще не завжди надійний.

5. Впровадження ШІ через страх втратити зиск

Чимало компаній впроваджують ШI тільки тому, що це «модно». Усі навколо вже з ним щось роблять — значить, і нам не можна відставати. Але як і з популярними фреймворками JavaScript — копіювання трендів без усвідомлення мети рідко призводить до успіху. Якщо команда не розуміє, навіщо це все — ефект буде мінімальний.

6. Обмеження, пов’язані з безпекою

Це особливо важливо для організацій, що працюють з чутливими даними — як-от держструктури, фінансові компанії або юридичні фірми. У таких випадках краще звернутися до локальних ШI-рішень, які можна запускати у власній інфраструктурі, без відправки даних у хмару. Можна звернути увагу на інструменти на кшталт LM Studio, Jan, Ollama, GPT4All, Msty — вони дозволяють експериментувати без загроз безпеці.

Як підходити до впровадження ШІ в інженерних командах

Я рекомендую підхід знизу вгору — коли зміни стартують із команди, а не навʼязуються згори. Почати варто з побудови здорової культури, де людям комфортно працювати й експериментувати.

Сфокусуйтеся на культурі

Почніть із формулювання базових цінностей вашої організації. Ось кілька ключових, які я зазвичай використовую:

• Відкритість і довіра

• Ініціативність

• Прозорість

• Повага до чужого часу.

  
  

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

Почніть з «навіщо»

Кожен у команді має розуміти мету впровадження ШІ. Якщо використовуємо його «просто, бо всі так роблять», — це не працюватиме.

Ось кілька питань, які варто поставити перед початком:

• Які проблеми ми намагаємось вирішити?

• Де наші ботлнеки?

• Чи точно ШІ — це найкращий інструмент для цього? (інколи звичайна автоматизація чи оптимізація процесів буде ефективнішою).

  
  

ШI-чемпіони: люди, які драйвлять інновації

У кожній команді знайдуться ті, хто швидко підхоплює нові технології. Варто дати їм більше простору для експериментів та обміну знаннями з іншими — через міні-сесії, демо, воркшопи.

Рекомендую створити окремий канал у Slack чи будь-якому іншому інструменті — для обміну корисними інсайтами, новими підходами та фреймворками.

Сесії з обміну знаннями та зовнішнє навчання

У здоровій командній культурі обмін знаннями є нормою. Але при впровадженні ШІ це варто підкреслити окремо. Заохочуйте всіх ділитись тим, що вони тестують або вивчають.

Класна ідея — запустити внутрішній (а можливо, і зовнішній) блог, де інженери зможуть ділитись інсайтами письмово. Це не лише прокачує навички письма, а й допомагає структуровано передавати знання іншим.

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