Tekoäly kirjoittaa koodia, mutta pystyykö infrastruktuurisi pitämään perässä?

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 kerrosmme todennäköisyyspohjaisia tekoälyjärjestelmiä perustaan, generoiden koodia hämmästyttävällä skaalalla ja nopeudella. Ja rehellisesti? Useimmat infrastruktuurimme eivät ole suunniteltu tätä varten.

Olen viettänyt vuosia työskentelemällä DevOps-työkaluissa, yhteiskirjoittamalla tutkimuksia ja auttamalla insinööritiimejä saavuttamaan korkeimman suorituskyvyn. Mitä nyt näen tekoälyohjatuissa kehityksissä, on enemmän kuin vain evoluutio. Se paljastaa jokaisen rakon olemassa olevissa työnkulkujemme.

Ongelma on jo täällä

Vuoden 2025 GitClear-tutkimus osoitti, että lähes 7 %:ssa commiteissa on tekoälyllä generoitu koodia. Heidän aikaisempi 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 aikakauden perustasoihin.

Turvallisuusvaikutukset ovat yhtä dramaattisia. Viimeisin analyysi 80:sta koodaus-tehtävästä yli 100 suuren kielen mallissa osoitti, että tekoälyllä generoitu koodi esittää turvallisuusriskejä 45 %:ssa tapauksista. Todellinen vaikutus? Viimeisin analyysi osoitti, että tekoälyllä generoitu koodi on nyt yhden viidestä tietoturvaloukkauksesta aiheuttava tekijä, mutta kehittäjät ja turvallisuusjohtajat uskovat, että teknologia tulee lopulta toimimaan.

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

Vahvistusvaikutus

Yksi asia, jonka olen oppinut, on, että tekoäly vahvistaa kaiken. Jos sinulla on hyvät käytännöt, tekoäly tekee ne paremmiksi ja nopeammiksi. Jos prosessisi on sekava, tekoäly korostaa sekavuutta. Tämä heijastaa mallia, joka ilmestyy 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älyjärjestelmät seuraavat samaa mallia. Anna heille yhdenmukainen ympäristö, jossa Python tarkoittaa samaa versiota jokaisen kehittäjän koneella, jossa riippuvuudet ovat lukittu ja seurattu, ja he menestyvät. Pakota heidät navigoimaan 17 eri konfiguraatiota, joissa jokaisessa on hienoisia eroja, ja poltat tokenit ympäristöä koskevien ominaisuuksien selvittämiseen sen sijaan, että ratkaiset todellisia ongelmia.

Determinismin paradoksi

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

Vastaukseni? Pitäkää mahdollisimman paljon pinosta deterministisenä. Jos voitte ylläpitää 80 %:a infrastruktuuristanne deterministisenä tasolla, tekoälyagentillanne on vähemmän muuttujia hallitsemista. Ne eivät kuluta kontekstiaikaa “Miksi tämä riippuvuus ei asentunut?” tai “Anna minun yrittää tätä käännös-komentoa uudelleen.” Ne keskittyvät todelliseen työhön, jonka pyydätte niiden tekemään.

Ajattele: kun agentti yrittää kääntää jotain ja alkuperäiset sidokset epäonnistuvat, koska ImageMagick ei ole asennettu, se on token-kallista kiertotietä. Jos ympäristössänne on jo kaikki tarvittava (kääntäjät, kirjastot, koko riippuvuuspuu aina libc:hen asti), agentti vain toimii. Ei debuggausta, ei koetta ja virhettä, vain edistystä.

Määrittely ja validointi ovat avainasemassa

Mitä nyt selviää, on, että tekoälyohjattu kehitys pakottaa meidät ajattelemaan tarkemmin kahta historiallisesti aliarvostettua taitoa: määrittelyä ja validointia. Tarvitsette selkeän kuvauksen siitä, mitä oikeasti rakennatte, ja tarvitsette vahvat tavat vahvistaa, että saavutitte sen.

Olen huomannut mielenkiintoisen asian: ihmiset, joilla on tuotepäällikkö- tai tuote-insinööritausta, ovat usein menestyksekkäämpiä tekoälyagenttien 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 sen perustelun mukaan.

Validointi, tietäminen, onko asia todella oikein, on aina ollut ohjelmistosuunnittelun vaihinainen ongelma. QA on ollut rikosluonteisesti 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ä vielä kriittisempää, koska nyt vahvistatte todennäköisyyspohjaisia tulosteita determinististen vaatimusten vastaisesti.

Luota, mutta tarkista (ja ohjaa)

On olemassa tietty asenne, jota olen alkamassa omaksua: meidän pitäisi olettaa, että tekoälyllä generoitu koodi on vihamielinen, kunnes se on osoittautunut toisin. Ei siksi, että tekoäly on pahantahtoinen, vaan siksi, että emme vain 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 kehitysaikana, tarvitsemme vahvempia valvontaa suoritusaikana. Operaatoreiden, SRE:iden, alustatiimien, kenenkään, joka on vastuussa tuotannosta, on oltava parempi näkyvyys siitä, mitä suoritetaan, täydellinen riippuvuuden seuranta ja selkeä alkuperä jokaiselle artifactille.

Tässä toistettavuus tulee oleelliseksi. Kun voitte matemaattisesti osoittaa, että artifact, jonka testasitte paikallisesti, on identtinen sille, joka suoritetaan tuotannossa – samat sisääntulot, samat tulostulot, sama riippuvuuden sulkeminen – voitte aloittaa älykkäiden päätösten tekemisen. Ehkä et tarvitse uudelleenajaa yksikkötestejä CI:ssä, jos olet jo suorittanut ne paikallisesti eikä mitään muutosta ole tapahtunut. Ehkä voit kartoittaa testikattavuutta koodin muutoksiin ja ohittaa merkityksettömät testisarjat.

Mitä seuraavaksi

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

Infrastruktuuri, joka mahdollistaa tekoälyohjatun kehityksen, on rakennettava toistettavuutta varten alusta alkaen. Ei kiinnitettyä skannaus- ja tarkastustyökaluilla myöhemmin, vaan leivottu siihen, miten kehittäjät työskentelevät päivästä yhdestä. Kun kehitysympäristö on identtinen Mac- ja Linux-järjestelmissä, kun jokainen riippuvuus on seurattu ja lukittu, kun sinulla on täydellinen alkuperä jokaiselle artifactille, tekoälyagentit muuttuvat voimamonoiksi sen sijaan, että ne aiheuttavat kaaosta.

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

• Standardisoi armotomasti. Vähemmän muuttujia korreloi suuremman suorituskyvyn kanssa. Lukitse teknologiapinssi, pakota yhdenmukaiset ympäristöt kaikilla alustoilla ja poista konfiguraatioiden siirtymä ennen kuin tekoäly vahvistaa sen. Jos Pythonin versio-eros ongelma nyt, se aiheuttaa 10-kertaisen enemmän ongelmia, kun tekoäly generoi koodia suuressa mittakaavassa.

• Rakenna validointi työnkulkuun, ei loppuun. Kun tekoäly generoi koodia nopeammin kuin ihmiset voivat tarkastaa sitä, et voi luottaa vain manuaaliseen koodin tarkastukseen. Toteuta automaattinen testaus, joka validoi, että koodi ei vain suorita, vaan ratkaisee todellisen vaatimuksen. Tee CI/CD-putki turvallisuusverkkosi, vahvoilla portilla suoritusaikana tuotannon käyttöönottoja varten.

• Panosta toistettavuuteen infrastruktuurina. Käsittele ympäristön yhdenmukaisuutta ensisijaisena infrastruktuurin huolenaiheena. Kun voitte matemaattisesti osoittaa, että paikallinen ympäristö, CI-ympäristö ja tuotantoympäristö ovat identtisiä, poistatte koko “toimii minun koneellani” -ongelman luokan. Tämä deterministinen perusta on se, joka mahdollistaa turvallisen kerroksen todennäköisyyspohjaisia tekoälytyökuormia.

Kysymys ei ole siinä, kirjoittaako tekoäly suurimman osan koodistamme. Se jo tekee sitä monille tiimeille. Kysymys on siinä, pystyykö infrastruktuurimme pitämään perässä.