Tekninen velka on tuttu käsite. Koodia kirjoitetaan nopeasti minkä takia laatu kärsii ja myöhemmin maksetaan korkeampaa hintaa muutoksista. AI-avusteinen kehitys ei poista teknistä velkaa vaan muuttaa sen luonnetta.
AI laskee koodin lisäämisen kustannuksia ja nostaa koodin ymmärtämisen kustannuksia. Se optimoi paikallisesti ja heikentää kokonaisuutta. Se kannustaa “riittävän hyvään” lopputulokseen. Tämä ei ole sama asia kuin perinteinen tekninen velka.
Päällekkäiset koodinpätkit
AI-tekninen velka ilmenee päällekkäisinä koodinpätkinä, epätasaisena laatuna ja piilevinä tietoturva-aukkoina. Ne syntyvät kun mallit priorisoivat välitöntä tuotosta pitkän aikavälin kestävyyden kustannuksella.
Kehittäjä käskee mallia ratkaisemaan ongelman. Malli tuottaa koodia joka toimii. Kehittäjä hyväksyy sen. Myöhemmin toinen kehittäjä kohtaa saman ongelman, kysyy mallia ja saa hieman erilaisen ratkaisun. Sekin toimii. Sekin hyväksytään.
Kuukauden kuluttua koodipohjassa on kolme eri tapaa tehdä sama asia. Kukaan ei tiedä miksi. Kukaan ei omista niitä. Kaikki toimivat, mutta yhteensopivuus kärsii.
Käyttäytymiseen perustuva analyysi
Perinteinen staattinen analyysi ei tunnista tätä. Se näkee kolme toimivaa toteutusta. Käyttäytymiseen perustuva koodianalyysi ottaa huomioon inhimillisen tekijän. Se seuraa miten kehittäjät ovat vuorovaikutuksessa koodipohjan kanssa.
Keskeinen mittari on “hotspot”. Moduuli tai osa, joka on sekä monimutkainen että usein muutettu. Tyypillisesti hotspotsit muodostavat minimaalisen osan koko koodipohjasta, mutta aiheuttavat suuren osan kaikista virheistä.
AI-avusteisessa kehityksessä hotspotsit syntyvät eri tavalla. Ne eivät johdu siitä, että kehittäjät kirjoittavat huonoa koodia. Ne johtuvat siitä, että AI tuottaa koodia joka ei integroidu kokonaisuuteen ja kehittäjät palaavat korjaamaan sitä uudelleen ja uudelleen.
Mittarit jotka paljastavat AI-velan
Epäterveessä koodissa on enemmän virheitä ja kehitysnopeus on hitaampi.
Hotspot-esiintymistiheys kertoo osuuden commiteista, jotka keskittyvät tiettyihin tiedostoihin. Korkea tiheys on riski suunnittelemattomalle työlle ja tuotanto-ongelmille.
Katselmointikierrosten määrä AI-avusteisissa pull requesteissa viittaa heikkoon ymmärrettävyyteen tai korkeaan integraatiomonimutkaisuuteen. Jos PR vaatii kolme kierrosta niin ongelma ei ole koodissa vaan siinä miten se liittyy kokonaisuuteen.
Hiljaisen rappeutumisen voi tunnistaa ennakoivasti tiedostoista, jotka aiheuttavat toistuvia virheitä commitin jälkeen. Tämä mahdollistaa puuttumisen ennen kuin moduulista tulee pullonkaula.
Muuta suhdetta AI:n tuotoksiin
Organisaatioiden tulisi määritellä käytäntö, jossa AI:n ehdotukset nähdään lähtökohtana eikä lopullisina tuotoksina. Kokeneiden kehittäjien on asetettava arkkitehtuuriset päätökset ja liiketoimintalogiikka etusijalle verrattuna rutiininomaiseen koodin tuottamiseen.
Junior-kehittäjiä tulisi kouluttaa kyseenalaistamaan AI:n tuottama koodi sen sijaan, että he hyväksyisivät sen sellaisenaan. Tämä ei ole epäluottamusta työkalua kohtaan. Vaan tervettä suhtautumista automaattisesti tuotettuun koodiin.
AI-agentteja voidaan käyttää myös teknisen velan purkamiseen. Päällekkäisten testausohjelmien siirtäminen keskitettyihin paketteihin on tehtävä, joka vähensi yhdessä tapauksessa Docker-kuvien paisumista 50 prosenttia. Tämä vaatii kuitenkin tietoista ohjausta — ei vain mallin päästämistä vapaaksi.
Tuottavuuden laskuvaihe
Organisaatioiden on varauduttava mahdolliseen tuottavuuden laskuvaiheeseen siirryttäessä perinteisestä kehityksestä ihmisen ja AI:n yhteisiin työskentelymalleihin. Tämä ei tarkoita että AI on haitallinen. Vaan että siirtymä vaatii uusien käytäntöjen oppimista.
Mittarit on määriteltävä uudelleen:
- Sykliaika laadun kanssa.
- Tuotantoon päätyvät virheet.
- Keskimääräinen aika koodin ymmärtämiseen ja muuttamiseen.
- Testien laatu ja kattavuuden relevanssi.
Nämä kertovat enemmän kuin rivien määrä tai commitien tiheys.
