Tekoäly suoltaa koodia, mutta ymmärtääkö se Gittiä?
Tekoäly on kiihdyttänyt koodin tuottamista, mutta samalla se on hämärtänyt ohjelmistokehityksen tärkeintä turvaverkkoa: versionhallintaa. Keskustelu pyörii IDE:n ja mallien ympärillä, mutta harva puhuu siitä, mitä tapahtuu git log:ssa.
Kun tekoäly otetaan osaksi koodausta, versiohistorian merkitys aktiivisena kontekstina kasvaa. Tässä kolme pointtia, miksi siisti Git-historia on tekoälyn aikakaudella tärkeämpää kuin koskaan.
Commit-viesti on syöte seuraavalle promptille
Ennen commit-viestin tärkein lukija oli kollega (tai sinä itse) puolen vuoden päästä. Nyt tärkein lukija on tekoäly viiden minuutin päästä.
Kun pyydät tekoälyä refaktoroimaan koodia tai etsimään bugia, se käyttää olemassa olevaa koodia ja sen historiaa kontekstina. Geneerisiä "updates" tai "fixes" -viestejä täynnä oleva historia ei kerro tekoälylle, miksi jokin ratkaisu on tehty.
Hyvä commit-viesti kertoo "miksi", ei "mitä" (tämänhän näkee diffistä). Tämä on kriittistä harjoitusdataa. Jos emme kerro tekoälylle, miksi koodi on sellaista kuin se on, se voi alkaa ehdottamaan muutoksia, jotka rikkovat hiljaista tietoa ja liiketoimintalogiikkaa. Roskaa sisään, roskaa ulos – myös konteksti-ikkunassa.
Jos ihminen ei ymmärrä diffiä, koodi on vaarallista
Tekoäly saattaa tuottaa ratkaisun, joka on teknisesti oikein ja menee testeistä läpi. Mutta jos sen tuottama muutos on ihmiselle lukukelvoton, olemme ongelmissa.
Koodia luetaan moninkertaisesti enemmän kuin sitä kirjoitetaan. Jos AI tekee massiivisen muutoksen, jota katselmoitsija ei pysty hahmottamaan, koodikatselmointi muuttuu kumileimasimeksi. "Näyttää toimivan" ei ole sama asia kuin "ymmärrän, mitä tässä tapahtuu".
Jos diffi on liian monimutkainen ihmisen ymmärrettäväksi, se on teknistä velkaa heti syntyhetkellään. Kun se bugi lopulta löytyy (ja se löytyy), sen korjaaminen on mahdotonta, jos kukaan ei ymmärtänyt logiikkaa alun perinkään. Tekoälyn on tuotettava koodia, joka on optimoitu ihmisen luettavaksi, ei vain kääntäjälle.
Aikakoneen on toimittava: "Undo" on tärkeämpi kuin "Generate"
Gitin tärkein ominaisuus ei ole tallentaminen, vaan palaaminen. Jokainen kehittäjä tietää sen tunteen, kun on koodannut kaksi tuntia väärään suuntaan ja haluaa palata alkupisteeseen.
Nykyisten AI-työkalujen kanssa tämä on yllättävän vaikeaa. Monet työkalut muokkaavat koodia suoraan editorissa tekemättä väli-committeja. Kun huomaat kahdentunnin työskentelyn jälkeen olevasi umpikujassa, sinulla ei olekaan hyvää versiota, johon palata. Olet jumissa rikkinäisen ja kryptisen koodin kanssa, jota et itse kirjoittanut.
Tekoälyn tulisi toimia Gitin ehdoilla: pienten, loogisten ja peruttavissa olevien askelten kautta. Jos tekoäly ei osaa pilkkoa työtään peruttaviksi osiksi, se ei ole apuri, vaan riski. Rollback-kyky on kehittäjän supervoima, ja tekoäly, joka vie sen pois, ei ole valmis tuotantokäyttöön.
Yhteenveto
Tekoäly on loistava renki, mutta huono isäntä versionhallinnassa. Meidän on vaadittava työkaluilta ja itseltämme kurinalaisuutta:
Kirjoita commit-viestejä, jotka selittävät syyt, eivät seurauksia. Vaadi myös tekoälyltä samaa!
Hylkää muutokset, jotka ovat ihmiselle lukukelvottomia, vaikka ne toimisivat.
Vaadi tekoälyltä atomisia committeja, jotta voit aina palata ajassa taaksepäin.
Git ei ole vain koodivarasto. Se on projektin muisti. Älä anna tekoälyn aiheuttaa sille dementiaa.
Aleksi on DevOps-asiantuntija, versionhallintaekspertti ja suosittu Git-kouluttaja.
