Saulius Lazaravičius, Hostingerin tuotejohtaja – Haastattelusarja

Saulius Lazaravičius, Hostingerin tuotejohtaja, on kokenut teknologia‑ ja tuotejohtaja, jonka ura kattaa yli kahden vuosikymmenen ajan ohjelmistokehityksessä, yrittäjyydessä, verkkokaupassa ja tuotekehityksessä. Hän aloitti ohjelmistosuunnittelijana ennen kuin perusti yhdessä B2B‑SaaS‑yrityksen, jossa hän auttoi rakentamaan kuljetusten hallintaalustan alusta alkaen. Myöhemmin hän perusti ja johti BARBORA‑nimisen ohjelmistokehitystiimin, joka on yksi Baltian suurimmista päivittäistavarakaupan verkkokauppa-alustoista, ennen kuin siirtyi NFQ:hun, jossa hän johti poikkitoiminnallisia teknologiatiimejä ja asiakasprojektien tuotekehitystä. Lazaravičius liittyi Hostingeriin tuotepäällikkönä vuonna 2022 ja nousi tuotejohtajaksi vuonna 2024, laajentaen vastuunsa verkkohostingista ja hallinnoidusta WordPressistä laajaan portfolioon, joka kattaa ydininfrastruktuurin, VPS:n, domainit, yrityssähköpostin, tuotesuunnittelun, tuotekasvun ja nousevat AI‑tuotteet. Hänen viimeaikainen työnsä sisältää Hostingerin sähköpostimarkkinointipalvelun lanseeraamisen ja kasvattamisen sekä hallinnoitujen avoimen lähdekoodin AI‑agenttien ratkaisujen esittelyn.

Hostinger on Liettualaisena perustettu teknologiayritys, joka on kehittynyt perinteisestä web‑hosting‑palvelusta laajemmaksi tekoälypohjaiseksi alustaksi, jonka avulla rakennetaan, lanseerataan ja kasvatetaan verkkoliiketoimintoja. Yritys perustettiin vuonna 2004, ja se palvelee nykyään yli 5 miljoonaa käyttäjää yli 150 maassa, ja sen henkilöstöön kuuluu noin 900 työntekijää. Sen tuotevalikoima kattaa web‑ ja pilvihostingin, hallinnoidun WordPressin, virtuaaliset yksityispalvelimet (VPS), domainit, yrityssähköpostin, verkkokaupan ja tekoälypohjaiset luomistyökalut. Hostinger on asettanut tekoälyn yhä enemmän strategiansa keskiöön, mukaan lukien Hostinger Horizons, jonka avulla käyttäjät voivat luoda ja julkaista verkkosivustoja ja -sovelluksia keskustelevan tekoälyn avulla, sekä integroidut tekoälyominaisuudet verkkokauppaan, asiakastukeen ja hallinnoituihin tekoälyagentteihin.

Aloitit urasi ohjelmistosuunnittelijana, rakensit ja johdit myöhemmin kehitystiimejä, ja nyt valvot laajaa Hostingerin tuoteportfoliota, joka kattaa ydininfrastruktuurin, VPS:n, domainit, tuotekasvun ja hallinnoidut ratkaisut avoimen lähdekoodin AI‑agenteille. Miten tämä kehitys on vaikuttanut siihen, miten ajattelet, mitä kehittäjät todella tarvitsevat tekoälyltä pelkän koodin tuottamisen lisäksi?

Minulle ohjelmistokehityksen mielenkiintoisin osa ei ole itse koodin kirjoittaminen. Se on oikean ratkaisun löytäminen tekniseen tai käyttäjäongelmaan, hypoteesin muodostaminen, sen ympärille rakentaminen ja sitten näkeminen, miten ihmiset todella käyttävät ja hyötyvät siitä.

Menneisyydessä suuri osa kehittäjän ajasta kului toistuvaan työhön prosessin ympärillä: kirjastojen ja koodinpätkien etsimiseen, eri osien yhdistämiseen, virheenkorjaukseen, testaamiseen ja pienten ongelmien korjaamiseen ennen kuin ratkaisuun voitiin edes kunnolla arvioida, oliko se hyvä.

Tekoäly muuttaa tätä tasapainoa. Suuri osa toistuvasta työstä voidaan nyt hoitaa muutamalla kehotteella, jolloin kehittäjille jää enemmän aikaa luovaan osaan: ongelman ymmärtämiseen, eri lähestymistapojen tutkimiseen, tuotepäätösten tekemiseen ja todellisesta käyttäjäkäyttäytymisestä oppimiseen.

Tässä näen tekoälyn suurimman arvon kehittäjille. Kyse ei ole vain nopeammasta koodin tuottamisesta. Kyse on pakollisen, mutta vähemmän mielenkiintoisen työn poistamisesta, jotta kehittäjät voivat käyttää enemmän aikaa todellisesti merkittävien ongelmien ratkaisemiseen.

Tekoälypohjaiset koodausvälineet ovat merkittävästi lyhentäneet aikaa, joka kuluu ideasta toimivaan koodiin. Uskotko, että käyttöönotto ja infrastruktuurin hallinta ovat nyt nousemassa suurimmiksi pullonkauloiksi tekoälyavusteisessa ohjelmistokehityksessä?

Kyllä, mielestäni ne ovat nousemassa seuraavaksi merkittäväksi kitkan lähteeksi.

Tekoäly on pakannut idean ja käyttökelpoisen koodin välisen ajan dramaattisesti. Mutta kun koodi on olemassa, se täytyy silti sijoittaa jonnekin, konfiguroida oikein, yhdistää palveluihin, hallita domaineja ja turvallisuutta sekä pitää sovellus käynnissä. Jos nämä vaiheet edellyttävät edelleen siirtymistä useiden hallintapaneelien, dokumentaatiosivujen, terminaalien ja työkalujen välillä, työnkulku hidastuu jälleen.

Voimme nähdä, että kehittäjät haluavat saman nopeuden koodista tuotantoon, kuin he saavat nyt ideasta koodiin. Yli 19 000 asiakasta on jo kokeillut Hostinger Connectoria, noin 1 500 käyttää sitä päivittäin, ja he suorittavat noin 30 000–40 000 toimintoa päivässä. Tämä on vahva merkki siitä, että käyttöönotto ja operaatioiden hallinta siirtyvät suoraan tekoälyavusteiseen kehitysprosessiin.

Hostinger ilmoittaa, että Connector käsittelee jo 30,000 to 40,000 toimintoa päivässä verkkosivustoilla ja palveluissa. Mitä kehittäjät oikeasti pyytävät AI‑agentteja tekemään tuotannossa, ja ovatko jotkut näistä käyttökuvioista yllättäneet sinut?

Kehittäjät käyttävät Connectoria suoraan työkaluistaan, kuten VS Code, Antigravity ja Cursor. Tämä muutos on merkittävä, koska se tuo infrastruktuuritoiminnot kehitysvirtaan sen sijaan, että kehittäjien täytyisi hypätä eri hallintapaneelien välillä.

Yksi selkeimmistä käyttötapauksista, joita näemme, on käyttöönotto. Yli 14 600 ainutlaatuista verkkosivustoa on jo otettu käyttöön MCP:n kautta, ja viikoittaiset käyttöönotot kasvoivat lähes 300 % viime kuukauden aikana.

Lisäksi käyttöönoton jälkeen agentit käyttävät Connectoria hallinnoimaan domaineja ja DNS:ää, verkkosivustojen tiedostoja, palvelinresursseja, palomuurisääntöjä, SSH‑avaimia, verkkokauppatehtäviä, sähköpostikampanjoita ja muita Hostinger‑palveluita. Käytännössä tämä tarkoittaa, että agentti voi siirtyä projektin rakentamisen avustamisesta sen julkaisemiseen verkossa ja palveluiden hallintaan sen ympärillä.

On merkittävä ero sen välillä, että AI‑agentille annetaan mahdollisuus kirjoittaa koodia, ja sen välillä, että se saa muuttaa DNS‑tietueita, palomuurisääntöjä, SSH‑avaimia tai palvelinkonfiguraatioita. Mitä uusia suojatoimia tarvitaan, kun agenteille annetaan tällainen operatiivinen hallintataso?

Tärkein ero on, että agentti ei enää pelkästään ehdota mitä tehdä. Se tekee todellisia muutoksia toimivaan järjestelmään, joten turvallisuus ja hallinta nousevat paljon tärkeämmiksi.

Tämä tarkoittaa, että agenteilla täytyy olla selkeät käyttöoikeusrajat, turvallinen pääsy ja näkyvyys niiden suorittamiin toimiin. Mutta ihannetapauksessa kehittäjien ei pitäisi itse hallita kaikkea tätä monimutkaisuutta.

Tämä on lähestymistapa, jota noudatamme Hostinger Connectorissa ja agenttialustassamme. Alusta hoitaa infrastruktuurin, pääsyn ja turvallisuuskerrokset agentin ympärillä, jotta kehittäjät voivat keskittyä siihen, mitä he haluavat agenttiensa tekevän, sen sijaan että heidän täytyisi konfiguroida ja ylläpitää kaikkea alla olevaa.

“Vibe coding” on tehnyt ohjelmistokehityksestä saavutettavampaa ihmisille, joilla saattaa olla rajallinen tieto infrastruktuurista tai DevOpsista. Mitä tapahtuu, kun nämä käyttäjät alkavat ottaa sovelluksia käyttöön agenttien kautta ilman, että he täysin ymmärtävät niiden alla olevia järjestelmiä?

Uskon, että tämä asettaa enemmän vastuuta alustalle, ei käyttäjälle. Jos tekoäly mahdollistaa yhä useamman ihmisen ohjelmistojen rakentamisen, emme voi odottaa kaikkien myös tulevan infrastruktuuri‑asiantuntijoiksi.

Alustan on huolehdittava enemmän alla olevasta monimutkaisuudesta, kuten turvallisuudesta ja varmuuskopioista, valvonnasta, resurssirajoista ja järkevistä oletusasetuksista. Käyttäjien tulisi ymmärtää, mitä tapahtuu korkealla tasolla, mutta heidän ei tulisi tarvita syvällistä DevOps‑tietämystä pelkästään sovelluksen turvalliseen verkkoon saattamiseksi.

Olemme jo nähneet samanlaisen mallin AI‑agenteissa. Tuotteiden, kuten Managed OpenClaw, kanssa haaste monille käyttäjille ei ollut se, mitä agentti pystyi tekemään, vaan kaikki, mitä sen luotettavaan toimintaan tarvittiin: hosting, konfigurointi, API‑avaimet, turvallisuus ja ylläpito. Tämä asennusrasituksen poistaminen teki teknologiasta paljon saavutettavampaa.

Uskon, että infrastruktuuri toimii yhä enemmän samalla tavalla. Käyttäjien tulisi pystyä keskittymään siihen, mitä he haluavat rakentaa, kun taas alusta hoitaa taustalla operatiivisen monimutkaisuuden turvallisesti.

Jotta AI‑agentti voisi hallita infrastruktuuria luotettavasti, kuinka paljon kontekstia sen tarvitsee ympäröivästä ympäristöstä, kuten riippuvuuksista, palvelinresursseista, turvallisuuspolitiikoista, tunnistetiedoista ja aikaisemmista konfiguraatiomuutoksista?

Agentin täytyy saada riittävästi kontekstia ymmärtääkseen paitsi tehtävän, myös sen ympäröivän ympäristön.

Yksinkertainen toiminto, kuten DNS‑tietueen muuttaminen, palvelimen uudelleenkäynnistys tai uuden version käyttöönotto, voi vaikuttaa järjestelmän muihin osiin. Siksi agentin tulisi saada pääsy rakenteelliseen tietoon hallinnoimista resursseista: mikä on otettu käyttöön, mistä se riippuu, mitä resursseja on saatavilla, mitä käyttöoikeuksia agentilla on ja mitä on tapahtunut aiemmin.

Samaan aikaan enemmän kontekstia ei saa tarkoittaa rajoittamatonta pääsyä. Agentin tulisi saada vain se tieto ja käyttöoikeudet, joita se todella tarvitsee tehtävän turvalliseen suorittamiseen. Antaa agentille liiallista pääsyä pelkästään siksi, että enemmän kontekstia saattaisi tehdä siitä älykkäämmän, olisi väärä kompromissi.

Missä ihmisen hyväksyntä tulisi edelleen olla pakollista? Onko infrastruktuuritoimintoja, joiden luulet AI‑agenttien pystyvän suorittamaan itsenäisesti, ja toisia, jotka aina vaativat eksplisiittistä ihmisen valtuutusta?

Uskon, että AI‑agentit voivat toimia suurelta osin itsenäisesti, kunhan järjestelmä on alusta alkaen asianmukaisesti konfiguroitu.

Sen sijaan, että yksi agentti tekisi kaiken, eri agenteilla voi olla erilaiset vastuut. Yksi voi hoitaa koodauksen ja käyttöönoton, toinen voi testata tuloksen, kolmas voi valvoa järjestelmää ja lähettää hälytyksiä, ja toinen voi eskaloida ongelmia, kun jokin menee pieleen.

Tässä asetelmassa ihmisen ei tarvitse hyväksyä jokaista yksittäistä toimintoa. Hänen roolinsa on valvoa koko agenttijärjestelmää: määritellä säännöt, asettaa oikeat käyttöoikeudet, seurata, miten agentit toimivat yhdessä, ja jatkuvasti parantaa asetelmaa.

Joten minulle keskeinen kysymys on vähemmän se, mitkä yksittäiset toimet aina vaativat ihmisen hyväksynnän, ja enemmän se, onko koko järjestelmä suunniteltu oikeilla tarkistuksilla, vastuilla ja eskalointipoluilla.

Kun kehitysympäristöt yhä enemmän muuttuvat käyttöliittymiksi sovellusten käyttöönottoon, domainien hallintaan, palvelimien konfigurointiin ja ulkoisten palveluiden ohjaukseen, odotatko perinteisten rajojen hälventymistä IDE:n, DevOps‑alustojen ja pilvihallintakonsolien välillä?

Odotan, että rajat hämärtyvät merkittävästi, vaikka en usko, että kaikki erikoistuneet käyttöliittymät katoavat.

Tänä päivänä kehittäjät siirtyvät usein IDE:n, hosting‑hallintapaneelin, domain‑paneelin, terminaalin ja useiden ulkoisten palveluiden välillä vain saadakseen yhden sovelluksen tuotantoon. AI‑agentit voivat yhdistää monia näistä vaiheista ja tuoda ne ympäristöön, jossa kehittäjä jo työskentelee.

Tämä ei tarkoita, että hallintapaneelit tai pilvihallintatyökalut katoaisivat. Ne ovat edelleen hyödyllisiä syvällisempään konfigurointiin ja valvontaan. Mutta monissa jokapäiväisissä tehtävissä kehittäjien ei enää tarvitse miettiä, mitä käyttöliittymää heidän täytyy avata seuraavaksi.

Kokemus keskittyy enemmän haluamaasi tehtävään kuin siihen, mikä työkalu perinteisesti omistaa kyseisen tehtävän.

AI‑agentit voivat mahdollisesti tehdä infrastruktuurimuutoksia paljon nopeammin kuin ihmiset, mutta ne voivat myös tehdä virheitä koneen nopeudella. Kuinka tärkeiksi auditointilokit, palautusmekanismit, käyttöoikeusrajat ja jatkuva valvonta nousevat, kun agenttipohjainen kehitys kehittyy?

Nämä ominaisuudet tulevat oleellisiksi, kun agentit ottavat vastaan yhä enemmän operatiivista työtä.

Tekoäly voi tehdä infrastruktuurimuutoksia paljon nopeammin kuin ihminen, mikä on hyödyllistä, kun kaikki sujuu hyvin. Mutta sama nopeus voi myös levittää virheen paljon nopeammin. Siksi käyttäjien täytyy tietää, mitä on muutettu, mihin agentilla oli pääsy, ja miten palautua, jos jokin menee pieleen.

Auditointilokit, käyttöoikeusrajat, valvonta ja palautusmekanismit tekevät tällaisesta automaatiosta luotettavan.

Kun agentit tulevat kykenevämmiksi, uskon, että näiden suojatoimien laatu on yhtä tärkeä kuin itse agentin älykkyys.

Tulevaisuutta ajatellen, uskotko, että menestyvät AI‑kehitysplatformit ovat niitä, joilla on parhaat koodausmallit, vai että kilpailuetu tulee yhä enemmän siitä, että agenteille annetaan turvallinen pääsy infrastruktuuriin, työkaluihin, organisaatiokontekstiin ja tuotantojärjestelmiin?

Koodausmallin laatu on edelleen tärkeä, mutta en usko, että se riittää yksinään.

Kun mallit ovat hyviä koodin generoinnissa, suurempi kysymys on, mitä tapahtuu seuraavaksi. Voiko agentti ottaa sovelluksen käyttöön? Voiko se yhdistää oikeat palvelut, ymmärtää ympäristön, tehdä muutokset turvallisesti ja varmistaa, että kaikki toimii?

Tässä kohtaa infrastruktuuripääsy, työkalut, käyttöoikeudet ja konteksti nousevat paljon tärkeämmiksi.

Uskon, että vahvimmat AI‑kehitysplatformit yhdistävät hyvät mallit turvalliseen pääsyyn koodin ympärillä oleviin järjestelmiin. Todellinen arvo ei ole pelkästään auttaa jotakuta kirjoittamaan ohjelmistoja nopeammin, vaan auttaa heitä siirtymään ideasta toimivaan tuotteeseen vähemmillä välikäsillä.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää tarjolla olevista hosting‑ratkaisuista, kannattaa vierailla Hostinger-sivustolla.