Tällä hetkellä Anthropicin, OpenAI:n ja Googlen LLM:t tuottavat sinänsä varsin luotettavaa koodia. Bugeja tulee jonkin verran etenkin uusia ominaisuuksia lisätessä, kun LLM:llä ei yleensä ole aukotonta käsitystä koko projektista, mutta väittäisin, että jälki on parempaa kuin suurimmalla osalla ammattikoodareista.
Keskustelusta saa sen käsityksen, että tekoälyä käytetään vain koodin kirjoittamiseen, vaikka ohjelmistokehitys on nimenomaan kehittämistä. Kysynpä vaan paljonko uusien ominaisuuksien kehityksessä menee aikaa testailuun ja viankorjauksiin verrattuna käytössä olevan ohjelmiston viankorjauksiin? Muuttaako tekoäly niiden suhdetta?
No en ole itse huomannut tässä tasapainossa erityistä eroa verrattuna perinteiseen kehitykseen. Niissä projekteissa, joissa olen itse ollut mukana viimeisten 10 vuoden aikana, ohjelmistoja ei ole koskaan onnistuttu määrittelemään kerralla valmiiksi puhumattakaan virheettömästä toteutuksesta. Niihin on jouduttu tekemään melko isojakin muutoksia, kun tuotantokäytössä on havaittu puutteita tai ongelmia. Tekoäly nopeuttaa merkittävästi ongelmien syiden etsintää ja niiden ratkaisua riippumatta siitä, missä vaiheessa korjaaminen on tarpeen.
Miten ohjelmiston on ”tarkoitus toimia” määritellään viime kädessä kirjoittamalla testitapauksia ja tietysti lähdekoodia, mutta funtsauksestakin täytyy jäädä joku jälki jonnekin; ohjelmistosta ja sen ominaisuuksista täytyy voida viestiä, sopia ja tehdä päätöksiä ihan ihmisten kesken.
Onko tekoälyllä mitään roolia siinä, miten inhimilliset funtsaukset kirjataan ja miten niitä tulkitaan koodauksessa?
Kielimallit ymmärtävät erittäin hyvin luonnollisella kiellä tehtyjä määritelmiä ja pystyvät kommunikoimaan suoraan sillä tasolla. Käytännössä määrittely kannattaa kirjoittaa tekstimuodossa tai hieman rikkaammassa Markdown-formaatissa, jota LLM:t voivat lukea ja editoida suoraan ilman lisätyökaluja. Tämä onkin olennainen vaihe, kun kielimalleja käytetään vähänkään isompien kokonaisuuksien kehittämiseen.
Käytännössä työ on hyvä aloittaa niin, että LLM:lle kirjoitetaan prompti, jossa kuvataan kohtalaisen lyhyesti esimerkiksi sovellukseen kehitettävä uusi ominaisuus. Promptissa pyydetään kirjoittamaan lyhyen määrittely pohjalta yksityiskohtaisempi toteutussuunnitelma markdown-muodossa. Isompaan kokonaisuuteen kannattaa pyytää myös jako työvaiheisiin tai sprintteihin, joiden välillä konteksti voidaan tyhjentää, jotta LLM säilyttää fokuksen olennaisessa. Samaa periaatetta sovelletaan usein ihmiskehittäjienkin kanssa. Kun suunnitelma on kirjoitettu, ihmiskehittäjä/sovellusarkkitehti voi lukea sen läpi ja tehdä tarvittavat muutokset ja lisäykset. Suunnitelmaa voi myös iteroida tekoälyn kanssa, esimerkiksi pyytäen sitä selittämään asioita sopivalla abstraktiotasolla.
Varsinainen koodaus toteutetaan sitten uusilla prompteilla, joissa pyydetään toteuttamaan (ja mahdollisuuksien mukaan myös testaamaan) aina seuraava vaihe suunnitelmasta. LLM:ää pyydetään myös seuraamaan edistymistä ja merkitsemään se joko samaan suunnitelmadokumenttiin tai erilliseen tiedostoon. Jokainen toteutusvaihe on sitten hyvä tallentaa versionhallintaan asianmukaisine kuvauksineen, jotka LLM osaa kirjoittaa ilman apua.
Kun koodi on valmis ja yksikkö- ja integraatiotestit tehty, lopullinen käyttötestaus on yleensä ihmisen vastuulla. Etenkin graafisten työpöytäsovellusten testaus on vielä jokseenkin hankalaa nykyisillä koodaustekoälyillä. Komentorivikäyttöliittymät ja palvelinohjelmat ovat helpompia ja niiden testausta voi automatisoida pitkälle. Havaittuja ongelmia korjataan sitten iteroimalla toteutusta joko kooditasolla tai tarvittaessa uudella suunnittelukierroksella.
Tällä tyylillä kehitystyö valmistuu ainakin omissa hommissani n. neljäsosassa ajasta, joka siihen kuluisi perinteisillä menetelmillä. Dokumentaatio, koodin laatu ja testaus on myös parempaa kuin aiemmin.
Tai miten käyttöoppaita laaditaan?
LLM on mainio apuri käyttöoppaiden kirjoittamiseen ja päivittämiseen. Formaatti kannattaa valita niin, että sitä on helppo editoida tekstimuodossa. Tässä rima on ollut jo pitkään hyvin matalalla, ja kielimallien avulla oppaissa päästään helposti paremmalle tasolle kuin mihin nykyisissä kaupallisissa ohjelmistoissa on totuttu.
Tai miten käyttäjien/asiakkaiden/sidosryhmien näkemyksiä kerätään, seulotaan ja tulkitaan vaatimustenhallinnan tarpeisiin?
Eiköhän tämä ole useimmissa projekteissa ja firmoissa edelleen ihmisten työtä. Mikään ei kuitenkaan estä keräämästä käyttäjien toiveita vaikka yhteen pitkään tekstitiedostoon ja pyytää sen perusteella LLM:ltä ehdotus toteutuskelpoisista ideoista ja niille jonkinlaiset työmääräarviot. En ole itse kokeillut, mutta tuskin menee enempää pieleen kuin itse arvioimalla.
Näytä kirjoitukset
