The Next Evolution of Open Source Is Sharing Intelligence, Not Just Code

At Meta, James Everingham's Dev Infra team owned the entire development workflow for tens of thousands of engineers — authoring, land, release, monitoring, deployment. Sixteen thousand internal tools. No single developer could even know what all of them were, let alone use the right one at the right time. You needed a platform with intelligence to select and operate tools on your behalf.

That experience is the reason Guild.ai exists. In a short portfolio welcome conversation with GV General Partner Michael McBride, the Guild CEO laid out a thesis that's deceptively simple: engineers should be able to go from idea to working software without fighting their tools. Getting there will require millions of agents. And no single company — not even one that's already built hundreds internally — can build them all.

"From thought to realization instantly"

We see a future where engineers can go from thought to realization instantly.

That line sounds like a tagline, but Everingham grounded it in operational reality. The friction he's targeting isn't the coding itself — it's everything around the coding. The review cycles, the deployment pipelines, the monitoring setup, the security checks, the compliance gates. The accumulated weight of process that sits between an engineer's idea and a user experiencing it.

At Meta's scale, even with a thousand-person Dev Infra org and hundreds of internal agents already running, they still hit the ceiling. AI code review alone would probably take hundreds of specialized agents — graphics experts, security reviewers, compliance checkers, each tuned to a different domain. One company can't build all of them. The breadth is too wide, the specialization too deep, the surface area too large.

That's why the Guild CEO frames the problem as fundamentally requiring community. Not community as a marketing concept, but community as an engineering constraint. The number of agents the world needs will dwarf what any single team can produce.

The next evolution of open source

It's almost like the next evolution of open source where engineers used to share code to get ideas. Now with AI, they can not only share code, but they can share context, they can share capability, they can share actual intelligence.

This is the core of the Guild thesis, and it's worth sitting with. Open source changed software because it let engineers learn from each other's work — read the code, fork it, improve it, share it back. But code is static. It captures a solution, not the reasoning behind it.

Agents change that equation. When an engineer packages an agent, they're sharing something richer than a function or a library. They're sharing decision-making — how to review this kind of code, how to triage this class of alert, how to deploy to this environment safely. The intelligence layer on top of the code.

Guild's vision is to be the platform where that sharing happens. Engineers discover agents, create them, publish them. And critically, agents discover and collaborate with each other — a code review agent that doesn't know a repository can ask an onboarding agent for context, the same way a new engineer would ask a colleague. Software delivery itself may change down to the granularity of a single customer, with agents adapting the pipeline per deployment target.

The speed round

McBride closed with a rapid-fire set of questions that drew out some of Everingham's sharpest takes.

Most overhyped thing in AI right now?

The most overhyped thing is the general agent. Like having a general agent that can do everything. I don't think that that's feasible.

Most underhyped?

The most underhyped thing are the agents that are addressing the 80% of the friction and monotony in the tools that are non-coding.

The unsexy agents — the ones handling CI configuration, deployment scripts, monitoring dashboards, permission requests — are where most of the developer time actually goes. And almost nobody is building for that space yet.

Will there be more or fewer developers in the future? More. Significantly more. The barrier to building software drops, and when barriers drop, more people build. Open or closed systems? Open wins every time.

And when McBride asked what one thing developers will always do better than AI, the Guild CEO didn't hesitate: "They will disagree with their managers."

The name itself is the tell.

It's why we even named it Guild. It's going to take community, collaboration, context, and craft.

The future of engineering is *community*

Guild is building the platform where engineers share not just code, but intelligence — and where agents discover and collaborate with each other. If you believe open systems win, this is where it starts.

Frequently asked questions

Guild is building a platform where engineers go from thought to working software without fighting their tools. That requires millions of specialized agents — far more than any single company can build — so the platform is designed around community contribution, discovery, and agent-to-agent collaboration.

A general agent that handles everything isn't feasible at production scale. Real workflows require deep specialization — AI code review alone might need hundreds of agents tuned to different domains like security, graphics, or compliance. Specialized agents are more debuggable, more trustworthy, and more effective.

Traditional open source shares code — static solutions to known problems. Guild's model shares intelligence: context, capability, and decision-making packaged as agents. Engineers don't just read and fork code; they discover agents that can reason, collaborate with other agents, and operate autonomously within governed infrastructure.

The agents tackling the 80% of engineering friction that isn't writing code. CI/CD configuration, deployment pipelines, monitoring setup, permission management — the monotonous tool work that dominates a developer's day but attracts almost no attention from the AI community.

No. Everingham expects significantly more developers, not fewer. When the barrier to building software drops, more people build. The pattern is consistent across every previous wave of tooling improvement in software history.