Tidigare teknikgrundare på Meta delar tre saker som varje CTO måste göra innan AI tas i bruk

James Everingham har lett ingenjörsarbetet på några av världens mest avancerade företag, däribland Meta. Han är för närvarande vd och medgrundare av Guild.ai, en styrplan för AI-agenter som ger organisationer en enda plats för att distribuera, styra, övervaka och optimera alla agenter i produktion.

Vi satte oss ner med James för att ta reda på hur AI förändrar ingenjörers arbetsflöden – och vad ingenjörsteamen behöver förändra innan AI kan integreras effektivt. Här är vad han berättade.

Från Meta till AI-startup

Jag är vd och medgrundare av Guild.ai, styrplanen för AI-agenter som ger organisationer en enda plats för att distribuera, styra, övervaka och optimera alla agenter i produktion. Vi har tagit in 44 miljoner dollar – en serie A-runda ledd av Google Ventures, med deltagande från NFX, Acrew, Scribble Ventures, Khosla Ventures och Webb Investment Network. Vi är ett team på omkring 35 personer och har vårt säte i San Francisco.

Innan dess var jag vice president för teknik på Meta DevInfra, där jag byggde och drev de centrala utvecklarverktygen, tjänsterna och plattformarna som driver Metas produkter. Mitt team byggde Metas första interna AI-agent, vilket omedelbart påverkade hur Metas ingenjörer använde AI-verktyg. Under min tid på Meta var jag också med och skapade Diem och var Instagrams teknikchef.

Under en 40-årig karriär som chef, entreprenör och teknikutvecklare har jag lett många ingenjörsteam i världsklass. På Yahoo var jag vice president för teknik för Yahoos medieverksamheter efter att företaget förvärvat Luminate, ett företag inom interaktiv bildteknik som jag grundade. Dessförinnan ledde jag team på Oracle, Netscape Communications, Tellme (förvärvat av Microsoft) och flera av mina egna företag.

Hur AI hjälpte till att avskaffa Metas årliga kodstopp

När jag var på Meta använde vi en AI-baserad riskmodell för att avskaffa det årliga kodstoppet.

Tidigare frös Meta sin kodbas varje år från mitten av december till januari, eftersom det är den period då företagets produkter har högst trafik. I flera år lanserade ingen något under de mest riskfyllda veckorna för att undvika produktionsincidenter. Det var säkert, men produktiviteten i hela företaget stannade också upp i över en månad.

Mitt team byggde och publicerade Diff Risk Score som öppen källkod, ett LLM-drivet system som bedömer sannolikheten för att en kodändring ska få produktionen att krascha. I stället för att behandla varje ändring som lika farlig under kodstoppet utförde modellen en riskprioritering. Den tilldelade varje kodändring en kontinuerlig riskpoäng, inställd på hög återkallelsegrad – till exempel genom att flagga 10 procent av kodändringarna och samtidigt fånga upp 60 procent av de ändringar som faktiskt orsakar incidenter. Modellen gjorde det möjligt för kodändringar med låg risk att tas i bruk även under kodstoppet, men höll tillbaka dem som flaggats som riskfyllda.

Som ett resultat är kodstoppet inte längre allt eller inget. Och Diff Risk Score gör det möjligt för Meta att börja avskaffa kodstoppet helt – ingenjörerna återfår veckor i kalendern som tidigare var outnyttjade, utan att behöva offra det säkerhetsnät som kodstoppet gav.

Det är ett bra exempel på min bredare filosofi: ge inte ingenjörerna ett toppstyrt AI-mandat, ge dem infrastruktur – en centraliserad plattform, en risksignal och en styrplan – och låt dem själva hitta hävstångseffekten.

Varför människor måste kunna förklara kod innan den tas i drift

Om du inte kan förklara det kan du inte lansera det.

Jag använder AI-verktyg intensivt för att påskynda arbetet, men jag råder ingenjörer att alltid kräva validering innan något når produktionen. AI ersätter inte ingenjörens omdöme; det ger ingenjörer större hävstång för att tillämpa det omdömet i stor skala.

AI bidrar nu till arbetet med riskbedömning samt upptäckt av verktyg och arbetsflöden.

Där människor är bäst:

• Styrning och skyddsräcken kring själva agenterna: När team bäddar in resonemangsmodeller och agenter djupt i infrastrukturen ser de snabbt brister i styrningen — agenterna blir fler snabbare än någon förväntat sig och budgetar försvinner över en natt. Du behöver samma styrningslager kring icke-deterministiska agenter som du skulle ha kring människor som använder infrastrukturen — det innebär att människor fortfarande sätter budgetgränser, åtkomstbegränsningar och krav på granskning.
• Adoptionsstrategi: Du kan inte beordra användning av AI-verktyg — användning som förtjänats slår beordrad användning, eftersom påbud leder till ytlig användning. Att besluta hur AI ska integreras i ett teams arbetsflöde är helt och hållet ett mänskligt ledarskaps- och kulturrelaterat beslut — verktyget kan bevisa sitt värde, men adoptionsbeslutet kan inte automatiseras.

Varför ingenjörsteam måste tänka om kring sin arkitektur

Den tidiga databehandlingen började med en stordator som alla delade på och gick sedan över till rack med servrar som körde specialiserade tjänster. Agenter följer samma utvecklingskurva.

Det gamla antagandet var att bygga en handfull agenter för allmänna ändamål och centralisera användningen kring dem, på samma sätt som man centraliserade datorkraft. Men företag inser att deras verklighet inte består av en handfull delade verktyg — den liknar snarare ett ekosystem av specialiserade, ändamålsbyggda agenter. Detta tvingar fram en omprövning av vad ”arkitektur” ens betyder för en kodbas: mindre monolit med insticksprogram, mer en mikrotjänstevärld, med skillnaden att tjänsterna är agenter i stället för slutpunkter.

Instinkten i de flesta organisationer är att behandla en agent som vilken annan programvara som helst — skriva specifikationen, leverera den och förvänta sig konsekventa resultat. Jag övergav det och ersatte det med en mental modell baserad på en arbetsstyrka. Detta omformulerar frågor om organisationsdesign — vem som godkänner vad, vem som äger budgeten och vem som är ansvarig när något går sönder — till ledningsfrågor, inte driftsättningsfrågor. Det är ett annat sätt att strukturera ett teams relation till sina verktyg.

Varför styrningen måste finnas på plats innan AI-användningen tar fart

I mina tidigare roller önskar jag att vi hade byggt styrningslagret innan användningen tog fart, inte efteråt.

När jag var på Meta började ingenjörerna bygga och publicera sina egna agenter på den interna plattformen; agenterna blev snabbt fler och infrastrukturteamet fick plötsligt kämpa för att möta efterfrågan — bokstavligen försöka hitta tiotusentals lediga servrar.

Så här i efterhand hade detta kunnat undvikas. Om du antar att användningen kan bli viral internt bygger du in kostnadskontroller och åtkomstbegränsningar som en del av plattformen från dag ett, inte som en akut krishanteringsåtgärd.

CTO:er behöver omforma gränsen mellan ”var AI finns” och ”vad AI kan påverka” — flytta den från redigeraren till infrastrukturen, eftersom det är där risken uppstår och styrningen måste finnas.

James delar med sig

CTO:er behöver omforma gränsen mellan “var AI finns” och “vad AI kan påverka” — flytta den från redigeraren till infrastrukturen, eftersom det är där risken uppstår och styrningen måste finnas.

Varför organisationer måste ha en centraliserad plats där agenter kan förgrenas

Som ingenjör var jag bättre på att stjäla än på att koda. Jag hittade något som delvis uppfyllde mina behov, anpassade det för mitt specifika ändamål och lärde mig under vägen.

Det första steget i arbetsflödet är inte att ”skriva en prompt till en modell”, utan att bläddra på en centraliserad plats för att se vilka agenter som redan finns för uppgiften och förgrena en av dem i stället för att börja från noll. Organisationer måste skapa processer som gör det enkelt att ”stjäla” agenter.

Tre råd till CTO:er som integrerar AI i tekniska organisationer

Här är mina råd:

1. Påtvinga det inte – förtjäna det. Påtvingad användning av AI för produktivitet frustrerar mig eftersom det leder till ett ytligt införande – de bästa utvecklarverktygen förtjänar att användas, och utvecklare är tillräckligt smarta för att motsätta sig att bli tillsagda vilka verktyg de ska älska. CTO:er bör presentera affärsutmaningar av en helt annan storleksordning för organisationen – problem som är så stora att AI är den enda realistiska lösningen. Låt sedan ingenjörerna som löser dem bli naturliga ambassadörer. 
2. Sluta se AI som ett verktyg för att skapa innehåll och börja se det som infrastruktur. 2025 var året då kodningsverktyg som Cursor och Copilot slog igenom brett; nu slutar resonemangsmodeller och agenter i flera steg att vara tillägg i kodredigerare och blir i stället en del av företagens infrastruktur – de skickar in kod, kör tester, introducerar nya ingenjörer och hanterar produktionsbeteende. Om din AI-strategi fortfarande handlar om ”vilket tillägg för kodmiljön ska vi köpa?”, löser du ett gammalt problem.
3. Styr agenter som du skulle styra en arbetsstyrka, inte som du skulle styra programvara. Agenter som drivs av resonemangsmodeller är icke-deterministiska – ge samma agent samma indata två gånger, så kan du få olika utdata. Det här är inte ett fel som ska rättas till; det är teknikens grundläggande natur. CTO:er hanterar redan icke-deterministiska system varje dag genom att leda medarbetare. Du behöver tillämpa vissa av samma skyddsräcken på agenter som du tillämpar på din arbetsstyrka. Ge inte en agent obegränsad åtkomst till produktionen, root-behörighet eller en obegränsad molnbudget från dag ett, lika lite som du skulle ge detta till en helt nyanställd.

Följ arbetet

Du kan följa James Everinghams arbete på X och LinkedIn.

Fler expertintervjuer kommer på The CTO Club!