Entinen Metan teknologia-alan perustaja kertoo kolme asiaa, jotka jokaisen teknologiajohtajan on tehtävä ennen tekoälyyn tarttumista

James Everingham on johtanut joidenkin maailman edistyneimpien yritysten, kuten Metan, tuotekehitystä. Hän toimii tällä hetkellä Guild.ai-yrityksen toimitusjohtajana ja perustajajäsenenä. Guild.ai on tekoälyagenttien hallintataso, joka tarjoaa organisaatioille yhden paikan jokaisen tuotannossa olevan agentin käyttöönottoon, hallintaan, valvontaan ja optimointiin.

Haastattelimme Jamesia saadaksemme selville, miten tekoäly muuttaa tuotekehityksen työnkulkuja — ja mitä tuotekehitystiimien on muutettava, jotta tekoäly voidaan integroida tehokkaasti. Näin hän vastasi.

Metalta tekoäly-yrityksen perustajaksi

Olen Guild.ai-yrityksen toimitusjohtaja ja perustajajäsen. Guild.ai on tekoälyagenttien hallintataso, joka tarjoaa organisaatioille yhden paikan jokaisen tuotannossa olevan agentin käyttöönottoon, hallintaan, valvontaan ja optimointiin. Olemme keränneet 44 miljoonaa dollaria — Google Venturesin johtaman A-sarjan rahoituskierroksen, johon osallistuivat myös NFX, Acrew, Scribble Ventures, Khosla Ventures ja Webb Investment Network. Tiimissämme on noin 35 jäsentä, ja toimimme San Franciscossa.

Ennen tätä toimin Metan DevInfra-yksikön tuotekehitysjohtajana ja rakensin sekä johdin keskeisiä kehittäjätyökaluja, palveluita ja alustoja, jotka mahdollistavat Metan tuotteet. 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 työskennellessäni olin myös luomassa Diemiä ja toimin Instagramin tuotekehitysjohtajana.

Olen toiminut 40-vuotisen urani aikana johtajana, yrittäjänä ja teknologian kehittäjänä sekä johtanut lukuisia maailmanluokan tuotekehitystiimejä. Yahoolla toimin Yahooon kuuluvien mediasivustojen tuotekehitysjohtajana sen jälkeen, kun yritys oli ostanut perustamani interaktiivisen kuvateknologiayritys Luminaten. Sitä ennen johdin tiimejä Oraclella, Netscape Communicationsilla ja Tellmellä (jonka Microsoft osti) sekä useissa omissa yrityksissäni.

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

Kun työskentelin Metalla, käytimme tekoälyyn perustuvaa riskimallia vuosittaisen koodijäädytyksen lopettamiseen.

Aiemmin Meta jäädytti koodikantansa joka vuosi joulukuun puolivälistä tammikuuhun, koska kyseessä on sen tuotteiden vilkkain ajanjakso. Vuosien ajan kukaan ei vienyt muutoksia tuotantoon riskialtteimpien 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 Score -järjestelmän, joka käyttää suurta kielimallia arvioidakseen, kuinka todennäköisesti koodimuutos kaataa tuotantoympäristön. Sen sijaan, että jokaista muutosta olisi pidetty yhtä vaarallisena jäädytysjakson aikana, malli suoritti riskien luokittelun. Se määritti jokaiselle koodimuutokselle jatkuvan riskipistemäärän ja oli viritetty korkeaan kattavuuteen — esimerkiksi se merkitsi riskialttiiksi 10 % muutoksista ja havaitsi samalla 60 % muutoksista, jotka todellisuudessa aiheuttavat häiriöitä. Mallin ansiosta vähäriskiset muutokset voitiin viedä tuotantoon myös jäädytyksen aikana, kun taas riskialttiiksi merkityt muutokset pidettiin odottamassa.

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

Tämä on hyvä esimerkki laajemmasta toimintaperiaatteestani: älä anna insinööreille ylhäältä alaspäin tulevaa tekoälymääräystä, vaan tarjoa heille infrastruktuuri — keskitetty alusta, riskisignaali ja hallintataso — ja anna heidän itse löytää, miten tekoälystä saadaan suurin hyöty.

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

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

Käytän tekoälytyökaluja aktiivisesti työn nopeuttamiseen, mutta kehotan insinöörejä vaatimaan aina validointia ennen kuin mitään viedään tuotantoon. Tekoäly ei korvaa insinöörien harkintaa, vaan antaa heille enemmän mahdollisuuksia soveltaa tätä harkintaa laajassa mittakaavassa.

Tekoäly tuottaa nykyään tietoa riskien arviointiin sekä työkalujen ja työnkulkujen kartoittamiseen.

Alueet, joilla ihmiset ovat parhaimmillaan:

• Hallinta ja suojamekanismit itse agenteja varten: Kun tiimit upottavat päättelymalleja ja agentteja syvälle infrastruktuuriin, ne näkevät nopeasti hallinnan puutteet — agentit lisääntyvät nopeammin kuin kukaan odotti, ja budjetit haihtuvat yhdessä yössä. Tarvitset epädeterministisille agenteille saman hallintakerroksen, jonka ottaisit käyttöön infrastruktuuria käyttävien ihmisten ympärille — eli ihmiset asettavat edelleen budjettirajat, käyttöoikeuksien rajat ja auditointivaatimukset.
• Käyttöönoton strategia: Tekoälytyökalujen käyttöönottoa ei määrätä — ansaittu käyttö toimii paremmin kuin määrätty käyttö, sillä määräykset johtavat pinnalliseen käyttöönottoon. Päätös siitä, miten tekoäly integroidaan tiimin työnkulkuun, on nimenomaan ihmisten johtamiseen ja kulttuuriin liittyvä päätös — työkalu voi osoittaa arvonsa, mutta käyttöönottoa koskevaa päätöstä ei voi automatisoida.

Miksi suunnittelutiimien on ajateltava arkkitehtuurinsa uudelleen

Varhainen tietojenkäsittely alkoi yhdestä kaikkien jakamasta keskustietokoneesta ja siirtyi sitten erikoistuneita palveluja suorittaviin palvelintelineisiin. Agentit seuraavat samaa kehityskaarta.

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

Useimpien organisaatioiden vaistonvarainen tapa on kohdella agenttia kuten mitä tahansa muuta ohjelmiston osaa — kirjoittaa määrittely, julkaista se ja odottaa yhdenmukaista 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 rikkoutuu — johtamiskysymyksiksi eikä käyttöönottoa koskeviksi kysymyksiksi. Se on erilainen tapa jäsentää tiimin suhdetta työkaluihinsa.

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

Aiemmissa tehtävissäni toivoin, että olisimme rakentaneet hallintakerroksen ennen käyttöönoton kiihtymistä emmekä vasta 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ä kamppailemaan kysynnän perässä — yrittäen kirjaimellisesti löytää kymmeniätuhansia vapaita palvelimia.

Tämä olisi jälkikäteen ajatellen ollut vältettävissä. Jos oletat, että käyttöönotto saattaa levitä sisäisesti kulovalkean tavoin, rakennat kustannustenhallinnan ja käyttöoikeuksien rajat osaksi alustaa heti alusta alkaen etkä hätätoimenpiteenä.

CTO:iden on suunniteltava uudelleen raja sen välillä, ”missä tekoäly sijaitsee” ja ”mihin tekoäly voi koskea” — siirtämällä se editorista infrastruktuuriin, koska juuri tällä tasolla riskit syntyvät ja hallinnan on sijaittava.

James kertoo

\u003cstrong\u003eCTO:iden on suunniteltava uudelleen raja sen välillä, \u0022\u003cem\u003emissä tekoäly sijaitsee\u003c/em\u003e\u0022 ja \u0022mihin tekoäly voi koskea\u003c/em\u003e\u0022 — siirtämällä se editorista infrastruktuuriin, koska juuri tällä tasolla riskit syntyvät ja hallinnan on sijaittava.\u003c/strong\u003e

Miksi organisaatioilla on oltava keskitetty paikka, jossa agenteista voidaan tehdä haaroja

Insinöörinä olin parempi varas kuin koodari. Etsin jotain, joka vastasi tarpeitani osittain, mukautin sen tiettyyn tarkoitukseeni ja opin samalla.

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

Kolme neuvoa CTO:ille tekoälyn integroimiseksi teknisiin organisaatioihin

Tässä neuvoni:

1. Älä määrää sitä — ansaitse se. Pakotettu tekoälyn käyttö tuottavuuden parantamiseksi 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 riittävän älykkäitä vastustamaan sitä, että heille sanellaan, mistä työkaluista heidän pitäisi pitää. Teknologiajohtajien tulisi esittää organisaatiolle suuruusluokaltaan merkittäviä liiketoimintahaasteita — niin suuria ongelmia, että tekoäly on ainoa realistinen ratkaisu. Sen jälkeen niiden ratkaisemiseen osallistuvista insinööreistä tulee luontevasti asian puolestapuhujia. 
2. Lakkaa kohtelemasta tekoälyä sisällön luomiseen tarkoitettuna 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 editorien lisäosia ja muuttuvat sen sijaan osaksi yritysten infrastruktuuria — ne lähettävät koodia, suorittavat testejä, perehdyttävät uusia insinöörejä ja hallinnoivat tuotantoympäristön toimintaa. Jos tekoälystrategiasi on edelleen ”minkä IDE-lisäosan meidän pitäisi hankkia”, ratkaiset vanhaa ongelmaa.
3. Hallinnoi agentteja kuten hallinnoisit työvoimaa, älä kuten ohjelmistoa. Päättelymallien ohjaamat agentit ovat epädeterministisiä — kun annat samalle agentille saman syötteen kahdesti, saatat saada erilaiset tulokset. Tämä ei ole korjattava virhe, vaan teknologian perustavanlaatuinen ominaisuus. Teknologiajohtajat hallinnoivat jo päivittäin epädeterministisiä järjestelmiä työntekijöiden avulla. Agentteihin on sovellettava joitakin samoja suojatoimia kuin työvoimaan. Älä anna agentille rajoittamatonta pääsyä tuotantoympäristöön, pääkäyttäjän tunnistetietoja tai rajoittamatonta pilvipalvelubudjettia heti ensimmäisenä päivänä sen enempää kuin antaisit niitä vastikään palkatulle työntekijälle.

Seuraa

Voit seurata James Everinghamin työtä X:ssä ja LinkedInissä.

Lisää asiantuntijahaastatteluja luvassa The CTO Clubissa!