GitHub COO Kyle Daigle on Copilot scale, platform openness, and why enterprise code fine-tuning rarely moves the needle

Summary

Kyle Daigle, COO of GitHub, joined the show to discuss Copilot's scale, the case for platform openness, and why the path to better enterprise performance runs through the harness before it runs through fine-tuning.

Copilot at scale

GitHub has over 3,000 full-time employees and Copilot is reaching developers at a striking rate: 80% of new GitHub users engage with it in their first week, and roughly 36 million developers joined the platform in the past year alone. Daigle frames that penetration not as a lock-in win but as a constant retention challenge — developers today move fast across tools, and GitHub's response is openness rather than walls.

Platform first

Daigle draws a parallel to the pre-API era, when closed apps were the norm before interconnection unlocked compounding value. AI tools and agents are in a similar quasi-walled-garden moment right now, and his argument is that the industry needs to return to a platform-first posture. Without that, even the best model or agent breaks down at the point where it can't place a grocery order because there's no API for it. GitHub's strategy is to be the connective layer across whatever tools developers choose, not to mandate which tools they use.

Enterprise performance and the harness argument

On the question of whether enterprises with bespoke codebases — Fortran-heavy systems, proprietary frameworks — need fine-tuning to get value from Codex, Daigle is direct: there's a large capability overhang in current models that can be unlocked well before anyone touches pre-training. The first lever is the harness — how instructions, context, and workflow are structured around the model. Instacart is already running Codex inside an automated workflow for code maintenance without any model customization. Fine-tuning and training are available levers, but Daigle says most enterprises haven't exhausted the harness layer yet.

Enterprise adoption is following two patterns. The first is developer-led: give engineers the tooling and let preference drive adoption. The second is project-led: a large migration or replatforming effort where GitHub works directly with the customer to build a meta-harness around Codex. Benchmarks barely come up in those conversations — enterprise buyers care whether developers like the product and whether it can handle the specific task at hand.

Trust and the SDLC gap

The deeper product challenge Daigle identifies is that coding agents are currently evaluated only on code generation. A human teammate who could only write code — not read user feedback, not monitor Slack, not notice an outage — wouldn't be trusted with much. The path to real trust runs through expanding agent presence across the full software development lifecycle: ideation, planning, code review, deployment, and telemetry. Codex code review is one recent step in that direction, and Daigle says it's been well received.

The bottleneck, in his framing, is shifting from how frequently a developer can prompt an LLM to how well they can structure work so agents — and people — can execute independently and know when to ask questions. That's a meaningful change in how developers think about their own leverage.

Codex team growth

The Codex team went from roughly five engineers a few months ago to around 25 today. Feedback loops are still partly informal — the team monitors social media closely — but Daigle acknowledges the signal quality problem: public feedback skews heavily toward power users, and silent churn goes unmeasured. His product focus is split between advancing capabilities for those power users and sharpening the first-mile experience, which he says is still too complex for mainstream adoption.