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, ett kontrollplan för AI-agenter som ger organisationer en enda plats för att distribuera, styra, observera och optimera varje agent i produktion.

Vi satte oss ner med James för att lära oss hur AI förändrar ingenjörernas arbetsflöden – och vad ingenjörsteam 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, kontrollplanet för AI-agenter som ger organisationer en enda plats för att distribuera, styra, observera och optimera varje agent i produktion. Vi har tagit in 44 miljoner dollar – en 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 är baserade i San Francisco.

Innan dess var jag teknikchef på Meta DevInfra, där jag byggde och drev de centrala utvecklarverktyg, tjänster och plattformar som driver Metas produkter. Mitt team byggde Metas första interna AI-agent, vilket gav omedelbar effekt på 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 teknikchef för Yahoos medieegendomar 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 och Tellme (som förvärvades av Microsoft), samt på flera av mina egna företag.

Hur AI bidrog till att ta bort Metas årliga kodfrysning

När jag arbetade på Meta använde vi en AI-baserad riskmodell för att avskaffa den årliga kodfrysningen.

Tidigare frös Meta sin kodbas varje år från mitten av december till och med januari, eftersom det är den period då företagets produkter har flest besökare. Under flera år skickade ingen ut kod under de mest riskfyllda veckorna för att undvika produktionsincidenter. Det var säkert, men det stoppade också produktiviteten i hela företaget i över en månad.

Mitt team byggde och gjorde Diff Risk Score till öppen källkod, ett LLM-drivet system som bedömer sannolikheten för att en kodskillnad ska få produktionen att krascha. I stället för att behandla varje ändring som lika farlig under frysningsperioden utförde modellen en riskprioritering. Den tilldelade varje kodskillnad en kontinuerlig riskpoäng, anpassad för hög täckningsgrad – till exempel genom att flagga 10 % av kodskillnaderna samtidigt som den fångade 60 % av de ändringar som faktiskt orsakar incidenter. Modellen gjorde det möjligt för kodskillnader med låg risk att släppas även under frysningen, medan den höll tillbaka sådana som flaggades som riskfyllda.

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

Det är ett bra exempel på min bredare filosofi: ge inte ingenjörer ett beslut om AI uppifrån. Ge dem infrastruktur – en centraliserad plattform, en risksignal, ett kontrollplan – och låt dem själva hitta hävstångseffekterna.

Varför människor måste kunna förklara kod innan den driftsätts

Om du inte kan förklara det kan du inte driftsätta 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örers omdöme; det ger ingenjörer större hävstång för att tillämpa det omdömet i stor skala.

AI ger nu underlag för riskbedömning samt för att upptäcka 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 budgetarna försvinner över en natt. Du behöver samma styrningslager kring icke-deterministiska agenter som du skulle ha kring människor som använder den infrastrukturen — det innebär att människor fortfarande sätter budgetgränser, åtkomstbegränsningar och krav på granskning.
• Adoptionsstrategi: Du kan inte kräva att AI-verktyg ska användas — användning som förtjänats slår påtvingad användning, eftersom krav 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 kultur 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 datoranvändningen började med en stordator som alla delade på och gick sedan över till serverrack 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, ungefär 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 ett nytänkande kring vad ”arkitektur” ens betyder för en kodbas: mindre monolit med insticksprogram, mer en mikrotjänstevärld, förutom 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 synsättet och ersatte det med en mental modell av en arbetsstyrka. Det omformulerar frågor om organisationsdesign — vem godkänner vad, vem äger budgeten och vem ä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 vara 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 arbetade på Meta började ingenjörer bygga och publicera egna agenter på den interna plattformen; agenterna blev snabbt fler och infrastrukturteamet fick plötsligt kämpa för att hålla jämna steg med efterfrågan — de försökte bokstavligen hitta tiotusentals lediga servrar.

Så här i efterhand hade detta kunnat undvikas. Om du utgår från att användningen kan bli viral internt bygger du in kostnadskontroller och åtkomstbegränsningar som en del av plattformen från dag ett, i stället för att hantera dem som akut krishantering.

CTO:er behöver omforma gränsen mellan ”var AI finns” och ”vad AI kan komma åt” — flytta den från redigeraren till infrastrukturen, eftersom det är på den nivån som riskerna 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 komma åt” — flytta den från redigeraren till infrastrukturen, eftersom det är på den nivån som riskerna 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 längs vägen.

Det första steget i arbetsflödet är inte att ”skriva en prompt till en modell”, utan att gå till 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. Kräv det inte – förtjäna det. Påtvingad AI-användning för produktivitet frustrerar mig eftersom den 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 göra motstånd när de blir tillsagda vilka verktyg de ska älska. CTO:er bör presentera affärsutmaningar av storleksordningen 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 behandla AI som ett verktyg för att skapa innehåll och börja behandla det som infrastruktur. 2025 var året då kodningsverktyg som Cursor och Copilot blev etablerade på bred front; nu slutar resonemangsmodeller och agenter i flera steg att vara tillägg i redigerare och blir i stället en del av företagens infrastruktur – de skickar in kod, kör tester, introducerar nya ingenjörer och hanterar beteendet i produktion. Om din AI-strategi fortfarande handlar om ”vilket tillägg för utvecklingsmiljö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 ickedeterministiska – ge samma agent samma indata två gånger, så kan du få olika utdata. Det här är inte ett fel som ska åtgärdas; det är teknikens grundläggande natur. CTO:er hanterar redan ickedeterministiska system dagligen i form av medarbetare. Du måste 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 den första dagen, lika lite som du skulle ge detta till en helt nyanställd.

Följ med

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

Fler expertintervjuer kommer på CTO-klubben!