Building Developer Infrastructure at Scale: Office Hours w/ James Everingham
What does it take to move AI coding tools from individual experiments into the daily work of thousands of engineers? James Everingham, cofounder and CEO of Guild.ai and former leader of developer infrastructure at Meta, joins Tomasz Tunguz on Office Hours to share what he learned. The conversation covers the shift from autocomplete to shared agents, the infrastructure those agents need, and why engineering leaders should measure the constraints they remove rather than the volume of code they produce.
In our conversation, we discuss:
- What supporting tens of thousands of developers at Meta taught James about infrastructure
- Why autocomplete was only the beginning of AI’s impact on engineering
- How shared agents and visible demonstrations helped adoption spread
- Why agents belong in background workflows as well as chat interfaces
- What an agent control plane needs for releases, access, observability, and budgets
- How teams can own evaluations while a platform enforces common policies
- Why customer outcomes and reduced toil matter more than pull-request counts
Three takeaways from this conversation:
1. Adoption grows when engineers can see and share useful work. James describes agents spreading through internal tools that let engineers discover, use, and build on one another’s creations. Demonstrations and recognition gave teams concrete examples of what worked. Leaders can support that process by setting specific challenges, such as reducing operational toil, and revisiting tools as models improve. A mandate to use AI is less useful than a problem engineers want to solve.
2. Background agents need the discipline of production software. Agents can respond to check-ins, run in CI/CD, and perform recurring work without waiting for a chat message. That expands their usefulness and the infrastructure required to manage them. James describes Guild’s focus on versioning, releases, rollback, observability, permissions, and spending controls. As agents become part of the development process, teams need to understand what ran, what it could access, and how to change it safely.
3. Evaluate the work where its value is understood. Specialized teams understand the tasks and failure modes their agents need to handle. James argues for letting those teams develop evaluations while central infrastructure provides governance and enforcement. The same principle applies to productivity: counting code or pull requests misses whether a customer problem was solved. Better questions concern which bottlenecks disappeared, which systems became easier to operate, and what engineers can now accomplish.
