AI-Assisted Architecture Migration
ШІ-міграція архітектури CleanTech-платформи
ШІ-міграція архітектури CleanTech-платформи
ШІ-міграція архітектури CleanTech-платформи
Проектування за допомогою ШІ допомогло модернізувати складну мікрофронтенд-платформу, скоротивши час міграції з чотирьох тижнів до одного. Автоматизований моніторинг залежностей також покращив довгострокову стабільність у шести репозиторіях.
Проектування за допомогою ШІ допомогло модернізувати складну мікрофронтенд-платформу, скоротивши час міграції з чотирьох тижнів до одного. Автоматизований моніторинг залежностей також покращив довгострокову стабільність у шести репозиторіях.
Проектування за допомогою ШІ допомогло модернізувати складну мікрофронтенд-платформу, скоротивши час міграції з чотирьох тижнів до одного. Автоматизований моніторинг залежностей також покращив довгострокову стабільність у шести репозиторіях.
AI
Renewable Energy
SaaS
AI-Assisted Architecture Migration
AI-Assisted Architecture Migration
Опис клієнта
Опис клієнта
Опис клієнта
Наш клієнт — європейська CleanTech-платформа, яка працює в індустрії відновлюваної енергетики. Їхній продукт — це платформа для управління та передачі сертифікатів. Платформа дозволяє займатися транскордонним брокерством сертифікатів між країнами та великими споживачами енергії. Продукт спрощує придбання, відстеження та верифікацію сертифікатів, що підтверджують споживання компанією певної кількості енергії з відновлюваних джерел протягом звітного періоду.
Наш клієнт — європейська CleanTech-платформа, яка працює в індустрії відновлюваної енергетики. Їхній продукт — це платформа для управління та передачі сертифікатів. Платформа дозволяє займатися транскордонним брокерством сертифікатів між країнами та великими споживачами енергії. Продукт спрощує придбання, відстеження та верифікацію сертифікатів, що підтверджують споживання компанією певної кількості енергії з відновлюваних джерел протягом звітного періоду.
Наш клієнт — європейська CleanTech-платформа, яка працює в індустрії відновлюваної енергетики. Їхній продукт — це платформа для управління та передачі сертифікатів. Платформа дозволяє займатися транскордонним брокерством сертифікатів між країнами та великими споживачами енергії. Продукт спрощує придбання, відстеження та верифікацію сертифікатів, що підтверджують споживання компанією певної кількості енергії з відновлюваних джерел протягом звітного періоду.
Контекст галузі
Контекст галузі
Контекст галузі
Ринок сертифікатів на відновлювану енергію швидко зростає, але функціонує повільно.
Ринок сертифікатів на відновлювану енергію швидко зростає, але функціонує повільно.
Оскільки вимоги щодо звітності ESG стають дедалі суворішими у Європі та Північній Америці, компанії відчувають дедалі більший тиск з боку регулюючих органів. Компаніям необхідно довести, що їхнє енергоспоживання походить з відновлюваних джерел. Таким доказом виступають сертифікати: гарантії походження в Європі та RECs (сертифікати відновлюваної енергії) у США. Ці сертифікати видаються державними реєстрами і передаються між сторонами через різноманітні внутрішньодержавні процедури в кожній окремій країні.
Проблема полягає в тому, що більша частина цього процесу досі забюрократизована. Кожна країна має свій власний реєстр, правила та вимоги до інтеграції. Великі споживачі енергії можуть вести переговори безпосередньо з урядами. Меншим компаніям потрібні посередники. А платформи, що об'єднують покупців, продавців і реєстри, часто побудовані на застарілій інфраструктурі, яка не була розрахована на обсяги або складність, що їх наразі вимагає ринок.
Оскільки вимоги щодо звітності ESG стають дедалі суворішими у Європі та Північній Америці, компанії відчувають дедалі більший тиск з боку регулюючих органів. Компаніям необхідно довести, що їхнє енергоспоживання походить з відновлюваних джерел. Таким доказом виступають сертифікати: гарантії походження в Європі та RECs (сертифікати відновлюваної енергії) у США. Ці сертифікати видаються державними реєстрами і передаються між сторонами через різноманітні внутрішньодержавні процедури в кожній окремій країні.
Проблема полягає в тому, що більша частина цього процесу досі забюрократизована. Кожна країна має свій власний реєстр, правила та вимоги до інтеграції. Великі споживачі енергії можуть вести переговори безпосередньо з урядами. Меншим компаніям потрібні посередники. А платформи, що об'єднують покупців, продавців і реєстри, часто побудовані на застарілій інфраструктурі, яка не була розрахована на обсяги або складність, що їх наразі вимагає ринок.
Оскільки вимоги щодо звітності ESG стають дедалі суворішими у Європі та Північній Америці, компанії відчувають дедалі більший тиск з боку регулюючих органів. Компаніям необхідно довести, що їхнє енергоспоживання походить з відновлюваних джерел. Таким доказом виступають сертифікати: гарантії походження в Європі та RECs (сертифікати відновлюваної енергії) у США. Ці сертифікати видаються державними реєстрами і передаються між сторонами через різноманітні внутрішньодержавні процедури в кожній окремій країні.
Проблема полягає в тому, що більша частина цього процесу досі забюрократизована. Кожна країна має свій власний реєстр, правила та вимоги до інтеграції. Великі споживачі енергії можуть вести переговори безпосередньо з урядами. Меншим компаніям потрібні посередники. А платформи, що об'єднують покупців, продавців і реєстри, часто побудовані на застарілій інфраструктурі, яка не була розрахована на обсяги або складність, що їх наразі вимагає ринок.
Для платформних компаній, таких як наш клієнт, це створює наступні виклики: ви здійснюєте розробку в умовах мінливих регуляторних вимог, тоді як ваша власна кодова база накопичує технічний борг через швидке впровадження нових функцій. Команди, які можуть модернізувати свою інфраструктуру найшвидше без порушення поточної роботи, отримують справжню конкурентну перевагу.
Для платформних компаній, таких як наш клієнт, це створює наступні виклики: ви здійснюєте розробку в умовах мінливих регуляторних вимог, тоді як ваша власна кодова база накопичує технічний борг через швидке впровадження нових функцій. Команди, які можуть модернізувати свою інфраструктуру найшвидше без порушення поточної роботи, отримують справжню конкурентну перевагу.
Виклик
Виклик
Виклик
Коли один із фронтенд-інженерів Brightgrove приєднався до проєкту, він виявив, що платформа зайшла в глухий кут: прогрес сповільнився, а команді бракувало узгодженості щодо основних проблем та найкращого шляху їх вирішення.
Приблизно за рік до цього фронтенд було розділено на мікрофронтенди. На папері це мало б дозволити командам працювати незалежно в різних предметних областях, але на практиці це створило більше проблем, ніж вирішило:
• Жорсткі перехресні залежності: мікрофронтенди використовували так багато спільних бібліотек, що оновлення однієї часто руйнувало іншу.
• Відсутність синхронізації версій інструментів: коли спільна бібліотека оновлювалася в оболонці додатка (shell app), кожен мікрофронтенд доводилося узгоджувати вручну. Невідповідності виявлялися лише під час виконання — вже в продакшені.
• Застарілий бандлер: усе працювало на WebPack, зібраному без послідовної конфігурації збірки в репозиторіях.
• Відсутність чіткого продуктового напрямку: платформа постійно переорієнтовувалася на той державний реєстр, який відкривався наступним, без стабільної дорожньої карти.
• Низьке покриття тестами: ~35% покриття юніт-тестами, жодних інтеграційних тестів між мікрофронтендами. Якість фронтенду значно відставала від бекенду.
Впровадження архітектури мікрофронтендів — це серйозне структурне рішення, і команда швидко зіткнулася з поширеним вузьким місцем масштабування: підтримка збірок та баги із залежностями почали поглинати години розробників. Щоб усунути це, подальший шлях вимагав подвійного підходу: оновлення кодової бази до сучасного інструменту збірки (Rsbuild) та впровадження автоматизованого структурного рішення для постійного керування залежностями.
Коли один із фронтенд-інженерів Brightgrove приєднався до проєкту, він виявив, що платформа зайшла в глухий кут: прогрес сповільнився, а команді бракувало узгодженості щодо основних проблем та найкращого шляху їх вирішення.
Приблизно за рік до цього фронтенд було розділено на мікрофронтенди. На папері це мало б дозволити командам працювати незалежно в різних предметних областях, але на практиці це створило більше проблем, ніж вирішило:
• Жорсткі перехресні залежності: мікрофронтенди використовували так багато спільних бібліотек, що оновлення однієї часто руйнувало іншу.
• Відсутність синхронізації версій інструментів: коли спільна бібліотека оновлювалася в оболонці додатка (shell app), кожен мікрофронтенд доводилося узгоджувати вручну. Невідповідності виявлялися лише під час виконання — вже в продакшені.
• Застарілий бандлер: усе працювало на WebPack, зібраному без послідовної конфігурації збірки в репозиторіях.
• Відсутність чіткого продуктового напрямку: платформа постійно переорієнтовувалася на той державний реєстр, який відкривався наступним, без стабільної дорожньої карти.
• Низьке покриття тестами: ~35% покриття юніт-тестами, жодних інтеграційних тестів між мікрофронтендами. Якість фронтенду значно відставала від бекенду.
Впровадження архітектури мікрофронтендів — це серйозне структурне рішення, і команда швидко зіткнулася з поширеним вузьким місцем масштабування: підтримка збірок та баги із залежностями почали поглинати години розробників. Щоб усунути це, подальший шлях вимагав подвійного підходу: оновлення кодової бази до сучасного інструменту збірки (Rsbuild) та впровадження автоматизованого структурного рішення для постійного керування залежностями.
Коли один із фронтенд-інженерів Brightgrove приєднався до проєкту, він виявив, що платформа зайшла в глухий кут: прогрес сповільнився, а команді бракувало узгодженості щодо основних проблем та найкращого шляху їх вирішення.
Приблизно за рік до цього фронтенд було розділено на мікрофронтенди. На папері це мало б дозволити командам працювати незалежно в різних предметних областях, але на практиці це створило більше проблем, ніж вирішило:
• Жорсткі перехресні залежності: мікрофронтенди використовували так багато спільних бібліотек, що оновлення однієї часто руйнувало іншу.
• Відсутність синхронізації версій інструментів: коли спільна бібліотека оновлювалася в оболонці додатка (shell app), кожен мікрофронтенд доводилося узгоджувати вручну. Невідповідності виявлялися лише під час виконання — вже в продакшені.
• Застарілий бандлер: усе працювало на WebPack, зібраному без послідовної конфігурації збірки в репозиторіях.
• Відсутність чіткого продуктового напрямку: платформа постійно переорієнтовувалася на той державний реєстр, який відкривався наступним, без стабільної дорожньої карти.
• Низьке покриття тестами: ~35% покриття юніт-тестами, жодних інтеграційних тестів між мікрофронтендами. Якість фронтенду значно відставала від бекенду.
Впровадження архітектури мікрофронтендів — це серйозне структурне рішення, і команда швидко зіткнулася з поширеним вузьким місцем масштабування: підтримка збірок та баги із залежностями почали поглинати години розробників. Щоб усунути це, подальший шлях вимагав подвійного підходу: оновлення кодової бази до сучасного інструменту збірки (Rsbuild) та впровадження автоматизованого структурного рішення для постійного керування залежностями.
Рішення
Рішення
Рішення
Основними інструментами були Qwen 3 та GPT-OSS (~120 млрд параметрів у моделях), які запускалися на власному ноутбуці інженера та доступ до яких здійснювався через розміщену на власному сервері OpenAI-сумісний ендпоінт в локальній мережі. Це не був хмарний сервіс чи SaaS-підписка; це була власна розгорнута модель, яка ітеративно навчалася для завдань фронтенд-розробки протягом місяців тестування та перевірки підказок.
Міграція відбувалася за структурованим процесом:
• Інвентаризація та аналіз: Файли проєктів, конфігурації збірки та дерева залежностей з кожного мікрофронтенду передавалися до LLM для структурного аналізу. ШІ визначав, які бібліотеки є спільними, де існують невідповідності версій і які конфігурації потребують перезапису.
• Генерація конфігурацій: LLM створювала нові конфігурації Rsbuild для кожного репозиторію, перекладаючи специфічні для WebPack шаблони на їхні еквіваленти в Rsbuild. Кожен результат перевірявся та коригувався інженером перед комітом.
• Розв'язання залежностей: ШІ виявляв спільні бібліотеки та позначав розбіжності у версіях у всіх 6 репозиторіях. Ця робота зазвичай вимагала б вручну зіставляти файли package.json у кількох репозиторіях.
• Валідація та ітерація: Кожен згенерований ШІ результат проходив ручну перевірку. Галюцинації виявлялися та виправлялися, підказки вдосконалювалися, і з кожним циклом розуміння кодової бази моделлю покращувалося.
Інструмент синхронізації та перевірки залежностей
Сама міграція виявила глибшу проблему — не було механізму для запобігання розбіжностям версій бібліотек між мікрофронтендами. Тож інженер створив його сам.
Використовуючи ту саму локальну інфраструктуру LLM, він створив власний інструмент для роботи на етапі CI, який сканує версії бібліотек у всіх репозиторіях і виявляє невідповідності до того, як вони потраплять у середовище виконання. Це запускається автоматично при кожній збірці — існуючі інструменти (syncpack, manypkg) не підходили для їхньої топології крос-репозиторних мікрофронтендів, тому вони створили інструмент під власні потреби. Він виявляє саме той клас помилок, який дошкуляв команді: «це працювало ізольовано, але ламається під час збірки разом».
Тестування та паритет функцій
Забезпечення того, щоб нічого не зламалося під час міграції, покладалося на поєднання кількох підходів:
• Валідація на рівні збірки: Кожен перенесений мікрофронтенд компілювався та тестувався з оболонкою застосунку. Помилки в рендерингу спільних компонентів або маршрутизації виявлялися безпосередньо під час збірки.
• Ручне "смоук"-тестування: Основні сценарії користувачів для кожного домену проходилися вручну для перевірки функціонального паритету.
• Чесне прийняття ризиків: Маючи лише ~35% покриття юніт-тестами та відсутність інтеграційного пакету тестів, команда визнала, що повна автоматизована перевірка на регресію неможлива. Написання вичерпного набору тестів насамперед додало б кілька тижнів роботи. Прагматичним вибором була структурна валідація (збірки + інструменти CI) та ручна перевірка (критичні сценарії), з подальшим виправленням едж-випадків на етапі очищення коду.
Подальша робота
Очищення коду після міграції зайняло приблизно 3 дні:
• Дні 1-2: Три спільні бібліотеки (бібліотека UI-компонентів, форматування дат, API-клієнт) мали незначні конфлікти версій, що спричиняло едж-випадки при рендерингу — локалізація вибору дати та позиціонування спливаючих підказок у спільних компонентах.
• День 3: Хот-релоад серверу розробки Rsbuild обробляв динамічні імпорти дещо інакше, ніж WebPack. Двом репозиторіям знадобилося коригування конфігурації відповідно до поведінки бандлінгу в продакшені.
• Постійно: Інструмент синхронізації та перевірки залежностей в CI тепер виявляє 2-3 випадки розбіжностей у версіях на місяць, які раніше залишалися б непоміченими, доки користувач не зіткнувся б із багом у продакшені.
Основними інструментами були Qwen 3 та GPT-OSS (~120 млрд параметрів у моделях), які запускалися на власному ноутбуці інженера та доступ до яких здійснювався через розміщену на власному сервері OpenAI-сумісний ендпоінт в локальній мережі. Це не був хмарний сервіс чи SaaS-підписка; це була власна розгорнута модель, яка ітеративно навчалася для завдань фронтенд-розробки протягом місяців тестування та перевірки підказок.
Міграція відбувалася за структурованим процесом:
• Інвентаризація та аналіз: Файли проєктів, конфігурації збірки та дерева залежностей з кожного мікрофронтенду передавалися до LLM для структурного аналізу. ШІ визначав, які бібліотеки є спільними, де існують невідповідності версій і які конфігурації потребують перезапису.
• Генерація конфігурацій: LLM створювала нові конфігурації Rsbuild для кожного репозиторію, перекладаючи специфічні для WebPack шаблони на їхні еквіваленти в Rsbuild. Кожен результат перевірявся та коригувався інженером перед комітом.
• Розв'язання залежностей: ШІ виявляв спільні бібліотеки та позначав розбіжності у версіях у всіх 6 репозиторіях. Ця робота зазвичай вимагала б вручну зіставляти файли package.json у кількох репозиторіях.
• Валідація та ітерація: Кожен згенерований ШІ результат проходив ручну перевірку. Галюцинації виявлялися та виправлялися, підказки вдосконалювалися, і з кожним циклом розуміння кодової бази моделлю покращувалося.
Інструмент синхронізації та перевірки залежностей
Сама міграція виявила глибшу проблему — не було механізму для запобігання розбіжностям версій бібліотек між мікрофронтендами. Тож інженер створив його сам.
Використовуючи ту саму локальну інфраструктуру LLM, він створив власний інструмент для роботи на етапі CI, який сканує версії бібліотек у всіх репозиторіях і виявляє невідповідності до того, як вони потраплять у середовище виконання. Це запускається автоматично при кожній збірці — існуючі інструменти (syncpack, manypkg) не підходили для їхньої топології крос-репозиторних мікрофронтендів, тому вони створили інструмент під власні потреби. Він виявляє саме той клас помилок, який дошкуляв команді: «це працювало ізольовано, але ламається під час збірки разом».
Тестування та паритет функцій
Забезпечення того, щоб нічого не зламалося під час міграції, покладалося на поєднання кількох підходів:
• Валідація на рівні збірки: Кожен перенесений мікрофронтенд компілювався та тестувався з оболонкою застосунку. Помилки в рендерингу спільних компонентів або маршрутизації виявлялися безпосередньо під час збірки.
• Ручне "смоук"-тестування: Основні сценарії користувачів для кожного домену проходилися вручну для перевірки функціонального паритету.
• Чесне прийняття ризиків: Маючи лише ~35% покриття юніт-тестами та відсутність інтеграційного пакету тестів, команда визнала, що повна автоматизована перевірка на регресію неможлива. Написання вичерпного набору тестів насамперед додало б кілька тижнів роботи. Прагматичним вибором була структурна валідація (збірки + інструменти CI) та ручна перевірка (критичні сценарії), з подальшим виправленням едж-випадків на етапі очищення коду.
Подальша робота
Очищення коду після міграції зайняло приблизно 3 дні:
• Дні 1-2: Три спільні бібліотеки (бібліотека UI-компонентів, форматування дат, API-клієнт) мали незначні конфлікти версій, що спричиняло едж-випадки при рендерингу — локалізація вибору дати та позиціонування спливаючих підказок у спільних компонентах.
• День 3: Хот-релоад серверу розробки Rsbuild обробляв динамічні імпорти дещо інакше, ніж WebPack. Двом репозиторіям знадобилося коригування конфігурації відповідно до поведінки бандлінгу в продакшені.
• Постійно: Інструмент синхронізації та перевірки залежностей в CI тепер виявляє 2-3 випадки розбіжностей у версіях на місяць, які раніше залишалися б непоміченими, доки користувач не зіткнувся б із багом у продакшені.
Основними інструментами були Qwen 3 та GPT-OSS (~120 млрд параметрів у моделях), які запускалися на власному ноутбуці інженера та доступ до яких здійснювався через розміщену на власному сервері OpenAI-сумісний ендпоінт в локальній мережі. Це не був хмарний сервіс чи SaaS-підписка; це була власна розгорнута модель, яка ітеративно навчалася для завдань фронтенд-розробки протягом місяців тестування та перевірки підказок.
Міграція відбувалася за структурованим процесом:
• Інвентаризація та аналіз: Файли проєктів, конфігурації збірки та дерева залежностей з кожного мікрофронтенду передавалися до LLM для структурного аналізу. ШІ визначав, які бібліотеки є спільними, де існують невідповідності версій і які конфігурації потребують перезапису.
• Генерація конфігурацій: LLM створювала нові конфігурації Rsbuild для кожного репозиторію, перекладаючи специфічні для WebPack шаблони на їхні еквіваленти в Rsbuild. Кожен результат перевірявся та коригувався інженером перед комітом.
• Розв'язання залежностей: ШІ виявляв спільні бібліотеки та позначав розбіжності у версіях у всіх 6 репозиторіях. Ця робота зазвичай вимагала б вручну зіставляти файли package.json у кількох репозиторіях.
• Валідація та ітерація: Кожен згенерований ШІ результат проходив ручну перевірку. Галюцинації виявлялися та виправлялися, підказки вдосконалювалися, і з кожним циклом розуміння кодової бази моделлю покращувалося.
Інструмент синхронізації та перевірки залежностей
Сама міграція виявила глибшу проблему — не було механізму для запобігання розбіжностям версій бібліотек між мікрофронтендами. Тож інженер створив його сам.
Використовуючи ту саму локальну інфраструктуру LLM, він створив власний інструмент для роботи на етапі CI, який сканує версії бібліотек у всіх репозиторіях і виявляє невідповідності до того, як вони потраплять у середовище виконання. Це запускається автоматично при кожній збірці — існуючі інструменти (syncpack, manypkg) не підходили для їхньої топології крос-репозиторних мікрофронтендів, тому вони створили інструмент під власні потреби. Він виявляє саме той клас помилок, який дошкуляв команді: «це працювало ізольовано, але ламається під час збірки разом».
Тестування та паритет функцій
Забезпечення того, щоб нічого не зламалося під час міграції, покладалося на поєднання кількох підходів:
• Валідація на рівні збірки: Кожен перенесений мікрофронтенд компілювався та тестувався з оболонкою застосунку. Помилки в рендерингу спільних компонентів або маршрутизації виявлялися безпосередньо під час збірки.
• Ручне "смоук"-тестування: Основні сценарії користувачів для кожного домену проходилися вручну для перевірки функціонального паритету.
• Чесне прийняття ризиків: Маючи лише ~35% покриття юніт-тестами та відсутність інтеграційного пакету тестів, команда визнала, що повна автоматизована перевірка на регресію неможлива. Написання вичерпного набору тестів насамперед додало б кілька тижнів роботи. Прагматичним вибором була структурна валідація (збірки + інструменти CI) та ручна перевірка (критичні сценарії), з подальшим виправленням едж-випадків на етапі очищення коду.
Подальша робота
Очищення коду після міграції зайняло приблизно 3 дні:
• Дні 1-2: Три спільні бібліотеки (бібліотека UI-компонентів, форматування дат, API-клієнт) мали незначні конфлікти версій, що спричиняло едж-випадки при рендерингу — локалізація вибору дати та позиціонування спливаючих підказок у спільних компонентах.
• День 3: Хот-релоад серверу розробки Rsbuild обробляв динамічні імпорти дещо інакше, ніж WebPack. Двом репозиторіям знадобилося коригування конфігурації відповідно до поведінки бандлінгу в продакшені.
• Постійно: Інструмент синхронізації та перевірки залежностей в CI тепер виявляє 2-3 випадки розбіжностей у версіях на місяць, які раніше залишалися б непоміченими, доки користувач не зіткнувся б із багом у продакшені.
Результати
Результати
Результати
Найбільш помітною зміною стала швидкість: міграція, яка забрала б близько місяця робочого часу, була завершена за тиждень, плюс три дні на фінальне очищення коду. Але значно важливішими були структурні зміни.
До міграції фронтенд проєкту розробникам доводилося самостійно стежити за синхронізацією версій бібліотек. Конфігурації збірки копіювалися та вставлялися між репозиторіями з ручними коригуваннями. Проблеми виявлялися вже в інструментах розгортання.
Після міграції платформа отримала:
• Сучасні інструменти збірки (Rsbuild) з узгодженою конфігурацією в усіх 6 репозиторіях.
• Автоматизований моніторинг залежностей, що виявляє розбіжності версій на етапі CI, ще до потрапляння коду на платформу розгортання.
• Перевірений робочий процес із залученням ШІ, який команда змогла застосувати до наступних викликів.
Ця міграція стала першим випадком, коли ШІ використовувався для інженерної роботи команди. Її успіх відкрив шлях для ширшого спектру інтеграцій ШІ, включаючи автономний аудит коду, базу знань про проєкт на основі RAG та багатоагентні процеси усунення помилок.
Порівняння «До» та «Після»
Щоб підтвердити ефективність наших методологій розробки з використанням ШІ, ми порівняли нашу архітектуру міграції за допомогою ШІ з традиційними, суто ручними підходами.
Традиційний підхід | З допомогою ШІ | |
|---|---|---|
Тривалість міграції | ~4 тижні | ~1 тиждень (+3 дні на очищення коду) |
Необхідні інженери | 1-2 провідні фронтенд-розробники | 1 провідний фронтенд-розробник |
Години розробки | ~160 год | ~50 год |
Прискорення процесу | - | у 3.5 раза швидше |
Переписані конфіги збірки | ~30 (вручну) | ~30 (створені ШІ, перевірені інженером) |
Поточні інструменти | Немає | Перевірка залежностей в CI (автоматична) |
Виявлення розбіжностей версій | Тільки під час роботи (помилки в продакшені) | Під час CI (фіксується перед деплоєм) |
Найбільш помітною зміною стала швидкість: міграція, яка забрала б близько місяця робочого часу, була завершена за тиждень, плюс три дні на фінальне очищення коду. Але значно важливішими були структурні зміни.
До міграції фронтенд проєкту розробникам доводилося самостійно стежити за синхронізацією версій бібліотек. Конфігурації збірки копіювалися та вставлялися між репозиторіями з ручними коригуваннями. Проблеми виявлялися вже в інструментах розгортання.
Після міграції платформа отримала:
• Сучасні інструменти збірки (Rsbuild) з узгодженою конфігурацією в усіх 6 репозиторіях.
• Автоматизований моніторинг залежностей, що виявляє розбіжності версій на етапі CI, ще до потрапляння коду на платформу розгортання.
• Перевірений робочий процес із залученням ШІ, який команда змогла застосувати до наступних викликів.
Ця міграція стала першим випадком, коли ШІ використовувався для інженерної роботи команди. Її успіх відкрив шлях для ширшого спектру інтеграцій ШІ, включаючи автономний аудит коду, базу знань про проєкт на основі RAG та багатоагентні процеси усунення помилок.
Порівняння «До» та «Після»
Щоб підтвердити ефективність наших методологій розробки з використанням ШІ, ми порівняли нашу архітектуру міграції за допомогою ШІ з традиційними, суто ручними підходами.
Традиційний підхід | З допомогою ШІ | |
|---|---|---|
Тривалість міграції | ~4 тижні | ~1 тиждень (+3 дні на очищення коду) |
Необхідні інженери | 1-2 провідні фронтенд-розробники | 1 провідний фронтенд-розробник |
Години розробки | ~160 год | ~50 год |
Прискорення процесу | - | у 3.5 раза швидше |
Переписані конфіги збірки | ~30 (вручну) | ~30 (створені ШІ, перевірені інженером) |
Поточні інструменти | Немає | Перевірка залежностей в CI (автоматична) |
Виявлення розбіжностей версій | Тільки під час роботи (помилки в продакшені) | Під час CI (фіксується перед деплоєм) |
Найбільш помітною зміною стала швидкість: міграція, яка забрала б близько місяця робочого часу, була завершена за тиждень, плюс три дні на фінальне очищення коду. Але значно важливішими були структурні зміни.
До міграції фронтенд проєкту розробникам доводилося самостійно стежити за синхронізацією версій бібліотек. Конфігурації збірки копіювалися та вставлялися між репозиторіями з ручними коригуваннями. Проблеми виявлялися вже в інструментах розгортання.
Після міграції платформа отримала:
• Сучасні інструменти збірки (Rsbuild) з узгодженою конфігурацією в усіх 6 репозиторіях.
• Автоматизований моніторинг залежностей, що виявляє розбіжності версій на етапі CI, ще до потрапляння коду на платформу розгортання.
• Перевірений робочий процес із залученням ШІ, який команда змогла застосувати до наступних викликів.
Ця міграція стала першим випадком, коли ШІ використовувався для інженерної роботи команди. Її успіх відкрив шлях для ширшого спектру інтеграцій ШІ, включаючи автономний аудит коду, базу знань про проєкт на основі RAG та багатоагентні процеси усунення помилок.
Порівняння «До» та «Після»
Щоб підтвердити ефективність наших методологій розробки з використанням ШІ, ми порівняли нашу архітектуру міграції за допомогою ШІ з традиційними, суто ручними підходами.
Традиційний підхід | З допомогою ШІ | |
|---|---|---|
Тривалість міграції | ~4 тижні | ~1 тиждень (+3 дні на очищення коду) |
Необхідні інженери | 1-2 провідні фронтенд-розробники | 1 провідний фронтенд-розробник |
Години розробки | ~160 год | ~50 год |
Прискорення процесу | - | у 3.5 раза швидше |
Переписані конфіги збірки | ~30 (вручну) | ~30 (створені ШІ, перевірені інженером) |
Поточні інструменти | Немає | Перевірка залежностей в CI (автоматична) |
Виявлення розбіжностей версій | Тільки під час роботи (помилки в продакшені) | Під час CI (фіксується перед деплоєм) |
Переваги
Переваги
Переваги
Пряма економія часу
Пряма економія часу
Пряма економія часу
~110 годин розробки заощаджено лише на самій міграції. За типовими рейтами Senior фронтенд-розробників, це значне зниження витрат на одному проєкті.
~110 годин розробки заощаджено лише на самій міграції. За типовими рейтами Senior фронтенд-розробників, це значне зниження витрат на одному проєкті.
~110 годин розробки заощаджено лише на самій міграції. За типовими рейтами Senior фронтенд-розробників, це значне зниження витрат на одному проєкті.
Зменьшення витрат
Зменьшення витрат
Зменьшення витрат
Інструмент синхронізації залежностей запобігає виникненню приблизно 2-3 помилок на місяць, пов'язаних із розбіжністю версій, які впливають на продакшн. На виявлення та усунення кожної з них зазвичай витрачалося б пів дня — це зберігає приблизно 12-18 інженерних годин на місяць.
Інструмент синхронізації залежностей запобігає виникненню приблизно 2-3 помилок на місяць, пов'язаних із розбіжністю версій, які впливають на продакшн. На виявлення та усунення кожної з них зазвичай витрачалося б пів дня — це зберігає приблизно 12-18 інженерних годин на місяць.
Інструмент синхронізації залежностей запобігає виникненню приблизно 2-3 помилок на місяць, пов'язаних із розбіжністю версій, які впливають на продакшн. На виявлення та усунення кожної з них зазвичай витрачалося б пів дня — це зберігає приблизно 12-18 інженерних годин на місяць.
Економія на інфраструктурі
Економія на інфраструктурі
Економія на інфраструктурі
Подальша оптимізація за допомогою ШІ (кешування, обмеження частоти запитів) дозволила скоротити кількість зайвих викликів API, які коштували 6–7 доларів на день через непотрібне навантаження на базу даних.
Подальша оптимізація за допомогою ШІ (кешування, обмеження частоти запитів) дозволила скоротити кількість зайвих викликів API, які коштували 6–7 доларів на день через непотрібне навантаження на базу даних.
Подальша оптимізація за допомогою ШІ (кешування, обмеження частоти запитів) дозволила скоротити кількість зайвих викликів API, які коштували 6–7 доларів на день через непотрібне навантаження на базу даних.
Масштабування потужності
Масштабування потужності
Масштабування потужності
Після міграції той самий інженер зміг паралельно працювати над 6 проєктами, регулярно закриваючи 20 сторі-пойнтів на тиждень. Повноцінну консоль управління (28 унікальних сторінок, 6 ролей користувачів) було створено з нуля приблизно за 3 тижні — робота, яка зазвичай забирала 5–6 місяців.
Після міграції той самий інженер зміг паралельно працювати над 6 проєктами, регулярно закриваючи 20 сторі-пойнтів на тиждень. Повноцінну консоль управління (28 унікальних сторінок, 6 ролей користувачів) було створено з нуля приблизно за 3 тижні — робота, яка зазвичай забирала 5–6 місяців.
Висновок
Висновок
Висновок
Поширене питання від керівників розробки полягає в тому, чи повинен ШІ бути частиною їхньої моделі ділівері. Відповідь залежить від того, як саме його застосовувати. ШІ не замінює інженера. Він його підсилює. Міграція пройшла успішно не тому, що ШІ написав код, а тому, що досвідчений інженер, який розумів архітектуру, використав ШІ для усунення механічних частин роботи: сканування конфігурацій, генерації шаблонів, мапування залежностей, виявлення невідповідностей.
Цей шаблон є універсальним. Незалежно від того, чи ви мігруєте з Angular на React, консолідуєте мікросервіси, оновлюєте систему збірки чи закриваєте старі технічні борги, підхід залишається незмінним:
Почніть із залучення досвідченого інженера, який розуміє як вихідну, так і цільову архітектуру.
Використовуйте ШІ для автоматизації інвентаризації, аналізу та генерації — роботи, яка забирає багато часу, але не потребує критичних мислення.
Залучайте людину до кожного архітектурного рішення та кожного перегляду коду (code review).
Створюйте інструменти (а не просто кінцеві результати), які продовжуватимуть приносити користь і після завершення міграції.
Інструмент синхронізації залежностей є підтвердженням цього принципу. Він не входив до початкового обсягу робіт. Він з'явився тому, що інженер, звільнившись від рутинної роботи, отримав можливість вирішити структурну проблему, що лежала в основі міграції.
Поширене питання від керівників розробки полягає в тому, чи повинен ШІ бути частиною їхньої моделі ділівері. Відповідь залежить від того, як саме його застосовувати. ШІ не замінює інженера. Він його підсилює. Міграція пройшла успішно не тому, що ШІ написав код, а тому, що досвідчений інженер, який розумів архітектуру, використав ШІ для усунення механічних частин роботи: сканування конфігурацій, генерації шаблонів, мапування залежностей, виявлення невідповідностей.
Цей шаблон є універсальним. Незалежно від того, чи ви мігруєте з Angular на React, консолідуєте мікросервіси, оновлюєте систему збірки чи закриваєте старі технічні борги, підхід залишається незмінним:
Почніть із залучення досвідченого інженера, який розуміє як вихідну, так і цільову архітектуру.
Використовуйте ШІ для автоматизації інвентаризації, аналізу та генерації — роботи, яка забирає багато часу, але не потребує критичних мислення.
Залучайте людину до кожного архітектурного рішення та кожного перегляду коду (code review).
Створюйте інструменти (а не просто кінцеві результати), які продовжуватимуть приносити користь і після завершення міграції.
Інструмент синхронізації залежностей є підтвердженням цього принципу. Він не входив до початкового обсягу робіт. Він з'явився тому, що інженер, звільнившись від рутинної роботи, отримав можливість вирішити структурну проблему, що лежала в основі міграції.
Поширене питання від керівників розробки полягає в тому, чи повинен ШІ бути частиною їхньої моделі ділівері. Відповідь залежить від того, як саме його застосовувати. ШІ не замінює інженера. Він його підсилює. Міграція пройшла успішно не тому, що ШІ написав код, а тому, що досвідчений інженер, який розумів архітектуру, використав ШІ для усунення механічних частин роботи: сканування конфігурацій, генерації шаблонів, мапування залежностей, виявлення невідповідностей.
Цей шаблон є універсальним. Незалежно від того, чи ви мігруєте з Angular на React, консолідуєте мікросервіси, оновлюєте систему збірки чи закриваєте старі технічні борги, підхід залишається незмінним:
Почніть із залучення досвідченого інженера, який розуміє як вихідну, так і цільову архітектуру.
Використовуйте ШІ для автоматизації інвентаризації, аналізу та генерації — роботи, яка забирає багато часу, але не потребує критичних мислення.
Залучайте людину до кожного архітектурного рішення та кожного перегляду коду (code review).
Створюйте інструменти (а не просто кінцеві результати), які продовжуватимуть приносити користь і після завершення міграції.
Інструмент синхронізації залежностей є підтвердженням цього принципу. Він не входив до початкового обсягу робіт. Він з'явився тому, що інженер, звільнившись від рутинної роботи, отримав можливість вирішити структурну проблему, що лежала в основі міграції.
Завантажте повний кейс-стаді англійською в .pdf
© 2025 Brightgrove. Всі права захищені.
© 2025 Brightgrove. Всі права захищені.
© 2025 Brightgrove. Всі права захищені.
© 2025 Brightgrove. Всі права захищені.