Recent Post
Miten korjata tekoälyn tuottaman koodin aiheuttamia ohjelmisto-ongelmia?
Pari vuotta sitten keskustelu ohjelmistokehityksessä pyöri sen ympärillä, voiko tekoäly auttaa kirjoittamaan koodia. Nykyään kysymys on usein toinen.
Miksi täysin toimivalta näyttävä koodi aiheuttaa ongelmia vasta myöhemmin?
Monessa yrityksessä tekoälyä käytetään jo päivittäin. Sillä kirjoitetaan testejä, API-kutsuja, tietokantakyselyitä, automaatioita ja kokonaisia sovellusmoduuleja. Kehitys nopeutuu selvästi, eikä sitä voi kiistää.
Samaan aikaan monessa projektissa on huomattu toinen ilmiö. Koodi kyllä toimii, mutta sen käyttäytymistä ei aina ymmärretä kunnolla. Kun järjestelmään tulee muutos, suorituskyky heikkenee tai tuotannossa ilmenee virhe, ongelman selvittäminen vie enemmän aikaa kuin alun perin säästettiin.
Tämä ei johdu siitä, että tekoäly kirjoittaisi aina huonoa koodia. Ongelma syntyy yleensä siitä, että koodi hyväksytään liian nopeasti ilman samanlaista tarkastelua kuin ihmisen kirjoittama toteutus.
Ensimmäinen merkki näkyy usein vasta kuukausien päästä
➠ Tekoälyn tuottama ratkaisu voi näyttää täysin järkevältä koodikatselmoinnissa.
➠ Sovellus käynnistyy.
➠ Testit menevät läpi.
➠ Toiminnallisuus toimii.
➠ Kaikki näyttää olevan kunnossa.
➠ Sitten muutaman kuukauden kuluttua joku yrittää muuttaa samaa moduulia.
➠ Siinä vaiheessa huomataan, ettei kukaan oikein tiedä, miksi ratkaisu on toteutettu juuri sillä tavalla.
➠ Eräässä projektissa kehittäjä yritti päivittää yhtä integraatiota. Muutos vaikutti pieneltä, mutta lopulta korjaus kesti useita päiviä. Syynä ei ollut itse integraatio. Ongelmana oli AI:n aiemmin tuottama koodi, jossa liiketoimintalogiikka oli hajautettu useaan eri paikkaan ilman selvää rakennetta.
➠ Alkuperäinen toiminnallisuus kyllä toimi.
➠ Ylläpito oli paljon vaikeampaa.
Toimiva koodi ei aina tarkoita hyvää ratkaisua
Tämä on ehkä yleisin väärinkäsitys.
Jos tekoälyn tuottama koodi suorittaa tehtävänsä, sitä pidetään helposti onnistuneena.
Todellisuudessa ohjelmistokehityksessä arvioidaan paljon muutakin.
Voiko ratkaisua ylläpitää vuoden päästä?
Onko virhetilanteet käsitelty järkevästi?
Ymmärtääkö uusi kehittäjä toteutuksen nopeasti?
Voiko samaa rakennetta käyttää muualla järjestelmässä?
AI osaa usein ratkaista ongelman.
Se ei kuitenkaan aina tunne kyseisen yrityksen arkkitehtuuria, kehityskäytäntöjä tai pitkän aikavälin tavoitteita.
Tästä syntyy tilanne, jossa teknisesti oikea ratkaisu ei välttämättä ole projektin kannalta paras ratkaisu.
Yllättävän moni ongelma liittyy kopioituun logiikkaan
Kun kehittäjä pyytää tekoälyä rakentamaan uuden ominaisuuden, vastaus perustuu usein samankaltaisiin ratkaisuihin, joita mallille on opetettu.
Se näkyy joskus siten, että samaa logiikkaa syntyy useisiin paikkoihin.
Aluksi tätä ei huomata.
Kun liiketoimintasääntö muuttuu myöhemmin, sama korjaus joudutaan tekemään useaan eri tiedostoon.
Ongelma ei siis ole itse tekoäly.
Ongelma on siinä, ettei kukaan pysähtynyt miettimään, pitäisikö logiikka keskittää yhteen paikkaan.
Moni ylläpitokustannus syntyy juuri tällaisista pienistä päätöksistä.
Turvallisuus jää helposti taustalle
➠ Tekoälyn tuottama koodi näyttää usein vakuuttavalta.
➠ Siksi siihen luotetaan joskus liikaa.
➠ Käytännössä turvallisuuteen liittyvät ongelmat löytyvät usein vasta myöhemmin.
➠ SQL-kysely voi toimia täydellisesti normaalitilanteessa, mutta käsitellä syötteitä väärin.
➠ API voi palauttaa oikeat vastaukset, mutta unohtaa käyttöoikeustarkistuksen.
➠ Lokit voivat sisältää tietoja, joita sinne ei pitäisi tallentaa.
➠ Nämä eivät yleensä näy käyttöliittymässä.
➠ Ne löytyvät vasta tarkemmassa katselmoinnissa tai tuotannossa tapahtuneen ongelman jälkeen.
➠ Siksi tekoälyn tuottamaa koodia kannattaa käsitellä samalla tavalla kuin mitä tahansa muuta koodia.
➠ Ei parempana.
➠ Ei huonompana.
➠ Vaan tarkastettavana ohjelmistona.
Suurin virhe on yrittää korjata kaikkea kerralla
Kun AI:n tuottamasta koodista löytyy ongelmia, ensimmäinen reaktio on usein tehdä täydellinen uudelleenkirjoitus.
Se kuulostaa houkuttelevalta.
Harvoin se kuitenkaan on paras ratkaisu.
Useimmissa tapauksissa kannattaa ensin tunnistaa, mikä osa aiheuttaa ongelman.
Onko kyse suorituskyvystä?
Ylläpidettävyydestä?
Turvallisuudesta?
Virheellisestä liiketoimintalogiikasta?
Kun todellinen ongelma löytyy, korjaus voidaan rajata paljon pienemmäksi.
Moni tiimi säästää huomattavasti aikaa sillä, että ongelma ratkaistaan vaiheittain eikä koko moduulia rakenneta uudelleen.
Dokumentaatio muuttuu tärkeämmäksi kuin ennen
Yksi asia on noussut esiin lähes kaikissa tekoälyä hyödyntävissä kehitystiimeissä.
Dokumentoinnin merkitys kasvaa.
Aikaisemmin kehittäjä usein muisti, miksi jokin ratkaisu oli tehty.
Nyt osa koodista voi syntyä muutamassa minuutissa usean eri keskustelun perusteella.
Muutaman kuukauden päästä alkuperäisiä perusteluja ei välttämättä enää muisteta.
Silloin dokumentaatio ei ole hallinnollinen tehtävä.
Se on käytännöllinen tapa estää tulevia ongelmia.
Koodikatselmoinnin rooli on muuttunut
➠ Ennen katselmoinnissa etsittiin lähinnä ohjelmointivirheitä.
➠ Nykyään tarkastellaan myös sitä, onko ratkaisu järkevä pitkällä aikavälillä.
➠ Tekoälyn kirjoittama koodi voi näyttää siistiltä ja noudattaa syntaksia täydellisesti.
➠ Silti se voi rikkoa projektin omia käytäntöjä.
➠ Tai käyttää rakennetta, jota muu järjestelmä ei käytä.
➠ Tai ratkaista ongelman tavalla, joka vaikeuttaa seuraavaa kehitysvaihetta.
➠ Siksi hyvä katselmointi ei keskity pelkkään koodiin.
➠ Se arvioi myös ratkaisun sopivuutta ympäröivään järjestelmään.
Tuotanto kertoo lopulta totuuden
Kehitysympäristössä lähes kaikki toimii.
Todelliset ongelmat löytyvät yleensä vasta silloin, kun käyttäjiä on paljon, dataa kertyy enemmän ja järjestelmä on jatkuvassa käytössä.
Tämä näkyy erityisesti AI:n tuottamassa koodissa.
Ratkaisu voi näyttää nopealta pienellä datamäärällä, mutta käyttäytyä täysin eri tavalla tuotannossa.
Siksi suorituskyvyn seuranta, lokit, mittarit ja käytännön havainnointi ovat edelleen yhtä tärkeitä kuin ennenkin.
Tekoäly ei poista tarvetta ymmärtää järjestelmää.
Se vain nopeuttaa koodin syntymistä.
Lopuksi
Tekoälyn tuottaman koodin suurin ongelma ei yleensä ole virheellinen syntaksi tai rikkoutuva sovellus. Nämä ongelmat löytyvät usein nopeasti.
Vaikeammat tilanteet liittyvät siihen, että ratkaisu näyttää oikealta, mutta sen pitkäaikaisia vaikutuksia ei arvioida kunnolla.
Siksi AI:n tuottaman koodin korjaaminen alkaa harvoin itse koodista.
Useimmiten kannattaa ensin selvittää, miksi ratkaisu tehtiin, miten se sopii järjestelmän kokonaisuuteen ja missä kohtaa todellinen ongelma syntyy.
Kun tämä ymmärretään, korjaaminen muuttuu huomattavasti suoraviivaisemmaksi. Ja usein huomataan, että ongelma ei ollutkaan tekoälyssä, vaan tavassa, jolla sen tuottamaa koodia otettiin käyttöön.