Kun koodin kirjoittaminen lakkasi olemasta pullonkaula

Ohjelmistoprojektien kustannusrakenne on pitkään nojannut yhteen oletukseen: koodin kirjoittaminen on hidasta ja kallista. Työmääräarviot, tiimikoot, sprintit ja hinnoittelumallit on rakennettu tämän oletuksen päälle. Kun kysyttiin “paljonko tämä maksaa”, kysyttiin käytännössä “montako kehittäjäviikkoa tämän näppäileminen vie”.

Tuo oletus ei enää pidä paikkaansa samalla tavalla. Toteutusvaiheen nopeus on kasvanut niin paljon, että se ei ole enää useimmissa projekteissa se kohta, joka määrää läpimenoajan.

Se ei kuitenkaan tarkoita, että ohjelmistokehitys olisi muuttunut helpoksi. Vaikein osa on vain siirtynyt toiseen paikkaan.

Pullonkaula siirtyi, muttei kadonnut

Kun toteutus nopeutuu, jono siirtyy ja kasaantuu jonkin toisen vaiheen eteen. Käytännössä se tarkoittaa kolmea asiaa: määrittelyä, katselmointia ja käyttöönottoa.

Määrittely on aina ollut projektien heikoin lenkki, mutta ennen sen puutteet paljastuivat hitaasti. Epäselvä vaatimus ehti kypsyä viikon verran ennen kuin se toteutui koodiksi, ja matkan varrella joku ehti kysyä tarkentavan kysymyksen.

Nyt tuo kysymys jää helposti kysymättä. Ongelma on harvemmin se, että vaatimus toteutuisi täsmälleen niin väärin kuin se oli kirjoitettu. Useammin se on se, ettei vaatimusta ole kirjoitettu tarpeeksi tarkasti ollenkaan, jolloin aukot täytetään oletuksilla. Oletukset taas näyttävät lopputuloksessa ihan samalta kuin määritellyt asiat.

Sama pätee tietysti ihmiseenkin. Ero on siinä, että agentti arvaa nopeammin, ei väsy kysymään ja tuottaa lopputuloksen, joka näyttää itsevarmalta.

Tässä on myös yksi hyödyllisimmistä kohdista käyttää AI:ta: anna sen lukea määrittely ja kertoa, mitä siitä puuttuu. Mitkä kohdat ovat tulkinnanvaraisia, mitä reunatapauksia ei ole käsitelty, mitä se joutuisi itse olettamaan. Se on halpa tarkistus ja monessa projektissa tuottavampi kuin sama malli koodin kirjoittajana.

Katselmoinnista on puolestaan tullut aidosti rajoittava tekijä. Kehittäjä ehtii tuottaa muutoksia nopeammin kuin toinen ihminen ehtii ymmärtää niitä. Tässä kohtaa moni organisaatio tekee hiljaisen päätöksen: katselmoidaan kevyemmin. Se on ymmärrettävä valinta ja monesti kyllä väärä (ainakin toistaiseksi).

Nopeus ei korjaa arkkitehtuuria, se altistaa sen

Hyvin rajattu järjestelmä, jossa on selkeät vastuut ja kunnolliset rajapinnat, hyötyy AI-avusteisesta kehityksestä valtavasti. Konteksti on pieni, säännöt ovat luettavissa koodista, ja muutos pysyy siellä minne se kuuluu.

Sekava järjestelmä käyttäytyy päinvastoin. Kun liiketoimintalogiikka on levinnyt kolmeen kerrokseen ja puoli totuutta asuu tietokannan trigger-funktioissa, nopeus vain lisää sotkua nopeammin. Muutos näyttää oikealta paikallisesti ja rikkoo jotain aivan muualla.

Tää on meille Koudilla tuttu kuvio esimerkiksi Go-projekteista. Yksinkertainen kieli, selkeä rakenne ja eksplisiittinen virheenkäsittely eivät ole vain esteettisiä mieltymyksiä. Ne ovat konteksti, jonka sekä ihminen että kone pystyy lukemaan ilman arvailua.

Arkkitehtuurin laadusta on tullut tuottavuustekijä tavalla, joka ei aiemmin näkynyt yhtä suoraan viivan alla.

Konteksti on uusi tuotantopanos

Agenttien laatu ei ratkea sillä, mikä työkalu valitaan. Se ratkeaa sillä, mitä työkalu näkee.

Testit, tyypit, dokumentoidut rajapinnat, kuvatut toimialan käsitteet ja johdonmukainen repositorion rakenne ovat käytännössä koneluettavaa määrittelyä. Projekti, jossa nämä ovat kunnossa, saa AI:sta moninkertaisen hyödyn verrattuna projektiin, jossa tieto on ihmisten päissä ja vanhoissa Slack-ketjuissa.

Tässäkin piilee myös ikävä lopputulos: AI ei tasoita hyvin ja huonosti hoidettujen koodikantojen eroa, vaan moninkertaistaa sen.

Laadunvarmistus siirtyy loppupäästä rakenteeseen

Kun muutoksia syntyy enemmän, manuaalinen tarkastus ei skaalaudu. Ainoa kestävä vastaus on siirtää laatuvaatimukset sinne, missä ne tarkistetaan automaattisesti ja joka kerta: kattavat testit, tiukat lintit, tyyppitarkistus, staattinen analyysi, riippuvuuksien ja tietoturvan skannaus, toistettavat ympäristöt ja luotettava CI-putki.

Tämä ei ole uusi oppi. Uutta on se, että sen laiminlyönnin hinta realisoituu nyt viikoissa eikä vuosissa.

Ihmisen katselmoinnin rooli muuttuu samalla. Kysymys ei ole enää “onko tämä rivi oikein” vaan “onko tämä ratkaisu oikea, kuuluuko se tähän järjestelmään ja mitä se maksaa meille vuoden päästä”. Se on arvioivaa työtä, ei tarkistuslistan läpikäyntiä, ja siihen tarvitaan kokenutta tekijää.

Legacy näyttää yhtäkkiä erilaiselta

Yksi konkreettisimmista muutoksista koskee vanhoja järjestelmiä.

Modernisointiprojektin suurin kustannus ei aina todellakaan ole ollut uuden kirjoittaminen. Se on ollut vanhan ymmärtäminen: dokumentoimattoman logiikan kaivaminen esiin koodista, jonka kirjoittajat ovat jo eläkkeellä. Juuri tässä nykyiset työkalut ovat poikkeuksellisen hyviä. Koodikannan läpikäynti, riippuvuuksien kartoitus ja liiketoimintasääntöjen kuvaaminen ihmisluettavaan muotoon on työtä, joka ennen vei kuukausia.

Moni “liian kallis modernisoitavaksi” -järjestelmä kannattaa arvioida uudelleen. Laskelma on tehty eri hinnoilla kuin mitkä ovat nyt voimassa.

Tää ei tarkoita, että migraation voisi antaa agentin hoidettavaksi kokonaan. Se tarkoittaa sitä, että esiselvityksen ja kartoituksen hinta on romahtanut, ja päätös on siksi helpompi tehdä tietoon kuin arvaukseen perustuen.

Mitä asiakas oikeastaan ostaa

Jos toteutusnopeus ei enää erottele toimittajia, on rehellistä kysyä, mistä ohjelmistotalolle maksetaan.

Vastaus on mielestämme selvä: arvioinnista ja vastuusta. Siitä, että joku päättää mitä ei rakenneta. Siitä, että joku tunnistaa, milloin nopeasti syntynyt ratkaisu on oikeasti valmis ja milloin se on vain demo, joka näyttää valmiilta. Siitä, että kun tuotannossa on ongelma kello 23, vastuu on sopimuksessa nimetyllä osapuolella eikä mallin toimittajalla.

Tämä kannattaa ottaa huomioon myös kilpailutuksissa. Tuntihinta ja arvioitu työmäärä kertovat aiempaa vähemmän. Enemmän kertovat kysymykset siitä, miten toimittaja katselmoi työn, mitä automaatiota heillä on laadun tukena, miten tekninen velka pidetään näkyvissä ja kuka kantaa vastuun lopputuloksesta.

Mistä lähtisimme liikkeelle

Jos organisaatiossa pohditaan, miten AI otetaan osaksi ohjelmistokehitystä, ensimmäiset askeleet eivät ole työkaluvalintoja:

• Selvitä, mikä teillä on oikeasti hitainta. Jos se on päätöksenteko tai hyväksyntäkierrokset, nopeampi koodintuotanto ei auta lainkaan.
• Laita CI, testit ja ympäristöt kuntoon ennen kuin kasvatat muutosten määrää. Tämä on investointi, joka maksaa itsensä takaisin nopeasti.
• Sovi pelisäännöt siitä, mitä tuotantokoodille saa tehdä ja millä tarkistuksilla. Kirjoita ne auki, älä oleta.
• Ratkaise tietoturva- ja datakysymykset etukäteen: mitä koodia tai dataa saa viedä mihinkin palveluun ja millä ehdoilla.
• Aloita rajatusta kokonaisuudesta, jolla on oikea omistaja ja mitattava lopputulos. Sisäiset kokeilut ilman omistajaa jäävät kokeiluiksi.

Lopuksi

Ohjelmistoalalla on totuttu siihen, että uusi teknologia lupaa poistaa monimutkaisuuden. Toistaiseksi mikään ei ole sitä tehnyt, vaikka hyviä yrityksiä toki on ollut! Monimutkaisuus on siirtynyt: assemblysta korkeamman tason kieliin, palvelinsaleista pilveen, ja nyt kirjoittamisesta arviointiin ja johtamiseen.

Omasta näkökulmasta sanoisin, et AI-avusteinen kehitys ei todellakaan vähennä osaamisen tarvetta, vaan nostaa sen hintaa. Kun kuka tahansa saa tuotettua toimivan näköistä koodia, arvo siirtyy niille, jotka osaavat sanoa, mikä siitä kestää tuotannossa. Kokemattomalle tiimille nopeus on riski, kokeneelle se on vipuvarsi.

Ja juuri siksi tärkein kysymys ei ole, mitä työkalua käytätte. Se on, tunnistaako joku teidän puolellanne pöytää, milloin nopeasti syntynyt vastaus on väärä.