Voormalige technische oprichter van Meta deelt drie dingen die elke CTO moet doen voordat hij AI aanraakt

James Everingham heeft leidinggegeven aan engineering bij enkele van de meest geavanceerde bedrijven ter wereld, waaronder Meta. Momenteel is hij CEO en medeoprichter van Guild.ai, een controlelaag voor AI-agents die organisaties één plek biedt om elke agent in productie te implementeren, te beheren, te observeren en te optimaliseren.

We gingen met James om de tafel om te horen hoe AI engineeringwerkstromen verandert — en wat engineeringteams moeten veranderen voordat AI effectief kan worden geïntegreerd. Dit is wat hij ons vertelde.

Van Meta naar een AI-start-up

Ik ben de CEO en medeoprichter van Guild.ai, de controlelaag voor AI-agents die organisaties één plek biedt om elke agent in productie te implementeren, te beheren, te observeren en te optimaliseren. We hebben $44M opgehaald — een Series A-ronde onder leiding van Google Ventures, met deelname van NFX, Acrew, Scribble Ventures, Khosla Ventures en Webb Investment Network. We zijn een team van ongeveer 35 mensen, gevestigd in San Francisco.

Daarvoor was ik Vice President of Engineering bij Meta DevInfra, waar ik de belangrijkste ontwikkelaarstools, services en platforms bouwde en beheerde die de producten van Meta aandrijven. Mijn team bouwde Meta's eerste interne AI-agent, waarmee we direct invloed hadden op de manier waarop Meta-engineers AI-tools gebruikten. Tijdens mijn tijd bij Meta was ik ook medeoprichter van Diem en Head of Engineering van Instagram.

In een carrière van 40 jaar als manager, ondernemer en technologieontwikkelaar heb ik leidinggegeven aan talrijke engineeringteams van wereldklasse. Bij Yahoo was ik Vice President of Engineering voor de media-eigendommen van Yahoo, nadat het bedrijf Luminate had overgenomen, een interactief technologiebedrijf voor afbeeldingen dat ik had opgericht. Daarvoor gaf ik leiding aan teams bij Oracle, Netscape Communications, Tellme (overgenomen door Microsoft) en verschillende bedrijven van mezelf.

Hoe AI hielp om Meta's jaarlijkse codefreeze af te schaffen

Toen ik bij Meta werkte, gebruikten we een AI-risicomodel om de jaarlijkse codefreeze af te schaffen.

Voorheen bevroor Meta de codebase elk jaar van half december tot en met januari, omdat dit de periode met het meeste verkeer voor de producten was. Jarenlang werd er tijdens de risicovolste weken niets uitgerold om incidenten in productie te voorkomen. Dat was veilig, maar legde ook de productiviteit van het hele bedrijf meer dan een maand stil.

Mijn team bouwde Diff Risk Score en stelde het systeem open source beschikbaar. Dit door een LLM aangedreven systeem beoordeelt de waarschijnlijkheid dat een codeverschil productie laat crashen. In plaats van elke wijziging tijdens de freezeperiode als even gevaarlijk te behandelen, voerde het model risicotriage uit. Het kende aan elk codeverschil een doorlopende risicoscore toe, afgestemd op een hoge recall — zo werd bijvoorbeeld 10% van de codeverschillen gemarkeerd, terwijl 60% van de wijzigingen die daadwerkelijk incidenten veroorzaken werden onderschept. Dankzij het model konden codeverschillen met een laag risico ook tijdens de freeze worden uitgerold, terwijl de gemarkeerde risicovolle wijzigingen werden tegengehouden.

Als gevolg daarvan is de freeze niet langer alles-of-niets. Diff Risk Score helpt Meta bovendien om de codefreeze helemaal af te schaffen — engineers krijgen weken terug op hun kalender die vroeger verloren tijd waren, zonder het vangnet van veiligheid op te offeren dat de freeze bood.

Dat is een goed voorbeeld van mijn bredere filosofie: leg engineers geen AI-mandaat van bovenaf op, maar geef ze infrastructuur — een gecentraliseerd platform, een risicosignaal, een controlelaag — en laat ze zelf ontdekken waar ze de meeste impact kunnen hebben.

Waarom mensen code moeten kunnen uitleggen voordat deze live gaat

Als je het niet kunt uitleggen, kun je het niet uitrollen.

Ik gebruik AI-tools intensief om werk te versnellen, maar ik adviseer engineers om altijd validatie te vereisen voordat iets productie bereikt. AI vervangt het engineeringoordeel niet; het geeft engineers meer mogelijkheden om dat oordeel op schaal toe te passen.

AI speelt nu een rol bij risicobeoordeling, maar ook bij het ontdekken van tools en werkstromen.

Waar mensen het beste in zijn:

• Governance en vangrails rond de agents zelf: Wanneer teams redeneermodellen en agents diep in de infrastructuur integreren, zien ze al snel tekortkomingen in de governance — agents vermenigvuldigen zich sneller dan iemand had verwacht en budgetten verdampen van de ene op de andere dag. Je hebt dezelfde governance-laag nodig rond niet-deterministische agents als rond mensen die deze infrastructuur gebruiken — wat betekent dat mensen nog steeds budgetlimieten, toegangsgrenzen en auditvereisten vaststellen.
• Adoptiestrategie: Je schrijft het gebruik van AI-tools niet voor — gebruik dat wordt verdiend werkt beter dan verplicht gebruik, omdat verplichtingen tot oppervlakkige adoptie leiden. Beslissen hoe AI in de workflow van een team wordt geïntegreerd, is nadrukkelijk een menselijke leiderschaps- en cultuurkwestie — de tool kan zichzelf bewijzen, maar de adoptiebeslissing kan niet worden geautomatiseerd.

Waarom engineeringteams hun architectuur opnieuw moeten doordenken

De vroege computertechnologie begon met één mainframe dat door iedereen werd gedeeld en verschoof daarna naar serverracks waarop gespecialiseerde diensten draaiden. Agents volgen dezelfde ontwikkeling.

De oude aanname was dat je een handvol agents voor algemene doeleinden bouwt en het gebruik daaromheen centraliseert, net zoals je rekenkracht centraliseert. Maar bedrijven beseffen dat hun werkelijkheid niet bestaat uit een handvol gedeelde tools — die lijkt meer op een ecosysteem van gespecialiseerde agents die voor specifieke doeleinden zijn gebouwd. Dit dwingt tot een heroverweging van wat "architectuur" überhaupt betekent voor een codebase: minder een monoliet met plug-ins en meer een wereld van microservices, alleen zijn de services agents in plaats van eindpunten.

Bij de meeste organisaties bestaat de neiging om een agent te behandelen als elk ander stukje software — schrijf de specificatie, lever het op en verwacht consistente output. Ik heb dat losgelaten en vervangen door een mentaal model van een personeelsbestand. Hierdoor worden vragen over de inrichting van de organisatie — wie keurt wat goed, wie beheert het budget, wie is verantwoordelijk als er iets misgaat — managementkwesties in plaats van implementatiekwesties. Het is een andere manier om de relatie van een team met zijn hulpmiddelen vorm te geven.

Waarom governance aanwezig moet zijn voordat de AI-adoptie een vlucht neemt

In mijn eerdere functies had ik gewild dat we de governance-laag hadden opgebouwd voordat de adoptie een vlucht nam, en niet erna.

Toen ik bij Meta werkte, begonnen engineers hun eigen agents te bouwen en te publiceren op het interne platform; de agents vermenigvuldigden zich snel en het infrastructuurteam moest plotseling alle zeilen bijzetten om de vraag bij te houden — letterlijk op zoek naar tienduizenden vrije servers.

Achteraf gezien was dit te voorkomen. Als je ervan uitgaat dat adoptie intern viraal kan gaan, bouw je de kostenbeheersing en toegangsgrenzen vanaf dag één in het platform in, in plaats van ze pas als noodmaatregel in te voeren.

CTO's moeten de grens tussen "waar AI zich bevindt" en "wat AI kan aanraken" opnieuw ontwerpen — en die grens uit de editor naar hun infrastructuur verplaatsen, omdat daar het risico ontstaat en governance moet plaatsvinden.

James deelt

CTO’s moeten de grens tussen “waar AI zich bevindt” en “wat AI kan aanraken” opnieuw ontwerpen — en die grens uit de editor naar hun infrastructuur verplaatsen, omdat daar het risico ontstaat en governance moet plaatsvinden.

Waarom organisaties een gecentraliseerde plek moeten hebben waar agents kunnen worden geforkt

Als engineer was ik een betere dief dan programmeur. Ik zocht iets dat gedeeltelijk aan mijn behoeften voldeed, paste het aan voor mijn specifieke doel en leerde onderweg.

Stap één van de workflow is niet "een model prompten"; het is bladeren door een gecentraliseerde plek om te zien welke agents al voor deze taak bestaan en er één te forken in plaats van helemaal opnieuw te beginnen. Organisaties moeten processen creëren waarmee agents gemakkelijk kunnen worden overgenomen.

Drie adviezen voor CTO's die AI in technische organisaties integreren

Dit is mijn advies:

1. Leg het niet op — verdien het. Verplicht AI-gebruik voor productiviteit frustreert me, omdat het leidt tot oppervlakkige adoptie — de beste ontwikkelaarstools verdienen gebruik, en ontwikkelaars zijn slim genoeg om zich ertegen te verzetten als hun wordt verteld van welke tools ze moeten houden. CTO's zouden de organisatie uitdagingen moeten voorleggen die een orde van grootte groter zijn — problemen die zo groot zijn dat AI de enige realistische oplossing is. Laat vervolgens de ingenieurs die ze oplossen organische evangelisten worden. 
2. Behandel AI niet langer als een hulpmiddel voor het schrijven van code, maar als infrastructuur. 2025 was het jaar waarin coderingstools zoals Cursor en Copilot gangbaar werden; nu houden redeneermodellen en agents met meerdere stappen op slechts editorplug-ins te zijn en worden ze in plaats daarvan onderdeel van de infrastructuur van bedrijven — ze dienen code in, voeren tests uit, helpen nieuwe ingenieurs aan boord en beheren gedrag in productie. Als je AI-strategie nog steeds draait om de vraag "welke IDE-plug-in moeten we kopen?", los je een oud probleem op.
3. Beheer agenten zoals je een personeelsbestand zou beheren, niet zoals je software zou beheren. Agenten die worden aangedreven door redeneermodellen zijn niet-deterministisch — geef dezelfde agent twee keer dezelfde invoer en je kunt verschillende uitvoer krijgen. Dit is geen bug die moet worden opgelost; het is de fundamentele aard van de technologie. CTO's beheren dagelijks al niet-deterministische systemen met werknemers. Je moet op agenten enkele van dezelfde beschermende maatregelen toepassen als op je personeelsbestand. Geef een agent op de eerste dag geen onbeperkte toegang tot productie, rootreferenties of een onbeperkt cloudbudget, net zomin als je die aan een gloednieuwe medewerker zou geven.

Blijf op de hoogte

Je kunt het werk van James Everingham volgen op X en LinkedIn.

Er komen meer expertinterviews op The CTO Club!