Long Story Short: що дав Райфу ШІ
Коли до Григорія прийшов студент-практикант і за тиждень створив повноцінний KYB-сервіс для перевірки бізнес-клієнтів — задачу, на яку штатний senior developer витратив би два спринти — СТО Райфу зрозумів, що фндустрія переживає справді фундаментальний зсув. «Він не був генієм-самоучкою. Він просто добре працював з Claude Code», — розповідає Таций.
За 18 місяців IT-фахівці Райфу досягли 50% зростання продуктивності розробки, зекономили $178 000 на одному проєкті, скоротили час створення POC з тижнів до чотирьох годин. «Але найважливіше — це не про інструменти. Коли я досліджував індустрійні дані DX, Dora, Antropic, які проаналізували понад 135 000 розробників у 435 компаніях, я побачив цікавий паттерн: традиційні enterprise-компанії зі структурованим впровадженням показують вищі результати впровадження AI, ніж технологічні гіганти. Це дало мені впевненість, що ми рухаємося правильним шляхом», — розповідає Григорій.
AI щороку змінюватиметься радикальніше, ніж змінювався весь софт за попередні двадцять років. Команди, які навчаться працювати в такому середовищі, отримають перевагу, яку неможливо купити. Її можна лише побудувати — системно, чесно і разом.
Швидкість для розробників вже не є конкурентною перевагою — вона стала гігієнічним мінімумом. У цій новій реальності AI не замінює інженерів. Він робить інженерів тими, ким вони мали бути від самого початку: людьми, які будують системи, приймають технічні рішення й несуть відповідальність за результат.
Розробник перестає бути людиною, що пише код рядок за рядком.
Історія впровадження ШІ в Райфі, за його словами, — не казка про швидку перемогу. «Це 18 місяців експериментів, провалів, змін курсу і системної роботи над культурою, яка перетворила скептиків на активних користувачів», — пояснює Таций. Далі — його висновки та інсайди, які СТО зробив та отримав за час впровадження ШІ.
Холодний старт: як одне питання в Парижі все змінило
У вересні 2023-го Григорій виступав на конференції McKinsey у Парижі, де розповідав про технологічні ініціативи Райфу. Після презентації один з присутніх поставив питання, яке СТО здивувало: «А ви вже пишете тести за допомогою AI, використовуючи GitHub Copilot?»
«Я тоді вперше почув про Copilot. Повернувшись в банк, ми запустили швидкий пілот на 50 ліцензій. І тут був перший холодний душ: Copilot на той момент був ще сирим, генерував багато „поганого“ коду, і лише 30% розробників реально його використовували. Решта повернулися до звичного workflow, і я їх розумів — інструмент більше заважав, ніж допомагав», — розповідає Григорій.
Він зізнається: тоді в банку могли б зупинитися на цьому, вирішивши, що «AI ще не готовий для enterprise». «Але щось мені підказувало, що це не про технологію в цілому, а про конкретну реалізацію», — зауважує СТО. Тому на початку 2025 року у райфі провели ще один пілот — цього разу з Cursor.
В пілотному проєкті взяли участь 20 розробників, середній рейтинг інструменту після оцінки розробниками 8.3 з 10. «Для рутинних задач інструмент працював у 10 разів швидше. Віталій, наш Backend Developer, сказав: „Політика Rego, над якою мій колега працював дві години з ChatGPT, у мене зайняла 20 хвилин із Cursor“. Микита, DevOps Engineer, рефакторив цілий проєкт за один вікенд — він зізнався, що вручну ніколи б не переписав його за такий час», — розповідає Григорій. .
Кейси, що переконали скептиків
У великих організаціях на кожну нову ідею є десяток причин, чому це «не спрацює». Enterprise любить конкретні докази. Тому у Райфі почали збирати їх системно.
Кейс 1: Конектор за день замість місяців
У банку була команда, яка рефакторила старий IBM-ний стек. Треба було для шини данних переключитися з Oracle DB на PostgreSQL — це 18 000 євро економії на рік і консистентність технологій замість зоопарку. Але було два болючі моменти: відсутність ODBC-конектору під AIX платформу для PostgreSQL і відсутність глибокої експертизи з СУБД в команді.
Кейс 2: Call analytics і $178,000 економії
До СТО Райфу звернувся департамент колекшну з запитом: нам потрібен інструмент для аналізу дзвінків колекторів. «Ми дуже піклуємося про наших клієнтів і хочемо бути впевненими, що наші спеціалісти дотримуються стандартів спілкування з клієнтами», — каже Григорій.
Перший прототип айтівці зібрали за чотири години. Три години вибирали модель для транскрибації — починали з OpenAI Whisper (≈65% точності — замало), перейшли до AWS Transcribe (~84% — прийнятно), пізніше замінили на Google Gemini 2.5, який дав стрибок до 93% точності. Ще годину зайняло написання фронта та бекенду під наші запити.
Коли Григорій порівнював ці цифри з індустрійними benchmarks, він побачив, що це не аномалія. За даними публічних досліджень, companies using AI-assisted development у середньому економлять 3,6 години на тиждень на розробника, а ті, хто використовує щоденно — 4,1 години. Показники райфівців були в тому ж діапазоні, але вони застосували ці години економії до конкретних бізнес-кейсів з вимірюваним ROI.
Кейс 3: Студент і нова реальність сеньйорності
Третій перелом був коли до банку на стажування прийшов студент — без досвіду у фінтеху й навіть без досвіду у enterprise-розробці. Це була людина, яка просто володіє базовими знаннями в розробці.
Це підтверджується даними, які СТО бачив у публічних звітах: junior engineers є найактивнішими користувачами AI — 41,3% з них використовують інструменти щоденно, найбільше серед усіх рівнів seniority. І вони показують результати. Time to 10th PR для нових співробітників райфу, які використовують AI, впав з 86 днів у Q1 2024 до 39 днів у Q3 2025.
Кейс 4: Аналітик, який став розробником
Дмитро з аналітичного відділу був так зацікавлений у продукті аналізу дзвінків, що готовий був самостійно розробляти частину сервісу. Тому в банку вирішили провести експеримент: чи може людина взагалі без знань програмування розробляти хоча б частково функціонал?
Григорій нагадує, що у дослідженні Anthropic за результатом опитування 132 інженерів, фіксують той самий тренд: backend-розробники будують складні UI, нетехнічні спеціалісти долучаються до розробки. Один з їхніх інженерів описав свою трансформацію так: «shifted 70%+ to being a code reviewer/reviser rather than a net-new code writer». Це точно описує те, що наразі СТО бачить у Райфі.
Масштабування: чому купити ліцензії — це лише 10% роботи
Маючи ці конкретні докази, Григорій вирішив ШІ-досвід банку масштабувати. Кількість ліцензій к середені 2025 року GitHub Copilot зросла до 300, загальний річний AI-бюджет для розробників досяг 80 000 євро. І тут команда зіткнулась з проблемою, яку не очікували: ліцензії є, а користування немає
Перші два місяці після масштабування виглядали добре на папері — 300 ліцензій розподілені, каже Григорій. «Але коли ми подивились на реальне використання, побачили неприємну картину:
- 30% розробників активно користуються
- 40% мають ліцензію, але користуються Copilot пару раз на місяць
- 30% взагалі не беруть ліцензії
Для оцінки використовувались метрики premium request usage, line accepted, network traffic to endpoints», — пояснює він.
В команді розуміли, чому так сталося.
Тоді фахівці знайшли проміжне рішення: FinOps підхід до залученості. «Ми, як сильна FinOps-організація, вирішили застосувати той самий підхід до AI-ліцензій, що й до хмарних ресурсів. Правило просте: якщо Copilot не використовувався жодного разу протягом місяця — ліцензію відкликаємо. Не назавжди, не як покарання — просто рахуємо гроші. Але найважливіше — ми змінили метрику успіху. Раніше це було „скільки ліцензій роздали“ (охоплення). Тепер це „скільки людей реально використовують щоденно“ (залученість)», — пояснює Григорій.
Чому це важливо? За даними публічних досліджень, загальна AI adoption у компаніях досягла 91% — але це просто «є доступ». Реальне щоденне використання значно нижче. В Райфі вирішили фокусуватися на якості, а не красивих цифрах у звітах.
Якщо говорити про результативність такого підходу, варто зазначити, що нині в банку видано 220 ліцензій на 400 фахівців, що користуються IDE у роботі.
- 83 людини в когорті 2 (є ліцензія, майже не користуються)
- 137 людей в когорті 3 і 4 (occasional та daily users)
- 180 в когорті 1 (не користуються взагалі)
Завдяки зміні робочого процесу в IT-командах змінився й підхід до визначення грейдів.
«Якщо вже ми змінюємо робочий процес, логічно змінити й очікування від різних рівнів сеньйорності», — пояснюює Григорій. Нині вимоги до джунів, мідлів та сеньйорів в банку трансформувалися.
«Критично важливо: весь код, згенерований AI, проходить обов’язкове ревью сеньйорними інженерами. AI прискорює написання, але financial-grade (рівень, за якого система поводиться безпомилково у всьому, що стосується грошей) якість забезпечують люди. Це не „AI пише і йде в prod“ — це „AI пише, люди валідують логіку/архітектуру/безпеку/performance“. Така багаторівнева валідація дозволяє нам отримувати швидкість AI без жертв у якості», — коментує Таций.
Дані Anthropic це підтверджують: senior-інженери менше хвилюються про атрофію навичок, бо вони «know what the answer should be or should look like». Вони використовують AI як інструмент, а не як костиль. Молодші інженери більш схильні до сліпої довіри результатам AI.
Більше того, Anthropic у своєму дослідженні описує трансформацію так: інженери бачать себе «taking accountability for the work of 1, 5, or 100 Claudes».
Практично це означає наступне:
- менше часу на написання коду рядок за рядком;
- більше часу на архітектурні рішення та code review;
- фокус на валідації того, що AI генерує;
- робота з AI як з junior developer — ставити задачі, перевіряти результат, вчити
Роль розробника, зауважує Таций, не зникає — вона еволюціонує — від детального програмування до стратегічного керування AI-агентами, що вирішують технічні задачі під твоїм наглядом.
Підготовка команди: чому навчання критичне
Щоб підвищити залученість співробітників до використання ШІ, у банку запустили регулярний івент — Coffee Talks with CTO. Це не робочі зустрічі, а вечірні сесії поза робочим часом, де збирали зацікавлених людей, показували інструменти, ділилися реальними кейсами. «Ми запрошували найбільш активних користувачів, які демонстрували, як вони користуються AI», — каже Таций.
Також у банку запустили внутрішні воркшопи зі скілбілдінгу:
- Як вибирати модель
- Як писати промпти
- Як працювати з контекстом
- Як будувати пайплайни
- Як тестувати моделі
- Як НЕ користуватися MCP (це окрема історія про lessons learned)
Наразі AI-команда банку розробляє цілий курс-internal track, який навчить будь-якого співробітника працювати з AI незалежно від професії», — переконує Григорій.
Четвертий урок: Структуроване навчання та підтримка — не nice-to-have, а критичний фактор успіху. Різниця між «роздати ліцензії» і «системно впровадити» — це 6-16% покращення різних метрик (від швидкості delivery до зменшення knowledge gaps). Найбільший вплив — на впевненість команди та заповнення прогалин у знаннях.
Технічний стек: що працює для ШІ, а що — ні
Технічний стек в команді айтівців Райфу формувався через серію експериментів, каже Таций. Врешті фахівці виокремили сет інструментів, які працюють, а також назвали ті, які «не зайшли».
Григорій пишається, що AI не залишився забавкою тільки в одній команді. Різні підрозділи почали знаходити свої сценарії використання і впроваджувати рішення.
CloudOps команда створила Claude CLI agent workflow для review Terraform modules. Замість перевірки кожного модуля окремо, AI агрегує проблеми і показує «helicopter view» практик організації — повторювані антипатерни, відсутні стандарти, можливості для уніфікації. Результат: senior-level Terraform code quality review без вартості senior engineer.
Вони ж автоматизували RDS backup restore testing для PostgreSQL, MySQL, Oracle, MS SQL Server. Lambda function + engine-specific layers + Terraform module. Це скоротило development cycles.
Infrastructure команда мігрувала NiFi Registry на Infrastructure as Code з Terragrunt. Використовуючи AI для аналізу patterns і оптимізації, вони змінили instance type з c6a.large на t3a.medium — 50% економія коштів без деградації performance. Акселерували implementation на 35%.
Інша їхня робота — Terraform module для OCI Database automation. AI допомагав з генерацією коду, IAM policies, оптимізацією configurations. Результат: 30% зниження витрат, infrastructure implementation з тижнів до днів.
ESB (enterprise service bus) команда використала AI для Oracle to PostgreSQL migration (про це я розповідав на початку — €18k економії). Але вони пішли далі: оптимізували ActiveMQ infrastructure з AI. Deployment time з 1 дня до 16 хвилин (30x faster improvement). Terraform optimization + Ansible playbook + AWS cost optimization.
Data Lake команда побудувала custom MCP server з RAG для integration з Alation, AWS Glue, Athena. Це middleware між LLM agents (Claude, GitHub Copilot) і metadata repository. Тепер AI може генерувати SQL queries для Data Lake, Apache Spark code, navigating schemas через natural language prompts. Також робить SQL translation з source DWH databases (Sybase IQ, Oracle ADW) в Athena-compatible SQL.
Web development команда використала Claude Code для відеоідентифікації клієнта — складний мікрофронтенд в UFO (наша бекофіс система) без документації, без можливості дебагу на local. Claude Code допоміг розробити моки для локального оточення і розблокувати UI для всіх 4 кроків процесу. Також скоротив час на підтримку unit-тестів.
Це лише частина історій, каже СТО. За його словами, майже кожна команда знайшла свої сценарії використання і почала експериментувати.
Open-source внесок
У Райфі не тільки використовуємо AI-інструменти, але й ділять напрацюваннями з dev-спільнотою. «Ми заопенсорсили наш APM workflow для unit tests — це набір практик і автоматизації, які допомагають нам підтримувати якість коду при активному використанні AI-генерації», — гордо розповідає Таций.
Він пояснює важливість такого кроку: коли AI генерує код швидко, тестування стає критичним вузьким місцем. Розроблений райфівцям и workflow дозволяє автоматично генерувати unit tests з належним покриттям і валідацією. «Ми побачили цінність цього підходу внутрішньо і вирішили, що інші enterprise-команди, які стикаються з тими ж викликами, можуть отримати користь», — каже Григорій.
За його словами, частина філософії: банк не має бути чорною скринькою.
Григорій зауважує, що дотримуеться базових індустріальних рекомендацій: уникати vendor lock-in і тримати мультивендорний підхід. Він пояснює: ринок AI змінюється надто швидко, щоб ставити на одного постачальника. Дані ресерчів показують, що AI-native tools типу Cursor показують вищий PR throughput порівняно з традиційними рішеннями, але через кілька місяців картина може змінитися.
Виклики, про які треба говорити чесно
В роботі Райфівців з ШІ-інструментами не все було ідеально. СТО описує ряд приблем, з якими довелося стикнутися розробникам у пошуку вірних рішень.
Що далі: виводимо AI за межі коду
Райфівці лише на початку шляху, і мають чимало планів на майбутнє.
Навесні 2026 року в Райфі запустять «From Zero to Hero» — повноцінний внутрішній курс з AI. За словами Григорія, це не просто мануал, «як користуватися GitHub Copilot», а комплексна програма, яка дозволить дізнатися:
- Як вибирати між різними AI-моделями для різних задач
- Prompt engineering від базового до експертного рівня
- Робота з контекстом і structured outputs
- Етика використання AI та acceptable use policies
- Практичні воркшопи з реальними кейсами банку
Важливо: курс не тільки для розробників, оскільки AI змінює роботу далеко за межами коду. Григорій нагадує: за даними публічних досліджень, 60% дизайнерів і продакт-менеджерів у технологічних компаніях вже використовують AI щоденно. Engineering managers, які активно користуються AI, створюють вдвічі більше pull requests — вони самі пишуть код для прототипів і простих фіч.
Цей тренд він відмічає і в Райфі. Аналітики пишуть SQL і Python замість чекання на розробників. Продакт-менеджери створюють прототипи інтерфейсів. Дизайнери генерують код компонентів з Figma. DevOps автоматизують інфраструктурні задачі за години замість днів
8 порад для CTO, які планують впровадити ШІ в бізнесі
Якщо підсумувати 18-місячний досвід банку, СТО Райфа радить колегам з інших компаній притримуватись певних канонів.
Тестуйте перед масштабуванням. Не всі AI-інструменти однакові. Проведіть пілоти, виміряйте результати, послухайте розробників. Ми витратили 6 місяців на експерименти перед масштабуванням, вибирали з якими тулами, вендорами ми підемо далі — і це окупилося.
Фокусуйтеся на залученості, а не охопленні. 200 ліцензій з 30% adoption — це гірше, ніж 100 ліцензій з 60% активним використанням. Структуроване навчання та підтримка дають покращення ключових метрик:
- Зниження knowledge gaps
- Зростання впевненості в змінах
- Покращення залученості
- Прискорення delivery
Будуйте культуру через кейси. Enterprise любить конкретні докази. Збирайте їх системно, вимірюйте ROI, діліться успіхами.
Будьте чесні щодо викликів. Атрофія навичок, якість коду, shadow AI — це реальні проблеми. Визнавайте їх і працюйте над ними.
Думайте комплексно. AI — це не silver bullet. Вузькі місця поза AI (мітинги, code review, CI wait time) часто з’їдають більше часу. Продуктивність at scale вимагає оптимізації всього робочого процесу.
Уникайте vendor lock-in. Ринок змінюється надто швидко. Тримайте мультивендорний підхід і будьте готові експериментувати.
Діліться досвідом з community. Райфівці заопенсорсили свій APM workflow для unit tests, бо побачили, що багато команд стикаються з тими ж викликами. Enterprise може і повинна контрибутити в ecosystem — особливо коли йдеться про AI в highly regulated environments.
Не обмежуйтеся однією командою. Найбільша цінність прийшла, коли AI почали використовувати не тільки розробники, а й CloudOps, Infrastructure, Data, Web teams. Кожна команда знаходить свої унікальні use cases — від Terraform code review до custom MCP servers для Data Lake.
https://dev.ua/news/tatsyi-1765365975