Entinen Metan teknologiajohtaja kertoo kolme asiaa, jotka jokaisen teknologiajohtajan on tehtävä ennen tekoälyn käyttöönottoa

James Everingham on johtanut joidenkin maailman edistyksellisimpien yritysten, kuten Metan, suunnittelutoimintaa. Tällä hetkellä hän toimii Guild.ai:n toimitusjohtajana ja toisena perustajana. Guild.ai on tekoälyagenttien hallintataso, joka tarjoaa organisaatioille yhden paikan kaikkien tuotannossa olevien agenttien käyttöönottoon, hallintaan, seurantaan ja optimointiin.

Tapasimme Jamesin saadaksemme tietää, miten tekoäly muuttaa suunnittelun työnkulkuja – ja mitä suunnittelutiimien on muutettava, jotta tekoäly voidaan ottaa tehokkaasti käyttöön. Tässä on, mitä hän kertoi meille.

Metasta tekoäly-yritykseen

Olen Guild.ai:n toimitusjohtaja ja toinen perustaja. Guild.ai on tekoälyagenttien hallintataso, joka tarjoaa organisaatioille yhden paikan kaikkien tuotannossa olevien agenttien käyttöönottoon, hallintaan, seurantaan ja optimointiin. Olemme keränneet 44 miljoonaa dollaria – kyseessä on Google Venturesin johtama A-sarja, johon osallistuivat myös NFX, Acrew, Scribble Ventures, Khosla Ventures ja Webb Investment Network. Tiimimme koostuu noin 35 henkilöstä, ja toimimme San Franciscossa.

Ennen tätä toimin Metan DevInfran suunnittelujohtajana ja rakensin sekä johdin Metan tuotteiden taustalla olevia keskeisiä kehittäjätyökaluja, -palveluita ja -alustoja. Tiimini rakensi Metan ensimmäisen sisäisen tekoälyagentin, jolla oli välitön vaikutus siihen, miten Metan insinöörit käyttivät tekoälytyökaluja. Metalla ollessani olin myös mukana luomassa Diemiä ja toimin Instagramin suunnittelujohtajana.

Olen työskennellyt 40-vuotisen urani aikana johtajana, yrittäjänä ja teknologian kehittäjänä sekä johtanut lukuisia maailmanluokan suunnittelutiimejä. Yahoolla toimin Yahoon mediaomaisuuksien suunnittelujohtajana sen jälkeen, kun yritys oli ostanut perustamani interaktiivisen kuvateknologiayrityksen Luminaten. Tätä ennen johdin tiimejä Oraclella, Netscape Communicationsilla ja Tellmellä (jonka Microsoft osti) sekä useissa omissa yrityksissäni.

Miten tekoäly auttoi Metaa luopumaan vuotuisesta koodijäädytyksestä

Ollessani Metalla käytimme tekoälyyn perustuvaa riskimallia vuotuisen koodijäädytyksen lopettamiseen.

Aiemmin Meta jäädytti koodikantansa joka vuosi joulukuun puolivälistä tammikuuhun, koska kyseessä on sen tuotteiden vilkkain liikennekausi. Vuosien ajan kukaan ei vienyt muutoksia tuotantoon riskialttiimpien viikkojen aikana tuotantohäiriöiden välttämiseksi. Tämä oli turvallista, mutta samalla se pysäytti koko yrityksen tuottavuuden yli kuukaudeksi.

Tiimini rakensi ja julkaisi avoimena lähdekoodina Diff Risk Scoren, suurten kielimallien avulla toimivan järjestelmän, joka arvioi, kuinka todennäköisesti koodin erotus kaataa tuotantoympäristön. Sen sijaan, että jokaista muutosta olisi pidetty yhtä vaarallisena jäädytysjakson aikana, malli suoritti riskien luokittelun. Se antoi jokaiselle erotukselle jatkuvan riskipisteytyksen, joka oli säädetty korkeaan kattavuuteen – esimerkiksi se merkitsi 10 % erotuksista ja havaitsi samalla 60 % niistä muutoksista, jotka todellisuudessa aiheuttavat häiriöitä. Malli salli vähäisen riskin erotusten viemisen tuotantoon myös jäädytyksen aikana, mutta pidätti riskialttiiksi merkitsemänsä erotukset.

Tämän seurauksena jäädytys ei enää ole kaikki tai ei mitään -ratkaisu. Diff Risk Score auttaa Metaa myös aloittamaan koodijäädytyksestä luopumisen kokonaan – insinöörit saavat takaisin kalenteristaan viikkoja, jotka aiemmin olivat joutoaikaa, tinkimättä jäädytyksen tarjoamasta turvaverkosta.

Tämä on hyvä esimerkki laajemmasta ajattelutavastani: älä anna insinööreille ylhäältä annettua tekoälymääräystä, vaan tarjoa heille infrastruktuuri – keskitetty alusta, riskisignaali ja hallintataso – ja anna heidän itse löytää, miten siitä saa eniten hyötyä.

Miksi ihmisten on pystyttävä selittämään koodi ennen sen viemistä tuotantoon

Jos et pysty selittämään sitä, et voi viedä sitä tuotantoon.

Käytän tekoälytyökaluja aktiivisesti työn nopeuttamiseen, mutta neuvon insinöörejä vaatimaan aina validointia ennen kuin mitään viedään tuotantoon. Tekoäly ei korvaa suunnitteluun liittyvää harkintaa, vaan antaa insinööreille enemmän vipuvoimaa tämän harkinnan soveltamiseen mittakaavassa.

Tekoäly ohjaa nykyään työtä riskien arvioinnissa sekä työkalujen ja työnkulkujen kartoittamisessa.

Missä ihmiset ovat parhaimmillaan:

• Agenttien hallinto ja suojakaiteet: Kun tiimit upottavat päättelymalleja ja agentteja syvälle infrastruktuuriin, ne näkevät nopeasti hallinnon puutteet — agenttien määrä kasvaa nopeammin kuin kukaan odotti, ja budjetit haihtuvat yhdessä yössä. Tarvitset saman hallintokerroksen ei-determinististen agenttien ympärille kuin infrastruktuuria käyttävien ihmisten ympärille — eli ihmiset määrittävät edelleen budjettirajat, käyttöoikeuksien rajat ja auditointivaatimukset.
• Käyttöönottostrategia: Tekoälytyökalujen käyttöönottoa ei määrätä — ansaittu käyttö voittaa määrätyn käytön, sillä määräykset johtavat pinnalliseen käyttöönottoon. Päätös siitä, miten tekoäly integroidaan tiimin työnkulkuun, on selvästi ihmisten johtamiseen ja kulttuuriin liittyvä päätös — työkalu voi osoittaa hyödyllisyytensä, mutta käyttöönottopäätöstä ei voi automatisoida.

Miksi suunnittelutiimien on ajateltava arkkitehtuurinsa uudelleen

Varhainen tietojenkäsittely alkoi yhdestä kaikkien jakamasta keskustietokoneesta ja siirtyi sitten palvelintelineisiin, joissa ajettiin erikoistuneita palveluita. Agentit kulkevat samaa kehityskaarta.

Vanha oletus oli rakentaa kourallinen yleiskäyttöisiä agentteja ja keskittää niiden käyttö niiden ympärille, aivan kuten laskenta keskitetään. Yritykset kuitenkin ymmärtävät, ettei niiden todellisuus koostu kourallisesta jaettuja työkaluja — se muistuttaa enemmän erikoistuneiden, tiettyyn tarkoitukseen rakennettujen agenttien ekosysteemiä. Tämä pakottaa ajattelemaan uudelleen, mitä ”arkkitehtuuri” edes tarkoittaa koodipohjan kannalta: vähemmän monoliittia liitännäisineen, enemmän mikropalvelumaailmaa, paitsi että palvelut ovat päätepisteiden sijaan agentteja.

Useimpien organisaatioiden vaistona on kohdella agenttia kuten mitä tahansa muuta ohjelmistoa — kirjoittaa määrittely, julkaista se ja odottaa johdonmukaista tulosta. Luovuin tästä ja korvasin sen työvoimaa koskevalla ajattelumallilla. Tämä muuttaa organisaation suunnitteluun liittyvät kysymykset — kuka hyväksyy mitäkin, kuka omistaa budjetin ja kuka on vastuussa, kun jokin menee rikki — johtamiskysymyksiksi, ei käyttöönottokysymyksiksi. Se on erilainen tapa jäsentää tiimin suhdetta työkaluihinsa.

Miksi hallinnon on oltava kunnossa ennen tekoälyn käyttöönoton kiihtymistä

Aiemmissa tehtävissäni toivoin, että olisimme rakentaneet hallintokerroksen ennen käyttöönoton kiihtymistä, emme sen jälkeen.

Kun työskentelin Metalla, insinöörit alkoivat rakentaa ja julkaista omia agenttejaan sisäiselle alustalle; agenttien määrä kasvoi nopeasti, ja infrastruktuuritiimi joutui yhtäkkiä kiireellä vastaamaan kysyntään — kirjaimellisesti yrittäen löytää kymmeniätuhansia vapaita palvelimia.

Tämä olisi jälkikäteen ajateltuna ollut vältettävissä. Jos oletat, että käyttöönotto voi levitä sisäisesti kulovalkean tavoin, rakennat kustannusten hallinnan ja käyttöoikeuksien rajat osaksi alustaa heti alusta lähtien, etkä kiireellisenä hätätoimenpiteenä.

Teknologiajohtajien on suunniteltava uudelleen raja sen välillä, ”missä tekoäly sijaitsee” ja ”mihin tekoäly voi koskea” — siirrettävä se editorista infrastruktuuriin, koska riskit syntyvät tällä tasolla ja hallinnon on sijaittava siellä.

James kertoo

Teknologiajohtajien on suunniteltava uudelleen raja sen välillä, “missä tekoäly sijaitseemihin tekoäly voi koskea

Miksi organisaatioilla on oltava keskitetty paikka, jossa agentteja voidaan haarauttaa

Insinöörinä olin parempi varastamaan kuin koodaamaan. Etsin jotain, joka vastasi tarpeitani osittain, muokkasin sitä omaan tarkoitukseeni sopivaksi ja opin samalla.

Työnkulun ensimmäinen vaihe ei ole ”kehota mallia”, vaan keskitetyn paikan selaaminen sen selvittämiseksi, mitä agentteja tätä tehtävää varten on jo olemassa, ja yhden haarauttaminen sen sijaan, että aloitettaisiin tyhjästä. Organisaatioiden on luotava prosessit, joiden avulla agentteja voidaan helposti kopioida.

Kolme neuvoa teknologiajohtajille, jotka integroivat tekoälyä teknisiin organisaatioihin

Tässä neuvoni:

1. Älä määrää sitä – ansaitse se. Tuottavuuden vuoksi määrätty tekoälyn käyttö turhauttaa minua, koska se johtaa pinnalliseen käyttöönottoon – parhaat kehittäjätyökalut ansaitsevat käyttäjien hyväksynnän, ja kehittäjät ovat tarpeeksi fiksuja vastustaakseen sitä, että heille sanellaan, mistä työkaluista heidän pitäisi pitää. Teknologiajohtajien tulisi esittää organisaatiolle suuruusluokan liiketoimintahaasteita – niin suuria ongelmia, että tekoäly on ainoa realistinen ratkaisu. Sen jälkeen on annettava niitä ratkaisevien insinöörien toimia luontaisina puolestapuhujina. 
2. Lakkaa kohtelemasta tekoälyä sisällön tuottamisen työkaluna ja ala kohdella sitä infrastruktuurina. Vuosi 2025 oli vuosi, jolloin Cursorin ja Copilotin kaltaiset koodaustyökalut yleistyivät; nyt päättelymallit ja monivaiheiset agentit lakkaavat olemasta editorin lisäosia ja muuttuvat sen sijaan osaksi yritysten infrastruktuuria – ne lähettävät koodia, suorittavat testejä, perehdyttävät uusia insinöörejä ja hallitsevat tuotantoympäristön toimintaa. Jos tekoälystrategiasi on edelleen ”minkä IDE-lisäosan meidän pitäisi hankkia”, ratkaiset vanhaa ongelmaa.
3. Hallinnoi agentteja samalla tavalla kuin hallinnoisit työvoimaa, älä samalla tavalla kuin hallinnoisit ohjelmistoja. Päättelymalleihin perustuvat agentit ovat epädeterministisiä – anna samalle agentille sama syöte kahdesti, ja voit saada erilaiset tulokset. Tämä ei ole korjattava virhe, vaan teknologian perustavanlaatuinen ominaisuus. Teknologiajohtajat hallitsevat jo päivittäin epädeterministisiä järjestelmiä työntekijöiden avulla. Sinun on sovellettava agentteihin joitakin samoja suojamekanismeja kuin työvoimaasi. Älä anna agentille rajoittamatonta pääsyä tuotantoympäristöön, pääkäyttäjän tunnistetietoja tai rajatonta pilvipalvelubudjettia ensimmäisenä päivänä sen enempää kuin antaisit niitä vasta palkatulle työntekijälle.

Pysy ajan tasalla

Voit seurata James Everinghamin työtä palveluissa X ja LinkedIn.

Lisää asiantuntijahaastatteluja tulossa The CTO Clubiin!