"Моя робота — перетворювати технічну невизначеність на конкурентну перевагу": інтерв'ю з Євгеном Піотровським, Senior Software Engineer у Throne Labs

За даними глобальних опитувань McKinsey та Deloitte, понад 70% компаній інвестують у впровадження нових технологій раніше, ніж вони стають галузевим стандартом, а близько третини пов’язують раннє впровадження з конкурентною перевагою. У технологічному секторі це особливо помітно: інфраструктурні рішення або

AI-інструменти, запущені раніше за ринок, дозволяють швидше масштабувати продукти і залучати інвестиції.

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

Один із таких фахівців — Євген Піотровський, Senior Software Engineer у Throne Labs. Євген має понад десять років досвіду на перетині інженерії та програмної архітектури: від аерокосмічної галузі до фінтеху, AI-стартапів і міської IoT-інфраструктури. Кар’єру розпочав як інженер-конструктор в авіаційній сфері, після чого перейшов у розробку програмного забезпечення.

У 2017 році Євген Піотровський став співзасновником і CTO IT-компанії YOJJI, де очолював технічну розробку міжнародної платформи грошових переказів Valapay. Згодом працював системним архітектором і техлідом у каліфорнійському AI-стартапі Jellibeans, де створював інфраструктуру для роботи з GPU ще до масового поширення генеративного AI. З 2024 року працює у Throne Labs — компанії, продукт якої увійшов до списку TIME Best Inventions 2025 і розгортається у містах США напередодні чемпіонату світу з футболу 2026 року.

Випускник Національного аерокосмічного університету "Харківський авіаційний інститут" (ХАІ), факультет літакобудування. Переможець NASA Space Apps Challenge (Global Nominee, Дніпро) та національного конкурсу "Авіатор-2015".

Брав участь у створенні технологічних продуктів стартапів, які сукупно залучили понад $40 млн венчурного фінансування. Активно працює з відкритим кодом: серед його проєктів — сервіс моніторингу Peekaping та колекція AI-агентів Claude Code Subagents, що використовуються розробниками для побудови інфраструктури AI-асистованої розробки. Має статус IEEE Senior Member (2025).

Поговорили з Євгеном Піотровським про роботу з інфраструктурою міських сервісів у США, раннє впровадження технологій і створення рішень у проєктах без готових стандартів.

— Зараз ви працюєте над продуктом Throne Labs, який використовуватиметься в міській інфраструктурі США напередодні чемпіонату світу з футболу 2026 року. Що це за технологія, як вона працює і яку роль ви в ній відіграєте?

— Ми створюємо систему для управління так званою "розумною" міською інфраструктурою — зокрема модульними громадськими просторами, які підключені до хмарної платформи. У цих об’єктах встановлено датчики, IoT-пристрої та програмне забезпечення, яке в реальному часі передає дані про використання, технічний стан і потребу в обслуговуванні. Для міст це означає можливість контролювати інфраструктуру віддалено, швидко реагувати на проблеми і планувати роботу сервісних команд на основі даних, а не вручну.

Компанія, в якій я працюю, отримала фінансування і розгортає свої системи у великих містах США. Частина інфраструктури розгортається у містах США напередодні чемпіонату світу 2026 року. Йдеться не про сам турнір як цифровий продукт, а про міське середовище, яке має витримати різке зростання навантаження: великий потік людей, інтенсивне використання громадських просторів, підвищені вимоги до стабільності сервісів.

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

— Ви створювали GPU-інфраструктуру ще до масового інтересу до генеративного AI. Що це означає і чому це було важливо?

— Коли я приєднався до AI-стартапу у сфері fashion, потрібно було запускати моделі для обробки зображень і масштабувати обчислення залежно від навантаження. Задачі приходили нерівномірно: іноді система простоювала, іноді виникали пікові запити. Постійно тримати дорогі GPU-сервери увімкненими було занадто витратно, але й затримки в роботі моделі були неприйнятними для продукту. Тому ми почали будувати інфраструктуру, яка автоматично піднімає ресурси під конкретні задачі й вимикає їх після завершення обчислень.

Готових рішень тоді майже не існувало, тож архітектуру довелося продумувати з нуля.

Ми налаштовували моніторинг, інстанси піднімали автоматично, контролювали витрати. Частину підходів перевіряли експериментально, паралельно пояснюючи бізнесу, чому інвестиції в таку систему виправдані. У підсумку команда отримала можливість масштабувати обчислення без постійних витрат на інфраструктуру.

— Повернімось у 2017 рік. Ви тоді почали використовувати Docker у фінтех-проєкті. Розкажіть, що це за технологія і чому її впровадження тоді було важливим?

— Docker — це інструмент, який пакує програму разом з усім необхідним для її роботи в окремий контейнер. Запускаєш цей контейнер на будь-якому сервері — все працює однаково. Сьогодні це стандарт, але у 2017 році у фінтех-проєктах його майже не використовували.

У нашій команді була типова для того часу проблема: програма працювала по-різному на комп’ютерах розробників і на сервері. Через це кожен реліз супроводжувався довгими перевірками і ручними виправленнями. Новому розробнику потрібно було витратити кілька днів або навіть тиждень, щоб налаштувати середовище. Це уповільнювало розвиток продукту і створювало ризики помилок.

Ми почали тестувати Docker як спосіб зробити середовище однаковим для всіх. Спочатку перевели в контейнери один сервіс, переконалися, що деплой проходить стабільно, і поступово перенесли інші частини системи.

Коли система запрацювала в контейнерах, зміни стали відчутними. Нові розробники могли підняти проєкт за кілька годин. Релізи стали більш передбачуваними та зменшилася кількість помилок, пов’язаних із різницею середовищ. У підсумку команда отримала контроль над інфраструктурою і змогла швидше масштабувати продукт.

— Які у вас професійні плани на найближчі роки?

— У найближчі роки я планую зосередитися на проєктах, пов’язаних з інфраструктурою міських сервісів і IoT-системами. Мені цікаво працювати з продуктами, які взаємодіють із тисячами пристроїв у реальному часі, збирають телеметрію та потребують стабільної хмарної інфраструктури. Такий тип систем вимагає чіткої архітектури, контролю витрат і здатності масштабуватися без втрати надійності.

Окремий напрям — розвиток open-source-проєктів і технічних матеріалів. Я вже маю досвід створення інструментів для моніторингу сервісів і архітектур для AI-асистованої розробки. Планую розширювати цю роботу, зокрема в екосистемі Go та сучасних backend-підходів. Відкриті проєкти дозволяють перевіряти архітектурні рішення на практиці і отримувати зворотний зв’язок від розробників з різних країн. Це також спосіб систематизувати власний досвід і зробити його корисним для інших інженерів.

— Яку пораду ви дали б інженерам, які хочуть працювати з новими технологіями раніше за ринок?

Насамперед варто розвивати системне мислення і розуміння контексту продукту. Якщо ви впроваджуєте Kubernetes, бо це модно, а у вас три сервери — це не інженерія, це хайп. Тому важливо аналізувати архітектуру, навантаження, бізнес-модель і лише після цього пропонувати нові інструменти. Раннє впровадження працює тоді, коли воно дає вимірюваний результат: швидший деплой, менше інцидентів, дешевшу інфраструктуру або більш простий онбординг.

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

І, звичайно ж, потрібно бути готовим відповідати за всю роботу у продакшені. Тільки так команда навчиться довіряти і поступово нові інструменти стануть частиною стандартного процесу розробки.