AI:n avulla kuka vain voi tehdä ohjelmiston. Miksi ammattilaisia silti tarvitaan?

Vielä muutama vuosi sitten toimivan ohjelmiston rakentaminen vaati käytännössä ohjelmistokehittäjän. Nyt AI pystyy tuottamaan muutamassa minuutissa käyttöliittymän, tietokannan ja rajapinnan. Ensimmäinen versio sovelluksesta voi syntyä yhden illan aikana.

Tämä on valtava muutos. Suhteellisen kokematonkin henkilö pystyy rakentamaan toimivan näköisiä verkkosivuja, sovelluksia ja automaatioita. Palveluntarjoajien määrä kasvaa, koska tekninen toteutus näyttää helpolta. Tarjous syntyy nopeasti, demokin syntyy nopeasti, ja näyttää siltä kuin ohjelmisto olisi jo valmis.

Samalla yhdestä kysymyksestä on tullut entistä tärkeämpi. Jos kuka tahansa pystyy tekemään ohjelmiston, mistä tunnistaa ammattilaisen?

Kynnys on madaltunut, ja se on hyvä asia

Tätä kehitystä ei kannata surra. Ohjelmistokehitys demokratisoituu. Monet ongelmat voidaan nyt ratkaista nopeammin ja halvemmalla kuin ennen. Yritys voi kokeilla pientä työkalua ilman vuoden mittaista hanketta. Sisäinen asiantuntija voi rakentaa automaation, joka aiemmin jäi tekemättä, koska se oli “liian pieni ohjelmistoprojektiksi”.

Myös me käytämme AI:ta joka päivä. Se nopeuttaa työtä, jota aiemmin tehtiin käsin. Tämä artikkeli ei siis ole varoitus tekoälyä vastaan. Se on huomio siitä, mitä kyky generoida koodia ei vielä kerro.

Toimivan näköinen ohjelmisto ja tuotannossa kestävä ohjelmisto ovat eri asioita. Ero ei näy ensimmäisessä demossa. Se näkyy siinä, kuka ymmärtää ongelman, mitä tapahtuu, kun kaikki ei menekään oikein, ja kuka vastaa järjestelmästä vuoden kuluttua.

Ensin pitää ymmärtää ongelma

Suurin arvo ei synny siitä, kuinka nopeasti koodi kirjoitetaan. Olennaisempaa on ymmärtää, mitä ongelmaa oikeasti ratkaistaan.

Ammattilainen kysyy ensin, kenen arki helpottuu, mitä tietoa tarvitaan ja mikä saa jäädä ennalleen. Hän ei aloita ruudusta. Hän aloittaa työstä: kuka kirjaa, kuka hyväksyy, missä tieto katkeaa ja mitä tapahtuu, jos kirjaus jää tekemättä.

Hän osaa myös sanoa, milloin uutta ohjelmistoa ei kannata rakentaa lainkaan. Ratkaisu voi olla valmis ohjelmisto, integraatio kahden nykyisen järjestelmän väliin, pieni automaatio tai hyvin rajattu oma työkalu. Joskus järkevin vastaus on, että nykyistä tapaa kannattaa siistiä ennen kuin mitään uutta rakennetaan.

Kun koodin tuottaminen on halpaa, houkutus on rakentaa. Silloin syntyy järjestelmiä, joita kukaan ei pyytänyt ja jotka jäävät elämään, koska ne “jo toimivat”. Hyvä tekijä jarruttaa tässä kohdassa. Hän erottaa sen, mikä on mahdollista, siitä mikä on asiakkaalle järkevää.

Ammattilaisen arvo ei ole siinä, että hän kirjoittaa kaiken itse. Se on siinä, että hän tietää, mitä ei kannata kirjoittaa.

Jonkun pitää ymmärtää, mitä koodi tekee

AI voi kirjoittaa nopeasti suuren määrän toimivaa koodia. Se ei silti takaa, että ratkaisu on hyvä. Generoitu koodi voi nojata huonoihin oletuksiin. Se voi jättää tietoturvan vajavaiseksi, tehdä rakenteesta tarpeettoman monimutkaisen, käsitellä virheet puutteellisesti tai tehdä tietokannasta hitaan.

Koodi voi näyttää valmiilta ja silti kaatua, kun kaksi tapahtumaa osuu päällekkäin. Tai kun käyttäjä tekee jotain, mitä demo ei testannut. Tai kun rajapinta palauttaa datan eri muodossa kuin eilen.

Näitä asioita ei tarvitse osata nimetä teknisillä termeillä. Päättäjän kannalta olennaista on tämä: jos kukaan ei ymmärrä, mitä järjestelmä tekee, kukaan ei myöskään osaa korjata sitä. Ammattilaisen pitää pystyä lukemaan, arvioimaan ja tarvittaessa kyseenalaistamaan AI:n tuottamaa koodia. Muuten yritys ostaa nopeuden, mutta ei ymmärrystä.

Käyttöliittymä ei ole koko ohjelmisto

Web-sovellus ei ole vain se näkymä, jonka käyttäjä näkee. Taustalla ovat tietokannat, rajapinnat, kirjautuminen, käyttöoikeudet, verkot, palvelimet, varmistukset, lokitus, integraatiot ja käyttöönotto. Jos nämä kerrokset jäävät sivulauseeksi, ohjelmisto voi näyttää valmiilta ja olla silti hauras.

Teollisuudessa mukaan tulevat vielä koneet ja linjat. Ohjelmisto voi olla yhteydessä PLC:hen, robottiin, tuotantoverkkoon tai fyysiseen prosessiin. Yhteys voi kulkea OPC UA:n tai kenttäväylän kautta. Silloin virhe ei jää ruudulle. Se voi pysäyttää työn, kirjata väärän määrän tai jättää huollon tekemättä.

Mitä kriittisempi järjestelmä, sitä tärkeämpää on ymmärtää nämä kerrokset. AI auttaa kirjoittamaan osia. Se ei korvaa ymmärrystä siitä, miten osat liittyvät toisiinsa ja mitä tapahtuu, kun yksi niistä pettää.

Pk-yrityksessä tämä näkyy usein käytännön kysymyksinä. Kuka pääsee mihinkin tietoon? Missä data asuu? Mitä tapahtuu, jos yhteys tehtaalta toimistoon katkeaa? Kuka huomaa, jos yöajossa syntyy virhe? Näihin ei vastata sillä, että käyttöliittymä näyttää modernilta.

Demo toimii, kun kaikki menee oikein

Demo näyttää hyvältä, kun verkko toimii, käyttäjä tekee odotetun asian ja data on siistiä. Tuotannossa yhteydet katkeavat. Käyttäjä tekee odottamattomia asioita. Rajapinta palauttaa virheen. Tietokanta on hetken tavoittamattomissa. Integraation data on väärässä muodossa. Fyysinen laite käyttäytyy eri tavalla kuin oletettiin.

Ammattimaisessa toteutuksessa nämä tilanteet mietitään etukäteen. Mitä käyttäjä näkee, kun yhteys katkeaa? Kuka saa tiedon virheestä? Voiko työ jatkua, vai pitääkö se pysäyttää? Palautuuko järjestelmä itsestään, vai tarvitaanko ihmistä?

Tämä ero ei näy myyntidemossa. Se näkyy ensimmäisenä maanantaiaamuna, kun halli on käynnissä ja joku odottaa, että näkymä kertoo totuuden. Silloin ei auta, että illalla koodi syntyi nopeasti. Silloin auttaa se, että joku on miettinyt poikkeuksen ennen kuin se tapahtui.

Demo todistaa, että asia on mahdollinen. Tuotanto paljastaa, onko se kestävää.

Ohjelmiston hinta ei lopu julkaisuun

Ohjelmiston todellinen kustannus ei ole ensimmäinen versio. Koodia pitää pystyä muuttamaan, päivittämään, valvomaan ja korjaamaan myöhemmin. Tarpeet muuttuvat. Laitteet vaihtuvat. Ihmiset vaihtuvat. Tietoturvaa pitää hoitaa myös sen jälkeen, kun käyttöönotto on ohi.

Asiakkaalle tärkeämpää kuin käytetty teknologia on se, että ratkaisu pysyy toimintakykyisenä ja että joku ymmärtää kokonaisuuden. Jos tekijä on kadonnut ja koodi on syntynyt ilman rakennetta, seuraava muutos on kallis. Silloin ei osteta enää ominaisuutta. Ostetaan selvitystä siitä, mitä järjestelmä oikeastaan tekee.

Vastuu ei ole sivuseikka. Joku vastaa käyttöoikeuksista, varmistuksista, lokituksesta ja siitä, että järjestelmä voidaan siirtää eteenpäin. Jos tätä vastuuta ei ole nimetty, se jää käytännössä asiakkaalle, usein huomaamatta.

AI on ammattilaiselle vipuvarsi

Tässä ei ole kyse siitä, että AI pitäisi jättää käyttämättä. Päinvastoin. AI tekee hyvästä kehittäjästä huomattavasti tehokkaamman.

Kokeneen tekijän ei tarvitse käyttää aikaa kaikkeen käsin kirjoittamiseen. Hän voi käyttää enemmän aikaa rakenteeseen, ongelman ymmärtämiseen, testaamiseen ja siihen, että asiakkaalle syntyy oikeasti arvoa. Rutiini lyhenee. Harkinta ei lyhene.

Tämä muuttaa myös tiimin kokoa. Pieni toimija voi nykyään toteuttaa ratkaisuja, joihin aiemmin tarvittiin selvästi suurempi ohjelmistotiimi. Edellytys on sama kuin ennenkin: joku ymmärtää kokonaisuuden, osaa rajata työn ja kantaa vastuun tuotannosta.

Pk-yritykselle tämä voi olla etu. Ei tarvitse ostaa isoa ohjelmistotaloa jokaiseen tarpeeseen. Pitää kuitenkin ostaa osaamista, ei vain nopeaa koodin tuottamista. Ero näkyy siinä, puhutaanko ensin työstä vai heti toteutuksesta.

Mitä tämä tarkoittaa Kare Digitalin työssä

Kare Digital hyödyntää AI:ta aktiivisesti ohjelmistokehityksessä. Se ei ole erillinen tuote eikä myyntilause. Se on tapa tehdä työtä nopeammin, kun suunta on jo selvä.

Ajatus on yhdistää modernit AI-avusteiset kehitystyökalut käytännön ohjelmisto-, automaatio- ja teollisuusosaamiseen. Tavoitteena ei ole rakentaa ohjelmistoa ohjelmiston vuoksi. Tavoitteena on löytää asiakkaan ongelmaan mahdollisimman yksinkertainen ja toimiva ratkaisu.

Joskus se on pieni automaatio. Joskus valmis ohjelmisto. Joskus yrityskohtainen työkalu, joka kytkeytyy nykyisiin järjestelmiin ja tarvittaessa tuotannon laitteisiin. AI nopeuttaa toteutusta. Ammattitaito päättää, mitä kannattaa toteuttaa.

Jos kynnys rakentaa on nyt matala, kynnys rakentaa väärä asia on sekin matala. Siksi kysymys ei ole enää siitä, pystyykö joku tekemään ohjelmiston. Kysymys on siitä, osaako joku vastata sen toiminnasta silloinkin, kun kaikki ei mene oikein.