Codex збільшив темп релізів loveholidays без найму
За рік частка змін коду з ШІ в loveholidays зросла із 7% до 79%, а кількість розгортань — на 73% без розширення штату інженерів. У Data Platform успішність змін піднялася з 58% до 93%, а на одне звернення в підтримку припадає вчетверо більше змін.
Менеджери продукту, дизайнери й комерційні фахівці створюють прототипи через Search Playground. Там розробили понад 10 пошукових сценаріїв, переважно без інженерів; щонайменше три вже працюють на сайті. Це допомогло скоротити витрати на хмарне сховище приблизно на £36 000 і на обробку даних — ще на £100 000 на рік.
Що змінилося у створенні клієнтських сервісів
Search Playground відокремив перевірку ідей від черги інженерної команди. Його створили на основі чинної дизайн-системи, фронтенд-технологій компанії та Codex. Працівник може перетворити задум на робочий клієнтський досвід, зібрати відгуки й перевірити, чи дає рішення цінність, перш ніж інженери витратять на нього час.
Окремий приклад — Inspire Me. Цей сценарій допомагає мандрівникам досліджувати різні типи відпочинку: від пляжних поїздок до гастрономічних. Інша ситуація виникла в маркетингу під час кампанії Crisps from Abroad. Команді був потрібен інтерактивний мікросайт для заявок на конкурс і добірок ідей для подорожей. Раніше для окремого цифрового продукту залучили б зовнішню агенцію, а цього разу маркетингова команда зробила його самостійно за кілька годин і зберегла наявну дизайн-систему.
Як перенесли підхід на дані та інфраструктуру
Раніше зміни в Data Platform та інфраструктурі вимагали знання спеціалізованих інструментів, репозиторіїв, контролю версій і внутрішніх процедур. Якщо користувач зупинявся, до роботи підключався профільний інженер. Новий підхід полягає не в тому, щоб кожного навчити всіх систем, а в тому, щоб вбудувати інженерну експертизу в керований процес.
- Крок 1. Інженерні команди кодифікують найкращі практики, інструкції та перевірки.
- Крок 2. Працівник формулює, якого результату хоче досягти, не відтворюючи вручну весь технічний шлях.
- Крок 3. Codex допомагає запропонувати зміну та провести користувача через потрібні дії.
- Крок 4. Система запускає перевірки й супроводжує зміну через процес випуску.
- Крок 5. Команди оновлюють правила й валідації, коли змінюється реальна практика.
У ширших сценаріях самообслуговування інфраструктури успішність зросла з 63% до 90%. Працівники менше чекають профільної допомоги, а інженери менше часу витрачають на типові звернення та більше — на вдосконалення самої платформи.
Де підхід має межі
Цей досвід не зводиться до видачі доступу до інструмента. Він працює там, де команда спочатку описала практики, інструкції й валідації, а потім постійно їх оновлює. Без такого шару працівникові знову потрібне знання внутрішніх систем або допомога спеціаліста. Search Playground також створили самі інженери й прив’язали до технологій та дизайн-системи компанії: саме ця рамка дала неінженерним командам змогу робити узгоджені прототипи.
Не кожен прототип автоматично стає продуктом. Playground дає ідеї для перевірки, збору відгуків і оцінки цінності; у роботу на сайті перейшла лише частина створених сценаріїв. Тому помилка — оцінювати результат за кількістю згенерованого коду або самим фактом використання ШІ. loveholidays свідомо дивиться на бізнес-наслідки: чи розв’язано проблему, чи зросла успішність змін, чи зменшилися витрати й потреба в підтримці.
Що має перевірити людина
Перед випуском треба переконатися, що зміна пройшла закодовані командою валідації та внутрішній процес релізу. Для клієнтського сценарію окремо потрібні відгуки й підтвердження, що він дає цінність. Для змін у даних та інфраструктурі орієнтиром є не самостійність користувача, а успішний результат без додаткового звернення до профільного інженера.
- Чи сформульована бізнес-проблема, а не лише бажання створити більше коду.
- Чи відповідає клієнтський прототип чинній дизайн-системі та технологіям.
- Чи виконані передбачені командою перевірки перед релізом.
- Чи є фактичний сигнал цінності: відгуки, успішна зміна, менше підтримки або нижчі витрати.