Interviews

Saulius Lazaravičius, VP for Produkt hos Hostinger – Interviewserie

mm
Føj Unite.AI til dine foretrukne kilder på Google

Saulius Lazaravičius, VP for Produkt hos Hostinger, er en erfaren leder inden for teknologi og produkter, hvis karriere spænder over mere end to årtier inden for softwareudvikling, iværksætteri, e‑handel og produktudvikling. Han startede som softwareingeniør, før han medstiftede en B2B‑SaaS‑virksomhed, hvor han hjalp med at bygge en transportstyringsplatform fra bunden. Senere samlede han og ledede softwareudviklingsteamet bag BARBORA, en af de største dagligvare‑e‑handelsplatforme i Baltikum, før han gik ind i NFQ, hvor han styrede tværfunktionelle teknologiteams og kunders produktudvikling. Lazaravičius kom til Hostinger som Head of Product i 2022 og blev forfremmet til VP for Produkt i 2024, hvilket udvidede hans ansvarsområder fra webhosting og administreret WordPress til en bred portefølje, der omfatter kerneinfrastruktur, VPS, domæner, forretnings‑e‑mail, produktdesign, produktvækst og nye AI‑produkter. Hans seneste arbejde inkluderer lanceringen og væksten af Hostiners e‑mail‑marketingtilbud samt introduktionen af administrerede løsninger for open‑source AI‑agenter.

Hostinger er en litauisk‑grundlagt teknologivirksomhed, der har udviklet sig fra en traditionel webhosting‑udbyder til en bredere AI‑drevet platform for opbygning, lancering og vækst af online‑virksomheder. Virksomheden blev grundlagt i 2004 og betjener i dag mere end 5 millioner brugere i over 150 lande med et team på cirka 900 medarbejdere. Produktporteføljen dækker web‑ og cloud‑hosting, administreret WordPress, virtuelle private servere (VPS), domæner, forretnings‑e‑mail, e‑handel og AI‑drevne skabelsesværktøjer. Hostinger har i stigende grad placeret AI i centrum af sin strategi, herunder Hostinger Horizons, som gør det muligt for brugere at skabe og publicere hjemmesider og webapplikationer via samtale‑AI, samt integrerede AI‑funktioner for e‑handel, kundesupport og administrerede AI‑agenter.

Du startede din karriere som softwareingeniør, byggede senere udviklingsteams og har nu ansvaret for en bred Hostinger‑produktportefølje, der spænder over kerneinfrastruktur, VPS, domæner, produktvækst og administrerede løsninger for open‑source AI‑agenter. Hvordan har den udvikling påvirket din opfattelse af, hvad udviklere faktisk har brug for fra AI ud over blot at generere kode?

For mig har den mest interessante del af softwareudvikling aldrig været selve kodningen. Det er at finde den rigtige løsning på et teknisk eller bruger‑relateret problem, formulere en hypotese, bygge noget omkring den og så se, hvordan folk rent faktisk bruger og drager nytte af det.

Tidligere gik en stor del af udviklerens tid med det gentagne arbejde omkring den proces: at lede efter biblioteker og kode‑snippets, forbinde forskellige komponenter, fejlfinde, teste og rette små problemer, før man overhovedet kunne vurdere, om løsningen var god.

AI ændrer den balance. Meget af det gentagne arbejde kan nu håndteres med nogle få prompts, så udviklere får mere tid til den kreative del: at forstå problemet, udforske forskellige tilgange, træffe produktbeslutninger og lære af reel brugeradfærd.

Det er her, jeg ser den største værdi af AI for udviklere. Det handler ikke kun om at generere kode hurtigere. Det handler om at fjerne mere af det obligatoriske, men mindre interessante arbejde, så udviklere kan bruge mere tid på at løse de problemer, der virkelig betyder noget.

AI‑kodningsværktøjer har dramatisk reduceret den tid, det tager at gå fra en idé til fungerende kode. Tror du, at implementering og infrastruktur‑styring nu bliver de største flaskehalse i AI‑assisteret softwareudvikling?

Ja, jeg tror, de bliver den næste store kilde til friktion.

AI har komprimeret tiden mellem idé og brugbar kode markant. Men når koden først eksisterer, skal du stadig placere den et sted, konfigurere den korrekt, forbinde tjenester, håndtere domæner og sikkerhed samt holde applikationen kørende. Hvis de trin stadig kræver, at man skifter mellem flere dashboards, dokumentationssider, terminaler og værktøjer, så bremser workflowet igen.

Vi kan se, at udviklere ønsker den samme hastighed fra kode til produktion, som de nu får fra idé til kode. Over 19 000 kunder har allerede prøvet Hostinger Connector, omkring 1 500 bruger det dagligt, og de udfører cirka 30 000 til 40 000 handlinger pr. dag. Det er et stærkt signal om, at implementering og drift bevæger sig direkte ind i AI‑assisteret udviklings‑workflow.

Hostinger oplyser, at Connector allerede behandler 30 000 til 40 000 handlinger pr. dag på tværs af hjemmesider og tjenester. Hvad beder udviklere AI‑agenter om at gøre i produktion, og har nogen af disse brugsmønstre overrasket dig?

Udviklere bruger Connector direkte fra de værktøjer, de allerede arbejder i, såsom VS Code, Antigravity og Cursor. Det skift er vigtigt, fordi det bringer infrastruktur‑handlinger ind i udviklingsflowet i stedet for at tvinge udviklere til at hoppe mellem separate dashboards.

Et af de tydeligste brugstilfælde, vi ser, er implementering. Over 14 600 unikke hjemmesider er allerede blevet implementeret via MCP, og de ugentlige implementeringer voksede med næsten 300 % i løbet af den seneste måned.

Udover implementering bruger agenter Connector til at håndtere domæner og DNS, hjemmeside‑filer, serverressourcer, firewall‑regler, SSH‑nøgler, e‑handels‑opgaver, e‑mail‑kampagner og andre Hostinger‑tjenester. I praksis betyder det, at en agent kan gå fra at hjælpe med at bygge et projekt til faktisk at få det online og styre de tilhørende tjenester.

Der er en væsentlig forskel mellem at lade en AI‑agent skrive kode og lade den ændre DNS‑poster, firewall‑regler, SSH‑nøgler eller serverkonfigurationer. Hvilke nye sikkerhedsforanstaltninger bliver nødvendige, når agenter får dette niveau af operationel kontrol?

Den væsentlige forskel er, at agenten ikke længere kun foreslår, hvad der skal gøres. Den foretager reelle ændringer i et live‑system, så sikkerhed og kontrol bliver meget vigtigere.

Det betyder, at agenter har brug for klare tilladelsesgrænser, sikker adgang og synlighed i de handlinger, de udfører. Ideelt set bør udviklere dog ikke selv skulle håndtere al denne kompleksitet.

Det er den tilgang, vi har med Hostinger Connector og vores agentplatform. Platformen håndterer infrastruktur‑, adgangs‑ og sikkerhedslagene omkring agenten, så udviklere kan fokusere på, hvad de vil have deres agenter til at gøre, i stedet for at skulle konfigurere og vedligeholde alt underliggende.

Vibe coding” har gjort softwareudvikling tilgængelig for folk, der måske har begrænset viden om infrastruktur eller DevOps. Hvad sker der, når disse brugere begynder at implementere applikationer gennem agenter uden fuldt at forstå systemerne under dem?

Jeg mener, at dette lægger mere ansvar på platformen end på brugeren. Hvis AI gør det muligt for flere at bygge software, kan vi ikke forvente, at alle også bliver eksperter i infrastruktur.

Platformen skal tage sig af mere af den underliggende kompleksitet, fra sikkerhed og backup til overvågning, ressourcegrænser og fornuftige standardindstillinger. Brugerne bør forstå, hvad der sker på et overordnet niveau, men de skal ikke have brug for dyb DevOps‑viden for blot at få en applikation sikkert online.

Vi har allerede set et lignende mønster med AI‑agenter. Med produkter som Managed OpenClaw var udfordringen for mange brugere ikke, hvad agenten kunne gøre, men alt det, der krævedes for at køre den pålideligt: hosting, konfiguration, API‑nøgler, sikkerhed og vedligeholdelse. At fjerne den opsætningsmæssige byrde gjorde teknologien meget mere tilgængelig.

Jeg tror, at infrastrukturen fremover vil fungere på samme måde. Brugerne skal kunne fokusere på, hvad de vil bygge, mens platformen håndterer mere af den operationelle kompleksitet sikkert i baggrunden.

For at en AI‑agent kan drive infrastruktur pålideligt, hvor meget kontekst har den brug for om det omgivende miljø, såsom afhængigheder, serverressourcer, sikkerhedspolitikker, legitimationsoplysninger og tidligere konfigurationsændringer?

En agent har brug for tilstrækkelig kontekst til både at forstå opgaven og miljøet omkring den.

En simpel handling som at ændre en DNS‑post, genstarte en server eller implementere en ny version kan påvirke andre dele af systemet. Derfor bør agenten have adgang til struktureret information om de ressourcer, den opererer på: hvad der er implementeret, hvad der er afhængigt af det, hvilke ressourcer der er tilgængelige, hvilke tilladelser agenten har, og hvad der er sket tidligere.

Samtidig bør mere kontekst ikke betyde ubegrænset adgang. Agenten bør kun modtage den information og de tilladelser, den reelt har brug for at udføre opgaven sikkert. At give en agent overdreven adgang blot fordi mere kontekst kan gøre den smartere, er den forkerte afvejning.

Hvor bør menneskelig godkendelse forblive obligatorisk? Er der kategorier af infrastruktur‑handlinger, som du mener AI‑agenter bør kunne udføre autonomt, og andre som altid skal kræve eksplicit menneskelig autorisation?

Jeg tror, at AI‑agenter i høj grad kan operere selvstændigt, så længe systemet er korrekt konfigureret fra starten.

I stedet for at lade én agent gøre alting, kan forskellige agenter have forskellige ansvarsområder. En kan håndtere kodning og implementering, en anden kan teste resultatet, en tredje kan overvåge systemet og udsende alarmer, og en fjerde kan eskalere problemer, når noget går galt.

I sådan et setup behøver mennesket ikke godkende hver enkelt handling. Deres rolle er at overse hele agentsystemet: definere regler, sætte de rette tilladelser, overvåge hvordan agenterne samarbejder, og løbende forbedre opsætningen.

Så for mig er nøglespørgsmålet mindre, hvilke individuelle handlinger der altid skal have menneskelig godkendelse, og mere, om det samlede system er designet med de rette kontroller, ansvarsområder og eskaleringsveje.

Efterhånden som udviklingsmiljøer i stigende grad bliver grænseflader for at implementere applikationer, håndtere domæner, konfigurere servere og styre eksterne tjenester, forventer du, at de traditionelle grænser mellem IDE, DevOps‑platforme og cloud‑styringskonsoller forsvinder?

Jeg forventer, at grænserne bliver betydeligt mere flydende, selvom jeg ikke tror, at alle specialiserede grænseflader vil forsvinde.

I dag hopper udviklere ofte mellem en IDE, et hosting‑dashboard, et domæne‑panel, en terminal og flere eksterne tjenester blot for at få en applikation i produktion. AI‑agenter kan forbinde mange af disse trin og bringe dem ind i det miljø, hvor udvikleren allerede arbejder.

Det betyder ikke, at dashboards eller cloud‑styringsværktøjer forsvinder. De vil stadig være nyttige til dybere konfiguration og tilsyn. Men for mange daglige opgaver behøver udviklere måske ikke længere at tænke på, hvilken grænseflade de skal åbne næste gang.

Oplevelsen bliver mere om den opgave, du vil fuldføre, og mindre om hvilket værktøj der traditionelt ejer den opgave.

AI‑agenter kan potentielt foretage infrastrukturændringer langt hurtigere end mennesker, men de kan også begå fejl med maskinhastighed. Hvor vigtig vil funktioner som revisionsspor, rollback‑mekanismer, tilladelsesgrænser og kontinuerlig overvågning blive, efterhånden som agentbaseret udvikling modnes?

Disse funktioner vil blive afgørende, efterhånden som agenter påtager sig mere operationelt arbejde.

AI kan foretage infrastrukturændringer meget hurtigere end en person, hvilket er nyttigt, når alt går som planlagt. Men den samme hastighed kan også få en fejl til at sprede sig meget hurtigere. Derfor har brugerne brug for at vide, hvad der er ændret, hvilke tilladelser agenten havde, og hvordan man kan gendanne, hvis noget går galt.

Revisionsspor, tilladelsesgrænser, overvågning og rollback‑mekanismer er det, der gør sådan automation troværdig.

Efterhånden som agenter bliver mere kapable, tror jeg, at kvaliteten af disse sikkerhedsforanstaltninger vil være lige så vigtig som selve agentens intelligens.

Ser du fremad, tror du så, at de vindende AI‑udviklingsplatforme vil være dem med de bedste kodningsmodeller, eller vil konkurrencemæssige fordele i stigende grad komme fra at give agenter sikker adgang til infrastruktur, værktøjer, organisatorisk kontekst og produktionssystemer?

Kvaliteten af kodningsmodellen vil stadig have betydning, men jeg tror ikke, den alene vil være nok.

Når modellerne er gode til at generere kode, bliver det større spørgsmål, hvad der sker bagefter. Kan agenten implementere applikationen? Kan den forbinde de rette tjenester, forstå miljøet, foretage ændringer sikkert og verificere, at alt fungerer?

Det er her, adgang til infrastruktur, værktøjer, tilladelser og kontekst bliver meget vigtigere.

Jeg tror, at de stærkeste AI‑udviklingsplatforme vil kombinere gode modeller med sikker adgang til systemerne omkring koden. Den reelle værdi er ikke kun at hjælpe nogen med at skrive software hurtigere, men at hjælpe dem med at gå fra idé til et fungerende produkt med færre trin imellem.

Tak for det gode interview. Læsere, der ønsker at lære mere om de forskellige hosting‑løsninger, der tilbydes, bør besøge Hostinger.

Antoine er en visionær leder og medstifter af Unite.AI, drevet af en urokkelig passion for at forme og fremme fremtiden for AI og robotteknologi. En serieiværksætter, han tror, at AI vil være lige så omvæltende for samfundet som elektricitet, og han bliver ofte fanget i at tale om potentialet for omvæltende teknologier og AGI.

Som en futurist, er han dedikeret til at udforske, hvordan disse innovationer vil forme vores verden. Derudover er han grundlægger af Securities.io, en platform, der fokuserer på at investere i skarp teknologi, der gendefinerer fremtiden og omformer hele sektorer.