Tekoäly kirjoittaa koodia, mutta pystyykö infrastruktuurisi seuraamaan?

Elämme yhden historian outoummimmista käänteistä ohjelmistosuunnittelussa. Vuosikymmenien ajan tavoitteena oli determinismi; järjestelmien rakentaminen, jotka käyttäytyvät aina samalla tavalla. Nyt kerrostmme todennäköisyyspohjaisia tekoälyjärjestelmiä tähän perustaan, generoiden koodia hämmästyttävällä skaalalla ja nopeudella. Ja rehellisesti? Suurin osa infrastruktuuristamme ei ollut suunniteltu tätä varten.

Olen viettänyt vuosia työskentelemällä DevOps-työkaluilla, yhteiskirjoittamalla tutkimuksia ja auttamalla insinööritiimejä saavuttamaan huippusuorituksia. Mitä nyt näen tekoälyohjelmoinnissa, on enemmän kuin vain evoluutio. Se paljastaa jokaisen rakon olemassa olevissa työvirroissa.

Ongelma on jo täällä

Vuoden 2025 GitClear-tutkimus osoitti, että lähes 7 %:ssa commiteissa on nyt tekoälyllä generoitu koodi. Heidän aiempi analyysi 153 miljoonasta rivistä muuttuneesta koodista paljasti kustannukset: “koodin kierto” – koodi, joka kirjoitetaan uudelleen tai poistetaan kahden viikon kuluessa – kaksinkertaistui vuoteen 2024 verrattuna ennen tekoälyn vertailukohtiin.

Turvallisuusvaikutukset ovat yhtä dramaattiset. Viimeaikainen analyysi 80:sta kuratoidusta koodaus tehtävästä yli 100 suuren kielen mallin kautta osoitti, että tekoälyllä generoitu koodi tuo mukanaan turvallisuusongelmia 45 %:ssa tapauksista. Todellinen vaikutus? Joka viides CISO raportoi nyt merkittäviä tapahtumia, jotka johtuvat suoraan tekoälyllä generoidusta koodista.

Nopeusvoitot ovat todellisia, mutta myös stabiilisuuskustannukset ovat todellisia.

Vahvistusvaikutus

Yksi asia, jonka olen oppinut, on, että tekoäly vahvistaa kaikkea. Jos sinulla on hyvät käytännöt, tekoäly tekee niistä paremmat ja nopeammat. Jos prosessisi on sekava, tekoäly korostaa sekavuutta myös. Tämä heijastaa kuviota, joka näkyy vuosi vuodelta DORA:n vuosittaisissa DevOps-raporteissa: vähemmän muuttujia johtaa parempiin tuloksiin. Onnistuneet tiimit standardoivat vähemmän käyttöjärjestelmiä, vähemmän ohjelmointikieliä, vähemmän tapoja tekemiseen. He vähentävät monimutkaisuutta tarkoituksella.

Tekoälyagentit seuraavat samaa kuviota. Anna heille yhdenmukainen ympäristö, jossa Python tarkoittaa samaa versiota jokaisen kehittäjän koneessa, jossa riippuvuudet on lukittu ja seurattu, ja he menestyvät. Pakota heidät navigoimaan 17 eri konfiguraatiota, joissa on hienoisia eroja, ja poltat tokenit ympäristön erityispiirteiden selvittämiseen sen sijaan, että ratkaiset itse ongelmia.

Determinismin paradoksi

Tämä luo mielenkiintoisen jännitteen. Vuosien ajan tietokoneiden tieteessä determinismiä pidettiin lopullisena tavoitteena. Nyt suoritamme todennäköisyyskuormia, tekoälymalleja, jotka eivät voi taata samaa tulosta kahdesti, järjestelmiä, jotka on suunniteltu ennustettavuutta varten.

Vastaukseni? Pitäkää niin paljon pinosta kuin mahdollista deterministisenä. Jos voit ylläpitää 80 %:a infrastruktuuristasi deterministisenä tasolla, tekoälyagentit ovat vähemmän muuttujia hallitsemaan. Ne eivät kuluta kontekstiruutuja “Miksi tämä riippuvuus ei asentunut?” tai “Anna minun yrittää tätä käännös-komentoa uudelleen.” Ne ovat keskittyneet itse työhön, jonka pyydät heitä tekemään.

Ajattele: kun agentti yrittää kääntää jotain ja nativi-laitteiston sidokset epäonnistuvat, koska ImageMagick ei ole asennettu, se on token-kallinen kierros. Jos ympäristösi sisältää jo kaiken tarvittavan (kääntäjät, kirjastot, koko riippuvuuspuu aina libc:hen asti), agentti toimii. Ei debuggausta, ei koetta ja virhettä, vaan edistystä.

Määrittely ja validointi ovat avainasemassa

Mitä nyt selviää, on, että tekoälyohjelmointi pakottaa meidät ajattelemaan tarkemmin kahta historiallisesti aliarvostettua taitoa: määrittely ja validointi. Sinun on määriteltävä, mitä oikeasti rakennat, ja sinun on oltava robusteja keinoja vahvistaa, että saat sen.

Olen huomannut jotain mielenkiintoista: ihmiset, joilla on tuotepäällikkö- tai tuote-insinööritausta, ovat usein menestyksekkäämpiä tekoälyagentien kanssa tällä hetkellä. He ovat jo koulutettu ajattelemaan vaatimusten, onnistumisperusteiden ja kompromissien kautta. He ovat mukavia kysymään “Miksi teit tämän valinnan?” ja sopeuttamaan perustelun mukaan.

Validointi, tietäminen, onko asia oikein, on aina ollut ohjelmistosuunnittelun vaihin ainuttelinen ongelma. QA on ollut rikos ja aliarvostettu vuosikymmenien ajan, mutta se on haasteellisin osa: määrittäminen, ratkaiseeko ohjelmisto todellisen käyttäjän tarpeen. Tekoäly ei ratkaise tätä. Jos mikä, se tekee siitä kriittisemmän, koska nyt validoit todennäköisyyslähtöisiä tuloksia determinististen vaatimusten vastaisesti.

Luo luottamus, mutta tarkista (ja ohjaa)

On olemassa tietty mielentila, jota olen alkamassa omaksua: meidän pitäisi olettaa, että tekoälyllä generoitu koodi on vihamielinen, kunnes se on osoitettu toisin. Ei siksi, että tekoäly on pahantahtoinen, vaan siksi, että emme tiedä. Emme voi tarkastaa jokaista riviä, kun agentit generoivat tuhansia rivejä päivässä.

Tämä tarkoittaa valvontapisteiden siirtämistä. Jos emme voi estää kaikkea kehityksen aikana, meidän on oltava vahvempi valvonta suoritusajan aikana. Operaatoreiden, SRE:iden, alustatiimien, kenenkään, joka on vastuussa tuotannosta, on oltava parempi näkyvyys siihen, mitä suoritetaan, täydellinen riippuvuuden seuranta ja selkeä periytyminen jokaiselle artefaktille.

Tässä toistettavuus tulee olennaiseksi. Kun voit matemaattisesti osoittaa, että artefakti, jonka testasit paikallisesti, on identtinen sille, joka suoritetaan tuotannossa – sama syöte, sama tuloste, sama riippuvuus – voit aloittaa älykkäiden päätösten tekemisen. Ehkä et tarvitse suorittaa yksikkötestejä CI:ssä, jos olet jo suorittanut ne paikallisesti eikä mitään ole muuttunut. Ehkä voit kartoittaa testikattavuutta koodin muutoksiin ja ohittaa merkityksettömät testisarjat.

Mitä seuraa

Olemme käännekohtaa. Tiimit, joilla on jo hyvät käytännöt, näkevät massiivisia tuottavuusvoittoja tekoälyllä. Tiimit, jotka kamppailivat, kamppailevat nyt nopeammin.

Infrastruktuuri, joka mahdollistaa tekoälyohjelmoinnin, on rakennettava toistettavuutta varten alusta alkaen. Ei lisätty myöhemmin skannaus työkaluilla ja tarkastuksilla, vaan leivottu siihen, miten kehittäjät työskentelevät päivästä yksi. Kun kehitysympäristösi on identtinen Macilla ja Linuxilla, kun jokainen riippuvuus on seurattu ja lukittu, kun sinulla on täydellinen periytyminen jokaiselle artefaktille, tekoälyagentit muuttuvat voimakkaiksi moninkertaisiksi sen sijaan, että ne aiheuttavat kaaosta.

Tässä on suurin neuvoni tiimeille, jotka yrittävät menestyä tekoälyn aikakaudella:

• Standardisoi armotta. Vähemmän muuttujia korreloi parempaan suorituskykyyn. Lukitse teknologiapinoksi, pakota yhdenmukaiset ympäristöt kaikilla alustoilla ja poista konfiguraatiomuutokset ennen kuin tekoäly vahvistaa sen. Jos Pythonin version epäonnistumiset aiheuttavat ongelmia nyt, ne aiheuttavat 10-kertaiset ongelmia, kun tekoäly generoi koodia laajassa mittakaavassa.

• Rakenna validointi työvirraasi, ei loppuun. Kun tekoäly generoi koodia nopeammin kuin ihmiset voivat tarkastaa sitä, et voi riippua pelkästään manuaalisesta koodin tarkastelusta. Toteuta automaattinen testaus, joka validoi, että koodi ei ainoastaan suorita, vaan ratkaisee todellisen vaatimuksen. Tee CI/CD-putkistostasi turvallisuusverkon, jossa on vahvat portit suoritusajan aikana tuotannon käyttöönottoja varten.

• Panosta toistettavuuteen infrastruktuurina. Käsittele ympäristön yhdenmukaisuutta ensisijaisena infrastruktuurin huolenaiheena. Kun voit matemaattisesti osoittaa, että paikallinen ympäristö, CI-ympäristö ja tuotantoympäristö ovat identtisiä, poistat koko luokan “toimii minun koneellani” -ongelmia. Tämä deterministinen perusta on se, joka mahdollistaa turvallisen kerroksen todennäköisyyskuormia päälle.

Kysymys ei ole siinä, kirjoittaisiko tekoäly suurimman osan koodistamme. Se jo tekee sitä monille tiimeille. Kysymys on siinä, pystyykö infrastruktuurimme seuraamaan.