Tekoälyn hallintaa ei voi jättää jälkikäteen hoidettavaksi

Abhishek Ranjan toimii Apnan ja Blue Machinesin teknologiajohtajana, ja hän osallistuu syvällisesti sekä ihmistyövoiman että tekoälytyövoiman muuttamiseen.

Keskustelimme hänen kanssaan tekoälyn työnkulkujen hallinnasta. Tässä hänen näkemyksensä.

Teknologia ihmisten rinnalla

Olen Abhishek Ranjan. Toimin Apnan ja Blue Machinesin teknologiajohtajana. Kaksi hyvin toisiinsa liittyvää mutta silti erilaista maailmaa ovat muovanneet matkaani tähän tekoälyn muutoksen hetkeen.

Apnalla rakennamme ratkaisuja ihmistyövoimalle. Apna on yksi Intian nopeimmin kasvavista yksisarvisyrityksistä, ja sen alustalla on yli 60 miljoonaa käyttäjää. Tässä mittakaavassa näemme Intian työvoiman hyvin läheltä. Näemme miljoonia ihmisiä etsimässä parempia mahdollisuuksia, työnantajia yrittämässä rekrytoida nopeammin, erilaisia kieliä ja taitotasoja sekä digitaalisen pääsyn ja digitaalisen itsevarmuuden vaihtelevia tasoja.

Blue Machinesilla rakennamme ratkaisuja tekoälytyövoimalle. Keskitymme yrityksille suunnattuun puhetekoälyyn ja käsittelemme päivittäin miljoonia minuutteja. Emme rakenna vain botteja, jotka vastaavat kysymyksiin. Rakennamme tekoälytyöntekijöitä, jotka voivat keskustella asiakkaiden kanssa, ymmärtää asiayhteyksiä, vastaanottaa palautetta, kehittyä ajan myötä ja toteuttaa todellisia liiketoiminnan työnkulkuja.

Olen nähnyt, kuinka teknologia auttaa ihmisiä löytämään työtä, kehittymään ja osallistumaan talouteen. Nyt näen tekoälyn itsensä kehittyvän uudenlaiseksi työvoimaksi, joka voi työskennellä ihmisten rinnalla.

Siksi tämä hetki ei merkitse minulle vain tekoälyn hyödyntämistä tuottavuuden parantamiseen tai koodin kirjoittamista nopeammin. Kyse on siitä, että kuvittelemme uudelleen, miten yritykset toimivat ja miten työ itsessään tehdään.

Kahden hyvin erilaisen liiketoiminnan arkkitehtuuri

Apnan arkkitehtuuri on rakennettu suuren markkinapaikka-alustan tavoin. Meillä on kuluttajajärjestelmiä, työnantajajärjestelmiä, data-alustoja, tekoäly- ja yhteensovitusjärjestelmiä, haku-, viestintä-, petostenhallinta- ja luottamuskerroksia sekä nyt myös tekoälyrekrytoijan ja tekoälypohjaisen työhaastatteluun valmistautumisen ominaisuudet. Käyttöönottomalli on pilvipohjainen ja erittäin skaalautuva, ja se on suunniteltu korkeaan käytettävyyteen, koska miljoonat käyttäjät ja tuhannet yritykset käyttävät alustaa.

Tekniikan organisaatiossa on yli 100 henkilöä, jotka työskentelevät tuotekehityksen, taustajärjestelmien, käyttöliittymien, mobiilin, datan, tekoälyn, infrastruktuurin, tietoturvan ja alustatiimien parissa. Keskitymme ominaisuuksien rakentamisen lisäksi luotettavien järjestelmien kehittämiseen, jotta ne voivat toimia valtavassa mittakaavassa.

Blue Machines on toisenlainen teknologiaorganisaatio. Se keskittyy yrityksille suunnattuun puhetekoälyyn ja toiminnallisiin työnkulkuihin. Rakennamme tekoälytyöntekijöitä, jotka voivat keskustella, tehdä päättelyä, suorittaa toimia, integroitua liiketoimintajärjestelmiin ja kehittyä palautteen avulla. Toimimme jo nyt merkittävässä mittakaavassa, ja puhetekoälymme käsittelee päivittäin miljoonia minuutteja.

Blue Machinesin arkkitehtuuri on reaaliaikaisempi ja tekoälyperustaisempi. Siihen kuuluvat puheinfrastruktuuri, puhelinjärjestelmät, puheen muuntaminen tekstiksi, suurten kielimallien päättely, tekstin muuntaminen puheeksi, työnkulkujen orkestrointi, integraatiot, analytiikka, havainnointi- ja arviointijärjestelmät. Tuotteen monimutkaisuus on suurta, koska yrityksille suunnatun puhetekoälyn on toimittava tuotannossa, todellisissa keskusteluissa, pienellä viiveellä, erittäin tarkasti, vaatimustenmukaisuuden suojatoimet huomioiden ja selkeisiin liiketoimintatuloksiin tähtäävästi.

Blue Machinesilla neljän insinöörin ydintiimi rakensi hajautetun puheen orkestrointialustan muutamassa viikossa. Meillä on myös erittäin ansioitunut tutkimustiimi, joka työskentelee syvällisesti puhetekoälyn, agenttien arvioinnin, päättelyn, viiveen, monikielisten järjestelmien ja agenttien ajan myötä tapahtuvan kehittämisen parissa. Tämä tutkimuksen syvyys on tärkeää, koska yrityksille suunnattua puhetekoälyä ei voida ratkaista vain yhdistelemällä malleja. Se edellyttää vahvaa tuotekehitystä, vahvaa järjestelmäkehitystä ja vahvaa soveltavaa tekoälytutkimusta.

Kaiken kaikkiaan johtamani teknologiaorganisaatio toimii laajamittaisten alustojen ja tekoälyperustaisten järjestelmien risteyskohdassa.

Miten hyvin hallittu tekoäly parantaa ohjelmiston elinkaarta

Viime vuoden aikana tekoäly on muuttanut tapaamme rakentaa, testata ja julkaista teknologiaa.

Aiemmin julkaisuprosessimme oli perinteisempi. Insinöörit rakensivat ominaisuuksia, avasivat PR:t, kävivät läpi vertaisarvioinnit, suorittivat testitapaukset ja julkaisivat muutokset tavanomaisen käyttöönottoputken kautta. Prosessi toimi, mutta etenemisnopeus riippui ihmisten tekemistä katselmointikierroksista, manuaalisesta laadunvarmistuksesta ja tiimin luottamuksesta julkaisuun.

Kun tekoälyavusteisesta koodauksesta tuli yhä suurempi osa ohjelmistokehitystä, otimme sen käyttöön – ja ymmärsimme pian, että pelkät nopeusparannukset eivät riittäneet. Tekoäly voi auttaa insinöörejä kirjoittamaan koodia nopeammin, mutta ellei hallintaa paranneta, se voi myös aiheuttaa enemmän piileviä virheitä, huomiotta jääneitä poikkeustapauksia tai heikkoja abstraktioita.

Niinpä muutimme toimintamallia.

1. Lisäsimme tekoälyavusteisen PR-tarkistuskerroksen. Jokaiselle PR:lle tehtiin ennen ihmisen suorittamaa katselmointia tarkistukset riskialttiin logiikan, puuttuvien poikkeustapausten, API-sopimusten rikkoutumisten, tietoturvaongelmien, migraatioihin liittyvien riskien ja puutteellisen testikattavuuden varalta. Tämä vähensi ilmeisiä huomaamatta jääneitä ongelmia ennen katselmointia.
2. Vahvistimme CI-portteja. Muutos ei voinut edetä vain siksi, että koodi näytti toimivalta. Sen oli läpäistävä yksikkötestit, integraatiotestit, koodin tyylintarkistus, tietoturvatarkistukset, API-sopimustestit ja kyseiseen tuotealueeseen liittyvät regressiotestit.
3. Rakensimme kriittisiä työnkulkuja varten kattavammat regressiotestikokonaisuudet. Lisäsimme esimerkiksi testitapauksia todellisista käyttäjäskenaarioista, poikkeustapauksista, monikielisestä toiminnasta, virheenkäsittelystä ja liiketoiminnan tuloksista.
4. Muokkasimme kehotteiden hallintaa. Palaan siihen hetken kuluttua.
5. Teimme rajoitetuista ennakkojulkaisuista pakollisia riskialttiilla alueilla. Sen sijaan, että julkaisemme muutoksen kaikille, julkaisemme sen pienelle osalle liikenteestä, seuraamme virheitä, viivettä, konversiota, keskeytyksiä, agentin laatua ja asiakasvaikutuksia ja sen jälkeen laajennamme julkaisua tai palautamme aiemman version.
6. Paransimme havainnointia. Kun jokin rikkoutui, halusimme tietää tarkalleen, mikä koodiversio, kehoteversio, malli, työnkulku tai riippuvuus sen aiheutti.

Vaikutus on ollut hyvin näkyvä. Julkaisunopeutemme kasvoi merkittävästi. Aiemmin suurempia, yhteen koottuja julkaisuja tehneet tiimit siirtyvät nyt pienempiin ja tiheämmin julkaistaviin muutoksiin. Joillakin alueilla julkaisutiheys kasvoi lähes 2–3-kertaiseksi, koska tarkistukset ovat automatisoidumpia ja luottamus on suurempi. Näin neljän hengen tiimi rakensi hajautetun ja monimutkaisen alustan muutamassa viikossa.

Myös tuotantoympäristön ongelmien määrä väheni, koska jokainen julkaisu on pienempi, paremmin testattu ja helpompi palauttaa. Tuotantovirheet ovat vähentyneet merkittävästi erityisesti siellä, missä automatisoidut regressiotestit ja rajoitetut ennakkojulkaisut ovat nyt pakollisia. Nykyään virheiden määrä on lähes 40 % alkuperäistä lähtötasoa pienempi.

Tekoäly yksin tarjoaa nopeutta. Tekoäly yhdistettynä hallintaan tarjoaa nopeutta ja laatua.

Miksi kehotteita on käsiteltävä kuten koodia

Abhishek jakaa

Tekoälyjärjestelmissä aloimme myös käsitellä kehotteita kuten koodia… Tämä on ollut tärkeä parannus. Tiedämme, mikä kehote oli käytössä, mitä muutettiin, mikä parani ja paranivatko asiakastulokset.

Tekoälyjärjestelmissä aloimme myös käsitellä kehotteita kuten koodia.

Versioimme, katselmoimme, testaamme ja siirrämme nyt kehotteita ympäristöjen välillä sekä otamme ne käyttöön vaiheittain. Kehotteita ei enää käsitellä pieninä määrityspäivityksinä. Niille tehdään keskustelutestejä, poikkeustapaustestejä, monikielisyystarkistuksia, viivetarkistuksia, vaatimustenmukaisuustarkistuksia ja liiketoiminnan tuloksiin liittyviä tarkistuksia.

Voimme julkaista uuden kehotteen tai agenttityönkulun ensin pienelle osalle liikenteestä, seurata tuloksia ja ottaa sen sitten laajemmin käyttöön, jos mittarit näyttävät paremmilta.

Tämä on ollut tärkeä parannus. Aiemmin oli vaikea tietää, paransiko kehotteen muutos agenttia vai muuttiko se vain sen toimintaa. Nyt voimme vertailla versioita objektiivisemmin. Tiedämme, mikä kehote oli käytössä, mitä muutettiin, mikä parani ja paranivatko asiakastulokset.

Suurempi muutos on se, että koko teknologiajärjestelmä muuttui automatisoidummaksi, mitattavammaksi ja paremmin hallituksi.

Agenttipohjainen ohjelmistokehityksen julkaisutyönkulku

Käytämme agenttipohjaista ohjelmistokehityksen julkaisutyönkulkua, jossa ihmiset osallistuvat keskeisissä vaiheissa.

Tämä työnkulku ei sovellu jokaiseen julkaisuun. Erittäin monimutkaisissa alustamuutoksissa, syvällisissä arkkitehtuurimuutoksissa tai arkaluonteisissa järjestelmissä käytämme edelleen perinteisempää, ihmisten johtamaa prosessia. Joillakin tuotealueilla, erityisesti nopeammin kehittyvissä työnkuluissa, tästä on kuitenkin tullut oletusarvoinen tapa rakentaa.

Tässä työnkulku:

1. Prosessi alkaa, kun tuotetta koskeva vaatimus tai suunnitteluongelma saapuu. Tekoälyn suunnitteluagentti lukee vaatimuksen, jakaa sen tehtäviksi, tunnistaa riippuvuudet, merkitsee riskialttiit alueet ja ehdottaa toteutussuunnitelmaa. Insinööri tarkistaa suunnitelman, korjaa oletukset ja päättää lopullisen lähestymistavan.
2. Seuraavaksi koodausagentti luo koodia, uudelleenjärjestää moduuleja, kirjoittaa perusrakenteita ja luo yksikkö- sekä integraatiotestejä. Tarkistusagentti tarkistaa vetopyynnön riskialttiin logiikan, puuttuvien poikkeustapausten, tietoturvaongelmien, API-sopimusten rikkoutumisten ja testiaukkojen varalta.
3. Seuraavaksi testausagentti luo regressioskenaarioita ja validoi poikkeustapaukset. Tekoälyn työnkulkujen yhteydessä se suorittaa myös kehotearviointeja, keskustelutestejä, monikielisyystarkistuksia, viivetarkistuksia ja liiketoimintatulosten tarkistuksia.
4. Julkaisuagentti suosittelee tämän jälkeen testitulosten, vaikutusalueen, aiempien virheiden ja havainnointivalmiuden perusteella, onko muutos turvallinen kanarialle käyttöönottoa varten. Ihmiset kuitenkin hyväksyvät edelleen kriittiset käyttöönotot, erityisesti jos muutos vaikuttaa liikevaihtoon, asiakaskokemukseen, tietoturvaan tai keskeiseen infrastruktuuriin.
5. Kun muutos on julkaistu, valvonta-agentti seuraa virheitä, viivettä, konversiota, keskeytyksiä, agentin laatua ja vaikutuksia asiakkaisiin. Jos jokin näyttää olevan vialla, se suosittelee palautusta, avaa häiriötilanteen, tiivistää lokit ja laatii ensimmäisen RCA-luonnoksen.

Tämä työnkulku on agenttipohjainen, mutta ei sokeasti autonominen. Tekoälyagentit suunnittelevat, koodaavat, tarkistavat, testaavat, julkaisevat, valvovat ja tiivistävät. Ihmiset hyväksyvät, kyseenalaistavat, priorisoivat ja tekevät lopullisen päätöksen.

Missä Claude Code ja Cursor ovat parhaimmillaan

Suosikkityökalujani ovat Claude Code ja Cursor työnkulusta riippuen.

Cursor on parhaimmillaan silloin, kun insinöörit haluavat tekoälyn syvästi integroituna IDE-ympäristöönsä päivittäistä koodausta, uudelleenjärjestelyä, koodikannan ymmärtämistä ja nopeampaa toteutusta varten.

Claude Code on erittäin hyödyllinen agenttipohjaisemmissa tehtävissä: suurten koodikantojen ymmärtämisessä, useisiin tiedostoihin tehtävissä muutoksissa, testien luomisessa, ongelmien korjaamisessa ja iteroinnissa insinöörikumppanin tavoin.

Miksi tekoäly tarjoaa vipuvaikutusta, kun taas ihmiset tarjoavat harkintaa

Luotamme nyt vahvasti tekoälyyn kaikessa, mikä parantaa nopeutta, kattavuutta tai yhdenmukaisuutta, mutta emme tehtävissä, jotka edellyttävät harkintaa, vastuullisuutta tai pitkän aikavälin kompromissien arviointia.

Tekoäly auttaa meitä nykyään esimerkiksi koodin tarkistuksessa, testitapausten luomisessa, regressiokattavuudessa, dokumentoinnissa, virheenkorjauksessa, lokien analysoinnissa ja jopa häiriötilanteiden triagessa. Se voi nopeasti tunnistaa riskialttiita koodipolkuja, puuttuvia poikkeustapauksia, mahdollisia tietoturvaongelmia tai tuotantovirheiden malleja. Tekoälyjärjestelmissä se auttaa meitä myös vertailemaan kehoteversioita, arvioimaan keskusteluja ja ymmärtämään, missä agentti epäonnistuu.

Mutta lopulliset päätökset tehdään ihmisten toimesta. Tässä muutamia esimerkkejä:

• Arkkitehtuuria koskevien valintojen on pysyttävä ihmisillä, koska niihin liittyy kompromisseja skaalautuvuuden, kustannusten, luotettavuuden, tiimin kyvykkyyksien ja tuotteen pitkän aikavälin suunnan välillä.
• Tekoäly voi auttaa kokonaisvaltaisessa RCA:ssa, mutta ihmisten on edelleen yhdistettävä eri havainnot, validoitava hypoteesi ja päätettävä korjauksesta.
• Priorisoinnin on pysyttävä ihmisillä, koska se edellyttää asiakkaiden tuntemista, liiketoimintastrategiaa ja harkintaa siitä, mikä todella on tärkeää.
• Tietoturvatarkistuksissa hyödynnetään tekoälyä, mutta asiantuntijaharkinta on välttämätöntä. Tekoäly voi ilmoittaa ongelmista, mutta se voi myös tuottaa vääriä positiivisia tuloksia tai jättää liiketoimintakontekstiin liittyviä riskejä huomaamatta. Ihmiset säilyttävät vastuun, koska riskit ja tilivelvollisuus ovat liian suuria.

Esimerkkejä tekoälyn epäonnistumisista teknisessä harkinnassa tosielämässä

Tässä on muutama esimerkki ihmisen harkinnan tärkeydestä.

Ensimmäisessä tapauksessa oli kyse millisekuntitason viivepiikeistä ääniputkessamme. Tekoäly kommentoi ongelmaa asianmukaisesti ja tunnisti, että yhden polun viiveestä voisi tulla ongelma. Sen ehdottama koodi oli kuitenkin väärin. Se näytti siistiltä, mutta olisi aiheuttanut kuormituksen kasvaessa toisen pullonkaulan. Ihmisinsinööri puuttui tilanteeseen, ymmärsi ajonaikaisen toiminnan ja korjasi ongelman asianmukaisesti.

Toinen esimerkki tuli tuotannon ongelmanratkaisun aikana. Useat järjestelmät alavirran puolella kaatuivat, ja tekoäly jatkoi niiden analysointia erillään toisistaan ehdottaen optimointeja. Tiesimme kuitenkin jo, että todellinen ongelma oli ensin vikaantunut riippuvuus ylävirran puolella. Tekoäly sekoitti näkyvät virheet perimmäiseen syyhyn.

Tässä tekoälyllä on edelleen vaikeuksia. Se osaa lukea lokeja, tiivistää jäljitystietoja, ehdottaa korjauksia ja nopeuttaa virheenkorjausta. Monimutkaisissa hajautetuissa järjestelmissä se voi kuitenkin olla huomaamatta syy-yhteyksiä, ajoitusta ja koko järjestelmän kontekstia.

Miksi tiimit muuttuvat pienemmiksi ja osaamiseltaan laaja-alaisemmiksi

Tekoäly on muuttanut rekrytointiprofiilia enemmän kuin organisaatiokaaviota.

Aiemmin rekrytoimme kapeamman toiminnallisen syväosaamisen perusteella: taustajärjestelmät, käyttöliittymät, laadunvarmistus, DevOps, data ja niin edelleen. Nämä taidot ovat edelleen tärkeitä, mutta nykyään arvostan insinöörejä, jotka pystyvät työskentelemään koko teknologiapinon parissa, hyödyntämään tekoälyä syvällisesti ja etenemään ongelmasta tuotantoon huomattavasti vähemmällä ohjauksella.

Parhaat insinöörit eivät nykyään vain kirjoita koodia. He suunnittelevat työnkulkuja, käyttävät tekoälyä toteutukseen, luovat testejä, tarkistavat tuotoksia, korjaavat virheitä nopeammin ja ajattelevat julkaisun laatua.

Siksi rekrytointikriteerit painottuivat vahvan omistajuuden ja harkintakyvyn omaaviin insinööreihin. Sellaisiin ihmisiin, jotka osaavat esittää oikeat kysymykset, varmistaa tekoälyn tuotokset, ymmärtävät järjestelmät syvällisesti ja pystyvät viemään työn itsenäisesti tuotantoon.

Se on myös vähentänyt suurten tiimien tarvetta joillakin alueilla. Pienempi tiimi, joka hyödyntää tekoälyä tehokkaasti, pystyy nykyään tekemään työn, johon aiemmin tarvittiin huomattavasti enemmän ihmisiä.

Miksi tekoäly vaikeuttaa uusien insinöörien kouluttamista

Abhishek kertoo

En usko, että tekoälyn kieltäminen tai ihmisten pakottaminen koodaamaan kuin elettäisiin vuotta 2010 on vastaus. Se olisi väärin. En kuitenkaan myöskään usko, että olemme täysin ratkaisseet, miten rakennetaan syvällistä insinöörin harkintakykyä silloin, kun tekoäly tekee niin suuren osan ennakkotyöstä. Toistaiseksi paras vastaukseni on tehdä ymmärrys näkyväksi.

Miten koulutamme uusia insinöörejä tekoälyn aikakaudella? Minulla ei ole vielä täydellistä vastausta.

Kun aloitimme, kehitysympäristöt auttoivat meitä. Sitten Google auttoi meitä. Sen jälkeen Stack Overflow auttoi meitä. Kaikissa näissä vaiheissa sinun oli kuitenkin edelleen käytävä ongelma itse läpi. Sinun piti ymmärtää vastaus, mukauttaa sitä, korjata sen virheet ja oppia, miksi se toimi.

Tekoälyn ja fiiliskoodauksen avulla voimme ohittaa tuon kamppailun. Uusi insinööri voi tuottaa toimivaa koodia ymmärtämättä oikeasti järjestelmää, kompromisseja tai vikatilanteita. Se huolestuttaa minua.

En usko, että tekoälyn kieltäminen tai ihmisten pakottaminen koodaamaan kuin elettäisiin vuotta 2010 on vastaus. Se olisi väärin. En kuitenkaan myöskään usko, että olemme täysin ratkaisseet, miten rakennetaan syvällistä insinöörin harkintakykyä silloin, kun tekoäly tekee niin suuren osan ennakkotyöstä.

Toistaiseksi paras vastaukseni on tehdä ymmärrys näkyväksi. Insinöörien pitäisi pystyä selittämään, miksi koodi toimii, missä se voi epäonnistua, millä testeillä on merkitystä, mitä tapahtuu mittakaavan kasvaessa ja miten he korjaisivat sen virheitä tuotannossa.

Miten merkkien käyttöä hallitaan

Kustannukset ovat olleet yksi tekoälyn haasteista.

Merkkien käyttö näyttää aluksi harmittomalta, mutta kun tekoäly tulee mukaan koodaukseen, katselmointeihin, testaukseen, virheenkorjaukseen ja agenttipohjaisiin työnkulkuihin, kustannukset voivat kasvaa hyvin nopeasti.

Siksi meidän on nyt mitattava sijoitetun pääoman tuottoa työnkulkujen perusteella ja käytettävä älykkäämpää orkestrointia. Kaikki tehtävät eivät tarvitse kalleinta mallia.

Tulevaisuudessa oikeaa mallia käytetään oikeaan tehtävään.

Miksi teknologiajohtajien on edettävä nopeasti – hallintakeinot huomioiden

Tässä on neuvoni: Rakenna nopeasti. Kokeile nopeasti. Ota tekoäly osaksi todellista suunnittelutyötä, tuotekehitystä, tukea, myyntiä, operaatioita ja sisäisiä työnkulkuja. Älä teeskentele, ettei se toimi. Se toimii, joskus yllättävän hyvin.

Älä kuitenkaan muutu sokeaksi uskojaksi. Tekoäly on tehokas, mutta se ei ole taikuutta. Tarvitset hallintaa, ohjausta, testausta, havainnointia ja selkeän omistajuuden. Muuten luot vain kaaosta nopeammin.

Oikea ajattelutapa ei ole ”tekoäly korvaa kaiken” eikä ”tekoälyä hypetetään liikaa”. Oikea ajattelutapa on ”miten voin käyttää tätä organisaationi kyvykkyyden kymmenkertaistamiseen?”

Pysy mukana

Seuraa Abhishek Ranjania LinkedInissä. Tutustu myös hänen Hacktivate-uutiskirjeeseensä.

Lisää asiantuntijahaastatteluja on tulossa The CTO Clubiin!