eSimphony будує інженерна команда з п'яти людей. Продукт покриває понад 150 країн, має нативні застосунки для iOS та Android, тримає мультирегіональний стек інтеграцій з операторами, підтримує п'ять мов наскрізь і випускає зміни щотижня. Ми не телеком на тисячу співробітників. Ми маленька команда, яка свідомо працює з важелем.

Цей важіль — конкретний підхід до інженерії, який ми засвоїли за останні 18 місяців. Ми називаємо його ШІ-нативною розробкою. Ось як він виглядає на практиці.

Форма команди

П'ять інженерів. Один продуктовий дизайнер. Один CEO, який досі особисто пише частину продуктових специфікацій. Формального продакт-менеджера немає: специфікації народжуються з CEO, чернеток за допомогою Moza та інженерного судження. Окремої команди QA немає: тестування вбудоване в цикл розробки. Окремого DevOps немає: інфраструктурою володіє той, хто випускає фічу.

Це не вихваляння. Це обмеження. За такого розміру команди єдиний спосіб випускати продукт масштабу eSimphony — помножити віддачу кожного інженера. ШІ — той множник, на який ми зробили ставку.

Робочий процес із п'яти етапів

Кожна зміна в eSimphony — від правки тексту до інтеграції нового оператора — проходить ті самі п'ять етапів. Кожен етап іде за допомогою ШІ; на кожному етапі в контурі є людина.

1. Розвідка (без технічних бар'єрів)

Коли з'являється нова вимога («треба інтегрувати оператора X для покриття Єгипту»), перший крок інженера — не вгадувати те, чого він не знає. Це використати ШІ, щоб дослідити незнайому територію за 20 хвилин замість 2 днів.

На практиці: інженер, який ніколи не інтегрував єгипетського MVNO, дає ШІ-асистенту документацію API оператора, отримує структурований опис поверхні інтеграції, ставить уточнювальні запитання про граничні випадки («як тут зазвичай виглядає процес eKYC на цьому ринку?») і до обіду видає односторінкову оцінку зусиль, ризиків і невідомих.

Що змінюється: вузьке місце вже не «чи є в нас інженер, який знає цю галузь?», а «чи може наявний інженер, посилений ШІ, стати достатньо компетентним у цій галузі за кілька годин?». Майже завжди — так.

2. Специфікація (години, а не тижні)

У більшості компаній продуктова специфікація забирає 1–3 тижні: PM пише чернетку, стейкхолдери переглядають, додаються граничні випадки, уточнюються критерії приймання, потім інженерія перераховує обсяг. Коли специфікація нарешті «готова», початкова можливість уже змістилася.

Наш підхід: інженер (або CEO, залежно від фічі) накидає ідею в один рядок. ШІ розгортає її в структурований PRD — потік користувача, граничні випадки, метрики успіху, критерії приймання, відкриті питання. Команда допрацьовує це за 45-хвилинну робочу сесію. Того ж дня специфікація йде в розробку.

Компроміс: специфікації з такого процесу трохи сируваті порівняно з класичними двотижневими, які веде PM. Ми з цим погоджуємося. Стиснення часу до першої реалізації варте додаткової неоднозначності, яка знімається під час розробки, а не до неї.

3. Дизайн (швидкий цикл зворотного зв'язку)

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

Результат: дизайн та інженерія не послідовні, а паралельні. Коли дизайн стає «фінальним», реалізація вже здебільшого дійшла до продакшену.

4. Розробка (код пише ШІ, люди перевіряють кожен діф)

Це найпомітніша ШІ-нативна частина. Ось як сьогодні виглядає інженерний процес в eSimphony:

ШІ генерує близько 90% нового коду (Cursor, Claude, GitHub Copilot, часто в комбінації)
Інженери пишуть архітектурні рішення, межі інтеграцій і хитру бізнес-логіку, яка потребує глибокого знання системи
100% коду проходить людське рев'ю перед злиттям. Кожен діф. Кожен PR. Без винятків.

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

Типовий PR в eSimphony має:

200–800 змінених рядків коду (проти традиційних приблизно 100–200 у командах зразка 2024 року)
1 інженера, який детально його переглядає
Часто згенеровані ШІ юніт-тести з покриттям понад 80% нового коду
Коментарі рев'ювера, зосереджені на архітектурі, а не на синтаксисі

5. Реліз (адаптація за хвилини)

Реліз відбувається поступово: фіче-флаги для ризикованих змін, канаркові розгортання для бекенд-сервісів, телеметрія під наглядом ШІ, яка виявляє аномалії за лічені хвилини після викочування. Коли реліз щось ламає, відкат вимірюється хвилинами, а не годинами.

Про «телеметрію під наглядом ШІ» варто сказати окремо: після деплою ШІ-агент стежить за аномаліями в частоті помилок, затримках, скаргах користувачів і конверсії. Коли аномалія перетинає поріг, черговому інженеру приходить сповіщення з переліком імовірних першопричин. Це стискає час до виявлення з «користувач повідомляє про баг о 9:00» до «алерт спрацював о 09:03».

Цифри

Приблизні показники за останні 12 місяців:

Спринт: 1 тиждень. Нові фічі виходять щотижня; дрібні виправлення — щодня.
5 інженерів повний робочий день над продуктом. Ще один інженер на частковому контракті.
Понад 90% нового коду генерує ШІ (переважно Cursor + Claude).
100% злитого коду пройшло людське рев'ю.
Медіанний час від специфікації до продакшену: 5–10 днів.
Продакшн-інциденти за квартал: 1–2. Нижче за середнє по галузі для нашого масштабу.
Тікети підтримки, ескальовані в інженерію: близько 5 на тиждень. Більшість закривається того ж дня.

Ці цифри не теоретичні. Це реальний темп роботи нашої команди.

Чим це не є

Варто прямо сказати, чого ШІ-нативна розробка в eSimphony не означає.

Це не «vibe coding». Код переглядають рядок за рядком. Архітектурні рішення ухвалюють люди. ШІ прискорює набирання, а не мислення.

Це не «без тестів». Згенеровані ШІ тести мають характерні слабкості (вони ретельніше перевіряють щасливі сценарії, ніж граничні випадки), тож інженери дописують тести на краї вручну. Покриття нового коду стабільно тримається вище за 80%.

Це не «сеньйори більше не потрібні». Навпаки. ШІ різко піднімає цінність зрілого судження, бо сеньйор може перевірити й доопрацювати вивід ШІ в 5–10 разів швидше, ніж написав би це з нуля. Джуніори, які користуються ШІ без рев'ю сеньйора, зазвичай видають код, що компілюється, але структурно крихкий.

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

Що для цього потрібно

Три речі, за спаданням важливості.

1. Жорстке людське рев'ю

Кожен рядок згенерованого ШІ коду проходить перевірку сеньйора перед злиттям. Спокуса пропустити рев'ю для «очевидно правильних» дрібних змін цілком реальна й небезпечна. Ми втримали планку 100% рев'ю.

2. Тісні архітектурні обмежувачі

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

3. Культурне прийняття ШІ як стандарту

Команда явно домовилася, що допомога ШІ є стандартом у кожному робочому процесі. Нових інженерів онбордять саме в цю норму. Заперечення («але я волію писати сам») вислуховують і обговорюють, проте командна норма така: механіку бере на себе ШІ, якщо немає конкретної причини вчинити інакше.

Для чого ми ШІ не використовуємо

Перевірка згенерованого ШІ коду (нам потрібне свіже людське око)
Рішення про те, що будувати (продуктова стратегія — людська)
Прямі ескалації з підтримки клієнтів (складні випадки ведуть люди)
Оцінка роботи й зворотний зв'язок команді (тільки люди)
Рішення про наймання (тільки люди, ШІ допомагає лише з пошуком і первинним відсіюванням)

Патерн такий: ШІ підсилює виконання; рішення лишаються за людьми.

Чому це важливо для продукту

Результат цього процесу видно в продукті. Ми випустили:

Архітектуру безстрокової eSIM (у більшості компаній це проєкт на кілька кварталів)
Moza, ШІ-супутницю в подорожах, п'ятьма мовами
Динамічні тарифи на основі ШІ у трьох регіонах
ШІ-діагностику з автовідновленням
Нативні застосунки для iOS та Android із щотижневими релізами
Мультирегіональний бекенд із аптаймом понад 99,9%
Локалізацію п'ятьма мовами по всій поверхні продукту

Такий список зазвичай потребує 30–50 інженерів і понад 3 роки. Ми зробили це вп'ятьох за 18 місяців.

Кілька слів про наймання

Ми розширюємо команду обережно. Інженери, у яких тут виходить, мають три спільні риси:

Судження важливіше за обсяг. Набирання бере на себе ШІ; нам потрібні інженери, які чудово перевіряють, вирішують і формують.
Комфорт із ШІ як з колегою. Інженери, які ставляться до ШІ як до співробітника (делегують йому, перевіряють його, сперечаються з ним), а не як до магічного оракула чи загрози власній ідентичності.
Небайдужість до користувача. ШІ-нативні процеси достатньо швидкі, щоб наплодити купу коду, який компілюється, але нічого не важить. Найкраще працюють ті інженери, які здатні заземлити кожен PR питанням «чи допоможе це користувачеві».

Якщо це про вас — ми наймаємо. Напишіть через сторінку вакансій або звертайтеся напряму до Trung.

Що виходить далі

Той самий процес, який побудував нинішній продукт, зараз реалізує дорожню карту:

Керування кількома eSIM (травень 2026)
Сімейні тарифи (червень 2026)
Лояльність і винагороди (серпень 2026)
Пряме покриття від операторів по всьому світу (2027)

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

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

Подивіться eSimphony в дії, прочитайте про наше позиціювання або гляньте нашу презентацію з MVNO Nation Americas.

Як команда з 5 людей працює на 10×: ШІ-нативна розробка в eSimphony