GitHub’s Agent Era Is Stressing Commits, Actions, Pull Requests, and Trust

Kyle Daigle describes GitHub’s current shift as larger than code completion. Copilot’s first act was autocomplete; the next act is a coding-agent harness that can show up in the CLI, a desktop app, cloud agents, security remediation, documentation checks, issue handling, and internal workflows. The pressure is not only product strategy. It is measurable load.

A displayed Daigle post gave the clearest numbers: GitHub had 1 billion commits in 2025; by April, it was seeing 275 million commits per week, a pace of 14 billion commits for the year if growth stayed linear, though the post added “spoiler: it won’t.” The same post said GitHub Actions grew from 500 million minutes per week in 2023 to 1 billion minutes per week in 2025, and then 2.1 billion minutes so far in that displayed week. Elsewhere, Daigle said GitHub now has more than 200 million developers.

Daigle’s role has expanded with the same logic. After 13 years at GitHub, where he joined as a developer and built parts of the platform, he is now GitHub’s COO and also Microsoft’s CMO of Developer. He frames the Microsoft role as an attempt to apply GitHub’s developer posture across Microsoft: “tell the truth, be authentic, show people how to use it, and then let the products speak for themselves.”

That background matters because Daigle is not talking about AI from outside the work. He built webhooks, worked with teams building the API, built the platform layer, and ran engineering teams behind “anything that integrated with GitHub” up until around 2018. He also led the first version of GitHub Actions, launched at Universe in October 2018, and was involved as GitHub acquired or integrated npm, Semmle, Dependabot, and Pull Panda.

The agent-era claim is that GitHub has to support developers plus agents, repositories plus agents, and agents running across the software-development lifecycle. The important Copilot question is no longer only whether it writes better code. It is whether GitHub can expose enough context, compute, security boundaries, and workflow primitives for agents to operate where software work actually happens.

That is why Daigle keeps returning to context. The unsolved version is getting GitHub to “act like Kyle wants it to act” — or like Shawn, a team, or an organization wants it to act — through rules, memory, and understanding of surrounding work. He acknowledges that this borders on an open research problem. But even a partial version would be valuable: a system that understands team methods as they shift, knows what is happening in dependencies and open source, and can apply that understanding through Copilot.

Kyle Daigle’s GitHub contribution graph recently spiked after years of lower coding activity. A displayed X post from Rhys Sullivan showed Daigle at 28,000 contributions and joked that his commit count was “going to the moon.” Daigle’s reply, shown on screen, was: “As you can see, been a while since my day job has been coding + AI = he’s back 🤓.”

That is what happened, he says. His earlier visible pattern was the normal arc of a developer moving into management and then into a COO role. AI pulled him back into building — not only by writing software, but by connecting different data sources and turning business, marketing, operations, and engineering context into tools.

For Daigle, the common “write me a blog post” AI example is too thin. The more useful work is retrospective and connective: ask the system to inspect PRs, public posts, the last three months of work, Obsidian notes, Teams transcripts through WorkIQ, Slack, email, and GitHub, then build a view of what messaging actually happened that week and what should be adjusted over the next few days.

He describes AI as less about “building forward” and more as “a recursive loop backwards.” The system looks across what happened first, extracts patterns, then helps decide what to do next. That is especially useful for non-technical workers, because the value is not just code generation. It is sensemaking over company context.

The phrase “15 agents on Saturday” was not metaphorical. Daigle describes spinning up multiple agents while doing family logistics, using them to build tools, inspect data, and create assets. That workflow gave him back what he calls the feeling of creation: the first time someone builds an app, clicks it, shows it to someone, and sees that it works.

His revenue-planning example makes the point concrete. GitHub was preparing annual planning materials for CRO and CFO teams. Rather than build the spreadsheets and slides manually or hand the work to his team, Daigle gathered information, used the internal skills and context sources he had described, built a small app to inspect a SQLite database, and generated an entire presentation without touching the slides directly. He deliberately built a skill to make the deck look “very clearly not AI” — not polished in a conspicuously synthetic way, just plain and humanly unremarkable.

The deck was presented without telling the audience it had been AI-generated. No one raised it. His conclusion was not that AI-generated slides are inherently impressive, but that slides are only a medium for sharing information. If a tool can produce them from the relevant context, and humans can still review and discuss them, the prior manual labor loses much of its value.

Shawn Wang raised the counterpoint that there can be value in being visibly AI-generated, because it signals that the output may contain mistakes the user cannot fully vouch for. Daigle accepted the concern but stayed on the operational point: in a business setting, the work is not to display that AI was used. The work is to communicate effectively and move decisions forward.

GitHub’s internal AI adoption, as Kyle Daigle describes it, is built around a constraint: employees should not have to change how they work in order to use AI. Many tools fail because they require onboarding and a new operating habit. GitHub instead has been distributing a CLI and a set of internal skills, giving those skills permissioned access to the systems where work already lives.

For GitHub, that means GitHub itself, Teams, email, and Slack. The coexistence of Teams and Slack matters. GitHub uses Teams for video communication, but Slack remains embedded as the chat and ChatOps system. Moving away from Slack would be “bluntly expensive,” Daigle says, because so much internal tooling and workflow is built around it. GitHub’s AI layer therefore does not assume a single collaboration surface. It reads across the real surfaces.

WorkIQ is central to this pattern. Microsoft Learn documentation shown for “Work IQ MCP overview (preview)” describes WorkIQ as a preview-stage feature that grounds Microsoft 365 Copilot and agents in real-time shared organizational context. For people in the Microsoft 365 world, the WorkIQ MCP server allows backward-looking questions over organizational context. That is especially important at GitHub because the company is remote and globally distributed.

The outputs are not always private chat answers. GitHub posts findings, industry reports, and automation results into GitHub issues or discussions, where teams continue the conversation. Some automation runs through GitHub Actions; some runs through the Copilot app’s workflows. The pattern is to preserve the canonical collaboration record inside GitHub rather than forcing a parallel AI workspace.

Kyle Daigle is skeptical of the early pattern of large, polished AI skills that claim to perform an entire workflow. GitHub’s internal experience is moving in the opposite direction: away from “massive, beautiful, perfect skills” and toward micro-skills that do one thing well.

The reason is brittleness. A mega-skill that stitches together many tools and produces a full report may work for a while, but weeks or months later the inputs, business needs, and desired output change. At that point the skill is hard to adjust. Daigle prefers “Legos” over a fixed instruction book: small atomic capabilities, with orchestration assembled for the task.

Shawn Wang showed a GitHub repository of reusable skills, including examples such as media download, transcription, extraction, summarization, smart entity resolution, and setup workflows. He framed this through Postel’s Law — be liberal in what you accept, strict in what you output — and suggested that a personal or organizational /skills repository could become a special kind of GitHub object.

Daigle agreed with the direction but emphasized the occupational matrix beneath it. “Summarize anything” is not a single skill once it enters a company. Summarizing for an analyst is different from summarizing for a customer meeting, communications plan, marketing review, or internal executive briefing. The atomic component might be “good summarization,” but the profession-specific interpretation is different.

That difference is not cosmetic. These subtle permutations determine whether a reader thinks “Did AI make this?” or whether the output feels appropriate for a Gartner briefing or customer engagement. The practical challenge is capturing what “good” means across functions without turning every workflow back into an unmaintainable mega-skill.

One advantage is that AI skills are easier to inspect and edit than traditional plugins. If a response is wrong, a user can open the skill and type English instructions. That makes the building block itself more accessible, provided users learn how to make effective changes.

Shawn Wang asked whether the current period is a “golden age” for former developers who are now in leadership. Kyle Daigle’s answer was qualified but affirmative: the relevant advantage is not just knowing syntax. It is having learned pattern recognition and problem-solving as a developer, then adding years of business, operations, marketing, or organizational knowledge.

Daigle says that made him effective first as a developer, then as COO, and now as CMO of Developer. With AI, he can apply accumulated business knowledge through software again. He still knows enough to avoid asking for an app that cannot be deployed, scaled, or operated safely. But he now has a decade of additional expertise to encode into tools.

He distinguishes this from technical leaders returning to old side projects. The more interesting pattern is people who left day-to-day coding, learned an entirely new domain, and can now bring that expertise back into creation. He extends the point beyond executives. Many developers have some other underlying skill, background, or passion; AI lets them combine those domains with software production more directly.

The same logic shapes his view of the chief-of-staff role. Some of Daigle’s AI-generated executive work would historically have gone to a chief of staff. Daigle still has one. The job changes rather than disappears. He no longer needs someone spending most of their time building decks, but he does need someone who can find human connections across discussions, identify which teams he should meet, and coordinate opportunities when he is in San Francisco or Seattle.

His analogy is that chiefs of staff no longer open physical letters to process correspondence; they use email. AI changes the mechanics again. The human work that remains is not slide assembly, but judgment, relationship-mapping, and coordination.

Kyle Daigle’s history with Actions begins with an older GitHub pattern: webhooks and GitHub Services. In the earlier architecture, GitHub had a Ruby-code repository where users could write arbitrary Ruby code, and GitHub would execute it on their behalf as a service. The separation was mostly at the server level; this was around 2014, before the present containerization expectations.

That older model eventually became untenable. GitHub could not keep running arbitrary Ruby code on everyone’s behalf. Actions containerized and formalized that execution model. Today Daigle describes the containerization as strong, while acknowledging that many users still do not pin workflows to a specific SHA, which creates dependency-management risk similar to using broad package versions such as latest.

The agent era pushes this problem further. Daigle referred to a fast Azure “Dev Compute” layer that GitHub is using under the hood for parts of GitHub Actions, saying it can spin up small VMs quickly for cloud agents and related workloads. Wang characterized the capability as sandbox containerization, and Daigle agreed. The purpose is to protect GitHub and users from the code the platform is asked to run.

Actions has also escaped its nominal CI/CD category. People use it for CI/CD, side projects, processing, scraping, automation, and general compute. Shawn Wang showed an example repository for periodic data scraping using GitHub Actions. Daigle’s response was joking — “Thank you for your service” — but the underlying point was serious: Actions has become a general-purpose compute layer attached to the developer graph.

That has business and infrastructure consequences. GitHub gives away many Actions minutes through entitlements, while also charging for usage. But the more important point in Daigle’s scaling discussion is that more agents, more PRs, and more builds mean more CPU demand. GPUs matter too, but CPUs have become a real constraint.

Kyle Daigle frames the npm acquisition as a continuity and scaling decision. npm was already “basically powering the internet,” and the goal was to keep it running, keep it scaling, and improve the underlying backend. GitHub invested in backend changes, including manifest-related work, and is now focused on raising npm’s security posture.

The difficult part is that every security improvement can break many people. GitHub has changed two-factor authentication policies, changed token behavior, and invalidates tokens that have been exposed or potentially exposed. Those moves create real operational issues for developers. But GitHub is trying to push the community forward without breaking a long-standing contract around npm usage.

That tension led to a discussion of “slop forks,” vendoring, and whether AI agents might reduce the need for package managers by importing only source code. Shawn Wang proposed a possible future in which coding agents inspect source, adapt only the needed subset, and vendor it directly into an application. Daigle did not dismiss the idea, but treated it as a return of an older practice rather than a complete solution.

He remembers debates from 2013 and 2014 about whether to vendor an entire dependency or copy only one needed file. AI could make that smaller-grained dependency selection more practical. But it does not eliminate security risk. Agents can be fooled. Static analysis, runtime testing, package checks, vendoring checks, and tools such as GitHub Advanced Security and Socket-like approaches still matter.

The scope may change — a whole package versus a small piece of code — but the verification problem remains. And in enterprise settings, customers do not want a single imposed answer. They want different security and dependency-management processes suited to their environments.

That leads to a broader GitHub principle: GitHub usually does not invent a process and force it onto the community. It waits for a social or literal RFC-like convergence, then cements what the community has effectively agreed on. That posture is both a strength and a source of friction: GitHub has to help keep the ecosystem secure without locking maintainers into flows they dislike.

Kyle Daigle says the pull request became the standardized flow after a messier prior process. Now GitHub has to ask what a pull request means when 80% of a project’s PRs might come from agents rather than people.

Mitchell Hashimoto’s “Ghostty is Leaving GitHub” post appeared in the discussion, as did the mitchellh/vouch GitHub repository, described in its README as “A community trust management system” where people must be vouched for before interacting with certain parts of a project. Daigle said he has discussed these issues with Hashimoto and appreciates specific feedback from maintainers about what is not working.

But he resisted turning one trust mechanism into a universal GitHub default. Some maintainers like Vouch; others tell Daigle it does not work for them. That is the recurring GitHub tension: provide tools that maintainers can use to control how much AI-generated work and outside contribution they accept, but avoid forcing every project into a single social model unless it becomes a broadly adopted standard.

The deeper issue is that many proposed PR replacements or variants are trying to codify trust. If Shawn reviews a change, someone might trust it because Shawn is a known senior developer. But when one agent writes code, another agent reviews it, and Kyle glances over it, the trust becomes diffuse. Verification improves — there are more artifacts, checks, and summaries — but it does not fully solve the human question: “Can I trust this?”

Daigle compared this to self-driving cars. He took a Waymo and felt comfortable looking at his phone rather than the road. He says there are other self-driving systems he would not trust even while staring ahead. Trust, in his framing, combines verifiable evidence — accident rates, data, proof — with human feeling: what the system tells you, how it behaves, and whether it feels safe enough to rely on.

For enterprise and regulated industries, the problem is harder. Even if a tool is verified, the team, the company, regulators, and governments may also need to trust the process. Until the human and institutional side tips over, Daigle expects the movement toward full agent trust to be uneven.

GitHub’s existing social signals do not fully solve this. Stars, commit counts, and similar measures are passive and gameable. Sponsors is more interesting to Daigle because it costs something: paying to support a maintainer can be a stronger signal than clicking a star. But even that is not a universal trust metric.

Instead, he describes a future where projects encode their own heuristics. A maintainer might accept a PR only if the author has previously had PRs accepted across certain projects, has a social handle attached to GitHub, and that social account is older than a certain age. These rules can be complex because maintainers already hold such heuristics in their heads or in contributing guidelines. Agentic workflows can turn them into executable policy.

Attackers adapt to simple thresholds. If an account must be old, they age accounts. If it must have stars, they manufacture star networks. If it must have PRs, they create repos and submit PRs to one another. Daigle’s answer is not a single canonical trust score but tools that let maintainers choose which signals matter for their projects.

Shawn Wang pressed Kyle Daigle on whether GitHub stars are broken. Projects now appear to reach large star counts far faster than before, and Wang said he no longer fully trusts whether those stars are real, bought, or meaningful.

Daigle acknowledged spam, gamification, anti-abuse work, and the whack-a-mole nature of policing stars. GitHub removes abusive activity when it finds it. But he argues that the larger explanation is genuine audience expansion. AI is bringing many more people into software development, and those people are swarming around tools, agent packages, CLIs, and projects that feel central to the current moment.

When Wang questioned whether “developers” really means “people with a GitHub account,” Daigle said this is one of the biggest debates inside GitHub. His position is anti-gatekeeping. There is a difference between a professional enterprise developer and other developers, but he does not think GitHub should spend the early AI era splitting hairs over who qualifies.

Daigle’s own path shapes that view. He says he was not “a developer” when he started writing code. Wang gave a similar example: he had a GitHub account years before he learned to code, and later people called him a fraud when he wrote about learning to code. Daigle called that criticism “bullshit.” His definition is pragmatic: if a person has an idea and creates code that can run as an app, they are on the developer journey, even if they use AI heavily.

Those users may later need to learn databases, fix bugs, or understand more of the stack. For now, they are participating in the same way Daigle wanted to participate in the Ruby community when he was starting out. Clicking the star button is a low-friction way to signal interest in a moment.

This also explains why GitHub Spark, shown as a public-preview product promising “Dream it. See it. Ship it,” still shows code. GitHub may put a veneer on top of building, but it will not hide the code. That is a tenet. Spark’s value for many developers is not that it hides software from them; it provides an easy runtime and a simple way to build and run an app.

Daigle wants people to be able to cross the chasm into software without fear. He compares it to changing a light switch at home: he may not open the breaker box, but he can handle a small change. Likewise, people should be able to say an app does not do what they want and modify it. For him, GitHub’s continuity across professional developers, new AI-era builders, students, and side-project creators comes from that same promise: “I had an idea, I created it, and holy shit, here it is.”

Kyle Daigle says this is both a hard time and one of the most exciting times he remembers at GitHub. At Universe in October, GitHub was already describing the prior year as its fastest ever. Now, by multiple measures, GitHub is doing in a month what it did in a year.

Shawn Wang summarized the commit figures as roughly 14x growth and asked why GitHub had not handled it cleanly. Daigle’s answer was that the platform is not breaking in the old ways. Some older systems, such as webhooks, were historically unreliable and have since been rewritten to scale. The new problems are different: permissioning issues that show up only across many objects at platform scale, Actions CPU demand, database pressure, monorepo behavior, Git infrastructure, job queuing, and changes in the size of pushes and PRs.

Actions is one pressure point. More agents and more PRs produce more builds, which require more CPUs. GitHub is expanding not only through its data centers but also through Azure and additional cloud compute.

The deeper pain is permissioning. Many permission layers still sit in an internal database known as MySQL1, a term Daigle says older GitHub employees will recognize. GitHub has been pulling things out of that system for years, using technologies such as Vitess and sharding to break apart database infrastructure and create more separation between services. But the permissioning work is hard, and it affects not only github.com but GitHub Enterprise Server and data-resident deployments, where customers need data in a single location.

Monorepos are another change. Parts of the industry had been moving toward smaller repositories and more of them. Now GitHub is seeing more large repositories, including large monorepos, while overall repo growth continues. Big repositories have always had unique performance issues, especially when underlying blobs are large. Improvements for monorepos often help all repository infrastructure, but the work is nontrivial.

The most important distinction is that the old scaling assumptions no longer hold. Historically, GitHub could scale vertically, especially databases, or horizontally by adding more servers. The system assumed that the “pipe” of work would stay roughly the same size and that more users would simply flow through it. Now the unit of work itself has changed: Git pushes are larger, PRs are larger, agent activity is larger and more numerous, and compute constraints limit straightforward horizontal expansion.

Daigle calls it a “diagonal” scaling problem. Vertical scaling no longer works cleanly. Horizontal scaling is constrained by CPU and GPU availability. Services that have run for 10 or 15 years need to be opened up and rewritten because their operating rules have changed.

He is careful not to frame this as an excuse. GitHub has to do the work. He also explains why the company historically did not narrate every internal failure in detail: GitHub’s ethos was that uptime is GitHub’s problem, and users expect the service to be up. But the team is now trying to talk more openly, publish more technical details, and have engineers explain what they changed after the work is done.

On timing, Daigle says availability in recent weeks was much better than the prior several weeks, and he expects fewer availability problems month by month over the next three months. The improvements are not small tweaks with immediate outsized effects; they are material changes that take time and then produce step changes.

Kyle Daigle says Copilot’s early success with code completion created its own strategic trap. After the first year or year and a half, GitHub focused heavily on fine-tuning to improve correctness and performance. That included fine-tuning for the overall product and per-customer fine-tuned models offered as a service.

Then the next generation of models improved rapidly. Other AI coding tools appeared, and base model capability increased enough to change the calculus. Daigle characterizes this as models “sherlocking” some of the fine-tuning direction. GitHub still invested in code completion, better underlying models, post-trained models, and language-specific next-edit suggestions, but Copilot had to broaden.

The current Copilot direction uses a single underlying SDK and harness for a coding agent that can power multiple surfaces: the new CLI, the new desktop app, and cloud agents. The point is not only a better code-completion box. It is a coding-agent layer that can be used across the software-development lifecycle.

Examples include assigning agents to security remediation, attaching a coding agent to every GitHub issue to test whether a fix is possible, scanning repository documentation to find mismatches, or using background agents to break up and multiplex tasks. GitHub’s advantage, in this framing, is that the platform already contains code, issues, PRs, security signals, automation, dependencies, and open-source context.

Daigle encourages people who have not tried Copilot since the original autocomplete moment to look again, especially at the GitHub Copilot desktop app, which he says has become his daily driver. The CLI is another preferred surface for users who want that interaction model. He also mentions bring-your-own-key support and access to multiple models.

But the more ambitious claim is again about context. Copilot needs to know not just the repository but the surrounding intent, organizational history, dependencies, security posture, and user preferences. Without that, even a strong coding agent is operating in a narrow lane.

Shawn Wang asked whether the industry has already explored the main AI coding form factors: completion, agentic IDEs, background agents, orchestration, and security review. Kyle Daigle’s answer was no. He thinks the industry is still in a “hyper-myopic” phase where AI coding tools lack the broader context available outside coding.

His ideal is ambient AI, not another named assistant. Many pins, tools, and capture devices try to record information, codify it, and recall it, but they do not work the way he wants. What he wants is a system that knows the specs, emails, online conversations, and implementation discussions around a feature, and can use that context when helping build it.

Software development, in his view, has never been a single-lane task where the only missing ingredient is perfect code. It depends on other team members, business priorities, what is popular or expected now, and the taste and judgment accumulated by a person or group. A coding agent that does not know those things can write code, but it cannot fully participate in software development.

OpenClaw interests him because it connects to many of the data sources a person cares about and can use a computer. That makes it more like a general agent that understands a user than a task-specific coding tool. Daigle’s question is how to bring that kind of connected context into everyday software development, not merely how to use it to kick off another coding agent.

Wang raised the inversion-of-control concern: at some point the AI stops waiting for instructions and starts telling the user what to do. Daigle accepts that there are boundaries. He mentions Nat Friedman’s OpenClaw example from a Stripe event, where OpenClaw was connected to cameras and redirected an Uber. Daigle would like an agent to tell him to drink water; he is less sure he wants it changing where his car goes.

The point is not that AI should run a person’s life. It is that every time a user has to restate a preference, context, or fact they have already expressed many times, the system is failing to use available information. Daigle wants agents to have access to more of that context, codify it, and act proactively where appropriate.

The discussion of OpenClaw led Shawn Wang to ask why Microsoft would dedicate a corporate vice president to something it does not own. Kyle Daigle’s answer was that OpenClaw has become a personification of a valuable agent: it understands a user because it can access the user’s information and operate a computer. In a work context, that raises operating-system, security, and sandboxing questions that Microsoft can work on.

If an agent runs on a personal or work device, it needs better OS-level sandboxing. Users need to be able to use a “claw” at work without getting fired. It must access work assets, operate well on Windows, respect enterprise security, and avoid leaking private information. In Daigle’s account, Microsoft is thinking about and contributing to platform components: sandboxing on Windows, cloud sandboxing, agent compute, and developer-facing primitives.

Wang framed Microsoft as the original operating-systems company facing the new operating system for AI. Daigle agreed that operating systems need to look different than they did five years ago because humans are no longer the only users. It is not enough for an agent to create a normal user account. The stack has to be reconsidered down to compute and silicon in Azure: what kind of inference, what kind of compute, and what kind of workloads agentic flows require.

Daigle contrasts this with the prior SaaS era, where companies often announced variations of the same product pattern. Now, he says, the work has reached physics: compute limits, OS boundaries, sandboxing, data access, and enterprise governance.

He also points to Microsoft Build announcements around WorkIQ and FoundryIQ. He describes them as context engines, while saying that is an oversimplification. WorkIQ lets employees ask questions across work context in Microsoft 365; FoundryIQ extends a similar idea across existing stores without requiring companies to move to new tools. The key is that large enterprises can use them without IT shutting them off for leaking private data.

Wang’s reaction was that the WorkIQ people should be placed next to the Copilot people because they are solving the context problem Copilot needs. Daigle said that has effectively been happening over the prior months. The code asset problem has unique features, but otherwise “it’s all just context.”