Lovablesta liiketoimintakriittiseksi järjestelmäksi: mitä vibekoodauksen jälkeen?

Lovable on AI-pohjainen sovelluskehitysalusta, jolla verkkosovelluksia ja sivustoja voi rakentaa promptaamalla tekoälylle, mitä haluaa tehdä. Työkalu voi tuottaa käyttöliittymän lisäksi esimerkiksi taustajärjestelmää, tietokannan, kirjautumisen ja integraatioita.

Lovable on yksi tällä hetkellä näkyvimmistä AI-pohjaisista sovelluskehitysalustoista. Sama kehitys näkyy myös esimerkiksi Bolt.new:n, Microsoft Power Appsin, Bubblen ja Retoolin kaltaisissa low-code- ja no-code-ratkaisuissa. Työkalut ja niiden käyttötavat eroavat toisistaan, mutta yhteistä niille on se, että yrityksen omat asiantuntijat voivat rakentaa toimivia sovelluksia huomattavasti aiempaa pienemmällä teknisellä kynnyksellä.

Yrityksen oman prosessin hyvin tunteva ihminen voi esimerkiksi rakentaa ensimmäisen version sisäisestä työkalusta, asiakasportaalista tai uudesta digitaalisesta palvelusta ilman perinteisen ohjelmistoprojektin käynnistämistä. Ideaa voidaan kokeilla nopeasti, käyttäjiltä saada palautetta ja turhia ominaisuuksia karsia ennen suurempia investointeja. Myös lähtökohta mahdolliselle ohjelmistoprojektille paranee, kun ideasta on jo olemassa jotain konkreettista.

Vibekoodauksella voi nykyisin siis päästä yllättävän pitkälle. Jossain vaiheessa ensimmäisestä toimivasta versiosta saattaa kuitenkin tulla järjestelmä, jonka kautta käsitellään oikeita asiakkaita, tilauksia, henkilötietoja, tuotantoa tai muuta liiketoiminnalle tärkeää tietoa. Silloin myös järjestelmälle asetettavat vaatimukset muuttuvat.

Lovablella tehty prototyyppi on hyvä lähtökohta

Kun asiakas tulee meille vibekoodatun sovelluksen kanssa, projektia ei tarvitse aloittaa tyhjältä pöydältä. Ensimmäinen versio sovelluksesta kertoo paljon siitä, mitä ollaan tavoittelemassa.

Käyttäjäpolkuja on ehkä jo kokeiltu, tärkeimmät näkymät ovat hahmottuneet ja käyttäjiltä on voitu saada jopa palautetta. Samalla yrityksen sisällä on kertynyt ymmärrystä siitä, mitkä toiminnot ovat oikeasti tarpeellisia ja missä prosessin suurimmat hyödyt ovat.

Jo tehty työ antaa hyvän pohjan myös seuraaville kehitysvaiheille .Olemassa oleva sovellus toimii konkreettisena pohjana, jonka kautta voidaan keskustella liiketoiminnan tarpeista, teknisistä vaatimuksista ja seuraavista kehitysvaiheista huomattavasti tarkemmin kuin pelkän vaatimuslistan perusteella.

Myös itse koodia voidaan hyödyntää, jos sen rakenne ja tekniset valinnat sopivat tulevaan käyttötarkoitukseen. Joissakin projekteissa suuri osa nykyisestä toteutuksesta voi jatkaa mukana. Toisissa käyttöliittymä voidaan säilyttää, mutta taustajärjestelmä kannattaa uudistaa tietoturvan, ylläpidettävyyden ja jatkokehityksen näkökulmasta.

Seuraava askel selviää tutkimalla sitä, mitä on jo rakennettu ja mitä järjestelmältä seuraavaksi vaaditaan.

Kun järjestelmästä tulee tärkeä, myös tekniset vaatimukset kasvavat

Yrityksen sisäisessä kokeilussa muutama käyttäjä voi hyvin pärjätä sovelluksella, jonka rakenne on syntynyt vähitellen kokeilemalla. Tilanne muuttuu, kun käyttäjiä tulee lisää ja järjestelmän toimivuudesta alkaa riippua päivittäisiä prosesseja.

Sovellukseen kertyy oikeaa dataa. Käyttäjillä on erilaisia rooleja ja käyttöoikeuksia. Tietoa pitää siirtää CRM:n, ERP:n, taloushallinnon, verkkokaupan tai muiden järjestelmien välillä. Järjestelmää kehitetään uusilla ominaisuuksilla ja ensimmäisten kuukausien aikana tehdyt tekniset ratkaisut alkavat vaikuttaa siihen, kuinka helppoa muutosten tekeminen on.

Samalla virheiden merkitys kasvaa. Jos yrityksen sisäinen kokeilu on hetken pois käytöstä, vaikutus voi jäädä pieneksi. Jos saman järjestelmän kautta kulkevat päivän tilaukset, tuotannon työmääräykset tai laskutukseen tarvittavat tiedot, ongelma näkyy nopeasti myös muualla liiketoiminnassa.

Samalla mukaan tulevat tietoturvaan, tietosuojaan ja sääntelyyn liittyvät vastuut. Henkilötietojen käsittely tuo GDPR vaatimukset mukaan, ja toimialasta sekä järjestelmän roolista riippuen huomioitavaksi voivat tulla esimerkiksi NIS2 velvoitteet.

Tekoälyä hyödyntävässä palvelussa pitää puolestaan arvioida, tuoko EU:n AI Act järjestelmälle mitä velvoitteita. Tässä vaiheessa ohjelmistokumppanin tuoma arvo alkaa näkyä erityisesti kokonaisuuden hallinnassa.

Ensin selvitetään, mitä konepellin alla on

AI-työkalu voi tuottaa lyhyessä ajassa suuren määrän toimivaa koodia. Käyttäjälle näkyvä toimivuus kertoo kuitenkin vain osan järjestelmän teknisestä tilanteesta.

Kun sovellusta lähdetään viemään meidän kanssa pidemmälle, käymme läpi esimerkiksi:

• koodin rakenteen ja käytetyt teknologiat
• kirjastot ja ulkopuoliset riippuvuudet
• tietomallin
• kirjautumisen ja käyttöoikeudet
• integraatiot
• virheiden käsittelyn
• lokituksen ja monitoroinnin
• varmuuskopioinnin ja palautumisen

Samalla arvioidaan, kuinka helposti toinen kehittäjä pystyy ymmärtämään kokonaisuuden ja jatkamaan sen kehittämistä myöhemmin.

Tämä korostuu erityisesti yrityksen sisäisessä vibekoodauksessa. Sovelluksen ensimmäinen tekijä tuntee yleensä hyvin sen syntyhistorian, promptit ja ratkaisut, joiden kautta nykyiseen lopputulokseen päädyttiin. Vuoden päästä kehitysvastuussa voi olla joku muu. Silloin selkeä rakenne, dokumentointi ja ymmärrettävät tekniset ratkaisut helpottavat jatkoa huomattavasti.

Teknisessä läpikäynnissä tarkastellaan samalla asioita, joita käyttöliittymästä ei näe. Miten käyttöoikeudet on toteutettu? Tallentuuko lokiin riittävästi tietoa ongelmatilanteiden selvittämiseksi? Missä API-avaimia, salasanoja ja muita arkaluonteisia tunnistetietoja säilytetään? Miten järjestelmä palautetaan, jos jotain menee pieleen?

Tekninen arvio kertoo samalla, miten olemassa olevaa toteutusta kannattaa jatkaa ja miten muutokset kannattaa tehdä ennen kuin järjestelmän ympärille rakennetaan lisää toimintoja.

Arkkitehtuuri ratkaisee, kuinka helposti järjestelmää voidaan kehittää

Ensimmäisessä versiossa tärkeintä on usein saada haluttu toiminto käyttöön. Kun järjestelmän elinkaari pitenee, rakenteen merkitys kasvaa.

Frontendin, backendin, tietokannan ja ulkoisten palveluiden vastuiden pitää olla riittävän selkeitä, jotta järjestelmää voidaan muuttaa hallitusti. Hyvä rakenne auttaa lisäämään uusia ominaisuuksia ilman, että yhden toiminnon muuttaminen alkaa rikkoa asioita muualla.

Samalla pitää huomioida tuleva käyttö. Käyttäjämäärä voi kasvaa, dataa kertyä moninkertaisesti ja järjestelmän ympärille syntyä uusia integraatioita. Kun nämä tarpeet tunnetaan riittävän ajoissa, tekninen perusta voidaan mitoittaa tulevaa käyttöä varten ilman tarpeetonta ylimitoitusta.

Datan, käyttöoikeuksien ja tietosuojan pitää pysyä hallinnassa

Yrityksen omassa sovelluksessa data muuttuu nopeasti yhdeksi tärkeimmistä asioista. Asiakkaiden, tilausten, tuotteiden, tuotannon tai muiden prosessien tietoja pitää pystyä käsittelemään luotettavasti myös silloin, kun järjestelmää muutetaan.

Tietomallin lisäksi pitää miettiä varmuuskopiot, datan migraatiot, lokitiedot ja palautuminen virhetilanteista. Jos järjestelmään tehdään myöhemmin suuri tekninen muutos, tietojen pitää siirtyä mukana hallitusti.
Samalla pitää olla selvillä siitä, missä yrityksen data sijaitsee, kuka sitä hallitsee ja millä ehdoilla se voidaan siirtää toiseen ympäristöön.

Jos sovelluksessa käsitellään henkilötietoja, myös datan elinkaari pitää tuntea. Tietoja ei voi kerätä tai säilyttää varmuuden vuoksi, ja yrityksen pitää pystyä vastaamaan esimerkiksi siihen, miksi tietoa käsitellään, kuinka pitkään sitä säilytetään ja miten se poistetaan tarvittaessa.

Käyttöoikeudet, tietoturva ja tietosuoja kasvavat järjestelmän mukana

Kun sovelluksessa käsitellään asiakkaiden, tilausten, tuotteiden, tuotannon tai muiden prosessien tietoja, datan hallinta muuttuu nopeasti kriittiseksi osaksi kokonaisuutta.

Pitää tietää, missä data sijaitsee, kuka sitä hallitsee ja miten se voidaan tarvittaessa siirtää tai palauttaa. Tietomallin lisäksi pitää huomioida varmuuskopiot, migraatiot ja se, miten tietojen eheys säilyy järjestelmää muutettaessa.

Henkilötietojen käsittely tuo mukaan vielä oman vastuunsa. Yrityksen pitää pystyä vastaamaan ainakin seuraaviin kysymyksiin:

• Mitä henkilötietoja käsitellään ja millä perusteella?
• Kuka pääsee tietoihin käsiksi?
• Missä tiedot sijaitsevat ja kuinka pitkään niitä säilytetään?
• Mitä ulkopuolisia palveluita ja henkilötietojen käsittelijöitä käytetään?
• Miten tiedot voidaan palauttaa, poistaa tai siirtää tarvittaessa?

Myös käyttöoikeuksien pitää vastata todellisia työtehtäviä. Yksi käyttäjä voi saada tarkastella tietoja, toinen muokata niitä ja kolmas hyväksyä esimerkiksi tilauksen tai maksun. API-avaimet ja muut arkaluonteiset tunnistetiedot pitää suojata huolellisesti, jotta ne eivät päädy käyttäjien nähtäville tai lähdekoodiin.

Korkean riskin henkilötietojen käsittely voi edellyttää tietosuojaa koskevaa vaikutustenarviointia. GDPR-vastuita ei kannata jättää myöhemmäksi, sillä vakavimmillaan rikkomuksesta voidaan määrätä jopa 20 miljoonan euron tai neljän prosentin seuraamus yrityksen maailmanlaajuisesta vuotuisesta liikevaihdosta.

Alustan omat tietoturvaominaisuudet ovat tärkeä osa kokonaisuutta, mutta yrityksen vastuu oman sovelluksensa toteutuksesta ja henkilötietojen käsittelystä säilyy.

Integraatioissa pitää suunnitella myös poikkeustilanteet

Liiketoimintaa palveleva järjestelmä toimii harvoin yksin. Asiakastieto voi tulla CRMä, tilaus verkkokaupasta ja laskutustieto siirtyä taloushallintoon. Tuotannossa sama tieto voi jatkaa vielä toiminnanohjaukseen tai muihin järjestelmiin.

Integraatioissa tekninen työ ulottuu itse tiedonsiirtoa pidemmälle. Pitää päättää, mitä tapahtuu, jos toinen järjestelmä ei vastaa, sama tapahtuma tulee kahdesti tai rajapinnasta saadaan puutteellista tietoa.

Hyvin suunnitellussa integraatiossa nämä tilanteet voidaan käsitellä hallitusti. Huonosti hallittu virhe näkyy helposti ihmisille ylimääräisenä selvitystyönä, puuttuvina tietoina tai tarpeena korjata järjestelmien välisiä eroja manuaalisesti.

Ulkopuoliset palvelut ovat samalla osa järjestelmän tietoturvallisuutta. Esimerkiksi NIS2 soveltamisalaan kuuluvilla yrityksillä myös toimitusketjujen ja palveluntarjoajien kyberturvallisuusriskit kuuluvat huomioitaviin asioihin. Siksi integraatioiden kohdalla pitää tietää tiedonsiirron lisäksi myös se, mihin palveluihin liiketoimintakriittinen prosessi käytännössä nojaa.

Testaus ja monitorointi tuovat varmuutta jatkuvaan kehitykseen

Ensimmäisen version valmistuminen aloittaa yleensä uuden vaiheen. Käyttäjiltä tulee palautetta, prosessit muuttuvat ja järjestelmään lisätään uusia ominaisuuksia.

Automaattisilla testeillä voidaan tarkistaa keskeisiä toimintoja aina muutosten yhteydessä. Näin esimerkiksi tilauksen käsittely, laskenta tai muu liiketoiminnan kannalta tärkeä prosessi voidaan varmistaa ennen uuden version viemistä käyttäjille.

Tuotantoympäristössä tarvitaan lisäksi näkyvyys siihen, mitä järjestelmässä tapahtuu. Virhelokit, monitorointi ja hälytykset auttavat tunnistamaan poikkeamia ja selvittämään niiden syitä. Kehitystiimi saa samalla tietoa hitaista toiminnoista, toistuvista virheistä ja teknisistä asioista, joita kannattaa kehittää seuraavaksi.

Lokit ja monitorointi tukevat myös tietoturvaa. Jos jotain poikkeavaa tapahtuu, tapahtumien kulku ja tietoihin pääsy pitää pystyä selvittämään jälkikäteen. Sääntelyn piirissä olevissa järjestelmissä tämä voi olla myös osa yrityksen velvollisuutta osoittaa, miten riskejä ja poikkeamia hallitaan.

Käytetyn alustan ja palveluiden riippuvuudet kannattaa tunnistaa

Vibekoodatun sovelluksen ympärillä on usein useita ulkopuolisia palveluita. Itse kehitysalustan lisäksi käytössä voi olla esimerkiksi tietokanta-, autentikointi-, hosting- ja AI-palveluita.

Niiden käyttäminen on täysin normaali osa modernia ohjelmistokehitystä. Olennaista on tietää, mistä järjestelmä on riippuvainen ja millaisia vaikutuksia palvelun hinnoittelun, ehtojen tai teknisten ominaisuuksien muutoksilla olisi.

Samalla voidaan arvioida, kuka hallitsee lähdekoodia, dataa ja tuotantoympäristöä sekä kuinka helposti järjestelmän kehittämistä voidaan tarvittaessa jatkaa toisen teknisen ratkaisun päällä.

Riippuvuuksilla voi olla myös sääntelyyn liittyviä vaikutuksia. Yrityksen pitää esimerkiksi tietää, missä henkilötietoja käsitellään ja millaisia sopimuksia palveluntarjoajien kanssa tarvitaan. EU Cyber Resilience Act lisää puolestaan ohjelmistotuotteisiin kohdistuvia kyberturvallisuusvaatimuksia, mikä korostaa käytettyjen komponenttien, haavoittuvuuksien ja päivitysten hallintaa.

Hallittu tekninen omistajuus helpottaa pitkäjänteistä kehittämistä ja vähentää tilanteita, joissa yksittäinen työkalu alkaa myöhemmin määrittää liiketoiminnan vaihtoehtoja.

Hyvä kumppani myös haastaa alkuperäistä ajatusta

Ohjelmistokumppanin arvo ei siis synny pelkästään siitä, että joku toteuttaa pyydetyt ominaisuudet. Kun ulkopuolinen tiimi tulee mukaan, se pystyy tarkastelemaan ratkaisua myös kokemuksen kautta. Vastaavanlaisissa järjestelmissä on ehkä nähty jo aikaisemmin, millaiset ratkaisut toimivat, missä syntyy helposti teknistä velkaa ja mitkä ominaisuudet kasvattavat projektin kustannuksia suhteessa niiden tuomaan hyötyyn.

Jos järjestelmään suunnitellaan tekoälyä, tässä vaiheessa voidaan arvioida myös käyttötapauksen riskejä ja mahdollisia AI Actin vaatimuksia. Pelkkä AI-avusteinen koodaus ei tee sovelluksesta AI Actin tarkoittamaa tekoälyjärjestelmää, joten ratkaisevaa on se, miten valmiissa palvelussa tekoälyä käytetään.

Tavoitteena on käyttää kehitykseen käytettävä aika ja raha asioihin, jotka aidosti vievät liiketoimintaa eteenpäin.

Kaikkea Lovablella tehtyä ei tarvitse rakentaa uudelleen

Vibekoodatusta sovelluksesta tuotantokäyttöön siirtymiselle ei ole yhtä kaavaa. Joskus olemassa oleva toteutus tarjoaa hyvän pohjan ja kehitystä voidaan jatkaa suoraan sen päälle. Toisessa projektissa käyttöliittymä ja käyttäjäpolut voidaan säilyttää, samalla kun taustajärjestelmää, tietomallia tai integraatioita vahvistetaan. Joskus prototyypin suurin arvo löytyy siitä, mitä sen avulla on opittu käyttäjistä ja liiketoiminnan tarpeista.

Täysi uudelleenrakennus voi käyttää budjettia tarpeettomasti. Heikosti jatkokehitykseen sopivan rakenteen päälle rakentaminen voi puolestaan kasvattaa myöhempiä kustannuksia. Siksi nykyinen toteutus ja tulevat vaatimukset kannattaa ymmärtää ennen kuin seuraavasta vaiheesta päätetään.

Samalla alkaa yleensä hahmottua myös seuraavan vaiheen investointi. Oman projektin mahdollista kokoluokkaa voi arvioida suuntaa-antavasti ohjelmistokehityksen hintalaskurilla.

Vibekoodaus ja ammattimainen ohjelmistokehitys täydentävät toisiaan

Lovablen kaltaiset työkalut antavat yrityksille mahdollisuuden kokeilla ja rakentaa itse ratkaisuja, joihin vielä muutama vuosi sitten tarvittiin ohjelmistokehittäjä heti ensimmäisestä päivästä lähtien.

Se voi tehdä myös varsinaisesta ohjelmistoprojektista tehokkaamman. Kun yritys on jo kokeillut ideaa käytännössä, ohjelmistokumppanin aikaa ei tarvitse käyttää pelkästään sen selvittämiseen, miltä palvelun pitäisi näyttää tai mitä sillä halutaan tehdä.

Työ voidaan suunnata siihen, missä ulkopuolinen osaaminen tuo tässä vaiheessa eniten arvoa: arkkitehtuuriin, integraatioihin, tietoturvaan, laadunvarmistukseen, ylläpidettävyyteen ja liiketoiminnan kannalta tärkeän kokonaisuuden suunnitteluun.

Siihen kuuluu myös sen varmistaminen, että järjestelmän mukana kasvavat vastuut pysyvät hallinnassa. Kun kokeilusta tulee liiketoimintakriittinen ratkaisu, tietoturvan, tietosuojan, dokumentaation ja sovellettavan sääntelyn pitää kehittyä samaa tahtia.

Meille voi siis tulla esimerkiksi hyvinkin pitkälle rakennetun Lovable-sovelluksen kanssa. Käymme tällöin läpi nykyisen toteutuksen, liiketoiminnan tavoitteet ja tulevat vaatimukset sekä selvitämme, mitä kannattaa hyödyntää ja mitä vahvistaa seuraavaa vaihetta varten.

Vibekoodaus voi siis viedä idean nopeasti pitkälle, mutta silloin kun järjestelmästä tulee osa päivittäistä liiketoimintaa, sen rinnalle tarvitaan myös tekninen jatkuvuus, selkeät vastuut ja osaaminen, joiden varassa ratkaisua voidaan kehittää turvallisesti vuosien ajan.