Як перейти від хаотичного використання AI до системних змін у процесах і ролях

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

24 листопада 2025 року Anthropic випустили Claude Opus 4.5. Це перша модель, яка пробила 80% на SWE-bench Verified. Я запам’ятав цю дату, бо саме тоді для мене почався новий етап: AI перестав робити вигляд, що вміє інженерну роботу, а почав її реально робити.

Далі стало тільки краще. OpenAI відповіли GPT-5.1 і GPT-5.2 Codex. Моделі не просто навчилися кодити, вони почали кодити так, що їм можна довіряти. У травні 2025-го реакція на вдалий результат була «вау, круто, нічого собі». У листопаді, якщо щось зламалося, люди дивувались: «що за фігня, воно ж завжди працює».

Мене звати Юра Голюк, я CTO Mate academy і відповідаю за всю інженерну частину компанії. Більшість наших інженерів перестали писати код руками десь у грудні-січні.

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

Проблема не в моделях

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

Три причини, чому впровадження буксує

1. Промах з інструментом.

Багато компаній обрали Microsoft Copilot, базовий ChatGPT або щось дешевше і вважають, що питання закрите. Але для реальної інженерної роботи різниця між Claude чи Codex і Copilot не схожа на різницю між iPhone 15 і 14. Це різниця в порядок величини. Людина пробує слабкий інструмент, отримує слабкий результат і втрачає віру: «я вже пробував, не працює». Змінити сприйняття потім дуже важко. Тому саме тут не варто економити: перше враження вирішує, чи людина взагалі повірить інструменту.

1. Відсутність централізованої практики.

Компанія роздала ліцензії і сказала розбиратися самим. Кожен інженер вигадує свої промпти й воркфлоу. Жодного skill, MCP, CLAUDE.md чи internal CLI не потрапляє в спільний репозиторій. Internal sharing просто немає. Хтось у команді досягає крутих результатів, але про це ніхто не знає, бо це нічия відповідальність. Насправді питання тут не інженерне, а організаційне: чи є в компанії людина, яка відповідає за AI adoption?

1. Мисленнєвий блок.

Мабуть, найболючіша причина. Люди бояться інструмента: «я ж напишу краще». Пробують раз, виходить погано, кидають. Не бачать, де взагалі можна щось делегувати. Це справедливо і для інженерів, і ще більше для не-технічних команд, тільки навпаки: не-tech люди часто хочуть зробити інструментом усе підряд, а девелопери переживають, що інструмент забере в них роботу.

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

Що насправді змінюється, коли зроблено правильно

Роль інженера

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

Ми проаналізували PR throughput у восьми інженерів двох команд за період з вересня 2025 по квітень 2026. Шість із восьми показали стале зростання в 1,5-2 рази, а в сеньйорів — до трьох разів, з 7-10 PR на тиждень до 25 і більше. Один інженер лишився на тому ж рівні, ще один пішов вниз, але з причин, не пов’язаних з AI. Це стійкий новий режим тривалістю вже 2-4 місяці, а не короткий сплеск.

Тут потрібна важлива обмовка. Кількість PR сама по собі не показник цінності, тому дивитись треба ще й на cycle time, revert rate, кількість інцидентів після релізу. Але паттерн стабільний. І цікаве спостереження таке: для інженерів середнього рівня піднявся не пік, а floor. AI не так виводить на максимум, як прибирає погані тижні.

Нетехнічні команди

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

У Mate academy ми вже кілька місяців поширюємо Claude на нетехнічні команди. Один з класних прикладів — наша Head of HR, яка самостійно задеплоїла на GitHub два Slack-боти. Один щотижня об’єднує колег на random coffee, інший вітає з річницями та днями народження. Вона попросила в Claude покрокові інструкції, створила репозиторій, підняла GitHub Action на cron і підключила Slack credentials. Вона просила Claude пояснити кожен ключовий крок, перепитувала, чому саме так, а в одному критичному моменті прийшла перевірити рішення зі мною.

Внутрішні інструменти

Найбільший важіль тут з’являється, коли інженер за вечір робить інструмент, який раніше просто не вартий був часу.

Перший приклад. Сейлзи часто мали повторювані питання щодо продукту, які адресували команді. Ми зробили Slack-бота, що індексує ClickUp через OpenSearch і відповідає на основі документів, знань LLM і веб-пошуку. Тепер сейлз отримує відповідь за секунди, а не чекає, поки людина матиме час перевірити тег в треді.

Другий приклад показовіший. У нас є AI Tech Check: студенти проходять голосову репетицію співбесіди з AI перед реальним інтерв’ю і отримують оцінку та summary. Коли AI неправильно оцінював щось у проді, дебаг займав години. Потрібно було змінити модель локально, передиктувати голосом, подивитись результат.

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

Відтак кожний повторюваний біль у команді тепер проєкт на вечір, а не на спринт.

Як організувати впровадження, щоб отримати результат

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

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

Обери патерн під конкретний біль. Коли всі напрямки складаються разом, з’являються три способи, як AI входить у роботу команди, і робота відповідального — обрати правильний патерн для кожного болю, а не однаковий для всіх:

1. Дати інструмент і допомогти заадоптити. Не «видали й забули», а активна допомога: спілкування з людьми, дашборд adoption, питання до тих, хто не використовує AI, чому саме.
2. Спеціалізований інструмент під конкретний біль. Як наш sales-бот. Інженерне зусилля потрібне один раз, а користуються всі через звичайний @ у Slack. Тертя тут нульове.
3. Інфраструктура для самостійної автоматизації. N8N, MCP-доступи, набір skills. Не-технічні люди будують власні автоматизації самі.

Дай людям час на експерименти. Це інвестиція, а не марнування годин. Якщо керівник скептично дивиться на годину з AI, це сигнал команді, що в цю інвестицію в компанії не вірять.

Підсвічуй успіхи перших adopters. Саме через них поширюється довіра. Коли з’являється критична маса віри, додавай структуру: воркшопи, 1:1 наставництво, хакатони.

Як вимірювати вплив на бізнес

Тут я виділяю три категорії.

Найми, які не сталися. Це найчистіша метрика, бо вартість позиції за рік легко порахувати: зарплата плюс рекрутинг, онбординг, менеджмент-overhead. Ми не наймаємо додаткового спеціаліста з customer support, бо бот й автоматизація впораються самі. Не наймаємо додаткового перформанс-маркетолога, бо контентна команда з новими скілами тягне обсяг. Один незроблений найм це конкретна сума на рік, і це вже не «AI зекономив 10 хвилин», а реальний вплив на P&L.

Throughput delta. Це складніше вимірювати, але показовіше з часом, і не тільки в розробці. У нас у розробці це приблизно 2× у середньому й 3× у лідів. В інших відділах метрики ще вибудовуємо. Орієнтири такі: у контенті це час на одиницю контенту, у sales це час на типову відповідь клієнту, у креативі це кількість варіантів для A/B тестів.

Те, чого раніше просто не існувало. Це найважча категорія, бо немає бенчмарка «до». Але саме тут часто ховається найбільший довгостроковий ефект. Наприклад, sales-команда постійно годинами питала продакт-менеджера про деталі продукту й політики. Ми зробили Slack-бота, що індексує ClickUp через OpenSearch і відповідає на основі документів, знань LLM і веб-пошуку. Тепер сейлз отримує відповідь за секунди. Це процес, якого раніше взагалі не було, бо сейлзи просто чекали відповіді людини.

Варто зробити обмовку про раннє вимірювання. Міряти треба з першого дня, інакше ви не зрозумієте, що відбувається насправді. Але спочатку результату видно не буде, а можливе навіть коротке погіршення, бо люди вчаться, експериментують і ламають звичний воркфлоу. Це нормально. Треба перетерпіти 1-2 місяці й дивитися на тренд, а не на окремий тиждень.

Нові питання, які виникають

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

Впровадження AI — це проєкт, а не покупка ліцензій

Купівля ліцензії це найпростіший крок. Реальний результат приходить тоді, коли ви перебудовуєте процеси, ролі і команду під те, що стало можливим. Це не робота на день чи тиждень. Але вона того варта.