Q&A: Rakettiwebinaari – ohjelmistosuunnittelu AI-aikakaudella

Kysymys 1:

Kuinka moni koodari käyttää tekoälyä koodaamiseen ja miten paljon?

Ed: Vaihtelee varmaan paljon, mutta koska toisinaan hyöty on merkittävä, niin kyllä se on useimmilla tutuilla kovassa käytössä. Käyttötavoissa on sitten merkittäviä eroja.

Elina: Faktabladet: Raketin kehittäjistä ainakin 72 % on tutustunut AI-avusteiseen kehitykseen ja moni käyttää työkaluja osana kehitystyötä päivittäin. 

Kysymys 2:

Mitkä ovat TOP-3-virheet, joita tehdään, kun AI-työkalut tulevat osaksi devaajan arkea?

Janne: Hyvä kysymys! On vaikeaa sanoa, että toistuuko samat ongelmat eri työympäristöissä, mutta tässä muutamia omaan kokemukseeni perustuvia:

• Tekijä uskoo ymmärtävänsä tärkeät yksityiskohdat GPT-pohjaisesti generoidusta koodista. Esimerkki: generoit konfiguraation johonkin komponettiin, jossa GPT-generoi mukana kommentit jokaisen rivin yläpuolelle -> kommentit eivät vastaakaan sitä, mitä lähdedokumentaatiossa sanotaan tai niistä uupuu jokin oleellinen yksityiskohta.

• Tekijä saa valheellisen ymmärryksen, että hän osaisi hyvin jotain uutta teknologiaa, koska on pystynyt generoimaan ratkaisun, joka toteuttaa halutun lopputuloksen -> tekijä ei ymmärrä, mitä muuta ratkaisu mahdollistaa ja miten sitä kannattaisi käyttää, kun tehdään kehitystyötä pitkäjänteisesti (esim. tietoturva-aukot syntyvät usein myös ymmärtämättömyydestä käytettyjä teknologioita kohtaan).

• Katselmoija uskoo, että (aiemmin kokeneeksi ja huolelliseksi tunnustettu) tekijä olisi jo miettinyt ratkaisut ja niiden pullonkaulat läpi, jolloin katselmoinnissa voidaan edetä pintapuoleisemmalla tarkastelulla. Toisaalta katselmointityö vaikeutuu siinä kohtaa, kun katselmoijan on pakko alkaa epäilemään useampia tehtyjä ratkaisuja ja niiden järkevyyttä.

Ed: Komppaan Jannea, vielä pieni lisäys omasta puolesta: läpinäkyvyyden puute -> ei ymmärretä, minkälaisia virheitä saattaa tulla (failure modes) tai yleensäkään vielä missä LLM:t ovat hyviä ja missä ei. Vastausta "en tiedä" tulee hyvin harvoin, mikä on merkittävä ongelma.

Yleisön kommentti: Tietoturvauhka.

Yleisön kommentti: Luotetaan AI:n tuotoksiin sokeasti. Kaikki generoitu koodi pitää käydä läpi ajatuksella, ja läpikäyjällä pitää olla osaaminen tehdä kriittinen analyysi luodulle koodille ennen sen hyväksymistä.

Kysymys 3:

Mikä teidän näkemyksenne on, hyödyttääkö ai-pohjainen ohjelmistokehitys senioreita vai junioreita enemmän ja millä tavalla?

Ed: Hyvä kysymys; itse näen kielimallien olevan "tehokkuuskerroin", ei vakiolisä; siten kokeneemmat saavat niistä enemmän irti, erityisesti jos on perehtynyt siihen miten ydinjutut toimivat niissä (esim. word2vec, gradient descent, transformers).

Janne: Tähän vielä lisätäkseni: Tämä riippuu paljolti siitä, miten AI-pohjaisia työkaluja käytetään. Jos niitä käytetään sparrailuun ja alkuun pääsemiseen, hyöty voi olla suurta riippumatta kokemustaustasta. Se ei toisaalta ole muuttunut mihinkään, että juniorin polku kohti senioriteettiä tarvitsee opiskelua (lähdetietojen lukemista ja itse tekemistä ilman GPT-generoitua koodia) ja seniorikollegoiden mentorointia (opastusta ajatusprosessien ja työn pureskelun suhteen). Mitä vähemmän ymmärtää työstettävästä aihealueesta etukäteen, sitä hankalampaa on analysoida GPT:n tarjoamien ratkaisujen hyvyyttä.

Yleisön kommentti: Itse seniorina koen että enempi meitä. Pelottaa juniorien tulevaisuus, jos he luottavat sokeasti AI:n tuotoksiin, eivätkä pysähdy missään kohti ajattelemaan itse, niin ei yksinkertaisesti opi. Onkohan meille kasvamassa seuraavaksi sukupolvi "koodareita", jotka eivät oikeasti osaa mitään, jos otetaan LLM pois, ja sekin osaaminen LLM:n kanssa on "sinnepäin".

> Ed: totta -- toisaalta voi olla myös erinomainen tilaisuus teräville, uusille tulokkaille alalla perehtymällä syvästi kielimallien toimintaan, jolloin voi saada merkittävän kilpailuedun moniin kokeneempiinkin, sikäli kun kehitys jatkuu vielä hyvän aikaa samaan tapaan

Muita kommentteja:

Yleisön kommentti: LLM-kehityksessä korostuu erityisen voimakkaasti se, että onnistuminen ei riipu pelkästään koodista. Jotta lopputuloksesta voi edes teoriassa tulla aidosti hyvä, koko tekemisen ketjun on oltava kunnossa. Huolellinen määrittely, linterit, staattinen analyysi, dokumentaatio, yksikkötestit ja end-to-end-testit, kaikki ne perinteisetkin osa-alueet, jotka joskus jäävät vähemmälle huomiolle, ovat LLM-projekteissa käytännössä välttämättömiä. Pitkälti samaa mieltä, mielenkiintoiseksi toi menee sitten, kun kaikki speksejä ja testejä myöten on tuotettu kielimalleilla ;)

Ed: Pitkälti samaa mieltä, mielenkiintoiseksi toi menee sitten, kun kaikki speksejä ja testejä myöten on tuotettu kielimalleilla ;)

Yleisön kommentti: Juuri näin, sen takia joka vaiheessa pitää olla myös mukana manuaaliset tarkastukset

Yleisön kommentti: asiantuntevaa porukkaa, kiitos tästä infosta. Huomaa kyl ku ennen kielimalleja ongelmien ratkaisusta tuli opintojen aikana hyvä tunne ja virheistä oppi heti, nykyään kun jää johonkin jumiin, niin ei tuu enää onnistumisen tunnetta, jos kielimalleilta kysyy apua ja ongelma ratkeaa paljon nopeammin. Pitäis palata varmaan enemmän vanhaan tyyliin tälleen juniorina :-)

Janne: Suosittelen 👍

Ed: Kiitos itsellesi, ja viisaasti ajateltu. Eihän tässä koskaan olla täysin valmiita, jatkuvaa opettelua meilläkin :)

Katso webinaaritallenne >