Vibekoodauksen tekninen velka
Kun kielimallille antaa toimeksiannon, se on yleensä konkreettinen: lisää käyttäjälle mahdollisuus vaihtaa sähköpostiosoite, korjaa tämä virhe, tee hakutoiminto, luo uusi käyttäjärooli.
Malli ratkaisee sen tehtävän, joka on sen edessä, ja käyttää siihen sen tiedon, joka sille on annettu. Se ei välttämättä tiedä, että sama ongelma ratkaistiin kolme kuukautta sitten järjestelmän toisessa osassa hieman eri tavalla. Ja vaikka sen kertoisi sille, se ei silti välttämätä ota kaikkea tehtyä huomioon, sillä se ei tunne perusteluja, joiden takia nykyinen tietomalli suunniteltiin juuri tällaiseksi. Eikä se aina tunnista tilannetta, jossa uuden koodin kirjoittamisen sijaan pitäisi muuttaa olemassa olevaa rakennetta. Tämä toistuu myös silloin kuin käyttäjä yrittää korjata jo tehtyä koodia.
Vaikka lopputulos toimii, järjestelmään on voinut syntyä useampi tapa ratkaista sama asia. Ei tekniselle henkilölle jokainen muutos näyttää silti järkevältä, mikäli sillä saatiin aikaan toiminto, jota toivottiin.
Koodin huonossa laadussa on liiketoiminnan kannalta se ikävä ominaisuus, että sivuvaikutukset tulevat viiveellä. Kaatuva sovellus on helppo havaita, mutta huonosti jäsennelty ja toteutettu backend ei aiheuta aluksi mitään näkyvää.
Tekninen velka, joksi tällaista tilannetta usein kutsutaan, ei ole tekoälyn keksintö. Huonoa koodia on kirjoitettu niin kauan kuin ohjelmistoja on ollut. Tekoäly muuttaa yhtälöstä yhden asian: nopeuden, jolla huonoja rakenteellisia päätöksiä ehditään tehdä. Jos kehittäjä kirjoittaa päivässä sata riviä sekavaa koodia, vahinko on rajallinen. Tuhat riviä toimivaa mutta huonosti jäsenneltyä koodia on eri asia.
Hyvä koodi ei tarkoita täydellistä koodia, eikä prototyypin tarvitse olla arkkitehtoninen mestariteos. Käyttökelpoisempi mittari on muutoskyky, ja se konkretisoituu neljässä kysymyksessä.
- Kun palvelulle tulee uusi vaatimus, riittääkö sen toteuttamiseen yksi paikka vai onko sama muutos tehtävä seitsemään tiedostoon?
- Kun tietomallia muutetaan, tiedetäänkö mitä siihen on kytketty?
- Kun yksi komponentti vaihdetaan, voidaanko luottaa siihen, ettei samalla rikota kolmea muuta?
- Kun uusi kehittäjä avaa projektin, pystyykö hän päättelemään, miten järjestelmä toimii?
Kaikkea vibekoodia ei kannata siivota
Mikään edellä sanotusta ei tee vibekoodauksesta huonoa tapaa rakentaa ohjelmistoja. Jos tarkoitus on selvittää viikoissa, onko ideassa mitään järkeä, huolellisen arkkitehtuurin rakentaminen on huono investointi. Prototyypin tehtävä on vastata yhteen kysymykseen: haluaako kukaan käyttää tätä. Jos vastaus on ei, koodin laadulla ei ollut merkitystä.
Kiinnostava hetki on se, kun vastaus on kyllä. Silloin pitäisi tehdä päätös, joka nopeasti etenevässä kehityksessä on epähoukutteleva: onko tämä yhä kokeilu vai onko tästä tulossa ohjelmisto, jota kehitetään seuraavat viisi vuotta. Näiltä kahdelta kannattaa vaatia eri asioita.
Käytännössä päätös jää usein tekemättä, koska mikään ei pakota siihen. Tuote toimii, käyttäjiä tulee lisää, ja seuraava ominaisuus on aina houkuttelevampi kuin pysähtyminen.
Anna ammattilaisten tarkastaa ja ottaa vastuuta
Kun vibekoodattu tuote alkaa osoittaa arvonsa, jossain vaiheessa kannattaa antaa se ammattilaisen auritoitavaksi.
Hänen kysymyksensä ovat toisenlaisia. Miksi tämä on rakennettu näin? Miksi sama logiikka on neljässä paikassa? Tarvitaanko kaikkia näitä riippuvuuksia? Missä järjestelmän rajat kulkevat? Mitä tästä pitäisi yksinkertaistaa ennen kuin rakennetaan lisää?
Katselmointi voi johtaa refaktorointiin, arkkitehtuurin selkeyttämiseen, testien lisäämiseen tai jonkin osan kirjoittamiseen uudelleen. Kaikkea ei tarvitse uusia. Tavoite on löytää ne kohdat, joissa tulevaisuuden haasteet piilevät.
Vibekoodauksen koko lupaus on tehdä ohjelmistokehityksestä nopeampaa. Olisi ironista, jos vuoden päästä suurin este kehitetyn tuotteen jatkokehitykselle olisi juuri se koodi, jonka tekoäly auttoi tuottamaan nopeasti.
