Tidligere teknologigrundlægger hos Meta deler tre ting, som alle CTO’er skal gøre, før de tager AI i brug

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

Vi satte os ned med James for at høre, hvordan AI ændrer arbejdsgange 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, kontrolplatformen til AI-agenter, der giver organisationer ét sted at implementere, styre, overvåge og optimere alle agenter i produktion. Vi har rejst 44 mio. USD — en serie A-runde ledet af Google Ventures med deltagelse fra 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 effekt på, hvordan Metas ingeniører brugte AI-værktøjer. I min tid hos Meta var jeg også med til at skabe Diem og fungerede som Instagrams chef for ingeniørarbejde.

Med en 40 år lang 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 medieaktiviteter, 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 sendte ingen kode i produktion i de mest risikable uger for at undgå hændelser i produktionen. Det var sikkert, men det satte også produktiviteten på tværs af virksomheden i stå i over en måned.

Mit team byggede og gjorde Diff Risk Score tilgængelig som open source, et LLM-drevet system, der vurderer sandsynligheden for, at en kodeændring får produktionen til at bryde sammen. I stedet for at betragte alle ændringer som lige farlige under fryseperioden foretog modellen en risikoprioritering. Den tildelte en kontinuerlig risikoscore til hver kodeændring, optimeret til høj genkaldelse — den kunne for eksempel markere 10 % af kodeændringerne, samtidig med at den fangede 60 % af de ændringer, der faktisk forårsagede hændelser. Modellen gjorde det muligt for kodeændringer med lav risiko at blive implementeret selv under frysningen, mens den holdt ændringer tilbage, som den markerede som risikable.

Resultatet er, at frysningen ikke længere er alt eller intet. Og Diff Risk Score gør det muligt for Meta at begynde helt at fjerne kodefrysningen — ingeniørerne får uger tilbage i kalenderen, som tidligere var spildtid, uden at give afkald på det sikkerhedsnet, som frysningen gav.

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

Hvorfor mennesker skal kunne forklare kode, før den går live

Hvis du ikke kan forklare det, kan du ikke sende 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 faglig dømmekraft inden for ingeniørarbejde; den giver ingeniørerne større gennemslagskraft, så de kan anvende denne dømmekraft i stor skala.

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

Her er mennesker bedst:

• Styring og værn omkring selve agenterne: Når teams integrerer ræsonneringsmodeller og agenter dybt i infrastrukturen, opdager de hurtigt styringssvigt — agenter formerer sig hurtigere, end nogen havde 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 infrastrukturen — det betyder, at mennesker stadig fastsætter budgetgrænser, adgangsbegrænsninger og revisionskrav.
• Adoptionsstrategi: Du kan ikke pålægge AI-værktøjer — opnået brug slår pålagt brug, fordi 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 tekniske teams må gentænke deres arkitektur

Tidlig databehandling begyndte med én stormaskine, som alle delte, og bevægede sig derefter over til serverreoler, 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 databehandlingen. 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 verden med mikrotjenester, bortset fra at tjenesterne er agenter i stedet for endepunkter.

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

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

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

Da jeg var hos Meta, begyndte ingeniører at bygge og udgive 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 adoptionen kan gå viralt internt, bygger du omkostningskontrollerne og adgangsbegrænsningerne ind i platformen fra dag ét, ikke som akut brandslukning.

CTO'er skal gentænke grænsen mellem "hvor AI befinder sig" og "hvad AI kan røre ved" — flytte den ud af editoren og ind i infrastrukturen, fordi det er på dette lag, risikoen opstår, og styringen skal ligge.

James deler

CTO’er skal gentænke grænsen mellem “hvor AI befinder sig” og “hvad AI kan røre ved” — flytte den ud af editoren og ind i infrastrukturen, fordi det er på dette lag, risikoen opstår, og styringen skal ligge.

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 denne opgave, og forgrene en af dem i stedet for at begynde fra bunden. Organisationer skal skabe processer, der gør det nemt at stjæle agenter.

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

Her er mit råd:

1. Pålæg det ikke — fortjen det. Pålagt brug af AI for at øge produktiviteten frustrerer mig, fordi det fører til overfladisk anvendelse — de bedste udviklerværktøjer vinder brugernes tillid, og udviklere er intelligente nok til at modsætte sig at få fortalt, hvilke værktøjer de skal holde af. 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 skrive med, og begynd at betragte det som infrastruktur. 2025 var året, hvor kodningsværktøjer som Cursor og Copilot blev almindelige; nu holder ræsonneringsmodeller og agenter i flere trin op med at være tilføjelser til kodeeditorer og bliver i stedet en del af virksomhedernes infrastruktur — de indsender kode, kører test, introducerer nye ingeniører og håndterer adfærd i produktionen. Hvis din AI-strategi stadig handler om "hvilken IDE-udvidelse 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 ræsonneringsmodeller, 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 hver dag i form af medarbejdere. Du er nødt til at anvende nogle af de samme sikkerhedsforanstaltninger på agenter, som du anvender på din arbejdsstyrke. Giv ikke en agent ubegrænset adgang til produktionen, root-adgangsoplysninger 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!