Copilot kirjoitti sen, mutta kuka omistaa sen? Hallintaraon insinööritiimit saattavat jättää huomiotta

Insinööri avaa Copilotin auttamaan koodin laatimisessa asiakkaan sivustolle. Vain sekunneissa hän saa koodin, jonka kirjoittaminen olisi aiemmin vaatinut merkittävästi enemmän aikaa käsin. Monille web‑kehittäjille ja yrityksille, jotka optimoivat verkkosivustojaan, on normaalia pohtia: onko tuo koodi luotettava? Onko se turvallinen? Tulisiko sitä tarkastella ennen käyttöönottoa?  Nämä kysymykset kaikki kuuluvat yhteen kysymykseen: Kuka on vastuussa AI‑avusteisesta koodauksesta? Ja, mikä tärkeintä, kuka omistaa tuottavuusvoiton?

Jos AI mahdollistaa insinööritiimin suorittaa enemmän työtä samassa ajassa, kaikki voivat hyötyä enemmän tästä taloudellisesta arvosta. Tämä voi olla kehittäjän säästämä aika, työnantajan saama lisäarvo säästetyistä tunneista tai asiakkaan saama se, mistä he ovat maksaneet, ylimääräisinä tunteina. Riippumatta siitä, miten säästetty aika hyödyttää, keskeinen kysymys on, miten työtä hallinnoidaan ja hinnoitellaan.

AI ja koodaus muuttuvat väistämättömiksi

AI‑koodausvälineet saavat nopeasti jalansijaa ja vakiintuvat valtavirran kehityksessä. 2025 Stack Overflow Developer Survey, 84 % vastaajista käytti tai suunnitteli käyttävänsä AI‑työkaluja kehitysprosessissaan.

Vaikka AI:n käyttöönotto web‑kehittäjien työnkulkuihin yleistyy, sen luotettavuudesta on edelleen epäilyksiä. Samassa kyselyssä 46 % ei luottanut täysin AI:n tuottaman sisällön tarkkuuteen, ja noin 66 % mainitsi AI‑ratkaisut, jotka olivat “lähes oikeita, mutta eivät täysin”, turhautumisen lähteenä.

AI‑koodauskeskustelu, joka muotoutuu, koskee enimmäkseen sen luotettavuutta, eikä sitä, luoko koodi enemmän arvoa ja kuka on vastuussa sen varmistamisesta.

AI rikkoo tunnin ja tuotoksen välistä suhdetta

Ohjelmistokehityksen palkkiot perustuivat aina oletukseen, että insinööritoiminnan tuotanto liittyy tiiviisti insinööri‑ponnistuksiin. Generatiivinen AI monimutkaistaa tätä yhtälöä.

Kontrolloitu kokeilu, jossa oli 95 kehittäjää, osoitti, että GitHub Copilotin käyttöön päässeet osallistujat suorittivat tietyn JavaScript HTTP -palvelintehtävän 55,8 % nopeammin kuin ilman pääsyä.

Tämä korostaa, että AI voi nopeuttaa kehitystä mahdollisesti tinkimättä laadusta. Nämä luvut ovat kuitenkin merkityksellisiä, koska kokeilu perustui hyvin tarkkaan ohjelmointitehtävään. Vaikka tehtävä suoritettiin nopeammin, se ei tarkoita, että Copilot tekisi koko insinööriorganisaation 55,8 % tuottavammaksi.

Toinen tutkimus havainnollistaa tätä ajatusta. kokeilu, jossa oli 96 kokopäiväistä Google‑ohjelmistosuunnittelijaa osoitti, että AI:n käyttävät kehittäjät suorittivat yritystason tehtävän noin 96 minuutissa, verrattuna 114 minuuttiin ilman AI:ta. Tutkijoiden säädetty arvio viittasi noin 21 % lyhennykseen suoritusaikaan. Tutkimus ei kuitenkaan tarkastellut AI‑koodin laatua, eikä se käsitellyt tasapuolisuuskysymyksiä teknologian riippuvuudesta.

Myös on näyttöä siitä, että AI hidastaa koodausaikaa. METR:n satunnaistutkimus sisälsi 16 kokenutta avoimen lähdekoodin kehittäjää, jotka työskentelivät 246 todellisessa ongelmassa tutummissa repositorioissa. Käyttäen vuoden 2025 alussa saatavilla olleita työkaluja, kuten Claude Sonnet 3.5 ja 3.7 sekä Cursor Pro, he kuluivat tehtäviinsä noin 19 % pidempään, vaikka monet olettivat näiden työkalujen säästävän aikaa.

Yhdessä nämä tutkimukset kumoavat odotukset, että AI mahdollistaisi kehittäjien työskentelyn nopeammin. Sen sijaan se tekee kehittäjien ajasta ja arvosta vähemmän ennustettavan yrityksille, jotka tarjoavat web‑työtä, ja asiakkaille, jotka sitä vastaanottavat.

Hinnoittelun ongelma, josta harva puhuu

Aika‑ ja materiaali (T&M) on yleinen malli web‑kehityksessä ohjelmistojen hankintaan, koska se vastaa toistuvaan alan ongelmaan: kehittyvään projektiin.

Tässä mallissa, sen sijaan että kaikki ominaisuudet tai tehtävät määriteltäisiin ennen kehityksen aloitusta, asiakkaat voivat maksaa insinööri‑aikaan projektin edetessä ja muuttuessa.

Kuitenkin AI aiheuttaa nykäyksiä tässä testatussa mallissa. Kun korvaukset sidotaan suoraan insinööri‑tunteihin, tehokkaampi kehitysaika voi johtaa vähemmän laskutettaviin tunteihin asiakkaalle. Jos AI tukee samoja tuloksia lyhyemmässä ajassa, teknologia voi luoda arvoa asiakkaille, mutta laskutettavien tuntien väheneminen merkitsee vähemmän tuloja tarjoajille.

Ratkaisu ei ole kannustaa kehittäjiä työskentelemään hitaammin. T&M‑malli kohtaa nyt rakenteellisen ongelman hinnoittelun ja kannustimien suunnittelussa. Tuntipalkkojen käyttäminen arvon määrittämiseen voi olla rajoittavaa. Ostaja saattaa tietää tarkalleen, mitä kukin insinööri‑tunti maksaa, mutta olla epävarma kokonaisinvestoinnista, joka tarvitaan halutun tuloksen saavuttamiseksi.

Kun AI muuttaa insinöörituotavuutta, kysymys voi siirtyä:

“Mitä kehittäjän tunti maksaa?” → “Mitä tapahtuu arvolle, kun vähemmän kehittäjän tunteja tarvitaan?”

METR:n löydökset monimutkaistavat tätä kysymystä. Jos kehittäjät uskovat säästävänsä aikaa, vaikka todellisuudessa vie se pidempään, ei AI:n omaksuminen eikä koettu tuottavuus riitä osoittamaan taloudellista arvoa. Siksi organisaatioiden on oltava hallinnossa, joka pystyy mittaamaan, mitä todella tapahtui.

Hallintaraossa on neljä omistajaa

AI‑avusteisen kehityksen hallinnasta keskusteleminen vaatii menoa pidemmälle kuin politiikat, jotka säätelevät, mitä työkaluja kehittäjät saavat käyttää.

Insinööriorganisaatioiden tulisi määritellä vähintään neljä omistajuuden tyyppiä.

1. Kuka omistaa koodin?

AI voi tuottaa toteutuksen, mutta se ei voi toimia tekosyynä vastuuttomalle kehitykselle. Joku on edelleen vastuussa koodin tarkastamisesta, testaamisesta ja hyväksymisestä ennen kuin se siirtyy tuotantovaiheeseen.

2. Kuka omistaa riskin?

Nopeampi koodi on arvokasta vain, jos se ei aiheuta ongelmia muualla. AI‑luodun koodin empiirinen tutkimus havaitsi turvallisuusheikkouksia 29,5 % tarkastelluista Python‑koodinpätkistä ja 24,2 % JavaScript‑koodinpätkistä. Tutkimus löysi myös heikkouksia 43 Common Weakness Enumeration -kategorian alueella.

Kuitenkin tutkimus havaitsi, että staattisen analyysin varoitusten syöttäminen takaisin Copilot Chatiin voisi korjata jopa 55,5 % tunnistetuista turvallisuusongelmista. Tutkimus osoittaa, miten AI voi luoda ja ratkaista koodausongelmia, mutta organisaatioilla täytyy olla prosessit, joilla määritellään, miten sen tuloksia validoidaan.

NIST:n SP 800‑218A heijastaa tätä periaatetta laajentamalla Secure Software Development Framework -kehyksensä parhailla käytännöillä, jotka käsittelevät generatiivista AI:ta ja kaksikäyttöisiä perusmalleja.

3. Kuka omistaa tuottavuusvoiton?

Kaupalliset sopimukset alusta alkaen ovat olennaisia määriteltäessä, kuka saa hyötyä tehokkuusvoitoista. AI voi auttaa asiakkaita kuluttamaan vähemmän, mahdollistaa tiimien toimittaa enemmän ohjelmistoja tai tarjota projektin lopussa ei taloudellista hyötyä. 

Mikä pysyy samana, on tarve läpinäkyville prosesseille ja laadukkaan, sovitun työn toimittamiselle.

4. Kuka omistaa priorisoinnin?

AI voi tehdä ominaisuuksien tuottamisesta halvempaa ja nopeampaa, mutta se ei voi päättää, ovatko ne tarpeellisia.

Itse asiassa kehityskapasiteetin kasvattaminen voi tehdä priorisoinnista tärkeämpää. Kun tiimit voivat rakentaa ja kokeilla nopeammin, jonkun on edelleen päätettävä, mitkä tulokset oikeuttavat käytettävissä olevan budjetin ja mitkä ideat tulisi hylätä.

AI‑hallinto muuttuu talouskysymykseksi

Nämä kysymykset tekevät AI‑hallinnosta yhä merkityksellisemmän. Kuvittele kaksi kehityskumppania, jotka veloittavat samankaltaisia tuntihintoja.

Toinen on integroinut AI:n vahvaan insinööri‑prosessiin ja saavuttaa vaaditun tuloksen huomattavasti nopeammin, kun taas toinen vie pidempään. Pelkkä tuntihintojen vertailu ei kerro ostajalle paljon prosesseista, joita he toteuttavat.

Ostajien on arvioitava:

• Kokonaisodotettu investointi
• Vastuu ylityksistä
• Laatukontrollit AI‑luodun työn ympärillä
• Miten tehokkuusvoittoja jaetaan

T&M voi edelleen olla hyödyllinen molemmille osapuolille, jos he tietoisesti hyväksyvät palveluiden epävarmuuden. Kiinteähintaiset sopimukset voivat myös toimia, kun vaatimukset ja toimitukset ovat vakaita.

AI kuitenkin tekee myös vaihtoehtoisista rakenteista tarkastelun arvoisia. Yksi lähestymistapa on asettaa enimmäisraja taloudelliselle budjetille samalla kun pidetään laajuus joustavana. Tämän jälkeen ominaisuuksia voidaan priorisoida liiketoiminta‑arvon mukaan kyseisessä mallissa.

Jos insinöörityö tehostuu, voitot voivat muuttua lisäominaisuuksiksi tuotteessa sen sijaan, että ne lisäisivät laskutettavaa aikaa. Kaupallisten kannustimien tulisi edistää samaa lopputulosta kuin insinööri‑kannustimet, luoden mahdollisimman hyödyllistä ohjelmistoa tehokkaasti.

Sama AI‑keskustelu

Insinööri‑johtajien on ymmärrettävä, miten kaupalliset kannustimet vaikuttavat toimitukseen. Talous‑ ja hankintatiimien on saatava riittävästi näkyvyyttä AI‑avusteiseen insinöörityöhön arvioidakseen, tuottaako väitetty tehokkuus mitattavaa arvoa.

Tämä tarkoittaa, että kypsä AI‑hallinto ei voi pysähtyä hyväksyttyihin mallilistoihin, turvallisuusvalvontaan, datapolitiikkoihin tai koodikatselmointivaatimuksiin. Sen on käsiteltävä vastuullisuutta, taloudellista riskiä, priorisointia ja tuottavuusvoittojen omistajuutta.

Mutta on toinen omistajuuskysymys, jolla voi olla paljon suurempi vaikutus teknologiabudjetteihin: Kuka omistaa arvon, joka syntyy tai menetetään, kun AI muuttaa ohjelmiston rakennusnopeutta?

Organisaatiot, jotka määrittelevät, tuottaako nopeampi insinööritiimi parempia tuotteita, hallitsevat investointeja ja saavuttavat mitattavissa olevia liiketoimintatuloksia, ovat ne, jotka pystyvät pysymään kilpailijoita edellä.

Jos kehitystiimisi ottaisi AI:n käyttöön huomenna, kertoisiko nykyinen hallintomalli ja kaupallinen malli edes, onko se tehnyt toimituksesta arvokkaampaa?