Tekoälyarkkitehtuurin globaali johtaja sanoo, että tekoäly muuttaa toimintamallia eikä ole vain työkalujen käyttöönottoa

Manish Jain on Firstsourcen tekoälyarkkitehtuurin varatoimitusjohtaja ja maailmanlaajuinen johtaja, ja hän johtaa 50 henkilön tiimiä. Hänen tämänhetkinen painopisteensä on agenttisten järjestelmien rakentamisessa niin, että ne pystyvät käsittelemään monivaiheista työtä.

Keskustelimme Manishin kanssa siitä, miten AI muuttaa hänen toimintamalliaan. Tässä hänen vastauksensa.

Potentiaalista tuotantovalmiiksi kyvykkyydeksi

Olen Manish Jain, tekoälyn ja teknologian johtaja, joka keskittyy auttamaan organisaatioita muuttamaan tekoälyn potentiaalin luotettavaksi ja tuotantovalmiiksi kyvykkyydeksi. Perustan työni muutoksen käytännön realiteetteihin. Olen johtanut useita AI- ja ML-hankkeita viime vuosien aikana, tehnyt tiivistä yhteistyötä liiketoimintatiimien kanssa sekä työskennellyt suunnittelun ja käyttöönottojen parissa, joissa onnistuminen riippuu paljon muustakin kuin oikean mallin valinnasta. Arkkitehtuurin, datan laadun, turvallisuuden, integraation, käyttäjien omaksumisen ja selkeän liiketoiminta-arvon on nivouduttava yhteen.

Johdan tällä hetkellä tekoälyhankkeita noin 50 hengen monialaisessa organisaatiossa. Siihen kuuluu ohjelmisto- ja alustainsinöörejä, tekoälyn ja datan asiantuntijoita, tuotejohtajia, turvallisuuskumppaneita ja liiketoiminta-alueiden asiantuntijoita. Työ kattaa yritystason tekoälyn käyttöönoton ja asiakaslähtöisen toimituksen. Tiimit työskentelevät tiiviisti asiakkaiden ja sisäisten sidosryhmien kanssa viedäkseen arvokkaat käyttötapaukset selvitysvaiheesta turvalliseen ja skaalautuvaan tuotantokäyttöön.

Lähestymistapamme on tarkoituksella pilvi- ja malliriippumaton. Otamme ratkaisuja ensisijaisesti käyttöön Azure- ja AWS-ympäristöissä ja käytämme Google Cloudia valikoivasti asiakkaan ympäristön, dataomaisuuden ja operatiivisten tarpeiden perusteella. Sen sijaan että suunnittelisimme ratkaisun yhden pilvipalveluntarjoajan tai perustamallin ympärille, rakennamme modulaarisia arkkitehtuureja, joiden ansiosta voimme valita taustalla olevat komponentit ja kehittää niitä vaatimusten muuttuessa. Näihin kuuluvat mallikerros, tiedonhaku- ja datapalvelut, orkestrointikehys, arviointityökalut, havainnointi sekä turvallisuuskontrollit.

Varsinainen monimutkaisuus ei liity pelkästään LLM:n valintaan. Haasteena on tekoälyn integroiminen liiketoiminnan työnkulkuihin hajanaisten tietolähteiden, vanhojen sovellusten, vaihtelevien käyttöoikeuksien sekä turvallisuutta, luotettavuutta, kustannuksia ja vaatimustenmukaisuutta koskevien tiukkojen vaatimusten keskellä. Aloitamme yleensä rajatusta käyttötapauksesta ja perusteellisesta arvioinnista ja viemme toimiviksi osoittautuvat ratkaisut tuotantoon suojakaiteiden, tarvittaessa toteutettavan ihmisen valvonnan, seurannan ja jatkuvan kehittämisen avulla. Tavoitteena on luoda tekoälykyvykkyyksiä, jotka säilyvät mukautuvina teknologian muuttuessa ja joihin tiimit voivat luottaa päivittäisessä työssään.

Olen erityisen kiinnostunut siirtymisestä yksittäisistä tekoälyapureista agenttisiin järjestelmiin, jotka pystyvät käsittelemään monivaiheista työtä määriteltyjen rajojen sisällä. Teknologiajohtajille mahdollisuus on merkittävä, mutta sen hyödyntäminen edellyttää kurinalaista suunnittelua, harkittua hallintaa ja vahvaa tuloksiin keskittymistä.

Miksi arviointi ensin -periaatteella toteutettu AI-toimitus parantaa tuloksia

Viime vuoden aikana olen siirtänyt tekoälyn toimituksen prototyyppikeskeisestä ajattelutavasta arviointi ensin -periaatteella toimivaksi suunnittelukäytännöksi. Vuosi sitten tiimit rakensivat usein nopeasti vaikuttavia konseptitason ratkaisuja yhdistämällä työnkulkuja yksittäisiin malleihin. Tuotannossa tekoälyn luotettavuuden määrittäviin tekijöihin – laatuun, tietopohjaisuuteen, käyttöoikeuksien hallintaan, virheiden käsittelyyn, kustannuksiin ja käyttäjien vastuuseen – kuitenkin puututtiin usein liian myöhään.

Otimme käyttöön yhteisen toimitusmallin, jossa jokainen tekoälyn käyttötapaus alkaa onnistumisen selkeästä määrittelystä, edustavasta arviointidatasta, turvallisuuden ja dataan pääsyn tarkastelusta, jäljitettävyydestä sekä jatkuvasta seurannasta. Rakensimme myös taustalla olevan arkkitehtuurin pilvi- ja malliriippumattomaksi. Näin tiimit voivat arvioida kuhunkin työnkulkuun sopivaa mallien, tiedonhakumenetelmien ja orkestrointimallien yhdistelmää sitomatta tuotetta yhteen palveluntarjoajaan tai mallisukupolveen.

Käytännössä tämä vähensi uudelleentyötä ja lisäsi luottamusta tuotantokäyttöönottoihin. Tiimit voivat tunnistaa laatu- tai kustannusheikennykset ennen kuin ne vaikuttavat käyttäjiin, tehdä tietoisia päätöksiä siitä, missä ihmisen suorittama tarkistus on tarpeen, sekä parantaa järjestelmiä näyttöön perustuen yksittäisten kokemusten sijaan.

Tulevaisuutta ajatellen uskon tämän muodostavan vastuullisen agenttisen tekoälyn perustan. Kun järjestelmät siirtyvät kysymyksiin vastaamisesta monivaiheisten toimien toteuttamiseen yrityksen työnkuluissa, emme voi lisätä arviointia, havainnointia, käyttöoikeuksia ja hallintaa vasta myöhemmin. Niiden on oltava osa teknistä perustaa ensimmäisestä päivästä lähtien.

Miten ihmisistä tulee entistä tärkeämpiä agenttisen suunnittelun myötä

Käytämme tekoälyä koko tuote-elinkaaren ajan. Selvitysvaiheessa se muuntaa sidosryhmien syötteet, asiakaspalautteen ja olemassa olevan dokumentaation alustaviksi vaatimuksiksi, käyttäjätarinoiksi, hyväksymiskriteereiksi ja teknisiksi kysymyksiksi. Suunnittelussa se tukee koodikannan kartoittamista, dokumentointia, toteutusta, uudelleenjärjestelyä, yhdistämispyyntöjen valmistelua ja testien luomista. Operoinnissa se tekee yhteenvedon lokeista, yhdistää hälytykset viimeisimpiin julkaisuihin, hakee aiempien häiriöiden kontekstin ja rajaa hakualuetta häiriöiden selvityksen aikana. Tiimit käyttävät vähemmän aikaa kontekstin kokoamiseen eri työkaluista ja enemmän aikaa päätösten vahvistamiseen, monimutkaisten ongelmien ratkaisemiseen ja toimituksen edistämiseen.

Pidämme arkkitehtuurin omistajuuden, tietoturvan hyväksynnän, dataan pääsyä koskevat päätökset, julkaisuhyväksynnän ja prioriteettien väliset kompromissit ihmisten vastuulla. Nämä päätökset edellyttävät liiketoimintaympäristön tuntemusta, vastuullisuutta ja ymmärrystä seurauksista, jotka ulottuvat tiketin, kehotteen tai koodivaraston sisältöä laajemmalle. Tekoäly voi analysoida vaihtoehtoja, tunnistaa riippuvuuksia, nostaa esiin tietoturvaan liittyviä huolenaiheita ja koota näyttöä, mutta vastuullinen insinööri tai johtaja tekee päätöksen.

Teemme tämän eron tarkoituksellisesti siirtyessämme kohti agenttisempaa ohjelmistokehitystä. Odotan tekoälyn ottavan vastuulleen enemmän rajattua suorittamista, kuten tarkasti määriteltyjen muutosten toteuttamista, testien luomista ja suorittamista, käyttöönoton kriteerien validointia tai häiriöiden korjausvaiheiden ehdottamista. Tämän tapahtuessa ihmisen rooli muuttuu entistä tärkeämmäksi, ei vähemmän tärkeäksi. Insinöörit määrittelevät tarkoituksen, käyttöoikeudet, laatukynnykset ja palautusrajat sekä varmistavat, saavuttiko järjestelmä tarkoitetun lopputuloksen.

Miten tekoäly tehostaa päästä päähän ulottuvia ohjelmistokehityksen työnkulkuja

Tässä on päästä päähän ulottuva työnkulkumme, joka vie tarkasti määritellyn tuotevaatimuksen suunnittelun, toteutuksen, validoinnin ja tuotantojulkaisun läpi. Kaikki alkaa siitä, että tuotepäällikkö ja ohjelmistokehityksen vetäjä määrittelevät asiakashyödyn, rajoitteet ja hyväksymiskriteerit. Tekoäly kokoaa sitten olennaisen liiketoimintakontekstin, olemassa olevan dokumentaation, arkkitehtuurimallit ja riippuvuudet teknisen suunnitelman, toteutussuunnitelman ja testausstrategian luonnokseksi. Insinööri tarkistaa suunnitelman, tekee arkkitehtuuria koskevat päätökset ja jakaa työn pieniksi, itsenäisesti varmennettaviksi muutoksiksi.

Toteutuksen aikana insinöörit käyttävät tekoälyä koodikannassa olennaisten palveluiden ymmärtämiseen, alustavan koodin ja konfiguraatiomuutosten luomiseen, dokumentaation päivittämiseen sekä yksikkö- ja integraatiotestien laatimiseen. Jokainen muutos käy edelleen läpi versionhallinnan, automatisoidut CI-tarkistukset, vertaisarvioinnin, tietoturvatarkistuksen ja vakiintuneen julkaisuprosessin. Jos testi epäonnistuu, tekoäly tulkitsee epäonnistumisen, tunnistaa todennäköisen riippuvuuden tai regression ja ehdottaa korjausta, mutta insinööri varmistaa korjauksen ennen sen etenemistä.

Käyttöönoton jälkeen työnkulku jatkuu. Tekoäly tiivistää sovelluslokit, yhdistää poikkeamat viimeisimpiin julkaisuihin ja tuo päivystävän insinöörin nähtäville olennaiset aiemmat häiriöt tai toimintaohjeet. Mittaamme koko prosessia läpimenoajalla, testikattavuudella, muutosten epäonnistumisasteella, palautusten tiheydellä ja ratkaisuajalla.

Tämä ei ole autonomista ohjelmistokehitystä. Kyseessä on ihmisen johtama ja tekoälyn tukema toimitusjärjestelmä, jossa tekoäly tiivistää kontekstin keräämiseen ja suorittamiseen kuluvaa aikaa, kun taas insinöörit säilyttävät vastuun suunnittelusta, laadusta, tietoturvasta ja tuotantoympäristön lopputuloksesta.

Manish kertoo

Tekoäly on lyhentänyt merkittävästi aikaa, jonka insinöörit käyttävät kontekstin keräämiseen ja rutiinityön ensimmäisen version tuottamiseen. Se auttaa tiimejä siirtymään nopeammin alkuperäisestä vaatimuksesta jäsenneltyyn tekniseen lähestymistapaan, toteutukseen, testikattavuuteen ja dokumentaatioon.

Miten tekoäly parantaa toimintojen välistä työnkulkua

Tulosten osalta tekoäly on lyhentänyt merkittävästi aikaa, jonka insinöörit käyttävät kontekstin keräämiseen ja rutiinityön ensimmäisen version tuottamiseen. Se auttaa tiimejä siirtymään nopeammin alkuperäisestä vaatimuksesta jäsenneltyyn tekniseen lähestymistapaan, toteutukseen, testikattavuuteen ja dokumentaatioon. Se on nopeuttanut uusien ominaisuuksien ja tuotetoimintojen kehittämistä erityisesti silloin, kun insinöörien on analysoitava ennestään tuntematonta koodikantaa, jäljitettävä riippuvuuksia tai työskenneltävä useiden palveluiden parissa.

Tekoäly tukee myös arkkitehtuuria koskevia päätöksiä. Se voi nopeasti koota yhteen olemassa olevan järjestelmädokumentaation, tunnistaa riippuvuuksia, vertailla toteutusvaihtoehtoja, tuoda esiin todennäköisiä kompromisseja ja auttaa tiimejä laatimaan arkkitehtuuripäätösten kirjauksia. Ihmiset tekevät lopulliset arkkitehtuuripäätökset, mutta tiimit osallistuvat keskusteluihin paremman kontekstin pohjalta. Ne voivat käyttää enemmän aikaa aidosti merkityksellisten päätösten pohtimiseen, kuten skaalautuvuuteen, häiriönsietokykyyn, tietoturvaan, kustannuksiin ja pitkän aikavälin ylläpidettävyyteen.

Parannus ei ole vain nopeampaa koodin tuottamista. Näemme paremman työnkulun koko elinkaaren ajan, koska tuotehallinta, ohjelmistokehitys, laadunvarmistus ja operointi aloittavat työn kattavamman ja yhdenmukaisemman kontekstin pohjalta. Insinöörit käyttävät enemmän aikaa järjestelmän suunnitteluun, reunatapauksiin, integraatioiden monimutkaisuuteen ja asiakasvaikutuksiin sen sijaan, että kokoaisivat tietoja manuaalisesti koodivarastoista, tiketeistä, koontinäytöistä, lokeista ja aiemmista häiriöistä.

Miten menestystä tulisi mitata tekoälyn avulla

Olemme oppineet myös tärkeitä asioita haitoista. Tekoäly voi luoda vääränlaisen kuvan nopeudesta, kun tiimit hyväksyvät uskottavalta vaikuttavan tulosteen ilman riittävää validointia. Se voi tuottaa koodia, joka vaikuttaa oikealta mutta ei sovi ympäröivään arkkitehtuuriin, jättää huomaamatta hienovaraisia liiketoimintasääntöjä, lisää tarpeetonta monimutkaisuutta tai aiheuttaa tietoturva- ja ylläpidettävyysongelmia. Tuottavuushyödyt jakautuvat myös epätasaisesti. Eniten hyötyvät insinöörit, jotka ymmärtävät järjestelmän, muotoilevat tehtävänannon täsmällisesti ja validoivat tuotokset perusteellisesti.

Siksi mittaamme menestystä toimitusten laadun emmekä tekoälytoiminnan mittareiden avulla. Meille tärkeitä tuloksia ovat ominaisuuksien nopeampi toimitus, lyhyempi läpimenoaika, vakaat julkaisut, parempi testikattavuus, vähäisempi uudelleentyö, nopeampi häiriöiden ratkaiseminen ja jatkuva luotettavuus. Pitkän aikavälin mahdollisuus on merkittävä, mutta vain jos tekoäly parantaa teknistä harkintaa ja toteutusta sen sijaan, että siitä tulee jommankumman korvike.

Miten uudet rajoitteet muuttavat tiimirakenteita

Koodin generointi ei enää rajoita teknisen työn etenemisnopeutta. Todellisia rajoitteita ovat usein epäselvät vaatimukset, hajallaan oleva liiketoimintakonteksti, arkkitehtuuririippuvuudet, tietoturvatarkastukset, järjestelmien välinen integrointi sekä aika, joka tarvitaan muutoksen turvallisen toiminnan validoimiseen tuotannossa. Toimialan tiedot osoittavat samaan suuntaan: koodaaminen muodostaa suhteellisen pienen osan insinöörin päivästä, eikä tekoälyn käyttöönotto koodaamisessa automaattisesti johda suhteellisiin läpimenohyötyihin.

Tämä muutti tapaani ajatella tiimirakennetta. Sen sijaan että käsittelisimme tekoälyä vain toimitukseen tarvittavan työn vähentämisen välineenä, siirrymme kohti pienempiä ja monialaisempia tiimejä, joilla on vahvempi omistajuus selvitystyöstä tuotannossa oppimiseen asti. Insinöörien on käytettävä vähemmän aikaa ensimmäisten luonnosten laatimiseen ja enemmän aikaa tarkoituksen määrittelyyn, arkkitehtuurin suunnitteluun, tuotosten validointiin ja järjestelmän parantamiseen julkaisun jälkeen.

Lisäksi rekrytointimme painopiste on siirtynyt puhtaasta koodintuotannosta järjestelmäajatteluun, tuoteharkintaan ja tekoälyn avustaman työn validoimiseen. Arvostamme insinöörejä, jotka pystyvät käsittelemään epäselvyyttä, tekemään perusteltuja arkkitehtuuri- ja tietoturvaratkaisuja sekä kantamaan vastuun tuloksista tuotannossa.

Manish kertoo meille

Tulevaisuus ei tarkoita vain nopeampaa toteutusta. Se tarkoittaa nopeampaa yhteensovittamista sekä tiiviimpää yhteyttä idean, tuotannossa saavutetun tuloksen ja seuraavaa päätöstä ohjaavan oppimisen välillä.

Tulevaisuus ei tarkoita vain nopeampaa toteutusta. Se tarkoittaa nopeampaa yhteensovittamista sekä tiiviimpää yhteyttä idean, tuotannossa saavutetun tuloksen ja seuraavaa päätöstä ohjaavan oppimisen välillä.

Miksi testaaminen on suunniteltava uudelleen tekoälyn tukemaa tulevaisuutta varten

Testaaminen on suunniteltava uudelleen.

Tekoäly nopeuttaa koodin luomista huomattavasti, mikä tarkoittaa, että laadunvarmistuksen on oltava jatkuvaa ja automatisoitua sekä osa toimitusprosessia sen sijaan, että sitä käsiteltäisiin viimeisenä porttina. Tiimit tarvitsevat tekoälyavusteista testien generointia, realistisia arviointiaineistoja, tietoturva- ja suorituskykytarkastuksia, tuotannon valvontaa sekä selkeän ihmisen vastuun poikkeustilanteissa.

Tekoälyn tukemassa elinkaaressa kilpailuetu ei synny siitä, kuka generoi koodia nopeimmin, vaan siitä, kuka pystyy validoimaan muutokset turvallisesti ja oppimaan tuotannosta nopeimmin.

Miten vältät tekoälyn aiheuttamat kitkatekijät varhaisessa vaiheessa

Arvioimme tekoälyn käytännön realiteetit liian vähäisiksi. Tunnisteiden kulutus ja käyttörajat voivat rajoittaa toimitusta merkittävästi, erityisesti agenttimaisten koodaustyönkulkujen yhteydessä, kun tarvitaan suuren koodipohjan kontekstia tai toistuvia iteraatioita. Käsittelemme tekoälyyn käytettävät varat nykyään teknisen kapasiteetin päätöksenä, jossa näkyvät käyttö, mallien reititys, kontekstinhallinta ja tuotettu arvo — eivät ainoastaan lisenssikustannukset. Myös palvelun luotettavuudella on merkitystä. Ulkoinen malli tai koodausalusta voi kärsiä viiveestä, nopeusrajoituksista tai saatavuusongelmista, joten kriittiset työnkulut tarvitsevat varamalleja, hallittua toiminnallisuuden heikkenemistä ja tapoja, joilla insinöörit voivat jatkaa työskentelyä ilman tekoälypalvelua.

Olisimme voineet välttää varhaisen kitkan määrittelemällä alusta alkaen hyväksytyt työkalut, selkeät datarajat, tarkastusodotukset, kustannusten hallinnan ja varamenettelyt.

En myöskään määräisi yhtä ainoaa työkalua tai työnkulkua liian aikaisin. Teknologia muuttuu liian nopeasti. Parempi lähestymistapa on tarjota suojattu pääsy, uudelleenkäytettävät suojakaiteet, mahdollisuuksia vertaisoppimiseen ja selkeä vastuuvelvollisuus. Insinööri vastaa edelleen siitä, mitä hän suunnittelee, arvioi, yhdistää ja käyttää tuotannossa.

Miksi AI:ta pitäisi käsitellä toimintamallin muutoksena

Neuvoni teknologiajohtajille on käsitellä AI:ta toimintamallin muutoksena, ei työkalun käyttöönottona. Aloita pienestä määrästä arvokkaita työnkulkuja, joissa voit määrittää lähtötason, mitata vaikutuksia ja oppia nopeasti. Rakenna yhteinen AI-alusta ja toimituskurinalaisuus hyväksyttyjen mallien, suojatun pääsyn tietoihin, arvioinnin, havaittavuuden ja uudelleenkäytettävien integraatiomallien ympärille sekä pidä arkkitehtuuri pilvi- ja malliriippumattomana. Näin estetään jokaista tiimiä keksimästä samoja hallintakeinoja uudelleen tai sitoutumasta liian aikaisin yhteen palveluntarjoajaan.

Yhtä tärkeää on panostaa ihmisiin. Eniten hyötyvät organisaatiot eivät ole niitä, jotka yksinkertaisesti tuottavat enemmän koodia. Niitä ovat organisaatiot, jotka auttavat insinöörejä, tuotetiimejä, tietoturvakumppaneita ja liiketoimintajohtajia oppimaan, miten työ muotoillaan selkeästi, miten AI:n tuotokset validoidaan ja miten agenttijärjestelmiä käytetään määriteltyjen rajojen puitteissa. Toimi kiireellisesti, mutta tee luottamuksesta, laadusta, tietoturvasta ja mitattavista tuloksista tinkimättömiä vaatimuksia.

AI:sta on tulossa yrityksen keskeinen toteutuskerros, joten teknologiajohtajan tehtävänä on luoda arkkitehtuuri, hallintamalli ja kulttuuri, joiden ansiosta sitä voidaan skaalata vastuullisesti.

Seuraa mukana

Voit seurata Manish Jainin työtä hänen Substackissaan ja LinkedInissään.

Lisää asiantuntijahaastatteluja luvassa The CTO Clubissa!