Saulius Lazaravičius, wiceprezes ds. produktu w Hostinger – seria wywiadów

Saulius Lazaravičius, wiceprezes ds. produktu w Hostinger, jest doświadczonym liderem technologicznym i produktowym, którego kariera obejmuje ponad dwie dekady w inżynierii oprogramowania, przedsiębiorczości, e‑commerce i rozwoju produktów. Zaczynał jako inżynier oprogramowania, a następnie współzałożył firmę B2B SaaS, gdzie pomógł zbudować platformę zarządzania transportem od podstaw. Później stworzył i prowadził zespół programistów stojący za BARBORA, jedną z największych platform e‑commerce spożywczego w krajach bałtyckich, zanim dołączył do NFQ, gdzie zarządzał zespołami technologicznymi o różnorodnych kompetencjach oraz rozwojem produktów dla klientów. Lazaravičius dołączył do Hostinger jako Head of Product w 2022 roku i w 2024 został awansowany na wiceprezesa ds. produktu, rozszerzając zakres odpowiedzialności z hostingu internetowego i zarządzanego WordPressa na szerokie portfolio obejmujące infrastrukturę podstawową, VPS, domeny, firmowy e‑mail, projektowanie produktów, rozwój produktów oraz nowe produkty AI. Jego ostatnie działania obejmują uruchomienie i rozwój oferty e‑mail marketingu Hostinger oraz wprowadzenie zarządzanych rozwiązań dla otwarto‑źródłowych agentów AI.

Hostinger jest litewską firmą technologiczną, która przekształciła się z tradycyjnego dostawcy hostingu internetowego w szerszą platformę napędzaną AI, służącą do budowania, uruchamiania i rozwijania firm online. Założona w 2004 roku, firma obsługuje ponad 5 million użytkowników w ponad 150 krajach i zatrudnia około 900 pracowników. Jej portfolio produktów obejmuje hosting internetowy i chmurowy, zarządzany WordPress, wirtualne serwery prywatne (VPS), domeny, firmowy e‑mail, e‑commerce oraz narzędzia do tworzenia oparte na AI. Hostinger coraz częściej stawia AI w centrum swojej strategii, w tym Hostinger Horizons, które umożliwia użytkownikom tworzenie i publikowanie stron internetowych oraz aplikacji webowych przy pomocy konwersacyjnej AI, a także zintegrowane możliwości AI dla e‑commerce, wsparcia klienta i zarządzanych agentów AI.

Rozpocząłeś swoją karierę jako inżynier oprogramowania, później budowałeś i prowadziłeś zespoły deweloperskie, a teraz nadzorujesz szerokie portfolio produktów Hostinger obejmujące infrastrukturę podstawową, VPS, domeny, rozwój produktów oraz zarządzane rozwiązania dla otwarto‑źródłowych agentów AI. Jak ta ścieżka wpłynęła na Twoje myślenie o tym, czego deweloperzy naprawdę potrzebują od AI, poza samym generowaniem kodu?

Dla mnie najciekawszą częścią tworzenia oprogramowania nigdy nie było samo pisanie kodu. Chodzi o znalezienie właściwego rozwiązania problemu technicznego lub użytkownika, sformułowanie hipotezy, zbudowanie czegoś wokół niej i obserwowanie, jak ludzie faktycznie korzystają z tego i czerpią z tego korzyści.

W przeszłości duża część czasu dewelopera była poświęcana na powtarzalne czynności związane z tym procesem: poszukiwanie bibliotek i fragmentów kodu, łączenie różnych elementów, debugowanie, testowanie i naprawianie drobnych problemów, zanim jeszcze można było właściwie ocenić, czy rozwiązanie jest dobre.

AI zmienia tę równowagę. Znaczna część tych powtarzalnych zadań może być teraz obsłużona kilkoma poleceniami, pozostawiając deweloperom więcej czasu na część kreatywną: zrozumienie problemu, eksplorację różnych podejść, podejmowanie decyzji produktowych oraz uczenie się na podstawie rzeczywistych zachowań użytkowników.

Właśnie tam dostrzegam największą wartość AI dla deweloperów. Nie chodzi tylko o szybsze generowanie kodu. Chodzi o usunięcie większej części obowiązkowych, lecz mniej interesujących zadań, aby deweloperzy mogli poświęcić więcej czasu na rozwiązywanie naprawdę istotnych problemów.

Narzędzia do kodowania z użyciem AI drastycznie skróciły czas potrzebny na przejście od pomysłu do działającego kodu. Czy uważasz, że wdrażanie i zarządzanie infrastrukturą stają się teraz większymi wąskimi gardłami w rozwoju oprogramowania wspomaganego AI?

Tak, uważam, że stają się kolejnym głównym źródłem tarcia.

AI znacząco skróciło czas między pomysłem a użytecznym kodem. Jednak gdy kod już istnieje, trzeba go gdzieś umieścić, poprawnie skonfigurować, połączyć usługi, zarządzać domenami i bezpieczeństwem oraz utrzymać działanie aplikacji. Jeśli te kroki nadal wymagają przełączania się między wieloma pulpitami, stronami dokumentacji, terminalami i narzędziami, przepływ pracy znów się spowalnia.

Widzimy, że deweloperzy oczekują takiej samej szybkości od kodu do produkcji, jaką obecnie uzyskują od pomysłu do kodu. Ponad 19 000 klientów wypróbowało już Hostinger Connector, około 1 500 korzysta z niego codziennie i wykonuje około 30 000‑40 000 działań dziennie. To silny sygnał, że wdrażanie i operacje wchodzą bezpośrednio w przepływ pracy wspomagany AI.

Hostinger twierdzi, że Connector już przetwarza 30 000‑40 000 działań dziennie w ramach stron internetowych i usług. Co deweloperzy naprawdę proszą agenty AI o wykonanie w środowisku produkcyjnym i czy któreś z tych wzorców użycia Cię zaskoczyły?

Deweloperzy korzystają z Connectora bezpośrednio z narzędzi, w których już pracują, takich jak VS Code, Antigravity i Cursor. Ta zmiana ma znaczenie, ponieważ wprowadza działania infrastrukturalne do przepływu pracy dewelopera, zamiast zmuszać go do przełączania się między oddzielnymi pulpitami.

Jednym z najjaśniejszych przypadków użycia, które obserwujemy, jest wdrażanie. Ponad 14 600 unikalnych stron internetowych zostało już wdrożonych za pośrednictwem MCP, a tygodniowe wdrożenia wzrosły o prawie 300 % w ciągu ostatniego miesiąca.

Poza wdrażaniem, agenci używają Connectora do zarządzania domenami i DNS, plikami witryny, zasobami serwera, regułami zapory, kluczami SSH, zadaniami e‑commerce, kampaniami e‑mail oraz innymi usługami Hostinger. W praktyce oznacza to, że agent może przejść od pomocy przy budowie projektu do faktycznego umieszczenia go w sieci i zarządzania otaczającymi go usługami.

Istnieje istotna różnica między pozwoleniem agentowi AI na pisanie kodu a pozwoleniem mu na zmianę rekordów DNS, reguł zapory, kluczy SSH czy konfiguracji serwera. Jakie nowe zabezpieczenia stają się konieczne, gdy agentom przyznaje się taką kontrolę operacyjną?

Kluczowa różnica polega na tym, że agent nie tylko sugeruje, co zrobić. Wprowadza rzeczywiste zmiany w działającym systemie, więc bezpieczeństwo i kontrola stają się znacznie ważniejsze.

Oznacza to, że agenci potrzebują wyraźnych granic uprawnień, bezpiecznego dostępu i wglądu w wykonywane działania. Jednak w idealnym scenariuszu deweloperzy nie powinni sami zarządzać całą tą złożonością.

Takie podejście przyjmujemy w Hostinger Connector i naszej platformie agentów. Platforma obsługuje warstwy infrastruktury, dostępu i bezpieczeństwa wokół agenta, dzięki czemu deweloperzy mogą skoncentrować się na tym, co chcą, aby ich agenci robili, zamiast konfigurować i utrzymywać wszystko pod spodem.

„Vibe coding” uczyniło rozwój oprogramowania dostępnym dla osób, które mogą mieć ograniczoną wiedzę o infrastrukturze lub DevOps. Co się dzieje, gdy ci użytkownicy zaczynają wdrażać aplikacje przy pomocy agentów, nie rozumiejąc w pełni leżących pod nimi systemów?

Uważam, że przenosi to większą odpowiedzialność na platformę, a nie na użytkownika. Jeśli AI umożliwia większej liczbie osób tworzenie oprogramowania, nie możemy oczekiwać, że wszyscy staną się jednocześnie ekspertami od infrastruktury.

Platforma musi zająć się większą częścią złożoności pod spodem, od bezpieczeństwa i kopii zapasowych po monitorowanie, limity zasobów i rozsądne domyślne ustawienia. Użytkownicy powinni rozumieć, co się dzieje na wysokim poziomie, ale nie powinni potrzebować dogłębnej wiedzy DevOps, aby bezpiecznie uruchomić aplikację w sieci.

Już widzieliśmy podobny wzorzec w przypadku agentów AI. W produktach takich jak Managed OpenClaw wyzwaniem dla wielu użytkowników nie było to, co agent może zrobić, lecz wszystko, co jest potrzebne do jego niezawodnego uruchomienia: hosting, konfiguracja, klucze API, bezpieczeństwo i utrzymanie. Usunięcie tego obciążenia konfiguracyjnego uczyniło technologię znacznie bardziej dostępną.

Uważam, że infrastruktura będzie coraz częściej działać w ten sam sposób. Użytkownicy powinni móc skoncentrować się na tym, co chcą budować, podczas gdy platforma bezpiecznie zajmuje się większą częścią złożoności operacyjnej w tle.

Aby agent AI mógł niezawodnie obsługiwać infrastrukturę, ile kontekstu potrzebuje o otaczającym środowisku, takim jak zależności, zasoby serwera, polityki bezpieczeństwa, poświadczenia i wcześniejsze zmiany konfiguracji?

Agent potrzebuje wystarczającego kontekstu, aby zrozumieć nie tylko zadanie, ale także otaczające je środowisko.

Prosta akcja, taka jak zmiana rekordu DNS, ponowne uruchomienie serwera czy wdrożenie nowej wersji, może wpływać na inne części systemu. Dlatego agent powinien mieć dostęp do ustrukturyzowanych informacji o zasobach, które obsługuje: co jest wdrożone, od czego to zależy, jakie zasoby są dostępne, jakie uprawnienia ma agent oraz co wydarzyło się wcześniej.

Jednocześnie większy kontekst nie powinien oznaczać nieograniczonego dostępu. Agent powinien otrzymać jedynie informacje i uprawnienia niezbędne do bezpiecznego wykonania zadania. Przyznanie agentowi nadmiernego dostępu wyłącznie dlatego, że większy kontekst może go uczynić „inteligentniejszym”, byłoby niewłaściwą wymianą.

Gdzie zatwierdzenie przez człowieka powinno pozostać obowiązkowe? Czy istnieją kategorie działań infrastrukturalnych, które Twoim zdaniem agenci AI powinni móc wykonywać autonomicznie, a inne, które zawsze powinny wymagać wyraźnej autoryzacji człowieka?

Uważam, że agenci AI mogą działać w dużej mierze samodzielnie, pod warunkiem że system jest od samego początku odpowiednio skonfigurowany.

Zamiast polegać na jednym agencie, który robi wszystko, różni agenci mogą mieć różne obowiązki. Jeden może zajmować się kodowaniem i wdrażaniem, drugi testować wynik, trzeci monitorować system i generować alerty, a kolejny eskalować problemy, gdy coś pójdzie nie tak.

W takim układzie człowiek nie musi zatwierdzać każdej pojedynczej akcji. Jego rola polega na nadzorowaniu całego systemu agentów: definiowaniu zasad, ustalaniu właściwych uprawnień, monitorowaniu współpracy agentów i ciągłym udoskonalaniu konfiguracji.

Dlatego dla mnie kluczowe pytanie nie dotyczy tego, które konkretne działania zawsze wymagają zatwierdzenia przez człowieka, lecz tego, czy cały system został zaprojektowany z odpowiednimi kontrolami, odpowiedzialnościami i ścieżkami eskalacji.

W miarę jak środowiska deweloperskie coraz częściej stają się interfejsami do wdrażania aplikacji, zarządzania domenami, konfigurowania serwerów i kontrolowania usług zewnętrznych, czy spodziewasz się, że tradycyjne granice między IDE, platformami DevOps a konsolami zarządzania chmurą znikną?

Spodziewam się, że granice znacznie się zamglą, choć nie sądzę, aby wszystkie wyspecjalizowane interfejsy zniknęły.

Obecnie deweloperzy często przełączają się między IDE, panelem hostingu, panelem domen, terminalem i wieloma usługami zewnętrznymi, aby wprowadzić jedną aplikację do produkcji. Agenci AI mogą połączyć wiele z tych kroków i przenieść je do środowiska, w którym deweloper już pracuje.

To nie oznacza, że panele sterowania czy narzędzia zarządzania chmurą znikną. Nadal będą przydatne do głębszej konfiguracji i nadzoru. Jednak przy wielu codziennych zadaniach deweloperzy mogą już nie musieć myśleć, który interfejs otworzyć jako kolejny.

Doświadczenie staje się bardziej związane z zadaniem, które chcesz wykonać, a mniej z tym, które narzędzie tradycyjnie je obsługuje.

Agenci AI mogą potencjalnie wprowadzać zmiany w infrastrukturze znacznie szybciej niż ludzie, ale mogą też popełniać błędy w tempie maszyny. Jak ważne będą funkcje takie jak ścieżki audytu, mechanizmy wycofywania, granice uprawnień i ciągłe monitorowanie, gdy rozwój oparty na agentach będzie dojrzewał?

Te funkcje staną się niezbędne, gdy agenci przejmą więcej zadań operacyjnych.

AI może wprowadzać zmiany w infrastrukturze znacznie szybciej niż człowiek, co jest przydatne, gdy wszystko przebiega pomyślnie. Jednak ta sama prędkość może sprawić, że błąd rozprzestrzeni się znacznie szybciej. Dlatego użytkownicy muszą wiedzieć, co się zmieniło, do czego agent miał dostęp i jak przywrócić stan, gdy coś pójdzie nie tak.

Ścieżki audytu, granice uprawnień, monitorowanie i mechanizmy wycofywania to elementy, które czynią taką automatyzację godną zaufania.

W miarę jak agenci stają się bardziej zdolni, uważam, że jakość tych zabezpieczeń będzie tak samo ważna, jak inteligencja samego agenta.

Patrząc w przyszłość, czy uważasz, że zwycięskie platformy rozwoju AI będą te z najlepszymi modelami kodowania, czy przewaga konkurencyjna będzie coraz bardziej wynikać z zapewniania agentom bezpiecznego dostępu do infrastruktury, narzędzi, kontekstu organizacyjnego i systemów produkcyjnych?

Jakość modelu kodowania nadal będzie istotna, ale nie sądzę, aby była wystarczająca sama w sobie.

Gdy modele są dobre w generowaniu kodu, większym pytaniem staje się, co następuje dalej. Czy agent może wdrożyć aplikację? Czy potrafi połączyć odpowiednie usługi, zrozumieć środowisko, wprowadzić zmiany w sposób bezpieczny i zweryfikować, że wszystko działa?

To właśnie tam dostęp do infrastruktury, narzędzia, uprawnienia i kontekst stają się znacznie ważniejsze.

Uważam, że najsilniejsze platformy rozwoju AI połączą dobre modele z bezpiecznym dostępem do systemów otaczających kod. Realna wartość nie polega jedynie na pomocy w szybszym pisaniu oprogramowania, ale w przejściu od pomysłu do działającego produktu przy mniejszej liczbie pośrednich kroków.

Dziękujemy za wywiad, czytelnicy, którzy chcą dowiedzieć się więcej o dostępnych rozwiązaniach hostingowych, powinni odwiedzić Hostinger.