”Tekoäly tulee viemään työsi” -otsikot ovat olleet uuvuttavia – erityisesti, jos olet ohjelmistoinsinööri. Mutta kuten Cortex.io:n perustaja Anish Dhar selittää, insinöörityö ei ole kuolemassa, vaan kehittymässä. Tässä jaksossa Hannah keskustelee Anishin kanssa siitä, mitä insinöörityön erinomaisuus todella tarkoittaa vuonna 2025, miksi kehittäjien tuottavuuden mittaaminen ymmärretään yhä pahasti väärin ja mikä rooli tekoälypohjaisilla koodaustyökaluilla on tuotantomittakaavan järjestelmien todellisessa maailmassa. Juonipaljastus: miljoonan käyttäjän saavuttamiseen ei pääse pelkällä tunnelmakoodauksella.
Anish hyödyntää kokemuksiaan Uberilta ja Cortexilta eritellessään, kuinka insinöörijohtajat voivat paremmin yhdistää tekniset aloitteet liiketoiminnan tuloksiin, ottaa tekoälyn käyttöön tinkimättä koodin laadusta ja välttää tempautumisen mukaan hypejaksoihin, jotka eivät palvele organisaatiota.
Mitä opit
- Miksi ”insinöörityön erinomaisuus” ulottuu paljon kehittäjäkokemusta pidemmälle
- Kuinka tekniset aloitteet yhdistetään suoraan liiketoiminnan tavoitteisiin
- Panosten ja tuotosten mittareiden välinen ero insinöörityön tuottavuutta mitattaessa
- Missä Copilotin ja Cursorin kaltaiset tekoälypohjaiset koodaustyökalut ovat aidosti hyödyllisiä – ja missä ne jäävät vajaiksi
- Tekoälyn tuottaman koodin skaalaamisen piilevät riskit ilman selkeää omistajuutta ja valvontaa
Tärkeimmät opit
- Insinöörityön erinomaisuus alkaa liiketoiminnan tavoitteiden mukaisuudesta. Teknisten tiimien tulisi yhdistää työnsä suoraan tavoitteisiin, kuten markkinoilletuontiaikaan, asiakaskokemukseen ja operatiiviseen tehokkuuteen.
- Tuotosmittarit eivät yksin riitä. Käyttöönottojen tiheyden tai DORA-pisteiden kaltaiset mittarit tarjoavat pintapuolisen kuvan. Panosmittarit – kuten tuotantovalmiuden tarkistuslistat, testikattavuus ja häiriöprosessit – edistävät todellisuudessa pitkäaikaista kehitystä.
- Tekoälytyökalut auttavat iteroinnissa, eivät tuotantomittakaavassa. Koodiavustajat sopivat erinomaisesti prototyyppien tekemiseen ja nopeuttamiseen, mutta ne eivät ole vielä valmiita käsittelemään yritystason järjestelmien monimutkaisuutta. Ne ovat juniorikehittäjiä, eivät seniori-insinöörejä.
- Omistajuus on tärkeämpää kuin koskaan. Tekoälyn kiihdyttäessä koodin luomista selkeä omistajuus ja näkyvyys ovat olennaisia laadun, turvallisuuden ja luotettavuuden ylläpitämiseksi.
- Ota tekoäly käyttöön harkitusti. Älä osta lisenssejä massoittain FOMO:n vuoksi. Tiedä, miksi otat työkaluja käyttöön, ja mittaa niiden liiketoimintavaikutusta ajan mittaan.
Jaksot
- [00:00] Insinöörityö ei ole kuollut – se aikuistuu
- [01:20] Anishin matka: Uberilta Cortexille
- [02:59] Insinöörityön erinomaisuuden määrittely
- [05:08] Viitekehys: liiketoiminnan tavoitteiden mukaisuus ja neljä C:tä
- [07:34] Tuottavuusmittareiden uudelleenarviointi
- [09:40] Panosmittarit ja tuotosmittarit
- [13:18] Tunnelmakoodauksen rajat
- [16:37] Kuinka johtajien tulisi arvioida tekoälyinvestointeja
- [20:48] Valvonta, omistajuus ja tekoälyn riskit mittakaavassa
- [27:06] Mistä löydät Anishin ja lisätietoa Cortexista
Tutustu vieraaseemme
Anish Dhar on Cortexin toinen perustaja ja toimitusjohtaja. Cortex on sisäinen kehittäjäportaali, joka auttaa insinööritiimejä luetteloimaan, pisteyttämään ja parantamaan mikropalveluitaan ja pilvi-infrastruktuuriaan. Se vastaa haasteisiin, jotka Anish tunnisti työskennellessään insinöörinä Uberilla, jossa hän työskenteli Uber Eatsin ja Jumpin parissa. Hän käynnisti Cortexin sivuprojektina vuoden 2019 puolivälissä ja siirtyi nopeasti työskentelemään sen pariin kokoaikaisesti hankkien merkittävää rahoitusta, mukaan lukien tähän mennessä saadut 53 miljoonan dollarin rahoitukset. Ennen Cortexia Anish työskenteli vaativissa insinööritehtävissä Uberilla ja perusti yhdessä startup-yrityksiä, kuten Divtera Capitalin ja Homeroomin, hyödyntäen syvällistä asiantuntemustaan ohjelmistokehitystä sujuvoittavien ja järjestelmien luotettavuutta parantavien työkalujen rakentamiseen.
Tämän jakson resurssit:
- Tilaa The CPO Clubin uutiskirje
- Verkostoidu Anishin kanssa palveluissa LinkedIn ja X
- Tutustu Cortex.io:hon
- IDPCON – sisäisille kehittäjäportaaleille omistettu paikan päällä järjestettävä tapahtuma
Aiheeseen liittyvät artikkelit ja podcastit:
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Hannah Clark: On muodostunut vitsiksi, että tekoälyn aikakausi on johtanut jokaisen teknologia-alan työpaikan tuhoon. Itse asiassa tänä vuonna on kuollut niin monia työpaikkoja, että olen yllättynyt, ettei minua ole kutsuttu useampiin hautajaisiin. Tuotehallinta on kuollut, käyttäjätutkimus on kuollut ja kaikista räikeimpänä tapauksena ohjelmistokehitys on kuollut. Saatan saarnata kuorolle, mutta kuka tahansa, joka todella uskoo ohjelmistokehityksen kuolleen siksi, että ystävällinen naapuruston suuri kielimalli osaa kirjoittaa koodia, ei todellakaan itse ole ohjelmistokehittäjä.
Tämän päivän vieraani, Cortex.ion perustaja Anish Dhar, väittäisi jopa, ettei tekninen työ ole todellakaan kuollut. Se on vain aikuistumassa. Aiemmin Uberilla ohjelmistokehittäjänä työskennellyt Anish perusti Cortexin helpottamaan monimutkaisten koodikantojen ymmärtämistä. Itse ohjelmistokehittäjänä ja henkilöinä, jonka käyttäjiä ovat ohjelmistokehittäjät, hän näkee tällä alalla teknisen erinomaisuuden kehittyvän sekä uuden ja vanhan mittaustavan olevan irtautumassa toisistaan. Keskustelimme uuden sukupolven ajattelusta teknisen erinomaisuuden mittaamisessa ja arvioinnissa sekä rohkeasta näkemyksestä siitä, miten tunnelmakoodauksen villitys sopii tähän keskusteluun. Aloitetaan.
Niin, ja muuten: käymme tällaisia keskusteluja joka viikko, joten jos tämä kuulostaa kiinnostavalta, mikset tilaisi ohjelmaa? Hyvä, aloitetaan.
Tervetuloa takaisin The CPO Club -podcastiin. Tänään seurassani on Anish Dhar. Hän on Cortex.ion perustaja.
Anish, kiitos, että löysit aikaa keskustella kanssani tänään.
Anish Dhar: Kiitos paljon kutsusta.
Hannah Clark: Voisitko kertoa hieman taustastasi ja siitä, miten päädyit nykyiseen rooliisi?
Anish Dhar: Tietysti. Olen Cortex.ion toinen perustaja ja toimitusjohtaja. Perustimme yrityksen noin kuusi vuotta sitten, mutta sitä ennen työskentelin ohjelmistokehittäjänä Uberilla. Aloitin urani siellä, ja monet ongelmista, joita kohtasin Uberin ohjelmistokehittäjänä, innoittivat meidät perustamaan Cortexin.
Minulla oli kaksi hyvin läheistä ystävää. Uberilla on valtava sisäinen palveluarkkitehtuuri. Ohjelmistokehittäjänä minun oli todella vaikea ymmärtää koodikannan eri osia, erityisesti aloittaessani. Rakenteilla oli niin monia erilaisia palveluja. Se lisäsi valtavasti monimutkaisuutta, ja keskustelin läheisen ystäväni kanssa, joka oli ohjelmistokehittäjänä hyvin pienessä Lend-nimisessä startup-yrityksessä.
Heillä oli vain sata ohjelmistokehittäjää, kun taas Uberilla oli yli tuhat. Silti kohtasimme molemmat samanlaisia haasteita palveluarkkitehtuurimme järjestämisessä ja ymmärtämisessä. Se herätti hälytyskellot: jos Uber on mittakaavan toisessa päässä ja tämä mikropalveluihin vasta matkaansa aloittava yritys kohtaa samat ongelmat, on selvää, että kyseessä on suuri alan ongelma.
Niinpä perustimme lopulta yrityksen. Kävimme Winter 20 -kiihdyttämöohjelman läpi. Nyt olemme edenneet tähän päivään: saimme juuri päätökseen C-rahoituskierroksemme ja työskentelen muutaman sadan yritysasiakkaan kanssa, jotka käyttävät Cortexia monimutkaisuutensa hallintaan.
Hannah Clark: Hieno matka. On aina upeaa kuulla, kun yritys syntyy ongelmasta, jonka perustaja tuntee perusteellisesti.
Puhumme tässä jaksossa teknisestä erinomaisuudesta ja siitä, miltä se näyttää tämän päivän teknologia-alalla. Kyse on siis aiheesta, joka on ollut sinulle läheinen koko urasi ajan. Aloitetaan tästä: miten määrittelet teknisen erinomaisuuden vuonna 2025, ja miksi siitä on tulossa niin tärkeä painopiste teknologiajohtajille ja teknisen kehityksen johtajille?
Anish Dhar: Ehdottomasti. Loistava kysymys. Cortexissa olemme havainneet, että keskustelu keskittyi pitkään kehittäjäkokemukseen. Kehittäjäkokemus on erittäin tärkeä osa jokaista teknistä organisaatiota. Siihen kuuluvat yksinkertaiset asiat, kuten se, että yritykseen liittyvän kehittäjän on helppo ottaa sisäiset järjestelmät käyttöön ja yhdistää ne GitHubiin ja muihin käytössä oleviin työkaluihin. Tai kun palvelua otetaan käyttöön, infrastruktuuri on määritetty oikein eikä vianmääritykseen tai käyttöönottoon tarvita valtavaa määrää vaiheita.
Viime vuosina keskustelu on kuitenkin siirtynyt kehittäjäkokemuksesta siihen, mitä kutsumme tekniseksi erinomaisuudeksi. Suurin ero on mielestäni siinä, että tekninen erinomaisuus keskittyy organisaation eri tiimien toimintaan.
Näihin voivat kuulua esimerkiksi sivuston luotettavuustekniikka, tietoturva, kehittäjien tuottavuus ja kehittäjäkokemus. Olennaista on, että ne yhdistetään todellisiin liiketoimintatuloksiin. Tekninen erinomaisuus kysyy, miten tekemäni työ vaikuttaa liiketoimintaan ja miten se auttaa sitä etenemään.
Tavoitteet ulottuvat toimitusjohtajan organisaatiosta aina tiettyyn esimerkiksi sivuston luotettavuudesta vastaavaan henkilöön asti. Hyvä esimerkki voisi olla se, että organisaatio haluaa parantaa asiakaskokemusta ja tehdä tuotteestaan luotettavamman. Parempi asiakaskokemus johtaa suurempaan liikevaihtoon, koska ihmiset käyttävät tuotetta enemmän.
Teknisen erinomaisuuden aloitteessa sivuston luotettavuudesta vastaava tiimi voisi ottaa käyttöön tuotantovalmiuden tarkistuslistan. Ennen palvelujen käyttöönottoa halutaan varmistaa, että kaikki palvelut täyttävät organisaation standardit. Näin aloite yhdistyy todelliseen liiketoimintatulokseen, josta organisaatio välittää.
Tiimien on tärkeää ajatella aloitteitaan tällä tavalla, koska se vahvistaa niiden arvoa ja yhdistää tekniset aloitteet siihen, mistä liiketoiminta välittää. Mielestäni juuri siitä teknisessä erinomaisuudessa on kyse.
Hannah Clark: Mielenkiintoista. Kuten varmasti olet usein kuvannut, kyse on loputtomasta matkasta, jossa monet eri alat työskentelevät yhdessä.
Kerro tästä kehittämästäsi viitekehyksestä. Mitkä ovat sen keskeiset pilarit? Miten tarkastelette asiaa omassa organisaatiossanne?
Anish Dhar: Olet aivan oikeassa. Se on todella loputon matka. Monissa kanssamme työskentelevissä yrityksissä, erityisesti suurissa yrityksissä, on paljon vanhaa infrastruktuuria. Toisaalta uudempi yritys voi rakentua uudempien teknologioiden ja jopa tekoälyn varaan.
Tekniseen erinomaisuuteen liittyy silti erilaisia aloitteita. Niitä on lähestyttävä harkiten eri tiimeissä: mitä työ on ja miten se vaikuttaa lopulta liiketoiminnan erinomaisuustavoitteisiin? Viitekehyksen kannalta olemme keskittyneet erityisesti siihen, miten organisaation tekninen erinomaisuus määritellään.
Ajattelemme, että kaikki alkaa liiketoiminnan erinomaisuudesta. Johtoryhmällä on erilaisia tavoitteita, jotka voivat liittyä esimerkiksi innovaatioiden mahdollistamiseen ja markkinoille saapumisajan lyhentämiseen. Tavoitteena voi olla myös kustannusten alentaminen ja tehokkuuden lisääminen. Kolmas tavoite on laadun ja asiakaskokemuksen parantaminen.
Sen alla ovat teknisen erinomaisuuden pilarit. Ne ovat eri tiimejä ja ammattilaisia, jotka toteuttavat aloitteita ja vievät organisaatiota kohti tavoitteita. Näitä ovat esimerkiksi nopeus, tehokkuus, tietoturva ja luotettavuus. Niiden alla voi olla aloitteita, kuten tietoturvasiirtymä tai tuotantovalmiuden tarkistuslista.
Ehkä käyttöön otetaan häiriöiden hallintaprosessi. Tai halutaan seurata DORA-mittareita, jotta ymmärretään, miten tekninen tiimi suoriutuu tuottavuuden näkökulmasta. Teknisen erinomaisuuden aloitteen perusta koostuu neljästä C:stä: kattavasta näkyvyydestä, jatkuvasta parantamisesta, yhdenmukaisesta kehittäjäkokemuksesta ja selkeästä omistajuudesta.
Ilman omistajuutta ja ymmärrystä koodikannan eri osista ja palveluista näitä aloitteita on hyvin vaikea viedä eteenpäin. Havaitsemme yleensä, että ilman tätä perustaa minkään aloitteen edistäminen on vaikeaa.
Sisäiset kehittäjäportaalit ovat yleensä hyvä tapa rakentaa tämä perusta. Se voidaan tehdä myös sisäisten työkalujen avulla, mutta tarvitaan jonkinlainen järjestelmä, jonka avulla ymmärretään, mitä ihmiset rakentavat, jotta teknisiä aloitteita voidaan edistää.
Hannah Clark: Haluan tarttua mainitsemaasi suorituskyvyn mittaamiseen. Kehittäjien tuottavuuden mittaamiseen ja esimerkiksi koodirivien määrään liittyy jonkin verran jännitteitä. Ne voivat olla kehittäjien keskuudessa kiistanalaisia. Miten teknisen alan johtajien tulisi ajatella tuottavuuden mittaamista kokonaisvaltaisemmin niin, että kaikki nämä osa-alueet otetaan huomioon?
Anish Dhar: Viime vuosina kehittäjien tuottavuutta on usein mitattu koodiriveillä tai DORA-mittareilla. On olemassa monia viitekehyksiä, joiden tarkoitus on yksinkertaistaa tuottavuuden tarkastelua, ja mittareissa on oma totuutensa.
Koodirivien määrä ei ole hyvä osoitus siitä, onko joku tuottava. Jos koodirivejä syntyy kuitenkin jatkuvasti nolla neljänneksestä toiseen, tuotoksessa on selvästi jotain vialla. Myös tiimien välisessä vertailussa tiedot voivat joskus olla kiinnostavia. Keskustelu on kuitenkin siirtynyt datan keräämisestä siihen, miten insinöörit saadaan ajattelemaan dataa ja parantamaan tuloksia.
Kyse on täysin erilaisesta ja paljon vaikeammasta ongelmasta. Kuka tahansa voi kutsua GitHubin rajapintaa, saada nämä mittarit ja nähdä tilannekuvan tiimin toiminnasta. Jos näytän kehittäjälle mittarit ja sanon, että tätä mittaria on parannettava, se ei vielä merkitse hänelle mitään.
Hän keskittyy liiketoimintaa palvelevan ohjelmiston rakentamiseen ja haluaa tehdä sen mahdollisimman tehokkaasti. Keskustelu on siirtynyt erityisesti kanssamme työskentelevien teknologiajohtajien keskuudessa kysymykseen: miten mittarit muutetaan sellaiseksi, josta kehittäjä välittää?
Juuri tässä tekninen erinomaisuus on mielestäni ratkaisevassa asemassa. Kehittäjät, erityisesti nopeasti kasvavissa yrityksissä työskentelevät, haluavat liiketoiminnan kasvavan. He rakentavat tuotteita nähdäkseen työnsä vaikutuksen asiakkaisiin.
Kehityksen tuottavuus ei siis enää ole vain joukko mittareita. Liiketoiminnalla on tavoitteita, joista välitetään, ja mittarit kertovat niihin liittyvää tarinaa. Kehittäjän näkökulmasta on kuitenkin tärkeää kääntää tämä hänen tekemäkseen työksi, jolla on merkitystä.
Hannah Clark: Oletko huomannut vanhentuneita arviointimenetelmiä tai suorituskykymittareita, joista ihmiset ovat siirtymässä pois? Millainen on uusi arviointitapa? Voisitko jakaa konkreettisia esimerkkejä?
Anish Dhar: Ajattelisin tuottavuutta panos- ja tuotostason mittareina. Tuotostason mittarit ovat klassisia viitekehyksiä, joita käytetään kehityksen tuottavuuden seuraamiseen. Yksi tunnetuimmista on DORA-mittaristo, jonka pitäisi tarjota kokonaiskuva teknisen tiimin toiminnasta.
Useimmat tekniset organisaatiot haluavat nähdä ja kerätä näitä tuotostason mittareita. Mutta kuten aiemmin sanoin, seuraava kysymys on, miten mittareihin voidaan vaikuttaa ja saada ne muuttumaan. Asiakkaidemme parissa olemme nähneet, että panostason mittarit vaikuttavat tuotostason mittareihin.
Otetaan esimerkiksi käyttöönottojen tiheys. Se on hyvä mittari, koska ohjelmiston käyttöönottojen nopeus ennustaa todennäköisesti sitä, kuinka nopeasti tuotetta kehitetään. Se puolestaan vaikuttaa siihen, miten nopeasti yritys pääsee markkinoille ja voittaa kilpailijansa.
Jos organisaatio päättää seurata käyttöönottojen tiheyttä, voidaan näyttää mittaristo koko tekniselle tiimille: käyttöönottoja tehdään nyt kaksi viikossa ja tavoitteena on neljä. Kehittäjän on kuitenkin voitava ymmärtää, mitä tämä tarkoittaa hänen omassa työssään ja omistamissaan palveluissa.
Nopeampi käyttöönotto voi tarkoittaa suurempaa toimitusmäärää, mutta johtaako se virheiden lisääntymiseen? Heikkeneekö luotettavuus, koska ohjelmistoa toimitetaan enemmän? Tähän liittyy monia muuttujia. Siksi panostason mittarit ovat tärkeitä: ne vaikuttavat lopulta tuotostason mittareihin.
Esimerkiksi käyttöönottojen nopeuttamiseksi voidaan ottaa käyttöön prosessi. Eräs asiakkaistamme oli tässä tilanteessa. He seurasivat käyttöönottojen tiheyttä yhdellä teknisen älykkyyden mittaristollamme. He halusivat nopeuttaa käyttöönottoja, mutta tekivät sen luomalla tärkeät suojakaiteet ja selkeät ohjeet siitä, millainen hyvä käyttöönotto on luotettavuusohjeiden näkökulmasta.
Aiemmin nopeammat käyttöönotot johtivat virheisiin ja järjestelmien rikkoutumiseen. Siksi organisaatio epäröi liikkua mahdollisimman nopeasti. He loivat tuotantovalmiuden tarkistuslistan, joka koostui kahdeksasta tai yhdeksästä panostason mittarista. Yhdessä ne kertoivat, oliko käyttöönottoprosessi terveellä pohjalla.
Mittareihin kuului esimerkiksi se, oliko päivystysjärjestely määritetty oikein, läpäisikö koontiprosessi tarkistukset ja läpäisivätkö palvelujen testit. Näin kehittäjät saivat selkeät ohjeet: he omistivat kymmenen palvelua, joihin liittyi tietty prosessi ja merkitykselliset panostason mittarit.
Tuloksena käyttöönottojen tiheys kasvoi vähitellen kahdesta kolmeen ja neljään viikossa. Erityisesti kriittisten palvelujen kohdalla häiriöt vähenivät. Yritykset pohtivatkin nyt, miten tuotostason mittarit voidaan kääntää asioiksi, joista kehittäjät välittävät. Kehittäjien tuottavuutta ja mittareita on tarkasteltava näiden kahden tason kokonaisuutena.
Hannah Clark: Se tekee asiasta paljon kokonaisvaltaisemman. Vaihdetaan hieman näkökulmaa, mutta pysytään samassa aiheessa: käyttöönottojen tekemisessä nopeammin. Emme voi puhua vuoden 2025 teknisestä kehityksestä puhumatta tunnelmakoodauksesta.
Puhutaan tekoälytyökaluista, jotka muuttavat koodaustyönkulkuja. Olen kuullut sinun sanovan, ettei tunnelmakoodaamalla voi saavuttaa miljoonaa käyttäjää päivässä. Ehkä rohkea näkemys, ehkä ei. Mikä on todellisuus suhteessa hypetykseen, kun tekoälyä käytetään tuotantojärjestelmissä mittakaavassa?
Anish Dhar: Se on todella ajankohtainen aihe. Jokainen tekninen organisaatio pohtii tekoälyä tai on ottanut käyttöön jonkin tekoälyavusteisen koodaustyökalun. Markkinoilla on useita suosittuja työkaluja, kuten Cursor. Myös lähes kaikki Cortexin kehittäjät käyttävät jonkinlaista tekoälyavustajaa päivittäisessä työssään.
Olemme havainneet keskusteluissa tiimimme kehittäjien ja asiakkaidemme kanssa, että tekoälyavusteinen koodaus sopii hyvin alkuidean nopeaan validointiin. Se sopii myös esimerkiksi käyttöliittymäkehittäjälle, joka haluaa nopeasti havainnollistaa, miltä idea voisi näyttää ja tuntua.
Kehitysprosessissa se toimii hyvin, kun halutaan nopeasti rakennettu ja karkea versio, jonka avulla voidaan näyttää, miten jokin toimii. Yrittäjä voi myös validoida ideansa nopeasti. Tällaisissa tapauksissa kasvu on ollut hämmästyttävää.
Nykytilanteen todellisuus on kuitenkin se, ettei tunnelmakoodauksella tuotettua koodia voi luottaa tuotantojärjestelmän perustaksi, jos järjestelmää käyttää miljoonia käyttäjiä. Tämä perustuu siihen, mitä olemme käytännössä nähneet.
Tunnelmakoodaus on parhaimmillaan kuin aloitteleva kehittäjä, joka on juuri oppinut koodaamaan. Seniori- ja pääkehittäjät ymmärtävät järjestelmäsuunnittelua sekä sen, miten infrastruktuuri otetaan käyttöön mittakaavassa. Tekoäly ei vielä ole lähelläkään tätä, vaikka en väitä, etteikö se voisi joskus saavuttaa sitä.
Tekoälyn kehitysnopeus on uskomaton. Olisi typerää väittää, etteikö voisi syntyä järjestelmiä, jotka ymmärtävät todellisia tuotantoympäristöjä. Tällä hetkellä yksikään yritys ei kuitenkaan luota tunnelmakoodaukseen miljoonia tai miljardeja käyttäjiä palvelevan tuotantojärjestelmän perustana.
Tällaisten järjestelmien rakentamiseen, diagnosointiin ja skaalautuvuuden varmistamiseen tarvitaan niin paljon teknistä asiantuntemusta, ettei tekoäly ole vielä lähelläkään sitä. Kokonaisuutena tuottavuus on silti parantunut tekoälyavusteisen koodauksen ansiosta. Parannukset näkyvät vain eri alueilla kuin mistä markkinoilla ehkä halutaan puhua.
Hannah Clark: Monet ammattilaiset voivat varmasti samaistua tähän. Oman alan ulkopuoliset innostuvat siitä, että tekoäly tekee ammatista saavutettavamman, mutta se ei tarkoita, että tekoäly olisi heti korvaamassa ammattilaiset.
Ohjelmaa kuuntelee paljon johtajia. Miten teknisen alan johtajien tulisi tasapainottaa tekoälytyökaluihin tehtävät investoinnit ja henkilöstömäärä? Miten arvioidaan tekoälyn todellinen vaikutus tiimin tuottavuuteen ja otetaan se huomioon budjetissa?
Anish Dhar: Se on hyvä kysymys. Teknisellä alalla tai teknisenä johtajana olisi suuri virhe estää tiimejä tutustumasta näihin työkaluihin tai estää niiden käyttö, esimerkiksi Cursorin tai GitHub Copilotin käyttö. Se olisi pitkällä aikavälillä karhunpalvelus teknisen tiimin terveydelle ja laadulle.
Todennäköisesti seuraavan kymmenen vuoden aikana suuri osa järjestelmistä tai ainakin ihmisten ensimmäisenä kirjoittamasta koodista syntyy tekoälyn avustamana. Jos yritys on vasta aloittamassa tai haluaa nopeasti kokeilla ideaa, Cursorin kaltaisella työkalulla voidaan iteroida kymmenen kertaa nopeammin.
Siksi organisaatiot, jotka ottavat nämä työkalut käyttöön ja opettelevat hyödyntämään niitä kehityksen eri vaiheissa, ovat etulyöntiasemassa verrattuna niihin, jotka pitävät niitä pelkkänä hypenä. Johtajien on tärkeää antaa tiimeille mahdollisuus kokeilla tällaisia työkaluja ja tarjota niitä myös teknisesti suuntautuneille muille työntekijöille.
Mielenkiintoista on se, että esimerkiksi tuotejohtajat, tekniset ohjelmapäälliköt ja data-analyytikot, jotka ymmärtävät teknisiä käsitteitä mutta eivät aiemmin osanneet koodata, voivat nyt kehittää ideoita ja jakaa niitä tehokkaammin teknisen tiimin kanssa. He voivat rakentaa koodia ja toimivia kokeiluja itse.
Tästä näkökulmasta olisi typerää olla varaamatta budjettia siihen, että kehittäjät saavat käyttöönsä nämä työkalut. Miljoonan dollarin kysymys on kuitenkin se, kuinka paljon tuottavuutta todella saadaan.
Jokainen yritys yrittää parhaillaan vastata tähän. Asiakkaat ostavat usein tuotteemme yhdessä GitHub Copilotin kaltaisen työkalun kanssa. Ensimmäinen kysymys kuuluu: työkalun pitäisi kolminkertaistaa tai nelinkertaistaa teknisen tiimin tuotokset, mutta tapahtuuko se oikeasti?
Tässä palataan panos- ja tuotostason mittareihin. Ei riitä, että katsotaan käyttöönottojen tiheyttä ja todetaan työkalun vaikuttaneen siihen. Ehkä työkalu nopeuttaa toimitusta, mutta tuottaa huonoa koodia, mikä aiheuttaa luotettavuusongelmia. Siksi on tarkasteltava kokonaisuutta ja useita erilaisia mittareita.
Lopulta kyse on teknisestä erinomaisuudesta. Unohtakaamme tunnelmakoodaus ja muut yksittäiset ilmiöt hetkeksi: mihin liiketoiminta keskittyy juuri nyt? Mikä estää seuraavan kasvuvaiheen saavuttamisen? On arvioitava, auttaako koodaustyökalun tai tekoälyn käyttöönotto todella näiden tavoitteiden saavuttamisessa.
Vaikutusta ei välttämättä näe heti. Yrityksillä kestää jonkin aikaa ymmärtää, missä tällaiset työkalut vaikuttavat liiketoimintaan. Virhe on ostaa heti hypen perusteella esimerkiksi 5 000 käyttöoikeutta ja kysyä kuuden kuukauden päästä, onko niillä ollut vaikutusta.
Ilman harkittua strategiaa reaktio voi olla kielteinen. Strategia voi olla esimerkiksi se, ettei haluta jäädä jälkeen ja että kehittäjien halutaan kokevan työpaikan olevan alan eturintamassa. Kun tarkoitus ymmärretään, voidaan matkan varrella arvioida, tekevätkö työkalut todella sen, mitä odotettiin.
Hannah Clark: Olen samaa mieltä. Tällä hetkellä on paljon paineita hallita nämä työkalut ja löytää niille paikka työnkulussa. Monilla osastoilla törmätään kuitenkin suureen eroon tuotoksen määrän ja tulosten laadun välillä.
Meidän on oltava tarkoituksellisia paitsi teknisillä osastoilla myös siinä, käytämmekö näitä työkaluja oikeassa tilanteessa. Tarkoitus on vahvistaa ja auttaa henkilöstöä parhaalla tavalla, ei vain sokeasti olettaa, että ensi vuoden henkilöstömäärä voi olla pienempi, koska tekoäly korvaa ihmiset.
On kiinnostavaa seurata, kuinka kaikki ratkaisevat tätä samanaikaisesti eri tavoin. Teknologia-alalla on hyvin hämmentävä aika. Kun tekoälytyökalut yleistyvät kehitystyönkuluissa ja puhumme laadusta, miten tasapainotetaan koodin laatu, tietoturva ja luotettavuus sekä halu olla edistyksellinen työpaikka ja hyödyntää työkaluja parhaalla mahdollisella tavalla? Miten olette lähestyneet tätä Cortexissa?
Anish Dhar: Se on hyvä kysymys. Ajatus siitä, että tekoäly korvaa kehittäjät, on mielestäni kaukaa haettu ja absurdi. Totta on ehkä se, että yrityksen alkuvaiheessa ei tarvitse palkata viittätoista kehittäjää, vaan hieman vähemmän, koska tuotemarkkinoiden yhteensopivuutta etsittäessä voidaan iteroida paljon enemmän Cursorin kaltaisella työkalulla.
Kymmenen erilaista ideaa voidaan kokeilla nopeasti, ja iteraation nopeus on erittäin tehokas asia. Kun tuotantojärjestelmiä kuitenkin otetaan oikeasti käyttöön, yritykset, jotka väittävät tarvitsevansa tekoälyn vuoksi vähemmän kehittäjiä, yrittävät lähinnä saada huomiota.
Kehittäjien kysyntä ei tule katoamaan. Mitä tulee tekoälytyökalujen vaikutukseen luotettavuuteen ja tietoturvaan, se on tällä hetkellä suuri avoin kysymys. Se on todennäköisesti asia, joka huolestuttaa eniten sivuston luotettavuudesta, tietoturvasta ja operatiivisesta erinomaisuudesta vastaavia tiimejä.
Näiden työkalujen käyttöönotto kasvattaa hyökkäyspinta-alaa, koska ihmiset julkaisevat enemmän koodia. Mitä suurempi osa järjestelmästä on rakennettu tekoälyn avulla, sitä todennäköisempää on, ettei kukaan todella ymmärrä, miten kaikki toimii sisäisesti.
Kun väistämättä ilmenee luotettavuusongelma, tilanne on vaikeampi. Se voi johtua ennakoimattomasta käyttäjäryntäyksestä tai koodikannan osasta, jota ei täysin ymmärretty. Jos suurempi osa järjestelmästä on tekoälyn avustamaa, kehittäjän on vaikeampi käydä läpi koodikannan eri osia.
Siksi teknisen erinomaisuuden perusta on tärkeämpi kuin koskaan. Kattava näkyvyys ja selkeä omistajuus ovat teknisen erinomaisuuden aloitteen keskeisiä pilareita. Mitä enemmän järjestelmiä luodaan tekoälyn avulla, sitä heikompi näkyvyys ja omistajuus voivat olla.
Kuka omistaa järjestelmän? Kuka ymmärtää sen? Nämä ovat asioita, jotka huolestuttavat monia tietoturva- ja luotettavuustiimejä. Myös omassa teknisessä tiimissämme ollaan erityisen huolellisia, jos koodia on tuotettu tekoälyn avulla. Tällaiset järjestelmät tarkastetaan ylimääräisen huolellisesti.
Tekoälyavusteinen testaaminen on yleistynyt. Jotkin yritykset käyttävät tekoälyä testien tarkistamiseen. Se on hieman arveluttavaa, sillä tekoälyjärjestelmät ovat erittäin voimakkaita, mutta on pelottavaa ajatella maailmaa, jossa 80 prosenttia järjestelmästä on tekoälyn tuottamaa.
Se voi johtaa luotettavuusongelmien ja järjestelmien selvittämisen pitkittymiseen. Tietoturvahäiriöt voivat lisääntyä, koska näkyvyys järjestelmään heikkenee. Tätä on seurattava tarkasti.
Hannah Clark: Olen samaa mieltä. Tämä on vähemmän puhuttu logistinen ongelma: tuotosten määrän kasvu tarkoittaa myös valvonnan tarpeen kasvua.
Keskustelimme viime viikolla Mastercard Gatewayn tuotehallinnan varatoimitusjohtajan kanssa. Hän kertoi, kuinka tekoälytyökalut nopeuttavat esimerkiksi lomakkeiden täyttämistä uusille markkinoille siirryttäessä. Uudelle markkinalle pääsemiseen tarvittava paperityö ja sääntöjen noudattaminen voidaan hoitaa paljon nopeammin.
Samalla on kuitenkin varmistettava, että joku omistaa nämä hakemukset ja vastaa niiden oikeellisuudesta. Tässä on ristiriita: asiat voidaan tehdä nopeammin, mutta niistä on voitava vastata samalla nopeudella.
Tämä on suuri logistinen pullonkaula monille teknisille tiimeille ja muille työkalujen käyttäjille. Voimme toimittaa nopeasti, mutta pystymmekö samalla sanomaan olevamme vastuussa työstä? On kiinnostavaa nähdä, kuinka samanlaisia nämä huolet ovat eri osastoilla, vaikka itse työ olisi erilaista.
Arvostan todella paljon kaikkia tänään jakamiasi näkemyksiä. Jaksomme päättyy tähän. Mistä kuulijat voivat seurata sinua verkossa, Anish?
Anish Dhar: Minua voi seurata LinkedInissä tai Twitterissä. Kun haet nimelläni, löydät minut. Myös Cortex löytyy LinkedInistä.
Julkaisemme jatkuvasti sisältöä ja järjestämme Android Access -huippukokouksia ympäri maailmaa. Jos sellainen järjestetään lähelläsi, tule ihmeessä mukaan. Haluamme rakentaa yhteisön ihmisille, jotka pohtivat näitä asioita. Jokainen yritys käsittelee niitä, joten on hienoa nähdä, millainen yhteisö niiden ympärille syntyy.
Järjestämme myös IDPCON-konferenssia, joka keskittyy tekniseen erinomaisuuteen. Sinne saapuu johtajia erilaisista yrityksistä sekä kehittäjiä, jotka haluavat verkostoitua muiden teknisestä erinomaisuudesta kiinnostuneiden kehittäjien kanssa.
Luvassa on paljon hienoja puheenvuoroja. Tapahtuma järjestetään New Yorkissa lokakuussa, joten toivottavasti näemme sielläkin.
Hannah Clark: Kuulostaa upealta. Kiitos tiedosta. Laitamme sen ohjelman kuvauskenttään. Kiitos paljon, että käytit aikaasi keskusteluun kanssamme.
Anish Dhar: Kiitos kutsusta. Oli hienoa olla mukana.
Hannah Clark: Kiitos kuuntelusta. Saat lisää kiinnostavia näkemyksiä, käytännön oppaita ja työkaluarvosteluja tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla The CPO Clubin kaikissa podcast-palveluissa.
