Ex-Meta tech founder shares three things that every CTO must do before touching AI

James Everingham has led engineering at some of the world's most advanced companies, including Meta. He's currently the CEO and cofounder of Guild.ai, a control plane for AI agents, giving organizations one place to deploy, govern, observe, and optimize every agent in production.

We sat down with James to learn how AI is changing engineering workflows — and what engineering teams need to change before AI can be effectively integrated. Here's what he told us.

From Meta to AI startup

I'm the CEO and co-founder of Guild.ai, the control plane for AI agents, giving organizations one place to deploy, govern, observe, and optimize every agent in production. We've raised $44M — a Series A led by Google Ventures, with participation from NFX, Acrew, Scribble Ventures, Khosla Ventures, and Webb Investment Network. We're a team of about 35, based in San Francisco.

Before this, I was the Vice President of Engineering at Meta DevInfra, building and running the core developer tools, services, and platforms powering Meta's products. My team built Meta's first internal AI agent, delivering immediate impact on how Meta engineers used AI tooling. During my time at Meta, I also co-created Diem and served as Instagram's Head of Engineering.

With a 40-year career as a manager, entrepreneur, and technology developer, I've led numerous world-class engineering teams. At Yahoo, I was Vice President of Engineering for Yahoo's media properties after they acquired Luminate, an interactive image technology company I founded. Before that, I led teams at Oracle, Netscape Communications, Tellme (acquired by Microsoft), and several of my own companies.

How AI helped to remove Meta's annual code freeze

When I was at Meta, we used an AI risk model to kill the annual code freeze.

Before, Meta froze its codebase every year from mid-December through January, because that is the highest-traffic period for its products. For years, to avoid production incidents during the riskiest weeks, nobody shipped. This was safe, but it also stalled company-wide productivity for over a month.

My team built and open-sourced Diff Risk Score, an LLM-powered system that scores the likelihood of a code diff crashing production. Instead of treating every change as equally dangerous during the freeze window, the model performed risk triage. It assigned a continuous risk score to every diff, tuned for high recall — for example, flagging 10% of diffs while catching 60% of the changes that actually cause incidents. The model allowed low-risk diffs to land even during the freeze, but held those it flagged as risky.

As a result, the freeze is no longer all-or-nothing. And the Diff Risk Score is enabling Meta to start removing the code freeze altogether — engineers are regaining weeks of their calendar that used to be dead time, without sacrificing the safety net the freeze provided.

That's a good example of my broader philosophy: don't hand engineers a top-down AI mandate, give them infrastructure — a centralized platform, a risk signal, a control plane — and let them find the leverage themselves.

Why humans must be able to explain code before it goes live

If you can't explain it, you can't ship it.

I use AI tools aggressively to accelerate work, but I advise engineers to always require validation before anything reaches production. AI doesn't replace engineering judgment; it gives engineers more leverage to apply that judgment at scale.

AI now informs the work in risk assessment, as well as tooling and workflow discovery.

Where humans are best:

• Governance and guardrails around agents themselves: When teams embed reasoning models and agents deep into infrastructure, they quickly see governance failures — agents multiply faster than anyone expected, and budgets evaporate overnight. You need the same governance layer around non-deterministic agents that you would put around humans using that infrastructure — meaning humans still set budget limits, access boundaries, and audit requirements.
• Adoption strategy: You don't mandate AI tool adoption — earned usage beats mandated usage, since mandates produce shallow adoption. Deciding how to integrate AI into a team's workflow is squarely a human leadership and cultural decision — the tool can prove itself, but the adoption decision cannot be automated.

Why engineering teams must rethink their architecture

Early computing started with one mainframe everyone shared, then moved to racks of servers running specialized services. Agents are following the same arc.

The old assumption was to build a handful of general-purpose agents and centralize usage around them, like centralizing compute. But companies realize their reality isn't a handful of shared tools — it's closer to an ecosystem of specialized, purpose-built agents. This forces a rethink of what "architecture" even means for a codebase: less monolith-with-plugins, more a microservices world, except the services are agents instead of endpoints.

The instinct in most orgs is to treat an agent like any other piece of software — write the spec, ship it, expect consistent output. I abandoned that, replacing it with a workforce mental model. This reframes org design questions — who approves what, who owns budget, who's accountable when something breaks — as management questions, not deployment questions. It's a different way to structure a team's relationship to its tooling.

Why governance must be in place before AI adoption takes off

In my earlier roles, I wish we'd built the governance layer before adoption took off, not after.

When I was at Meta, engineers started building and publishing their own agents to the internal platform; the agents multiplied rapidly, and the infrastructure team suddenly scrambled to keep up with demand — literally trying to find tens of thousands of free servers.

This was avoidable in hindsight. If you assume adoption might go viral internally, you build the cost controls and access boundaries as part of the platform from day one, not as emergency triage.

CTOs need to redesign the boundary between "where AI lives" and "what AI can touch" — moving it out of the editor and into their infrastructure, because that's the layer where risk originates and governance must reside.

James Shares

CTOs need to redesign the boundary between “where AI lives” and “what AI can touch” — moving it out of the editor and into their infrastructure, because that’s the layer where risk originates and governance must reside.

Why organizations must have a centralized place where agents can be forked

As an engineer, I was a better thief than coder. I would find something that partially met my needs, adapt it for my specific purpose, and learn along the way.

Step one of the workflow isn't "prompt a model"; it's browsing a centralized place to see what agents already exist for this task and forking one instead of starting cold. Organizations must create processes to allow agents to be easily stolen.

Three pieces of advice for CTOs integrating AI into technical organizations

Here's my advice:

1. Don't mandate it — earn it. Mandated AI use for productivity frustrates me because it produces shallow adoption — the best developer tools earn usage, and developers are smart enough to resist being told which tools to love. CTOs should present order-of-magnitude business challenges to the organization — problems so big that AI is the only realistic solution. Then, let the engineers who solve them become organic evangelists. 
2. Stop treating AI as an authoring tool and start treating it as infrastructure. 2025 was the year coding tools like Cursor and Copilot went mainstream; now, reasoning models and multi-step agents stop being editor plugins and, instead, become part of the infrastructure of companies — submitting code, running tests, onboarding new engineers, and managing production behavior. If your AI strategy is still "which IDE plugin should we buy," you're solving an old problem.
3. Govern agents like you'd govern a workforce, not like you'd govern software. Agents powered by reasoning models are non-deterministic — give the same agent the same input twice, and you can get different outputs. This isn't a bug to fix; it's the technology's fundamental nature. CTOs already manage non-deterministic systems daily with employees. You need to apply some of the same guardrails to agents that you apply to your workforce. Don't give an agent unrestricted production access, root credentials, or an unlimited cloud budget on day one any more than you'd give those to a brand-new hire.

Follow along

You can follow James Everingham's work on X and LinkedIn.

More expert interviews to come on The CTO Club!