Kyle Daigle

Kyle Daigle is a GitHub executive who leads internal AI adoption and advocates using coding agents across the work of creating software. He became GitHub’s Chief Operating Officer in April 2023; in June and July 2026, he also held Microsoft’s CMO of Developer role. His work combines operating a developer company with hands-on building: agents that analyze company communications, reusable skills for nontechnical teams, and tools for his own executive work.[2][1][4]

In his June 2026 Latent Space interview, Daigle said AI had brought him back to coding after his move into management. Much of that building connected data sources rather than producing standalone applications. His agents examined pull requests, public posts, Obsidian notes, Slack conversations and Teams transcripts accessed through WorkIQ’s MCP server. He used them to reconstruct what the company had done, identify what worked, and suggest messaging changes for the next few days: “I’m always looking at what had happened first.”[1]

Daigle pushed for internal AI adoption that preserved employees’ existing workflows. He described distributing shared skills and CLI access, connecting GitHub, Teams, email and Slack, and posting findings into GitHub issues or discussions so teams could continue the conversation. GitHub retained Slack because its commands and automation were embedded in that environment; he considered replacing it expensive.[1]

His team moved toward small, reusable skills that performed one task well. Large skills intended to produce an entire report became difficult to maintain as tools and requirements changed. He also separated the mechanics of summarization from audience-specific instructions: an analyst briefing, customer meeting and marketing report need different selections and emphasis even when they draw on the same material.[1]

For revenue planning, Daigle recounted building a small app to inspect information in a SQLite database, then combining skills, company context and Obsidian notes to generate a presentation for GitHub’s CRO, CFO and their teams. He deliberately kept its appearance plain and said nobody raised its AI origin during the presentation. He still had a chief of staff, but described shifting that person’s work toward human connections, meetings and coordination as AI took on more presentation preparation.[1]

Daigle’s public account of Copilot’s development explains a change in priorities. After code completion, GitHub invested in general and customer-specific fine-tuning to improve results; stronger underlying models then changed the competitive landscape. In June 2026, he described a shared SDK and harness spanning Copilot’s CLI, desktop app and cloud agents, with uses extending to security remediation, issue investigation and documentation checks.[1]

In a July 2026 Observer interview, he argued: “It’s not solely about generating code. It’s about creating software, and that requires you to do more than just the code portion of it,” and emphasized model choice without changing interfaces. His broader ambition is for agents to use specifications, emails, conversations and team knowledge when implementing software, carrying accumulated judgment into the work rather than treating coding as an isolated task.[4][1]

For open source, Daigle distinguishes technical verification from human trust. An agent writing code and another reviewing it can leave trust diffuse; more artifacts to inspect do not automatically establish whether a maintainer should trust a contribution. He discussed Mitchell Hashimoto’s vouch system as one response, while stressing that other maintainers have different needs. He favored adaptable controls and community-developed practices over imposing a single contribution process.[1]

Daigle opposed gatekeeping people who build with AI, arguing that creating and running an idea can begin a developer’s learning journey. He also described showing users their code as a GitHub principle even when simplifying app creation: “We’re never going to, hide the code from you ever”.[1]

Before these AI and operating responsibilities, Daigle worked on GitHub’s integration platform. That earlier engineering work supplies context for his later discussions of APIs, automated execution and developer infrastructure.[1][3]

Daigle joined GitHub on April 23, 2013. He later recalled building webhooks, working with teams building the API, and building or leading engineering teams responsible for integrations through approximately 2018.[2][1]

As GitHub’s Platform Interface Engineering Manager, he co-presented Implementing and using GraphQL at GitHub at GitHub Universe in September 2016 with Dan Schafer, identified in the slides as a Facebook engineer and GraphQL co-creator. The presentation explained the problems with GitHub’s REST API: retrieving data could require multiple calls, comprehensive responses could be expensive, and the impact of changes was difficult to predict. It presented the public GraphQL API alongside OAuth-token limits on field and object visibility, selective exposure of schema elements, and GitHub engineers building on the same platform.[3]

Daigle said he was the engineering leader for the first GitHub Actions release and launched it at GitHub Universe before Microsoft’s acquisition closed in 2018. He described moving into the business side after the acquisition; GitHub’s biography credits him with work on the Semmle and npm acquisitions. Discussing npm, he emphasized the tension between improving security and preserving compatibility, including changes to two-factor authentication, token behavior and invalidation of exposed tokens. Observer later reported that he helped bring Copilot to market in preview in June 2021.[1][2][4]

In his April 25, 2023 COO announcement, Daigle committed to investing in culture, business strategy and how GitHub communicates with developers. By the June 2026 interview, reliability was a central public concern. He explained increased Actions CPU demand, permissioning concentrated in the database internally called “MySQL One,” larger repositories and changing queue requirements, while cautioning that infrastructure was not his day-to-day responsibility. He argued that the changed workloads required rewriting underlying services and sharing more technical detail with the community.[2][1]