Tidligere Meta-teknologigrundlægger deler tre ting, som alle CTO’er skal gøre, før de rører ved AI

James Everingham har ledet ingeniørarbejdet hos nogle af verdens mest avancerede virksomheder, herunder Meta. Han er i øjeblikket CEO og medstifter af Guild.ai, en kontrolplan for AI-agenter, der giver organisationer ét sted til at implementere, styre, overvåge og optimere alle agenter i produktion.

Vi satte os ned med James for at lære, hvordan AI ændrer arbejdsgangene inden for ingeniørarbejde — og hvad ingeniørteams skal ændre, før AI kan integreres effektivt. Her er, hvad han fortalte os.

Fra Meta til AI-virksomhed

Jeg er CEO og medstifter af Guild.ai, kontrolplanen for AI-agenter, der giver organisationer ét sted til at implementere, styre, overvåge og optimere alle agenter i produktion. Vi har rejst 44 millioner dollar — en serie A-runde ledet af Google Ventures med deltagelse af NFX, Acrew, Scribble Ventures, Khosla Ventures og Webb Investment Network. Vi er et team på omkring 35 personer med base i San Francisco.

Før det var jeg vicepræsident for ingeniørarbejde hos Meta DevInfra, hvor jeg byggede og drev de centrale udviklerværktøjer, tjenester og platforme, der driver Metas produkter. Mit team byggede Metas første interne AI-agent, hvilket havde en øjeblikkelig indvirkning på, hvordan Metas ingeniører brugte AI-værktøjer. Under min tid hos Meta var jeg også med til at skabe Diem og fungerede som Instagrams chef for ingeniørarbejde.

Med en 40-årig karriere som leder, iværksætter og teknologiudvikler har jeg stået i spidsen for adskillige ingeniørteams i verdensklasse. Hos Yahoo var jeg vicepræsident for ingeniørarbejde for Yahoos medieprodukter, efter at virksomheden havde opkøbt Luminate, en interaktiv billedteknologivirksomhed, som jeg grundlagde. Før det ledede jeg teams hos Oracle, Netscape Communications, Tellme (opkøbt af Microsoft) og flere af mine egne virksomheder.

Hvordan AI hjalp med at fjerne Metas årlige kodefrysning

Da jeg var hos Meta, brugte vi en AI-risikomodel til at afskaffe den årlige kodefrysning.

Tidligere frøs Meta sin kodebase hvert år fra midten af december til og med januar, fordi det er den periode, hvor virksomhedens produkter har mest trafik. I årevis udgav ingen kode i de mest risikable uger for at undgå hændelser i produktionen. Det var sikkert, men det satte også produktiviteten i hele virksomheden i stå i over en måned.

Mit team byggede og gjorde Diff Risk Score tilgængeligt som åben kildekode, et LLM-drevet system, der vurderer sandsynligheden for, at en kodeforskel får produktionen til at gå ned. I stedet for at betragte alle ændringer som lige farlige under frysevinduet foretog modellen en risikokategorisering. Den tildelte en kontinuerlig risikoscore til hver kodeforskel, indstillet til høj genkaldelse — den markerede for eksempel 10 % af kodeforskellene, samtidig med at den fangede 60 % af de ændringer, der faktisk forårsager hændelser. Modellen gjorde det muligt at få kodeforskelle med lav risiko i produktion selv under frysningen, mens den holdt dem tilbage, som den markerede som risikable.

Som resultat er frysningen ikke længere et enten-eller. Og Diff Risk Score gør det muligt for Meta at begynde helt at fjerne kodefrysningen — ingeniørerne genvinder uger i deres kalender, som tidligere var spildtid, uden at give afkald på det sikkerhedsnet, frysningen gav.

Det er et godt eksempel på min bredere filosofi: Giv ikke ingeniører et topstyret AI-mandat, giv dem infrastruktur — en centraliseret platform, et risikosignal, en kontrolplan — og lad dem selv finde ud af, hvordan de kan skabe størst effekt.

Hvorfor mennesker skal kunne forklare kode, før den sættes i produktion

Hvis du ikke kan forklare det, kan du ikke sætte det i produktion.

Jeg bruger AI-værktøjer intensivt til at fremskynde arbejdet, men jeg råder ingeniører til altid at kræve validering, før noget når produktionen. AI erstatter ikke ingeniørernes dømmekraft; den giver ingeniørerne større mulighed for at anvende denne dømmekraft i stor skala.

AI indgår nu i arbejdet med risikovurdering samt i opdagelse af værktøjer og arbejdsgange.

Det, mennesker er bedst til:

• Styring og sikkerhedsforanstaltninger omkring selve agenterne: Når teams integrerer ræsonneringsmodeller og agenter dybt i infrastrukturen, opdager de hurtigt styringssvigt — agenter formerer sig hurtigere end forventet, og budgetterne forsvinder fra den ene dag til den anden. Du har brug for det samme styringslag omkring ikke-deterministiske agenter, som du ville etablere omkring mennesker, der bruger denne infrastruktur — det betyder, at mennesker stadig fastsætter budgetgrænser, adgangsbegrænsninger og revisionskrav.
• Adoptionsstrategi: Du kan ikke pålægge brugen af AI-værktøjer — brug, der er opnået gennem tillid, overgår pålagt brug, eftersom påbud fører til overfladisk anvendelse. Beslutningen om, hvordan AI skal integreres i et teams arbejdsgang, er i høj grad en menneskelig ledelses- og kulturmæssig beslutning — værktøjet kan bevise sit værd, men beslutningen om at tage det i brug kan ikke automatiseres.

Hvorfor ingeniørteams må gentænke deres arkitektur

Den tidlige databehandling begyndte med én stormaskine, som alle delte, og bevægede sig derefter videre til serverracks, der kørte specialiserede tjenester. Agenter følger den samme udvikling.

Den gamle antagelse var, at man skulle bygge en håndfuld agenter til generelle formål og centralisere brugen omkring dem, ligesom man centraliserede databehandling. Men virksomheder indser, at deres virkelighed ikke består af en håndfuld delte værktøjer — den minder mere om et økosystem af specialiserede, formålsbyggede agenter. Det tvinger os til at gentænke, hvad "arkitektur" overhovedet betyder for en kodebase: mindre monolit med plugins, mere en mikrotjenesteverden, bortset fra at tjenesterne er agenter i stedet for slutpunkter.

Instinktet i de fleste organisationer er at behandle en agent som ethvert andet stykke software — skrive specifikationen, sende den ud og forvente et ensartet output. Det opgav jeg og erstattede det med en mental model baseret på en arbejdsstyrke. Det omformulerer spørgsmål om organisationsdesign — hvem godkender hvad, hvem ejer budgettet, hvem er ansvarlig, når noget går galt — til ledelsesspørgsmål og ikke implementeringsspørgsmål. Det er en anderledes måde at strukturere et teams forhold til dets værktøjer på.

Hvorfor styring skal være på plads, før anvendelsen af AI tager fart

I mine tidligere roller ville jeg ønske, at vi havde opbygget styringslaget, før anvendelsen tog fart, og ikke bagefter.

Da jeg var hos Meta, begyndte ingeniører at bygge og publicere deres egne agenter på den interne platform; agenterne formerede sig hurtigt, og infrastrukturteamet måtte pludselig kæmpe for at følge med efterspørgslen — helt bogstaveligt forsøge at finde titusindvis af ledige servere.

Set i bakspejlet kunne dette være undgået. Hvis du antager, at anvendelsen kan blive viral internt, indbygger du omkostningskontroller og adgangsbegrænsninger som en del af platformen fra dag ét, ikke som akut krisehåndtering.

CTO'er er nødt til at gentænke grænsen mellem "hvor AI lever" og "hvad AI kan røre ved" — flytte den ud af editoren og ind i deres infrastruktur, fordi det er på dette lag, risikoen opstår, og styringen skal være placeret.

James deler

CTO’er er nødt til at gentænke grænsen mellem “hvor AI lever” og “hvad AI kan røre ved” — flytte den ud af editoren og ind i deres infrastruktur, fordi det er på dette lag, risikoen opstår, og styringen skal være placeret.

Hvorfor organisationer skal have et centraliseret sted, hvor agenter kan forgrenes

Som ingeniør var jeg bedre til at stjæle end til at kode. Jeg fandt noget, der delvist opfyldte mine behov, tilpassede det til mit specifikke formål og lærte undervejs.

Det første trin i arbejdsgangen er ikke "at skrive en prompt til en model"; det er at gennemse et centraliseret sted for at se, hvilke agenter der allerede findes til opgaven, og forgrene en af dem i stedet for at begynde fra bunden. Organisationer skal skabe processer, der gør det let at stjæle agenter.

Tre råd til CTO'er, der integrerer AI i tekniske organisationer

Her er mine råd:

1. Pålæg det ikke — gør det fortjent. Obligatorisk brug af AI for at øge produktiviteten frustrerer mig, fordi det fører til overfladisk anvendelse — de bedste udviklerværktøjer gør sig fortjent til at blive brugt, og udviklere er kloge nok til at modsætte sig at få besked på, hvilke værktøjer de skal elske. CTO'er bør præsentere organisationen for forretningsmæssige udfordringer af en helt anden størrelsesorden — problemer, der er så store, at AI er den eneste realistiske løsning. Lad derefter de ingeniører, der løser dem, blive naturlige fortalere. 
2. Hold op med at betragte AI som et værktøj til at skabe indhold, og begynd at betragte det som infrastruktur. 2025 var året, hvor kodningsværktøjer som Cursor og Copilot blev allemandseje; nu holder modeller med ræsonneringsevne og agenter i flere trin op med at være redigeringsplugins og bliver i stedet en del af virksomheders infrastruktur — de indsender kode, kører tests, introducerer nye ingeniører og håndterer adfærd i produktionen. Hvis din AI-strategi stadig handler om "hvilket IDE-plugin skal vi købe", løser du et gammelt problem.
3. Styr agenter, som du ville styre en arbejdsstyrke, ikke som du ville styre software. Agenter, der drives af modeller med ræsonneringsevne, er ikke-deterministiske — giv den samme agent det samme input to gange, og du kan få forskellige resultater. Det er ikke en fejl, der skal rettes; det er teknologiens grundlæggende natur. CTO'er håndterer allerede ikke-deterministiske systemer dagligt i form af medarbejdere. Du skal anvende nogle af de samme sikkerhedsforanstaltninger på agenter, som du anvender på din arbejdsstyrke. Giv ikke en agent ubegrænset adgang til produktionen, root-legitimationsoplysninger eller et ubegrænset cloudbudget på dag ét, lige så lidt som du ville give det til en helt ny medarbejder.

Følg med

Du kan følge James Everinghams arbejde på X og LinkedIn.

Der kommer flere ekspertinterviews på The CTO Club!