Voormalig technisch oprichter van Meta deelt drie dingen die elke CTO moet doen voordat die 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 besturingslaag voor AI-agents die organisaties één plek biedt om elke agent in productie te implementeren, te beheren, te observeren en te optimaliseren.

We spraken met James om te horen hoe AI engineeringworkflows 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 CEO en medeoprichter van Guild.ai, de besturingslaag 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 kernontwikkelaarstools, -services en -platforms bouwde en beheerde die de producten van Meta aandrijven. Mijn team bouwde Meta's eerste interne AI-agent, wat direct invloed had op de manier waarop Meta-engineers AI-tools gebruikten. Tijdens mijn tijd bij Meta was ik ook medeoprichter van Diem en hoofd Engineering van Instagram.

Met een carrière van 40 jaar als manager, ondernemer en technologieontwikkelaar heb ik leidinggegeven aan talloze engineeringteams van wereldklasse. Bij Yahoo was ik Vice President of Engineering voor de mediadiensten 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 de jaarlijkse codefreeze van Meta af te schaffen

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

Voorheen bevroor Meta zijn 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 het legde ook de productiviteit van het hele bedrijf meer dan een maand stil.

Mijn team bouwde Diff Risk Score en stelde het open source beschikbaar: een door een LLM aangedreven systeem dat inschat hoe groot de kans is dat een codeverschil productie laat crashen. In plaats van elke wijziging tijdens de freezeperiode als even gevaarlijk te behandelen, voerde het model een risicotriage uit. Het kende aan elk codeverschil een doorlopende risicoscore toe, afgestemd op een hoge recall — het markeerde bijvoorbeeld 10% van de codeverschillen, terwijl het 60% van de wijzigingen ving die daadwerkelijk incidenten veroorzaakten. Dankzij het model konden codeverschillen met een laag risico ook tijdens de freeze worden uitgerold, terwijl de codeverschillen die het als risicovol markeerde werden tegengehouden.

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

Dat is een goed voorbeeld van mijn bredere filosofie: leg engineers geen van bovenaf opgelegd AI-mandaat op, maar geef ze infrastructuur — een gecentraliseerd platform, een risicosignaal, een besturingslaag — en laat ze zelf ontdekken waar de hefboomwerking zit.

Waarom mensen code moeten kunnen uitleggen voordat die live gaat

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

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

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

Waar mensen het best in zijn:

• Governance en vangrails rond 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 rond niet-deterministische agents nodig 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 je verdient werkt beter dan verplicht gebruik, omdat verplichtingen tot oppervlakkige adoptie leiden. Beslissen hoe AI in het werkproces 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 technische teams hun architectuur opnieuw moeten overdenken

De vroege computertechnologie begon met één mainframe dat iedereen deelde en verschoof daarna naar serverracks die gespecialiseerde diensten draaiden. Agents volgen dezelfde ontwikkeling.

De oude aanname was dat je een handvol agents voor algemene doeleinden moest bouwen en het gebruik eromheen moest centraliseren, net zoals je rekenkracht centraliseert. Maar bedrijven beseffen dat hun realiteit niet bestaat uit een handvol gedeelde tools — het lijkt meer op een wereld van microservices, behalve dat de services agents zijn in plaats van eindpunten.

Bij de meeste organisaties is de eerste ingeving om een agent te behandelen als elk ander stukje software — schrijf de specificatie, lever het op en verwacht consistente uitvoer. Ik heb dat losgelaten en vervangen door een denkmodel van een personeelsbestand. Hierdoor worden vragen over de inrichting van de organisatie — wie wat goedkeurt, wie eigenaar is van het budget en wie verantwoordelijk is als er iets kapotgaat — managementvragen in plaats van implementatievragen. Het is een andere manier om de relatie van een team tot zijn tools vorm te geven.

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

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

Toen ik bij Meta werkte, begonnen technici 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 als noodmaatregel achteraf toe te voegen.

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

James deelt

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

Waarom organisaties een centrale plek moeten hebben waar agents kunnen worden afgesplitst

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 gaandeweg.

De eerste stap in het werkproces is niet "een model een prompt geven"; het is bladeren door een centrale plek om te zien welke agents al voor deze taak bestaan en er één af te splitsen in plaats van helemaal vanaf nul te beginnen. Organisaties moeten processen creëren waarmee agents gemakkelijk kunnen worden gestolen.

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 worden uit eigen beweging gebruikt, en ontwikkelaars zijn slim genoeg om zich te verzetten tegen de boodschap welke tools ze geweldig moeten vinden. CTO's zouden de organisatie zakelijke uitdagingen van een orde van grootte moeten voorleggen — problemen die zo groot zijn dat AI de enige realistische oplossing is. Laat vervolgens de engineers die ze oplossen vanzelfsprekende ambassadeurs 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 gemeengoed werden; nu ontgroeien redeneermodellen en agents die meerdere stappen uitvoeren editorplug-ins en worden ze in plaats daarvan onderdeel van de infrastructuur van bedrijven — ze dienen code in, voeren tests uit, begeleiden nieuwe engineers bij hun inwerktraject 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 agents zoals je een personeelsbestand zou beheren, niet zoals software. Agents 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 je moet oplossen; het is de fundamentele aard van de technologie. CTO's beheren dagelijks al niet-deterministische systemen met medewerkers. Je moet op agents een aantal van dezelfde waarborgen toepassen als op je personeelsbestand. Geef een agent vanaf dag één geen onbeperkte toegang tot productie, root-referenties of een onbeperkt cloudbudget, net zomin als je die aan een kersverse medewerker zou geven.

Volg mee

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

Er volgen meer interviews met experts op The CTO Club!