Сауліус Лазаровічус, віце‑президент з продукту в Hostinger – Серія інтерв’ю

Saulius Lazaravičius, віце‑президент з продукту в Hostinger, є досвідченим технологічним та продуктовим лідером, кар’єра якого простягається понад два десятиліття у сфері розробки програмного забезпечення, підприємництва, електронної комерції та розробки продуктів. Він розпочав як інженер‑програміст, а потім співавтворив B2B SaaS компанію, де допомагав будувати платформу управління транспортом з нуля. Пізніше він створив і очолював команду розробки програмного забезпечення, що стояла за BARBORA — однією з найбільших платформ онлайн‑продажу продуктів у Балтійському регіоні, перед тим як приєднатися до NFQ, де керував міжфункціональними технологічними командами та розробкою продуктів для клієнтів. Лазаровічус приєднався до Hostinger у 2022 році як керівник продукту та у 2024 році був підвищений до віце‑президента з продукту, розширивши свої обов’язки від веб‑хостингу та керованого WordPress до широкого портфоліо, що включає основну інфраструктуру, VPS, домени, ділову електронну пошту, дизайн продукту, його зростання та нові AI‑продукти. Останнім часом він запустив і розвиває сервіс email‑маркетингу Hostinger та впровадив керовані рішення для відкритих AI‑агентів.

Hostinger — технологічна компанія, заснована у Литві, яка еволюціонувала від традиційного провайдера веб‑хостингу до ширшої AI‑орієнтованої платформи для створення, запуску та розвитку онлайн‑бізнесу. Заснована у 2004 році, компанія сьогодні обслуговує понад 5 мільйонів користувачів у більш ніж 150 країнах і має команду приблизно 900 співробітників. Портфоліо продуктів охоплює веб‑ та хмарний хостинг, керований WordPress, віртуальні приватні сервери (VPS), домени, ділову електронну пошту, електронну комерцію та інструменти створення на базі ШІ. Hostinger все більше ставить ШІ у центр своєї стратегії, включаючи Hostinger Horizons, що дозволяє користувачам створювати та публікувати веб‑сайти та веб‑додатки за допомогою розмовного ШІ, а також інтегровані можливості ШІ для електронної комерції, підтримки клієнтів та керованих AI‑агентів.

Ви розпочали кар’єру як інженер‑програміст, потім будували та керували командами розробки, а зараз керуєте широким портфоліо продуктів Hostinger, що охоплює основну інфраструктуру, VPS, домени, зростання продукту та керовані рішення для відкритих AI‑агентів. Як цей шлях вплинув на ваше розуміння того, чого розробникам дійсно потрібно від ШІ, окрім простого генерування коду?

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

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

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

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

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

Так, я вважаю, що вони стають наступним значним джерелом тертя.

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

Ми бачимо, що розробники хочуть таку ж швидкість переходу від коду до продакшну, яку зараз отримують від ідеї до коду. Понад 19 000 клієнтів вже спробували Hostinger Connector, близько 1 500 користуються ним щодня, і вони виконують приблизно 30 000–40 000 дій на день. Це сильний сигнал, що розгортання та операції безпосередньо входять у робочий процес розробки за підтримки ШІ.

Hostinger стверджує, що Connector вже обробляє 30 000–40 000 дій на день у різних веб‑сайтах та сервісах. Що саме розробники просять AI‑агентів робити у продакшн‑середовищі, і чи здивували вас якісь з цих патернів використання?

Розробники використовують Connector безпосередньо з інструментів, у яких вони вже працюють, таких як VS Code, Antigravity та Cursor. Це важливо, бо переносить дії з інфраструктурою у процес розробки, замість того, щоб змушувати розробників переходити між окремими панелями.

Одним із найочевидніших випадків використання, який ми спостерігаємо, є розгортання. Понад 14 600 унікальних веб‑сайтів вже розгорнуті через MCP, а щотижневі розгортання зросли майже на 300 % за останній місяць.

Поза розгортанням агенти використовують Connector для управління доменами та DNS, файлами веб‑сайту, ресурсами серверу, правилами брандмауера, SSH‑ключами, завданнями електронної комерції, email‑кампаніями та іншими сервісами Hostinger. На практиці це означає, що агент може перейти від допомоги у створенні проєкту до його фактичного розміщення онлайн та управління пов’язаними сервісами.

Існує суттєва різниця між дозволом AI‑агенту писати код і дозволом змінювати DNS‑записи, правила брандмауера, SSH‑ключі чи конфігурації серверів. Які нові захисні механізми стають необхідними, коли агентам надається такий рівень операційного контролю?

Ключова різниця полягає в тому, що агент вже не лише пропонує, що робити. Він вносить реальні зміни в живу систему, тому безпека та контроль стають набагато важливішими.

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

Саме так ми підходимо до справи з Hostinger Connector та нашою платформою агентів. Платформа керує інфраструктурою, доступом та рівнями безпеки навколо агента, дозволяючи розробникам зосередитися на тому, що вони хочуть, щоб їхні агенти робили, а не на налаштуванні та підтримці всього під ними.

«Vibe coding» зробив розробку програмного забезпечення доступною для людей, які можуть мати обмежені знання інфраструктури чи DevOps. Що трапляється, коли такі користувачі починають розгортати застосунки за допомогою агентів, не розуміючи повністю системи, що їх підтримує?

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

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

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

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

Щоб AI‑агент міг надійно керувати інфраструктурою, скільки контексту йому потрібно про навколишнє середовище, таке як залежності, ресурси серверу, політики безпеки, облікові дані та попередні зміни конфігурації?

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

Проста дія, як-от зміна DNS‑запису, перезапуск сервера чи розгортання нової версії, може вплинути на інші частини системи. Тому агент повинен мати доступ до структурованої інформації про ресурси, якими він керує: що розгорнуто, від чого це залежить, які ресурси доступні, які дозволи має агент і що сталося раніше.

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

Де людське схвалення має залишатися обов’язковим? Чи існують категорії інфраструктурних дій, які, на вашу думку, AI‑агенти повинні виконувати автономно, а інші — завжди потребувати явного людського дозволу?

Я вважаю, що AI‑агенти можуть працювати в основному самостійно, за умови правильного початкового налаштування системи.

Замість того, щоб один агент робив усе, різні агенти можуть мати різні обов’язки. Один може займатися кодуванням і розгортанням, інший — тестуванням результату, третій — моніторингом системи та підняттям тривог, а ще один — ескалацією проблем, коли щось йде не так.

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

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

Оскільки середовища розробки все більше стають інтерфейсами для розгортання застосунків, управління доменами, конфігурації серверів та контролю зовнішніх сервісів, чи очікуєте ви, що традиційні межі між IDE, платформами DevOps та консолями управління хмарами зникнуть?

Я очікую, що межі значно розмито, хоча не вважаю, що кожен спеціалізований інтерфейс зникне.

Сьогодні розробники часто переходять між IDE, панеллю хостингу, панеллю доменів, терміналом та кількома зовнішніми сервісами, лише щоб вивести один застосунок у продакшн. AI‑агенти можуть з’єднати багато з цих кроків і перенести їх у середовище, у якому розробник вже працює.

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

Досвід стає більше про завдання, яке ви хочете виконати, а не про те, який інструмент традиційно відповідає за це завдання.

AI‑агенти можуть здійснювати зміни в інфраструктурі набагато швидше, ніж люди, але вони також можуть робити помилки зі швидкістю машини. Наскільки важливими стануть можливості, такі як аудиторські журнали, механізми відкату, межі дозволів та безперервний моніторинг, коли розвиток агентних систем зрілості?

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

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

Аудиторські журнали, межі дозволів, моніторинг та механізми відкату — це те, що робить таку автоматизацію довіреною.

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

Заглядаючи в майбутнє, чи вважаєте ви, що переможними платформами для розробки AI будуть ті, що мають найкращі моделі кодування, чи конкурентна перевага все більше буде полягати у наданні агентам безпечного доступу до інфраструктури, інструментів, організаційного контексту та продакшн‑систем?

Якість моделі кодування все ще матиме значення, але я не вважаю, що цього буде достатньо самостійно.

Коли моделі добре генерують код, більш важливе питання — що відбувається далі. Чи може агент розгорнути застосунок? Чи може він підключити потрібні сервіси, зрозуміти середовище, безпечно внести зміни та перевірити, що все працює?

Саме тут доступ до інфраструктури, інструменти, дозволи та контекст стають набагато важливішими.

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

Дякуємо за чудове інтерв’ю, читачі, які бажають дізнатися більше про різноманітні хостингові рішення, які пропонує Hostinger, повинні відвідати Hostinger.