Tekoäly kirjoittaa koodia. Insinöörit rakentavat ohjelmistoja.

Tekoäly ei ole tappanut ohjelmointia. Se on tappanut ajatuksen siitä, että ohjelmointi olisi pääasiassa koodin kirjoittamista. Tämä ero on tärkeä. Suuri osa nykyisestä tekoälykeskustelusta käsittelee ohjelmistokehitystä yhä ikään kuin arvokkain työ olisi tuottaa enemmän koodirivejä nopeammin. Vallitseva ajattelutapa on antaa jokaiselle kehittäjälle koodausavustaja, luoda enemmän ominaisuuksia, toimittaa enemmän pull requesteja ja juhlia tuottavuuskäyrän nousua.

Ohjelmisto-organisaatiot kärsivät kuitenkin harvoin liian vähäisestä koodista. Useimmat kärsivät siitä, että niillä on liikaa koodia, jota ne eivät täysin ymmärrä, eivät voi muuttaa turvallisesti, eivät voi testata kunnolla eivätkä yhdistää selkeään liiketoiminta-arvoon. Huonosti käytettynä tekoäly vain pahentaa tätä ongelmaa. Koodista tulee yltäkylläistä, kun taas aidosta ohjelmistosuunnittelusta tulee niukkaa.

Koodin yltäkylläisyyden aika

Suurimman osan ohjelmistokehityksen historiasta koodin kirjoittaminen on ollut kallista. Tarvittiin ihmisiä, jotka tunsivat perusteellisesti järjestelmän kielen, frameworkit, kirjastot, mallit ja erityispiirteet. Pienikin ominaisuus edellytti, että joku analysoi ongelman, kirjoitti toteutuksen, korjasi syntaksin, ajoi testit ja vei muutoksen koodikatselmoinnin läpi.

Tekoälypohjaiset koodaustyökalut ovat muuttaneet tämän asetelman perustavanlaatuisesti. Kehittäjä voi nykyään pyytää avustajaa luomaan React-komponentin, rakentamaan API:n rungon, migroimaan testit tai selittämään legacy-funktion. Tuotos ei ole aina oikein, mutta se syntyy uskomattoman nopeasti. Esimerkiksi GitHubin tuoreet tiedot osoittavat, että kehittäjät koodaavat tekoälyavustajien avulla jopa 55 % nopeammin: aiemmin kolme päivää vienyt API-rungon rakentaminen onnistuu aamupäivässä.

En väitä, etteikö nopeudesta olisi hyötyä. Tekoäly poistaa tylsiä työvaiheita, nopeuttaa perehdytystä tuntemattomiin koodikantoihin ja auttaa muita kuin ইংlannin äidinkielisiä kirjoittamaan selkeämpää dokumentaatiota. Se voi muuttaa karkean ajatuksen sujuvasti toimivaksi lähtökohdaksi.

Koodin yltäkylläisyys luo kuitenkin uuden pullonkaulan. Keskeinen kysymys ei enää ole Voimmeko kirjoittaa tämän? Sen sijaan tiimien on kysyttävä:

• Pitäisikö tämän olla olemassa?

• Sopiiko se arkkitehtuuriin?

• Ratkaiseeko se todellisen ongelman?

• Voimmeko testata ja operoida sitä turvallisesti?

• Voiko seuraava henkilö ymmärtää sitä ja muuttaa sitä myöhemmin?

Nämä ovat ohjelmistosuunnittelun, eivät koodaamisen kysymyksiä.

AI slop on koodia ilman ohjelmistosuunnittelua

"AI slop" ei tarkoita vain rumaa koodia. Se on koodia, joka on tuotettu ilman riittävää kontekstia, rajoitteita, omistajuutta tai palautetta. Se voi kääntyä tai läpäistä yksinkertaisen testin, mutta ei lopulta kuulu järjestelmään.

Näin käy, kun tekoälyavustaja keksii uuden abstraktion, koska se ei ymmärtänyt olemassa olevaa, tai kun pull request lisää tarpeettomia riippuvuuksia ratkaistakseen ongelman, jonka alusta jo hoiti. Näin käy, kun testit luodaan suoraan toteutuksesta eikä vaatimuksesta, jolloin ne käytännössä vain vahvistavat, että tuotettu koodi toimii oman logiikkansa mukaisesti. Vaarallisinta on, kun kehittäjät hyväksyvät valtavia muutospaketteja vain siksi, että niiden huolellinen lukeminen kestäisi kauemmin kuin mallin pyytäminen kirjoittamaan ne. Lopputuloksena on koodia, joka toimii demossa mutta epäonnistuu tuotannossa salaperäisesti.

Se on tuotoksen hallintaa, ei ohjelmistosuunnittelua, eikä tuotoksen hallinta skaalaudu. Mitä enemmän koodia tekoäly pystyy tuottamaan, sitä tärkeämpää on valvoa tiukasti, mitä koodia järjestelmään päästetään.

Ohjelmoijan työ siirtyy abstraktiotasolla ylemmäs

Tämä muutos ei tee kehittäjistä vähemmän tärkeitä. Se vain siirtää heidän arvokkaan työnsä abstraktiotasolla ylemmäs. Kun koodirivien kirjoittaminen käsin ei ole enää keskiössä, järjestelmän syvällinen ymmärtäminen on elintärkeää. Ohjelmistoinsinöörin arvo siirtyy koodin tuottamisesta muutoksen muotoiluun.

Tähän kuuluu:

• Toimialan ymmärtäminen riittävän hyvin, jotta tietää, mitkä ongelmat todella kannattaa ratkaista.

• Selkeiden rajojen määrittely järjestelmien, palveluiden ja vastuiden välille.

• Epämääräisten pyyntöjen muuttaminen täsmälliseksi, testattavaksi tavoitteeksi.

• Tekoälytyökalujen varustaminen tarkalla kontekstilla sen sijaan, että toivotaan niiden päättelevän sen.

• Vahvojen palautesilmukoiden suunnittelu testien, CI/CD:n, havainnoitavuuden ja tuotantomittareiden avulla.

Tässä sanan engineer merkitys todella korostuu. Koodaaja pyytää tekoälyä rakentamaan ominaisuuden. Insinööri kysyy, kuuluuko ominaisuus tuotteeseen, mihin se tulisi sijoittaa, miten sen pitäisi epäonnistua, mitä sen operointi maksaa ja mitä tulevia muutoksia se helpottaa tai vaikeuttaa. Tekoäly nostaa koodintuotannon perustasoa, mutta se ei automaattisesti nosta ohjelmiston laadun ylärajaa. Tuo yläraja perustuu edelleen täysin ihmisen tekniseen harkintaan.

Orkestrointi on uusi ydinosaaminen

Parhaat tekoälyä käyttävät kehittäjät, joita näen, eivät pyydä valtavia määriä taianomaisesti syntyvää koodia. Sen sijaan he orkestroivat pieniä, hallittuja vaiheita.

He tarjoavat kontekstin, vaativat työkalua tarkastamaan olemassa olevan koodin ennen muutosten tekemistä ja rajaavat ratkaisua. He erottavat testien luomisen toteutuksesta, lukevat diffit huolellisesti ja hylkäävät armotta uskottavalta näyttävän koodin, joka ei sovi järjestelmään. Tämä työnkulku muistuttaa vähemmän automaattista täydennystä ja enemmän salamannopean juniorikehittäjän ohjaamista: sellaisen, joka on lukenut koko internetin mutta ei tiedä mitään tuotantoympäristöstäsi.

Kun koulutan kehitystiimejä tekoälyn käyttöönotossa, opetan heille, että hyödyllinen tekoälyavusteinen ohjelmistokehitys noudattaa yleensä tätä mallia:

1. Kuvaile haluttu toiminta selkeällä kielellä.

2. Pyydä työkalua tarkastamaan asiaankuuluva koodi ja tiivistämään nykyinen rakenne.

3. Kirjoita tai päivitä testit ensin, mieluiten erillisenä vaiheena.

4. Luo mahdollisimman pieni toteutus, joka läpäisee nämä testit.

5. Tee tavanomaiset ihmisen tekemät tarkistukset: linttaus, tyyppitarkistukset, tietoturvaskannaukset ja pipelinen validointi.

6. Tarkista diffistä arkkitehtuuri, luettavuus ja pitkän aikavälin ylläpidettävyys.

7. Dokumentoi kaikki, mitä seuraavan kehittäjän on tiedettävä.

Mikään tästä ei poista insinöörin roolia. Päinvastoin, se lisää vastuuta, sillä kun tekoäly tuottaa koodin, ihminen vastaa edelleen lopputuloksesta.

Organisaatioiden on lopetettava väärien asioiden mittaaminen

Tekoälypohjaisten koodaustyökalujen suurin riski ei ole kehittäjien laiskuus. Suurin riski on, että organisaatiot mittaavat vääriä parannuksia.

Jos tavoitteena on enemmän koodia, enemmän pull requesteja tai enemmän ominaisuuksia, tekoäly tuottaa juuri sitä – myös ominaisuuksia, joita ei olisi koskaan pitänyt rakentaa. Ohjelmistotoimitus on kuitenkin muutoksenhallinnan käytäntö, ei kirjoitusnopeuskilpailu. Kysymys ei ole siitä, kuinka paljon nopeammin voimme tuottaa koodia, vaan siitä, kuinka paljon nopeammin voimme toimittaa turvallisia, arvokkaita ja ylläpidettäviä muutoksia.

Tämä edellyttää perustavanlaatuisesti erilaista toimintamallia. Tiimit tarvitsevat koodausstandardeja, joita tekoälytyökalut voivat noudattaa, riittävän ajantasaisen arkkitehtuuridokumentaation sekä CI/CD-putket, jotka tarjoavat nopeaa palautetta. Ne tarvitsevat käyttäytymislähtöisiä testejä, riskeihin tyylin sijaan keskittyviä katselmointikäytäntöjä sekä havainnoitavuutta, jolla varmistetaan, että muutos todella toimi tuotannossa.

Toisin sanoen ne tarvitsevat vahvaa DevOps-kurinalaisuutta enemmän kuin koskaan. Tekoäly ei korvaa hyviä ohjelmistotoimituksen käytäntöjä, vaan rankaisee niiden puuttumisesta ankarasti. Kun auditoin asiakkaiden CI/CD-putkia, havaitsin, että nopeammat tekoälyn tuottamat pull requestit kasvattivat käyttöönottovirheiden määrää 20 %, koska automatisoitu testaus ei pysynyt perässä.

Menestyvät tiimit rakentavat järjestelmän tekoälyn ympärille

Tekoälyn käyttöönottoon liittyy houkutteleva mutta vaarallinen lähestymistapa: yritys ostaa lisenssit, ottaa työkalut käyttöön ja jää odottamaan tuottavuuden räjähdysmäistä kasvua.

Sitä myös tapahtuu osittain. Yksittäiset kehittäjät työskentelevät nopeammin, pienet tehtävät helpottuvat ja demot näyttävät vaikuttavilta. Pitkän aikavälin kilpailuetu ei kuitenkaan synny siitä, että käytössäsi ovat samat tekoälytyökalut kuin kilpailijoillasi, vaan niistä työkaluista ympärille rakentamastasi kehitysjärjestelmästä.

Tähän järjestelmään kuuluu:

• Selkeät säännöt siitä, missä tekoälyä saa käyttää ja missä ei.

• Turvallinen pääsy repositorioihin, dokumentaatioon ja ympäristöihin.

• Suojakaiteet tuotetulle koodille, riippuvuuksille ja salaisuuksille.

• Testausstrategiat, jotka tunnistavat tekoälyn hallusinaatiot varhain, sekä CI/CD-putket, joita tekoälyavusteiset muutokset eivät voi ohittaa.

• Arkkitehtuuripäätöstietueet ja standardit, jotka on suunniteltu työkalujen hyödynnettäviksi.

• Kulttuuri, jossa kehittäjät ovat edelleen täysin vastuussa lopputuloksesta.

Tämä on raja tekoälyavusteisen koodauksen ja tekoälyavusteisen ohjelmistosuunnittelun välillä. Toinen tuottaa tuotosta, toinen ohjelmistoja.

Koodaus on halvempaa. Ohjelmistosuunnittelu on erottava tekijä.

Suhtaudun edelleen optimistisesti tekoälyyn ohjelmistokehityksessä. Se vähentää kitkaa, nopeuttaa oppimista, lievittää legacy-järjestelmien aiheuttamaa vaivaa ja tarjoaa tärkeän ensimmäisen luonnoksen, kun tyhjä sivu on vaikein lähtökohta.

En kuitenkaan voi sekoittaa nopeampaa koodin generointia parempaan ohjelmistosuunnitteluun. Tekoälyn aikakaudella menestyvät kehittäjät eivät ole niitä, jotka tuottavat eniten koodia. He ovat niitä, jotka osaavat muuttaa sekavan tarkoituksen turvallisiksi, toimiviksi ja ylläpidettäviksi järjestelmiksi. He osaavat määritellä ongelmat, rajata ratkaisut, varmistaa tuotokset ja kantaa vastuun seurauksista.

He käyttävät tekoälyä kiihdyttimenä, eivät tekosyynä lopettaa ajattelua.

Tekoäly kirjoittaa koodia. Insinöörit rakentavat ohjelmistoja. Tällä erolla on pian enemmän merkitystä kuin koskaan.