Den tidigare teknikgrundaren på Meta delar tre saker som varje teknikchef måste göra innan de börjar arbeta med AI

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 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örsarbetsflö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-företag

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 $44M — 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å cirka 35 personer baserat i San Francisco.

Innan dess var jag vice president för ingenjörsverksamheten 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 tekniska chef.

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 ingenjörsverksamheten för Yahoos medieprodukter efter att företaget förvärvade 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 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 och med januari, eftersom det är den period då företagets produkter har som högst trafik. Under flera år skickade ingen ut kod för att undvika produktionsincidenter under de mest riskfyllda veckorna. Det var säkert, men det gjorde också att produktiviteten i hela företaget stannade av i över en månad.

Mitt team byggde och gjorde Diff Risk Score tillgängligt som öppen källkod, ett LLM-drivet system som bedömer sannolikheten för att en kodskillnad ska orsaka en produktionskrasch. I stället för att behandla varje förändring som lika farlig under kodstoppet genomförde modellen en riskprioritering. Den tilldelade varje kodskillnad ett kontinuerligt riskvärde, inställt för hög känslighet — till exempel genom att flagga 10 % av kodskillnaderna samtidigt som 60 % av de förändringar som faktiskt orsakar incidenter fångades upp. Modellen gjorde det möjligt för kodskillnader med låg risk att släppas även under kodstoppet, men höll tillbaka dem som flaggades som riskfyllda.

Som 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 gick förlorade, utan att behöva offra det säkerhetsnät som kodstoppet gav.

Det är ett bra exempel på min övergripande filosofi: ge inte ingenjörerna ett toppstyrt AI-direktiv, utan ge dem infrastruktur — en centraliserad plattform, en risksignal, ett kontrollplan — 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 sätta det i produktion.

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örernas omdöme; det ger ingenjörerna större hävstång för att tillämpa det omdömet i stor skala.

AI ger nu underlag för arbetet med riskbedömning, liksom för upptäckt av verktyg och arbetsflöden.

Det här är människor bäst på:

• 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 — vilket innebär att människor fortfarande sätter budgetgränser, åtkomstgränser och krav på granskning.
• Adoptionsstrategi: Du kan inte föreskriva användning av AI-verktyg — användning som förtjänats slår föreskriven användning, eftersom föreskrifter 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 kulturval — verktyget kan bevisa sitt värde, men adoptionsbeslutet kan inte automatiseras.

Varför tekniska team måste tänka om kring sin arkitektur

Tidig databehandling 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 centraliserar datorkraft. Men företag inser att deras verklighet inte består av en handfull delade verktyg — den liknar mer 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 plugin-program, 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 och ersatte det med en mental modell av en arbetsstyrka. Detta 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 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örer bygga och publicera sina 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 — bokstavligen försöka hitta tiotusentals lediga servrar.

Med facit i hand hade detta kunnat undvikas. Om du antar att användningen kan bli viral internt bygger du in kostnadskontroller och åtkomstgränser i plattformen från dag ett, i stället för att hantera dem som en akut krisinsats.

CTO:er behöver rita om 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 rita om 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 ”skriv 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. Föreskriv 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 stå emot 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 förespråkare. 
2. Sluta behandla AI som ett verktyg för kodskapande och börja behandla det som infrastruktur. 2025 var året då kodverktyg som Cursor och Copilot blev allmänt använda; nu slutar resonemangsmodeller och agenter med flera steg att vara insticksprogram 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 insticksprogram för utvecklingsmiljön ska vi köpa?” försöker du lösa 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 resultat. Det här är inte ett fel som ska åtgärdas; det är teknikens grundläggande natur. CTO:er hanterar redan icke-deterministiska system varje dag i form av 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 första dagen, lika lite som du skulle ge sådant till en helt nyanställd.

Följ med

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

Fler expertintervjuer kommer hos The CTO Club!