Jos tekoäly olisi ollut olemassa alusta alkaen: Halvempi koodi ei tehnyt päätöksentekoa helpommaksi

Suurimman osan ohjelmistojen historian ajan kallein osa oli niiden rakentaminen. Tiimit viettivät kuukausia ideoita toimivaksi koodiksi, ja se vaikutti kaikkeen työn organisointiin.

Tiekartat suunniteltiin insinöörien kapasiteetin mukaan; arkkitehdit ansaitsivat paikkansa pöydässä, koska he ymmärsivät järjestelmiä, joita kukaan muu ei ymmärtänyt; tuotepäälliköt viettivät viikkojaan epämääräisten liiketoimintapyynnösten kääntämiseen joksikin, mihin kehittäjä voisi toimia. Ohjelmiston kirjoittaminen oli pullonkaula, ja luonnollisesti kirjoittaminen oli siellä, missä vaikutusvalta asui.

Se ei ole enää totta, ja muutos on tapahtunut nopeammin kuin useimmat teknologiajohtajat ovat ehtineet sulatella.

Tekoälykoodausvälineet ovat romahduttaneet toteutuksen kustannukset. Niinpä työ, joka vei aiemmin joukkueelta viikkoja, kestää nyt agentilta vain pari tuntia. Ja selvä oletus oli, että nopeampi rakentaminen kääntyisi suoraan nopeammaksi arvon toimittamiseksi.

Mikä on todella tapahtunut, on kuitenkin monimutkaisempaa: tiimit voivat nyt tuottaa enemmän ohjelmistoa kuin he tietävät, mitä tehdä, ja se, mikä hidastaa heitä, on hiljalleen siirtynyt jonnekin muualle.

“Et voi soveltaa tekoälyä rikkoontuneeseen prosessiin”, sanoi Pablo Gamba, teknologian johtaja intivessä, globaalissa ohjelmisto- ja tekoälyratkaisujen startupissa. “Se on kuin antaa työntekijälle nopeampi lapio. Hän työskentelee nopeammin, mutta vain väärään suuntaan.”

Nopeampi toteutus, sama vanha rajoitus

Jokainen suuri teknologinen muutos – internet, pilvi ja ulkoistaminen – on seurannut samanlaista muotoa. Jokin, mikä oli aiemmin kallista, tuli lähes yötä päivää halvemmaksi, ja kaikki, mitä yritys oli rakentanut sen kalliin oletuksen varaan, piti purkaa ja rakentaa uudelleen.

Tällä kertaa se, mikä tulee halvemmaksi, on sovellettu tekninen älykkyys itse, joka juuri sattuu olemaan se, mihin palveluyritykset ja insinööritiimit ovat viettäneet vuosikymmenet laskemalla, Gamba väittää.

Halvempi toteutus ei kuitenkaan poista rajoitusta. Se siirtyy vain jonnekin vähemmän näkyvään. Koodauspullonkaula esimerkiksi on nopeutunut toteutuksessa, mutta este on nyt koodin tarkastelussa. Automaattinen koodin tarkastelu paljastaa ongelmia testauksessa ja käyttöönotossa; automaattinen testaus ja käyttöönotto paljastavat lopulta ongelman siinä, mitä ihmiset kirjoittavat agenttien työskentelemiseksi.

Koska agentti voi rakentaa vain sen, mitä on kuvattu tarkasti riittävästi toimimaan ilman arvaamista.

Se on ansa, johon moni tiimi juuri nyt kulkee, usein ilman huomautta. Jos voit rakentaa melkein mitä tahansa paljon lyhyemmässä ajassa kuin aiemmin, virheellisen rakennuksen kustannukset kasvavat, eivätkä laske, koska huomaat virheesi nopeammin ja enemmän jo toimitettuna.

Oletus, joka aiemmin tuli esiin hitaasti, useiden viikkojen aikana, voidaan nyt tehdä latausinfrastruktuuriksi ennen kuin kukaan ehtii kyseenalaistaa sitä. Priorisointi, ei raakatuotanto, päättää lopulta, maksavatko tekoälysijoitukset itsensä.

Gamban mukaan yritysten tulisi seurata kehityksen nopeutta, mutta myös koko sykliä aikomuksesta tuotantoon. “Jos parannat kehityksen nopeutta, mutta laadunvarmistus on pullonkaula, olet vain saavuttanut laadunvarmistuksen nopeammin. Sitten korjaat laadunvarmistuksen ja pullonkaula siirtyy vaatimuksiin”, hän sanoi.

Luvut tukevat hänen väitettään. Fortune 50 -yritykset, jotka käyttävät tekoälyavusteista kehittämistä, toimittavat commiteja 3-4 kertaa nopeammin kuin heidän kilpailijansa, Cloud Security Alliancen tutkimuksen mukaan, mutta esittävät uusia turvallisuustuloksia noin kymmenen kertaa nopeammin.

Nopeus ilman selkeää määränpäätä ei ainoastaan haaskaa ponnistelua; se kasvattaa riskiä nopeammin kuin useimmat turvallisuustiimit voivat pitää tahtia.

Vaatimusten saattaminen kielen, jonka tekoäly voi hyödyntää

Jos määrittely on siellä, missä todellinen rajoitus nyt on, korjaus ei ole enemmän dokumentaatiota. Se on erilainen dokumentaatio, kirjoitettu muodossa, jota tekoälyjärjestelmä voi suorittaa ilman, että se täyttää itse aukot.

Se tarkoittaa vaatimusdokumentin eläköitymistä, joka on kirjoitettu ihmisen tulkittavaksi ja korvaamista rakenteellisilla hyväksymiskriteereillä, eksplisiittisillä toimialamalleilla ja sopimustesteillä, jotka määrittelevät, mitä ominaisuus ei saa tehdä yhtä selvästi kuin mitä se saa tehdä.

Agentit täyttävät epäselvyyden samalla tavoin kuin nuori insinööri. Ero on, että jälkimmäisen arvaus tulee varmuuden kanssa, lippu seniorille, tunne, että jotain voi olla pielessä.

Agentin arvaus ei näytä siltä. Se näkyy puhdas, sujuva, täysin muodostunut koodi, ja siinä ei ole varauksia, vaikka se on väärin.

Kirjoittaminen spesifikaatiota, joka on tarpeeksi tarkka selviytymään tästä aukosta, alkaa tuntua vähemmän kuin tuotteen luonnostelusta ja enemmän kuin sopimuksen luonnostelusta. Nimität jokaisen toimijan, kartoitat jokaisen systeemin salliman tilanvaihdon ja huomioit tilanteet, joita useimmat vaatimusdokumentit jättävät hiljaisesti onnelliselle polulle.

Tiimit, jotka kohtelevat tätä dokumentaatiotehtävänä, oppivat vaikealla tavalla, että epämääräinen aikomus tuottaa vain epämääräistä ohjelmistoa koneen nopeudella.

Tiimit, jotka todella saavuttavat tuottavuuden hyödyt, kohtelevat tällaista spesifikaatiokirjoitusta omana insinööritieteellisenä tieteenään, samalla versionhallinnalla, tarkastuskiertoja ja testausvaatimuksilla, jotka aiemmin oli varattu koodille itselleen.

Gamban sanoissa tekoälyalkuperäinen ei ole lupaa ohittaa prosessi, vaan vaatimus suunnitella alusta alkaen. “Monet organisaatiot yrittävät soveltaa tekoälyä vanhoihin prosesseihin. Se ei ole muutos. Tekoälyalkuperäiset organisaatiot aloittavat toisella kysymyksellä: jos tekoäly olisi ollut olemassa alusta alkaen, miten suunnittelisimme tämän prosessin tänään?”

Takaisinvarastojen johtajat, aikomusten kuraattorit

Tuote, arkkitehtuuri ja insinöörit toimivat aiemmin kolmena erillisenä toimintona siistillä luovutuksilla heidän välillään: tuote päättää, mitä rakentaa, arkkitehtuuri keksii, miten, ja insinöörit toimittavat sen.

Kun toteutus tulee halvemmaksi ja nopeammaksi, nämä luovutukset muuttuvat koko ketjun hitaimmaksi osaksi. Se, mikä lopulta merkitsee, on se, kuka voi pitää koko kuvaa kerran, kääntää aikomusta tekoälylle suoritettavaksi ja pyydystää virheellisen oletuksen ennen kuin se muuttuu toimitetuksi koodiksi, jota kukaan ei halunnut.

Tämä uudelleensuunnittelu muokkaa hiljalleen sitä, kuka määrittelee, ja mitä työ on enää.

“Ajattele, mitä tapahtuu ohjelmistosuunnittelijan roolille. He eivät enää kirjoita vain koodia. He valvovat agenttien tuotosta, määrittelevät spesifikaatioita, valmistavat testejä, validoi tuloksia. Se on yhdistänyt kolmea aiempaa roolia yhteen”, Gamba sanoi.

Toisin sanoen, se, mikä on arvokasta nyt, ei ole tietäminen, miten kirjoittaa lippu tai suorittaa sprintti. Se on tietäminen, mitä “hyvä” näyttää ennen työn aloittamista, kyky erottaa se, mikä on älyllisesti mielenkiintoista, ja se, mitä asiakkaat todella tarvitsevat, ja rohkeus tappaa idea nopeasti, kun se ei selvästi ylitä kyseistä kynnystä.

Nämä ovat tuomiovaltaisia päätöksiä, jotka aiemmin jakautuivat tuotepäällikön, arkkitehdin ja teknisen johtajan välillä vertailemalla muistiinpanoja. Ne päätyvät yhä useammin sille, joka on lähinnä määrittelemässä työtä ensimmäisenä.

Ja on myös muistettava: mikään näistä ei tee nimistä häviävän. Mutta rivit heidän välillään tulevat yhä vaikeammaksi puolustaa, kun taas ihmiset, jotka menestyvät epäselvyydessä, ovat ne, jotka toimivat aikomusten kuraattoreina.

Nopea toteutus ilman suojavarusteita ei ole voitto

On yksi riski, joka on helppo menettää näkyvistä, kun aikomus on selvä ja tekoälyputki on oikeasti toimiva: nopea, hyvin määritelty toteutus voi edelleen esittää virheitä, joita hitaampi, enemmän ihmisten välittämä prosessi olisi pyydystänyt melkein vahingossa.

Luvut eivät ole edes lähellä. Veracoden kevään 2026 testaus johtavista malleista osoitti, että vain 55 % koodigeneraattoritehtävistä tuotti turvallisen tulosteen, kun ei ollut nimenomaista turvallisuusohjeistusta, luku, joka ei ole muuttunut juuri lainkaan kahdessa vuodessa, vaikka toiminnallinen tarkkuus on loikannut merkittävästi.

On selvää, että oikean syntaksin saaminen oikein lopetti olemasta vaikea osa jonkin aikaa sitten. Tuomiovaltaiset päätökset, joita ihmisinsinööri aiemmin teki vaistomaisesti kirjoittaessaan, turvallisuudesta, yhdenmukaisuudesta ja siitä, mitä tietoa ei pitäisi koskea mihinkään järjestelmään, ovat osia, jotka on vaikea korvata.

Tämä tarkoittaa, että sama tarkkuus, jota sovelletaan määrittelemään, mitä rakentaa, on sovellettava määrittelemään, mitä on kielletty, kuten yhdenmukaisuusrajoitukset, tietojen käsittelysäännöt ja eettiset rajoitukset, joita on määritelty samalla huolellisuudella kuin toiminnalliset vaatimukset.

Jättäminen implisiittiseksi ja toivo, että agentti johtaa ne oikein, on sama virhe kuin jättäminen tuotteen vaatimukset epämääräisiksi ja ristimällä sormet, jotta se jotenkin sujuu hyvin.

Mitä johtajuus näyttää

Mitään tätä ei voida väittää tekoälynopeutetun kehittämisen vastaan; rakentaminen ei ole koskaan ollut nopeampaa tai halvempaa, eikä sitä voida palauttaa pulloon.

Mikä ei ole helpompaa, ja voidaan väittää, että se on vaikeampaa, on päättäminen oikean tarkkuuden kanssa, mitä on arvoa rakentaa, kuvaaminen tarpeeksi hyvin tekoälylle uskollisesti suoritettavaksi ja piirtäminen

At the enterprise level, the teams pulling ahead aren’t the ones with the fastest coding agents, that part’s clear. It’s those who worked out, before their competitors did, that definition was always going to be the harder problem – and started treating it that way.