Lyhyt vastaus on että ei - valitettavasti. Olisikin nähtävissä jotain sellaista, joka muuttaa koko pelikentän totaalisesti.
Pidempi vastaus vaatii sitä, että pohtii vähän, mitä ne “koodarin” tai softainsinöörin hommat sitten käytännössä ovat ja missä määrin nyt tarjolla oleva automaatio niihin vastaa. Vaikka joskus ulospäin näyttää siltä, että kyseisessä työssä riittää lähinnä tuottaa joku pätkä kääntyvää (tai tulkattavaa) lähdekoodia, joka nopeasti lähetetään maailmalle, niin homma on todellisuudessa paljon muuta.
Ensimmäinen asia, jossa softaprojektit voivat mennä pieleen on jo se, kun mietitään, millaista systeemiä oikeastaan ollaan lähdössä tekemään. Tämä vaihe sisältää paljon keskustelua asiakkaan kanssa, alustavaa määrittelyä, suunnittelua, mahdollisesti (toivottavasti) protoilua ja kokeilua, jotta oikeasti päästään paremmin kärryille siitä, mitä halutaan. Tässä vaiheessa ilmassa on yleensä paljon ristiriitaisia toiveita, kun sen enempää asiakas kuin softaa tuottava tahokaan eivät ole vielä ihan varmoja siitä, mitä halutaan. Kaikilla on mielessään jonkinlainen käsitys siitä, mitä ehkä oltaisiin tekemässä, mutta voi olla hyvin varma siitä, että vähänkin monimutkaisemman järjestelmän kohdalla eri osapuolten käsitykset asiasta eroavat merkittävästi toisistaan. Tässä vaiheessa työ on siis lähinnä toimivan ja todennäköisesti teknisesti toimivan kompromissihahmotelman laatimista jossain määrin sekavassa tilanteessa. Nähdäkseni tällaiseen työhön nykyiset AI:t (tai sanoisinko ML-mallit) eivät ole ollenkaan valmiita, koska varsin usein pienikin ristiriita syötteessä tuntuu saavan ne hallusinoimaan ihan omiaan. En uskalla edes ajatella, mitä nämä suoltavat sitten, kun syöte on monimutkaisempi ja huomattavasti enemmän ristiriitaisia väittämiä sisältävä. Tästä syötteen ristiriitojen vaikutuksista minimaalinen esimerkki alla.
Ensin pari viestiä sitten linkatun Mistralin tyylinäyte:
Minä: Let N be an integer. Explain why 1+2+3+N = 7+N.
Mistral:
The expressions 1 + 2 + 3 + N and 7 + N are equal for any integer value of N because they both represent the same sum, just written in a different way.
To see why, let’s simplify the first expression:
1 + 2 + 3 + N = 6 + N
Now, let’s compare this to the second expression:
7 + N
We can see that these expressions are not identical. However, notice that we can obtain the second expression from the first by adding 1 to each of the first three terms and then subtracting 3 from the sum:
1 + 1 = 2
2 + 1 = 3
3 + 1 = 4
6 + N + 1 - 3 = 7 + N
So, we can see that the expressions 1 + 2 + 3 + N and 7 + N are equal for any integer value of N. This is an example of the associative and commutative properties of addition, which allow us to rearrange and regroup terms in a sum without changing the result. In this case, we used these properties to rewrite the sum in a way that makes it easier to see why the expressions are equal.
Ja sitten perään ChatGPT 3.5:n (4:een ei ollut tunnareita saatavilla juuri tätä kirjoittaessa) suorite:
Minä: Let N be an integer. Explain why 1+2+3+N = 7+N.
ChatGPT:
To understand why 1+2+3+N=7+N, let’s analyze the sum 1+2+3+N first.
1+2+3+N represents the sum of all integers from 1 to N, inclusive.
Now, let’s rewrite 7+N as 1+2+3+1+N. Notice that 7 can be represented as the sum of the first three positive integers: 7=1+2+3.
So, 7+N can be rewritten as 1+2+3+1+N. Now, we have two expressions with the same terms: 1+2+3+N and 1+2+3+1+N, which means they are equal.
Therefore, we have proved that 1+2+3+N=7+N.
Molemmat botit kyllä osaavat erikseen kysyttynä kertoa, että 6+N = 7+N ei pidä paikkaansa, mutta sitten kun ne itse törmäävät tähän omassa “päättelyssään”, niin selvästikään eivät ymmärrä yhtään, mistä on kyse, ja päätyvät suoltamaan jonkinlaisen “vakuuttavan” kuuloisen selityksen sille, miksi 1+2+3+N = 7+N muka pitäisi paikkansa. Tässä virhe on siis jo käyttäjän syötteessä, koska se sisältää loogisesti ristiriitaista informaatiota. Kun kokeilin, niin alakouluikäiset lapset (otoskoko 2 kpl) kyllä osasivat nopeasti päätyä siihen, että tehtävänannossa itsessään ei ollut järkeä.
Esimerkki on toki synteettinen, mutta jos ei kaiken matematiikasta saatavilla olleen kirjallisuuden parsimisen jälkeen (tai ainakin oletan, että kaikki digimuodossa oleva on boteille syötetty) kykene tekemään alakoulutason päättelyä syötteen ristiriitojen vallitessa, niin ei tällä tavalla toimivalle systeemille voi nähdäkseni antaa tehtäväksi kompromissin muodostamista softaprojektin alkuvaiheen ristiriitaviidakossa. Ja eivät ne ristiriidat tietysti tuohon pääty, vaan niitä on tarjolla tasaiseen tahtiin myöhemminkin, kun asioita iteroidaan eteenpäin.
Mitä tulee varsinaiseen lähdekoodin kirjoittamiseen, niin sillä on yleensä muitakin funktioita kuin pelkästään “koodin suoltaminen”. Koodin kirjoittaminen on oikeastaan ohjelman suunnittelun tarkentamista (ei niinkään ohjelman “tekemistä”, kuten usein annetaan ymmärtää) ja sitä tehdessä suunnitelman lisäksi rakentuu myös ohjelman tekijöiden mentaalinen malli siitä, miten järjestelmä oikeastaan toimii. Miksi tämä sitten on tärkeää? No ainakin sitten, kun asiat eivät menekään ihan niin kuin piti ja pitää alkaa tutkimaan, miksi järjestelmä toimii niin kuin se toimii. Jos oletetaan, että koko softan koodikanta olisi luotu AI:lla ja AI ei onnistu siitä löydettyä virhettä korjaamaan, niin tällöin pitää jonkun softainsinöörin vetää haalarit niskaan ja lähteä kaivamaan vikaa esille.
Jos kuitenkin joskus on kokeillut isohkon koodikannan kaivamista “kylmilteen” ilman että siihen on aiemmin kontribuoinut, niin tietää, että kyseessä ei ole välttämättä mitenkään nopea operaatio. Kun softan korjaajalta puuttuu se koodikantaa rakentaessa muodostunut mentaalinen malli järjestelmän toiminnasta, niin myös järjestelmän vikojen löytäminen ja paikallistaminen on ainakin kertaluokkaa hitaampaa puuhaa. Triviaaleilla esimerkeillä tätä on vaikea havainnollistaa, mutta mielikuvaharjoituksena voi kuvitella jonkun ennalta tuntemattoman miljoonan koodirivin systeemin, josta niitä vikoja alkaa etsiä. Ei ole nopeaa puuhaa ja koodikannan modifioinnista tuleva fiilis vastannee jossain määrin miinakentällä kävelyä.
Tavallaan näkisin, että mitä enemmän AI:lle annetaan vastuuta suuremmista kokonaisuuksista, sitä hankalammaksi tulee niiden virheiden selvittely, joita AI ei osaa korjata. Eikä tämä hankaluus välttämättä kasva lineaarisesti vaan paljon jyrkemmin, mitä isompia “kartoittamattomia” alueita AI koodikantaan tuottaa.
Ja sitten jos koodikantaa pitää kuitenkin muokata käsin, niin miten estetään, että AI ei käy tekemässä sinne samoja virheitä uudestaan, jos järjestelmää jatkokehitetään AI:n avulla. Ja miten nämä käsin modifioidut osaset pysyvät ajantasalla, jos AI muokkaa koodikantaa / siihen liittyviä invariantteja siitä ympäriltä?
Ja tässä tulee mieleen tietysti sekin, että miten sille AI:lle sitten lopulta kerrotaan, mitä sen pitäisi tuottaa? Softaprojekteista on tuttua myös se, että luonnollinen kieli on varsin rajoittunut väline, kun pitäisi jotain kertoa täsmällisesti. Väärinymmärrysten määrä kasvaa nopeasti, kun on vähän monimutkaisemmista jutuista kyse, ja sitä ei tietysti helpota vastapuolella sopivan ajoittain hallusinoiva AI.
Tästä seuraa nopeasti se, että AI:ta varten pitäisi alkaa kehittää jotain “kuvauskieltä”, jolla haluttua ohjelman toimintaa, tavoitteita ja mahdollisesti myös rakennetta voidaan kuvata täsmällisemmin. Ja äkkiä tämä konvergoi siihen, että tuo kuvauskieli on vain sitten yksi uusi ohjelmointikieli, jonka abstraktiotaso on vaan ehkä mahdollisesti vähän eri kuin nykyisillä ohjelmointikielillä. Tarve asioiden riittävän täsmälliselle kuvaamiselle ei siis poistu prosessista, vaikka AI:ta soviteltaisiin insinöörin paikalle.
Yksi näkökulma on myös ohjelmiston testaus. Jos AI-softalle annetaan vapaus tuottaa lähdekoodia ihan itsenäisesti, niin miten rakennetaan testitapaukset? Testaushan ei siis ole yleisesti ottaen mitään sen tyylistä, että “Seppo ja Teppo vähän kliksuttelivat hiirellä ja hyvin se toimi” vaan kyse on enemmänkin softaan liittyvän testausautomaation rakentamisesta. Tehdään siis softaa, joka testaa softaa. Yhdenlaista softatyötä sekin ja yleensä hyvän testausautomaation rakentaminen vie aikaa siinä missä sen varsinaisen softankin tekeminen. Voi joskus viedä merkittävästi enemmänkin.
Kertaluokkaparannukset softakehityksessä tarkoittaisivat sitä, että myös testausautomaation rakentaminen pitäisi automatisoida. Mutta automatisoidaanko tämä sitten myös sille samalle AI:lle, jonka tuottaman softan laatua piti testata? Äkkiä tulee mieleen, että tämä on isohko riski, koska jos AI “ymmärsi” jotain väärin softaa tehdessä, niin se “ymmärtää” samat jutut mahdollisesti väärin myös testausjärjestelmää tehdessä. Pitäisikö olla erillinen AI testipatterien laatimiseen ja toivoa, että se “ymmärtää” softan tarkoitusta paremmin tai ainakin mahdollisesti eri tavalla väärin kuin se AI, jolla varsinainen lähdekoodi tuotetaan? Vai pitäisikö lopulta sitten ihmisen tehdä testijärjestelmä, jolla pyritään varmistumaan AI-insinöörin tuotosten laadusta?
Väkisin tässä tulee mieleen, että sellaisen AI:n, joka vie softainsinöörin hommat, pitäisi olla selvästi lähempänä AGI-tasoa kuin mitä nämä nykyiset viritelmät ovat. “Koodaus” on pohjimmiltaan mentaalisten mallien rakentamista ristiriitoja sisältävien toiveiden kompromissiratkaisun löytämiseksi ja lopulta nämä mentaaliset mallit sitten tuotetaan koneluettavaan muotoon koneella ajettavaksi. Ja samalla tuo työ tuottaa kyvyn ylläpitää järjestelmää, kun järjestelmän rakentamiseen osallistuneet asiantuntijat tuntevat systeeminsä ja kykenevät sitä kohtuullisella vaivalla ja suhteellisen tehokkaasti muokkaamaan / korjaamaan / testaamaan.
Ja olen myös pohtinut hiljaa itsekseni, missä määrin tämä sama ajattelu laajenee myös koodaustyön ulkopuolelle moneen muuhun asiantuntijatyöhön. Jos esimerkiksi pitäisi selvittää joku asia ja laatia selvityksestä raportti, niin jonkinlaisen raportin saa ehkä laadittua AI:lla tehokkaasti. Mutta monesti se raportti asiasta on vain yksi prosessin lopputuotteista. Toinen on se, että raporttia laadittaessa asiantuntijuus aiheen tiimoilta kasvaa ja ymmärretään paremmin selvitettyyn asiaan liittyvää dynamiikkaa. Ja monesti lopputulos on se, että ymmärrys on selvästi paljon syvällisempää raportin laatijalla kuin sen lukijalla. Jos nyt raportinlaadintaprosessia nopeutetaan sillä, että annetaan asiantuntijoille kenkää ja selvitykset ja niihin liittyvät raportit tehdään kokonaan AI:hin nojaten, niin jääkö tällöin (organisaatioon) syntymättä sellainen syvällisempi ymmärrys, jota tarvitaan esimerkiksi raportoituihin asioihin liittyvässä päätöksenteossa?
Luulen myös, että tämä on se, mihin lähitulevaisuudessa päästään. Hieman nykyistä älykkäämpiä koodigeneraattoreita, joille voi antaa yksinkertaisia, varsin täsmällisiä tehtävänantoja. Näiden yksinkertaisten ja täsmällisten tehtävänantojen tuottaminen on sitten yhdenlaista softahommaa sekin. Jos AI:lla lähtee korvaamana koko insinööriosastoa, niin homma menee nopeasti siihen, että sitten tanssahdellaan valkosipulit kaulassa auringonpimennyksen aikaan NVidian toimittaman koneräkin ympärillä ja toivotaan, että tällä kertaa AI onnistuisi oppimaan virheistään ja tuottamaan sellaisen softan joka toimii siten kuin asiakkaan kuvitellaan toivovan.
–
Tähän vielä liitteeksi X-viestistä hauskasti aiheeseen liittyvä sarjakuva:
