Saulius Lazaravičius, VP Product bij Hostinger – Interviewserie

Saulius Lazaravičius, VP Product bij Hostinger, is een ervaren technologie‑ en productleider met een carrière die zich over meer dan twee decennia uitstrekt over software‑engineering, ondernemerschap, e‑commerce en productontwikkeling. Hij begon als software‑engineer voordat hij mede‑oprichtte een B2B‑SaaS‑bedrijf, waar hij hielp een platform voor transportbeheer vanaf de grond op te bouwen. Later vormde en leidde hij het software‑ontwikkelingsteam achter BARBORA, een van de grootste boodschappen‑e‑commerceplatformen in de Baltische staten, voordat hij bij NFQ ging, waar hij cross‑functionele technologische teams en klant‑productontwikkeling aanstuurde. Lazaravičius kwam in 2022 bij Hostinger als Head of Product en werd in 2024 gepromoveerd tot VP Product, waardoor zijn verantwoordelijkheden zich uitbreidden van webhosting en beheerd WordPress naar een breed portfolio dat core‑infrastructuur, VPS, domeinen, zakelijke e‑mail, productontwerp, productgroei en opkomende AI‑producten omvat. Zijn recente werk omvat de lancering en groei van Hostinger’s e‑mail‑marketingaanbod en de introductie van beheerde oplossingen voor open‑source AI‑agents.

Hostinger is een in Litouwen opgericht technologiebedrijf dat is uitgegroeid van een traditionele webhostingprovider tot een breder AI‑gedreven platform voor het bouwen, lanceren en laten groeien van online bedrijven. Opgericht in 2004, bedient het bedrijf nu meer dan 5 miljoen gebruikers in meer dan 150 landen en heeft het ongeveer 900 medewerkers. Het productportfolio omvat web‑ en cloudhosting, beheerd WordPress, virtuele private servers (VPS), domeinen, zakelijke e‑mail, e‑commerce en AI‑aangedreven creatietools. Hostinger heeft AI steeds meer in het centrum van haar strategie geplaatst, onder meer met Hostinger Horizons, waarmee gebruikers websites en webapplicaties kunnen creëren en publiceren via conversationele AI, naast geïntegreerde AI‑functionaliteiten voor e‑commerce, klantenondersteuning en beheerde AI‑agents.

U begon uw carrière als software‑engineer, later bouwde en leidde u ontwikkelingsteams, en nu overziet u een breed Hostinger‑productportfolio dat core‑infrastructuur, VPS, domeinen, productgroei en beheerde oplossingen voor open‑source AI‑agents omvat. Hoe heeft die ontwikkeling uw kijk gevormd op wat ontwikkelaars werkelijk nodig hebben van AI, verder dan alleen het genereren van code?

Voor mij is het meest interessante deel van software‑ontwikkeling nooit het schrijven van code zelf geweest. Het gaat om het vinden van de juiste oplossing voor een technisch of gebruikersprobleem, een hypothese vormen, er iets omheen bouwen en vervolgens zien hoe mensen het daadwerkelijk gebruiken en er baat bij hebben.

In het verleden ging een groot deel van de tijd van een ontwikkelaar naar de repetitieve werkzaamheden rond dat proces: zoeken naar bibliotheken en code‑fragmenten, verschillende onderdelen koppelen, debuggen, testen en kleine problemen oplossen voordat je überhaupt kon beoordelen of de oplossing goed was.

AI verandert dat evenwicht. Veel van die repetitieve taken kunnen nu met een paar prompts worden afgehandeld, waardoor ontwikkelaars meer tijd overhouden voor het creatieve deel: het probleem begrijpen, verschillende benaderingen verkennen, productbeslissingen nemen en leren van echt gebruikersgedrag.

Dat is waar ik de grootste waarde van AI voor ontwikkelaars zie. Het gaat niet alleen om sneller code genereren. Het gaat erom meer van het verplichte maar minder interessante werk weg te nemen zodat ontwikkelaars meer tijd kunnen besteden aan het oplossen van de problemen die er echt toe doen.

AI‑codeertools hebben de tijd die nodig is om van een idee naar werkende code te gaan drastisch verkort. Gelooft u dat implementatie en infrastructuurbeheer nu de grotere knelpunten worden in AI‑ondersteunde softwareontwikkeling?

Ja, ik denk dat ze de volgende belangrijke bron van frictie worden.

AI heeft de tijd tussen een idee en bruikbare code enorm verkort. Maar zodra de code bestaat, moet je die ergens plaatsen, correct configureren, services koppelen, domeinen en beveiliging afhandelen en de applicatie draaiende houden. Als die stappen nog steeds vereisen dat je tussen verschillende dashboards, documentatiepagina’s, terminals en tools schakelt, vertraagt de workflow ineens weer.

We zien dat ontwikkelaars dezelfde snelheid van code‑naar‑productie willen krijgen die ze nu ervaren van idee naar code. Meer dan 19 000 klanten hebben al Hostinger Connector geprobeerd, ongeveer 1 500 gebruiken het dagelijks, en ze voeren ongeveer 30 000 tot 40 000 acties per dag uit. Dat is een sterk signaal dat implementatie en operationele taken rechtstreeks in de AI‑ondersteunde ontwikkelworkflow terechtkomen.

Hostinger stelt dat de Connector al 30 000 tot 40 000 acties per dag verwerkt over websites en services. Wat vragen ontwikkelaars AI‑agents eigenlijk om te doen in productie, en hebben bepaalde gebruikspatronen u verrast?

Ontwikkelaars gebruiken Connector rechtstreeks vanuit de tools waarin ze al werken, zoals VS Code, Antigravity en Cursor. Die verschuiving is belangrijk omdat infrastructuuracties in de ontwikkelstroom worden gebracht in plaats van dat ontwikkelaars tussen afzonderlijke dashboards moeten springen.

Een van de duidelijkste use‑cases die we zien, is implementatie. Meer dan 14 600 unieke websites zijn al via MCP geïmplementeerd, en de wekelijkse implementaties groeiden de afgelopen maand met bijna 300 %.

Naast implementatie gebruiken agents Connector om domeinen en DNS te beheren, websitebestanden, serverresources, firewall‑regels, SSH‑sleutels, e‑commerce‑taken, e‑mail‑campagnes en andere Hostinger‑services. In de praktijk betekent dat dat een agent kan doorgroeien van het helpen bouwen van een project naar het daadwerkelijk online zetten en beheren van de bijbehorende services.

Er is een aanzienlijk verschil tussen een AI‑agent toestaan code te schrijven en toestaan DNS‑records, firewall‑regels, SSH‑sleutels of serverconfiguraties te wijzigen. Welke nieuwe waarborgen worden noodzakelijk zodra agents dit niveau van operationele controle krijgen?

Het belangrijkste verschil is dat de agent niet langer alleen suggesties doet. Hij brengt echte wijzigingen aan in een live systeem, waardoor beveiliging en controle veel belangrijker worden.

Dat betekent dat agents duidelijke permissiegrenzen, veilige toegang en inzicht in de uitgevoerde acties nodig hebben. Idealiter hoeven ontwikkelaars die complexiteit niet zelf te beheren.

Dat is de aanpak die we hanteren met Hostinger Connector en ons agentplatform. Het platform regelt de infrastructuur-, toegangs‑ en beveiligingslagen rond de agent, zodat ontwikkelaars zich kunnen concentreren op wat ze hun agents willen laten doen in plaats van alles eronder te moeten configureren en onderhouden.

“Vibe coding” heeft software‑ontwikkeling toegankelijk gemaakt voor mensen die beperkte kennis van infrastructuur of DevOps hebben. Wat gebeurt er wanneer die gebruikers applicaties via agents implementeren zonder volledig te begrijpen hoe de onderliggende systemen werken?

Ik denk dat dit meer verantwoordelijkheid bij het platform legt, niet bij de gebruiker. Als AI het mogelijk maakt dat meer mensen software bouwen, kunnen we niet verwachten dat al die mensen ook infrastructuur‑experts worden.

Het platform moet meer van de onderliggende complexiteit afhandelen, van beveiliging en back‑ups tot monitoring, resource‑limieten en verstandige standaardinstellingen. Gebruikers moeten op een hoog niveau begrijpen wat er gebeurt, maar ze hoeven geen diepgaande DevOps‑kennis te hebben om een applicatie veilig online te krijgen.

We hebben een vergelijkbaar patroon al gezien met AI‑agents. Bij producten zoals Managed OpenClaw lag de uitdaging voor veel gebruikers niet in wat de agent kon doen, maar in alles wat nodig was om hem betrouwbaar te laten draaien: hosting, configuratie, API‑sleutels, beveiliging en onderhoud. Het wegnemen van die setup‑last maakte de technologie veel toegankelijker.

Ik denk dat infrastructuur op dezelfde manier zal evolueren. Gebruikers moeten zich kunnen richten op wat ze willen bouwen, terwijl het platform meer van de operationele complexiteit veilig op de achtergrond afhandelt.

Voor een AI‑agent om infrastructuur betrouwbaar te laten bedienen, hoeveel context heeft hij nodig over de omgeving, zoals afhankelijkheden, serverresources, beveiligingsbeleid, inloggegevens en eerdere configuratiewijzigingen?

Een agent heeft voldoende context nodig om niet alleen de taak, maar ook de omgeving eromheen te begrijpen.

Een eenvoudige handeling zoals het wijzigen van een DNS‑record, het herstarten van een server of het uitrollen van een nieuwe versie kan invloed hebben op andere delen van het systeem. Daarom moet de agent toegang hebben tot gestructureerde informatie over de resources die hij beheert: wat er is uitgerold, waar het van afhankelijk is, welke resources beschikbaar zijn, welke permissies de agent heeft en wat er eerder is gebeurd.

Tegelijkertijd mag meer context niet gelijk staan aan onbeperkte toegang. De agent mag alleen de informatie en rechten ontvangen die hij echt nodig heeft om de taak veilig uit te voeren. Een agent overdreven veel toegang geven alleen omdat meer context hem slimmer zou maken, is de verkeerde afweging.

Waar moet menselijke goedkeuring verplicht blijven? Zijn er categorieën infrastructuuracties waarvan u denkt dat AI‑agents ze autonoom mogen uitvoeren en andere die altijd expliciete menselijke autorisatie vereisen?

Ik geloof dat AI‑agents grotendeels zelfstandig kunnen opereren, zolang het systeem vanaf het begin goed is geconfigureerd.

In plaats van één agent alles te laten doen, kunnen verschillende agents verschillende verantwoordelijkheden krijgen. Eén kan zich bezighouden met coderen en implementeren, een andere kan het resultaat testen, een derde kan het systeem monitoren en alerts genereren, en weer een andere kan escaleren wanneer er iets misgaat.

In zo’n opzet hoeft de mens niet elke individuele actie goed te keuren. Zijn rol is het hele agentsysteem te overzien: de regels definiëren, de juiste permissies instellen, monitoren hoe de agents samenwerken en de opzet in de loop van de tijd verbeteren.

Voor mij draait de kernvraag minder om welke individuele acties altijd menselijke goedkeuring nodig hebben, en meer om of het algehele systeem is ontworpen met de juiste controles, verantwoordelijkheden en escalatieroutes.

Naarmate ontwikkelomgevingen steeds meer interfaces worden voor het implementeren van applicaties, beheren van domeinen, configureren van servers en aansturen van externe services, verwacht u dat de traditionele grenzen tussen IDE, DevOps‑platformen en cloud‑managementconsoles verdwijnen?

Ik verwacht dat de grenzen aanzienlijk zullen vervagen, hoewel ik niet denk dat elke gespecialiseerde interface zal verdwijnen.

Vandaag de dag schakelen ontwikkelaars vaak tussen een IDE, een hosting‑dashboard, een domein‑paneel, een terminal en diverse externe services om één applicatie in productie te krijgen. AI‑agents kunnen veel van die stappen verbinden en ze naar de omgeving brengen waar de ontwikkelaar al werkt.

Dat betekent niet dat dashboards of cloud‑managementtools zullen verdwijnen. Ze blijven nuttig voor diepere configuratie en toezicht. Maar voor veel alledaagse taken hoeven ontwikkelaars misschien niet meer na te denken over welke interface ze vervolgens moeten openen.

De ervaring wordt meer gericht op de taak die je wilt voltooien en minder op welk gereedschap die taak traditioneel bezit.

AI‑agents kunnen infrastructuurwijzigingen veel sneller doorvoeren dan mensen, maar ze kunnen ook fouten maken met machinale snelheid. Hoe belangrijk zullen functies zoals audit‑logs, rollback‑mechanismen, permissiegrenzen en continue monitoring worden naarmate agent‑gedreven ontwikkeling volwassen wordt?

Deze functionaliteiten worden essentieel naarmate agents meer operationele taken oppakken.

AI kan infrastructuurwijzigingen veel sneller doorvoeren dan een mens, wat handig is wanneer alles goed gaat. Maar dezelfde snelheid kan een fout ook veel sneller laten verspreiden. Daarom moeten gebruikers weten wat er veranderd is, welke toegangsrechten de agent had en hoe ze kunnen herstellen als er iets misgaat.

Audit‑logs, permissiegrenzen, monitoring en rollback‑mechanismen zijn wat die automatisering betrouwbaar maakt.

Naarmate agents capabeler worden, denk ik dat de kwaliteit van deze waarborgen net zo belangrijk wordt als de intelligentie van de agent zelf.

Vooruitkijkend, denkt u dat de winnende AI‑ontwikkelplatformen die met de beste code‑modellen zullen zijn, of zal het concurrentievoordeel steeds meer komen van het geven van agents veilige toegang tot infrastructuur, tools, organisatorische context en productiesystemen?

De kwaliteit van het code‑model blijft belangrijk, maar ik denk niet dat dat alleen genoeg zal zijn.

Zodra modellen goed zijn in het genereren van code, wordt de grotere vraag wat er daarna gebeurt. Kan de agent de applicatie implementeren? Kan hij de juiste services koppelen, de omgeving begrijpen, veilig wijzigingen aanbrengen en verifiëren dat alles werkt?

Daarom worden infrastructuurtoegang, tools, permissies en context veel belangrijker.

Ik denk dat de sterkste AI‑ontwikkelplatformen die zullen combineren die goede modellen met veilige toegang tot de systemen rondom de code. De echte waarde ligt niet alleen in iemand sneller software laten schrijven, maar in iemand van een idee naar een werkend product laten gaan met minder tussenstappen.

Dank u voor het geweldige interview; lezers die meer willen weten over de verschillende hosting‑oplossingen die worden aangeboden, kunnen terecht op Hostinger.