Saulius Lazaravičius, Vice President för produkt på Hostinger – Intervjuserie

Saulius Lazaravičius, VP of Product på Hostinger, är en erfaren teknolog- och produktledare vars karriär sträcker sig över mer än två decennier inom mjukvaruutveckling, entreprenörskap, e‑handel och produktutveckling. Han började som mjukvaruingenjör innan han medgrundade ett B2B‑SaaS‑företag, där han hjälpte till att bygga en transporthanteringsplattform från grunden. Senare bildade och ledde han mjukvaruutvecklingsteamet bakom BARBORA, en av de största livsmedels‑e‑handelsplattformarna i Baltikum, innan han gick till NFQ, där han ansvarade för tvärfunktionella tekniska team och kundproduktutveckling. Lazaravičius anslöt sig till Hostinger som Head of Product 2022 och befordrades till VP of Product 2024, vilket utökade hans ansvar från webbhosting och hanterad WordPress till en bred portfölj som omfattar kärninfrastruktur, VPS, domäner, företags‑e‑post, produktdesign, produkttillväxt och framväxande AI‑produkter. Hans senaste arbete inkluderar lanseringen och tillväxten av Hostingers e‑postmarknadsföringstjänst samt introduktionen av hanterade lösningar för öppna AI‑agenter.

Hostinger är ett i Litauen grundat teknikföretag som har utvecklats från en traditionell webbhostingleverantör till en bredare AI‑driven plattform för att bygga, lansera och växa online‑verksamheter. Företaget grundades 2004 och betjänar nu mer än 5 miljoner användare i över 150 länder med ett team på cirka 900 anställda. Dess produktportfölj omfattar webb‑ och molnhosting, hanterad WordPress, virtuella privata servrar (VPS), domäner, företags‑e‑post, e‑handel och AI‑drivna skapandeverktyg. Hostinger har i allt högre grad placerat AI i centrum för sin strategi, bland annat genom Hostinger Horizons, som låter användare skapa och publicera webbplatser och webbapplikationer via konverserande AI, samt integrerade AI‑funktioner för e‑handel, kundsupport och hanterade AI‑agenter.

Du började din karriär som mjukvaruingenjör, byggde senare och ledde utvecklingsteam och ansvarar nu för en bred Hostinger‑produktportfölj som omfattar kärninfrastruktur, VPS, domäner, produkttillväxt och hanterade lösningar för öppna AI‑agenter. Hur har den utvecklingen påverkat ditt sätt att tänka på vad utvecklare egentligen behöver från AI, bortom att bara generera kod?

För mig har den mest intressanta delen av mjukvaruutveckling aldrig handlat om att skriva kod i sig. Det handlar om att hitta rätt lösning på ett tekniskt eller användarproblem, formulera en hypotes, bygga något kring den och sedan se hur folk faktiskt använder och drar nytta av det.

Tidigare gick en stor del av utvecklarens tid åt det repetitiva arbetet kring den processen: att söka efter bibliotek och kodsnuttar, koppla ihop olika delar, felsöka, testa och åtgärda små problem innan man ens kunde utvärdera om lösningen var bra.

AI förändrar den balansen. Mycket av det repetitiva arbetet kan nu hanteras med några få prompts, vilket ger utvecklare mer tid för den kreativa delen: att förstå problemet, utforska olika tillvägagångssätt, fatta produktbeslut och lära sig av verkligt användarbeteende.

Det är där jag ser det största värdet med AI för utvecklare. Det handlar inte bara om att generera kod snabbare. Det handlar om att ta bort mer av det obligatoriska men mindre intressanta arbetet så att utvecklare kan spendera mer tid på att lösa de problem som verkligen betyder något.

AI‑kodverktyg har dramatiskt minskat den tid det tar att gå från en idé till fungerande kod. Anser du att driftsättning och infrastrukturhantering nu blir de större flaskhalsarna i AI‑assisterad mjukvaruutveckling?

Ja, jag tror att de blir nästa stora källa till friktion.

AI har kraftigt komprimerat tiden mellan en idé och användbar kod. Men när koden väl finns måste du fortfarande placera den någonstans, konfigurera den korrekt, koppla tjänster, hantera domäner och säkerhet samt hålla applikationen igång. Om dessa steg fortfarande kräver att man hoppar mellan flera instrumentpaneler, dokumentationssidor, terminaler och verktyg, saktar arbetsflödet ner igen.

Vi kan se att utvecklare vill ha samma hastighet från kod till produktion som de nu får från idé till kod. Mer än 19 000 kunder har redan provat Hostinger Connector, omkring 1 500 använder den dagligen, och de utför ungefär 30 000 till 40 000 åtgärder per dag. Det är en stark signal om att driftsättning och drift flyttas direkt in i AI‑assisterade utvecklingsflöden.

Hostinger uppger att Connector redan bearbetar 30 000 till 40 000 åtgärder per dag över webbplatser och tjänster. Vad ber utvecklare egentligen AI‑agenter att göra i produktion, och har något av dessa användningsmönster överraskat dig?

Utvecklare använder Connector direkt från de verktyg de redan arbetar i, såsom VS Code, Antigravity och Cursor. Den förändringen är viktig eftersom den för in infrastrukturåtgärder i utvecklingsflödet istället för att tvinga utvecklare att hoppa mellan separata instrumentpaneler.

Ett av de tydligaste användningsfallen vi ser är driftsättning. Mer än 14 600 unika webbplatser har redan driftsatts via MCP, och veckovisa driftsättningar ökade med nästan 300 % under den senaste månaden.

Utöver driftsättning använder agenter Connector för att hantera domäner och DNS, webbplatsfiler, serverresurser, brandväggsregler, SSH‑nycklar, e‑handelsuppgifter, e‑postkampanjer och andra Hostinger‑tjänster. I praktiken betyder det att en agent kan gå från att hjälpa till att bygga ett projekt till att faktiskt lägga upp det online och hantera tjänsterna runt det.

Det finns en betydande skillnad mellan att låta en AI‑agent skriva kod och att låta den ändra DNS‑poster, brandväggsregler, SSH‑nycklar eller serverkonfigurationer. Vilka nya skyddsåtgärder blir nödvändiga när agenter får den här nivån av operativ kontroll?

Den avgörande skillnaden är att agenten inte längre bara föreslår vad som ska göras. Den gör faktiska förändringar i ett live‑system, vilket gör säkerhet och kontroll mycket viktigare.

Det innebär att agenter behöver tydliga behörighetsgränser, säker åtkomst och insyn i de åtgärder de utför. Idealiskt sett bör utvecklare dock inte behöva hantera all den komplexiteten själva.

Det är den strategi vi använder med Hostinger Connector och vår agentplattform. Plattformen hanterar infrastruktur‑, åtkomst- och säkerhetslagren kring agenten, så att utvecklare kan fokusera på vad de vill att deras agenter ska göra istället för att konfigurera och underhålla allt under ytan.

“Vibe coding” har gjort mjukvaruutveckling tillgänglig för personer som kanske har begränsad kunskap om infrastruktur eller DevOps. Vad händer när dessa användare börjar driftsätta applikationer via agenter utan att fullt ut förstå systemen under dem?

Jag tror att detta lägger mer ansvar på plattformen, inte på användaren. Om AI gör det möjligt för fler att bygga mjukvara kan vi inte förvänta oss att alla också blir infrastruktur‑experter.

Plattformen måste ta hand om mer av den underliggande komplexiteten, från säkerhet och säkerhetskopior till övervakning, resursgränser och rimliga standardinställningar. Användare bör förstå vad som händer på en hög nivå, men de bör inte behöva djup DevOps‑kunskap för att få en applikation online på ett säkert sätt.

Vi har redan sett ett liknande mönster med AI‑agenter. Med produkter som Managed OpenClaw var utmaningen för många användare inte vad agenten kunde göra, utan allt som krävdes för att köra den pålitligt: hosting, konfiguration, API‑nycklar, säkerhet och underhåll. Att avlägsna den installationsbördan gjorde tekniken mycket mer tillgänglig.

Jag tror att infrastrukturen kommer att fungera på samma sätt i allt större utsträckning. Användare bör kunna fokusera på vad de vill bygga, medan plattformen hanterar mer av den operativa komplexiteten säkert i bakgrunden.

För att en AI‑agent ska kunna driva infrastruktur på ett pålitligt sätt, hur mycket kontext behöver den om den omgivande miljön, såsom beroenden, serverresurser, säkerhetspolicyer, autentiseringsuppgifter och tidigare konfigurationsändringar?

En agent behöver tillräckligt med kontext för att förstå både uppgiften och den omgivande miljön.

En enkel åtgärd som att ändra en DNS‑post, starta om en server eller driftsätta en ny version kan påverka andra delar av systemet. Därför bör agenten ha tillgång till strukturerad information om de resurser den hanterar: vad som är driftsatt, vad som är beroende av det, vilka resurser som är tillgängliga, vilka behörigheter agenten har och vad som har hänt tidigare.

Samtidigt bör mer kontext inte innebära obegränsad åtkomst. Agenten bör endast få den information och de behörigheter som faktiskt behövs för att säkert slutföra uppgiften. Att ge en agent överdriven åtkomst bara för att mer kontext kan göra den smartare är ett felaktigt avvägning.

Var bör mänskligt godkännande förbli obligatoriskt? Finns det kategorier av infrastrukturåtgärder som du anser att AI‑agenter ska kunna utföra autonomt och andra som alltid bör kräva explicit mänsklig auktorisation?

Jag tror att AI‑agenter kan fungera i stor utsträckning på egen hand, så länge systemet är korrekt konfigurerat från början.

Istället för att förlita sig på en enda agent för allt kan olika agenter ha olika ansvarsområden. En kan hantera kodning och driftsättning, en annan kan testa resultatet, en tredje kan övervaka systemet och ge larm, och en fjärde kan eskalera problem när något går fel.

I den uppsättningen behöver människan inte godkänna varje enskild åtgärd. Deras roll är att övervaka hela agentsystemet: definiera reglerna, sätta rätt behörigheter, följa hur agenterna samarbetar och kontinuerligt förbättra konfigurationen över tid.

Så för mig handlar den centrala frågan mindre om vilka enskilda åtgärder som alltid kräver mänskligt godkännande och mer om huruvida hela systemet har utformats med rätt kontroller, ansvarsområden och eskaleringsvägar.

Allt eftersom utvecklingsmiljöer i allt högre grad blir gränssnitt för att driftsätta applikationer, hantera domäner, konfigurera servrar och styra externa tjänster, förväntar du dig att de traditionella gränserna mellan IDE, DevOps‑plattformar och molnhanteringskonsoler försvinner?

Jag förväntar mig att gränserna suddas ut avsevärt, även om jag inte tror att alla specialiserade gränssnitt kommer att försvinna.

Idag hoppar utvecklare ofta mellan en IDE, en hosting‑instrumentpanel, en domänpanel, en terminal och flera externa tjänster bara för att få en applikation i produktion. AI‑agenter kan koppla ihop många av dessa steg och föra in dem i den miljö där utvecklaren redan arbetar.

Det betyder inte att instrumentpaneler eller molnhanteringsverktyg försvinner. De kommer fortfarande vara användbara för djupare konfiguration och översikt. Men för många vardagliga uppgifter kan utvecklare sluta behöva fundera på vilket gränssnitt de måste öppna härnäst.

Upplevelsen blir mer fokuserad på den uppgift du vill slutföra och mindre på vilket verktyg som traditionellt äger den uppgiften.

AI‑agenter kan potentiellt göra infrastrukturförändringar mycket snabbare än människor, men de kan också göra misstag i maskinhastighet. Hur viktiga kommer funktioner som audit‑spår, återställningsmekanismer, behörighetsgränser och kontinuerlig övervakning att bli när agentbaserad utveckling mognar?

Dessa funktioner kommer att bli avgörande när agenter tar på sig mer operativt arbete.

AI kan göra infrastrukturförändringar mycket snabbare än en människa, vilket är användbart när allt går bra. Men samma hastighet kan också göra att ett misstag sprids mycket snabbare. Därför behöver användare veta vad som förändrades, vad agenten fick åtkomst till och hur man återställer om något går fel.

Audit‑spår, behörighetsgränser, övervakning och återställningsmekanismer är det som gör den typen av automatisering pålitlig.

När agenter blir mer kapabla tror jag att kvaliteten på dessa skyddsåtgärder kommer att vara lika viktig som agentens egen intelligens.

Framåt i tiden, tror du att de vinnande AI‑utvecklingsplattformarna kommer att vara de med de bästa kodmodellerna, eller kommer konkurrensfördelen i allt högre grad att komma från att ge agenter säker åtkomst till infrastruktur, verktyg, organisatorisk kontext och produktionssystem?

Kvaliteten på kodmodellen kommer fortfarande att spela roll, men jag tror inte att den ensam räcker.

När modellerna är bra på att generera kod blir den större frågan vad som händer härnäst. Kan agenten driftsätta applikationen? Kan den koppla rätt tjänster, förstå miljön, göra förändringar säkert och verifiera att allt fungerar?

Det är där åtkomst till infrastruktur, verktyg, behörigheter och kontext blir mycket viktigare.

Jag tror att de starkaste AI‑utvecklingsplattformarna kommer att kombinera bra modeller med säker åtkomst till systemen kring koden. Det verkliga värdet ligger inte bara i att hjälpa någon att skriva mjukvara snabbare, utan i att hjälpa dem gå från en idé till en fungerande produkt med färre steg emellan.

Tack för den fantastiska intervjun, läsare som vill lära sig mer om de olika hosting‑lösningarna som erbjuds bör besöka Hostinger.