GitHub’s agent transition: context, trust, and the infrastructure underneath

Reconstruct the week before planning the next

What did the team actually communicate this week? Answering that can require reading pull requests, public posts, Obsidian notes, meeting transcripts, and Slack conversations. Kyle Daigle describes an AI workflow that gathers this scattered context, reconstructs the messaging, and recommends adjustments for the next three or four days. Look backward to improve the next few decisions is his preferred loop: identify what happened, what worked, and what should change.

In the Latent Space conversation, Daigle describes combining his GitHub chief operating officer responsibilities with an expanded developer marketing role at Microsoft. He joined GitHub as a developer thirteen years earlier, built webhooks and the platform layer, and built or led integration capabilities through roughly 2018. His move into leadership drew on translating between developers and business leaders, running remote teams, and preserving GitHub’s way of operating after the Microsoft acquisition. His approach to developer marketing follows the same practical instinct: communicate honestly, show how the product works, and let people assess its value.

AI brought him back to active coding, often to connect information sources for leadership work. WorkIQ supplies work context, including Teams transcripts, through a server his workflow can call. He also uses internal tools and workflows in the GitHub Copilot desktop app, some running whenever he opens his laptop.

For the broader rollout, his constraint was preserve how employees already work. GitHub distributed a command-line interface, including to nontechnical employees, with internal skills and read access across GitHub, Teams, email, and Slack. The mixed environment had a reason: Teams handled video, while years of operational commands and workflows embedded in Slack made it expensive to replace. Automated findings could land in GitHub issues or discussions, sometimes through GitHub Actions, where people continued the conversation.

Small skills, specific audiences

A skill packages reusable instructions that colleagues can share in a repository and run through an app or command-line interface. Sharing these capabilities introduces a maintenance problem: requirements keep changing. The guest describes moving away from large skills that prescribe an entire report toward small skills that do one thing well. One might identify relevant marketing information from available context; a separate orchestration layer assembles the work. That separation makes it easier to change a workflow without rewriting a large bundle of interdependent instructions.

The interviewer offers downloading, transcription, and summarization as operations an orchestration skill could call in sequence. He proposes Postel’s law—accept varied inputs, enforce strict outputs—as a skill-design principle. It is a design suggestion, with no comparative reliability result attached.

Composition also needs to preserve professional judgment. A useful summary combines two responsibilities: - A reusable core: instructions for what good summarization requires. - Audience-specific priorities: what matters for an analyst briefing, customer meeting, marketing task, or communications task. These variations may be small, but they determine whether the result fits the occasion. Expanding skills across professions creates a matrix of needs rather than one universal summary.

The interviewer argues that flexible inputs could reduce the proliferation of framework-specific integration plugins. The guest emphasizes a more immediate benefit: after an unsatisfactory response, someone can open the skill and edit its English instructions. Editable instructions broaden who can maintain a capability, although colleagues still need to learn which edits produce useful changes.

Automate presentations, retain human coordination

Asked whether AI particularly benefits former developers now in leadership, the guest emphasizes pattern recognition and problem solving, combined with expertise accumulated outside daily coding. He describes running fifteen agents while his children play lacrosse as a return to the pleasure of creating things—not a measured productivity gain.

Annual revenue planning provides a concrete example. He built a small app to inspect information in a SQLite database, then generated a presentation from plans, Obsidian notes, and other context. A custom skill deliberately made the slides plain and unremarkable. When he presented them to the chief revenue officer, chief financial officer, and their teams, their AI origin never came up.

The exchange exposes two views of presentation style: - Fit the artifact to its audience. The guest treats slides as a way to share information. If AI can produce them with human direction and joint review, he sees little value in the extra manual production. - Make uncertainty visible. The interviewer sees value in an obviously generated aesthetic because it can signal that the presenter cannot vouch for every possible mistake.

The guest still has a chief of staff. With less need for slide production, the role puts more emphasis on finding connections between people, recognizing opportunities across teams, and arranging useful meetings during travel. Automation changes the allocation of work within the role. He reports faster, better decisions as a qualitative benefit, without quantifying the improvement.

Isolation and dependency security solve different problems

The conversation turns to GitHub’s history of running code for developers. The guest recalls leading engineering for the first version of GitHub Actions, launched at Universe shortly before the Microsoft acquisition closed in 2018. Earlier, GitHub Services executed Ruby code from a repository on users’ behalf, with isolation primarily at the server level around 2014. An early version of Pages used its own containerization infrastructure.

Asked whether Actions is GitHub’s largest security problem, the guest suggests that users’ repository code is probably the larger source, without offering a measured ranking. He separates two concerns: - Execution isolation: he describes Actions containerization as strong. - Dependency selection: workflow references such as v1 or latest, rather than a specific commit identifier, remain a significant dependency-management risk.

For agents, he describes an Azure-backed service used in parts of the new app that starts small virtual machines for individual tool calls or cloud-agent execution. The direction is isolate the code an agent runs. He describes startup as fast, without supplying timing measurements.

The npm acquisition introduces a different constraint: security changes can disrupt an ecosystem’s established workflows. The guest describes the acquisition’s goal as keeping npm running and scaling, followed by backend investment and stronger protections. Changes to two-factor authentication and token behavior, including invalidating exposed or potentially exposed tokens, can protect users while breaking workflows that depend on those tokens.

The interviewer proposes source-only distribution: an agent would inspect a dependency, adapt the required subset, and vendor it—copy that code into the consuming project. He leaves feasibility and security benefits open. The guest recognizes the older practice of importing one needed file instead of an entire library, but argues that smaller imports still require security checks. An agent can be persuaded to import unsafe code. Static analysis and runtime testing remain necessary whether the imported unit is a project or a fragment; Advanced Security and Socket are mentioned as addressing portions of that work.

Pull requests must carry trust as well as evidence

GitHub’s stated approach to contribution practices is to let community agreement emerge before incorporating a convention into the platform. Vouch, discussed as a system for establishing that a contributor’s pull requests should be accepted, illustrates the tension: some maintainers like it, while others say it does not fit their projects. The guest describes possible integration as conditional on broad adoption, without enforcement. He asks maintainers for specific descriptions of what fails in their own projects.

What should a pull request become when agents produce most submissions? The conversation uses 80% agent-generated pull requests as a hypothetical, not an adoption statistic. The guest frames the design problem as codifying trust. A known developer’s approval carries a social meaning that becomes diffuse when one agent writes code, another reviews it, and a human inspects the result afterward.

Verification artifacts improve assessment without fully establishing trust. More development assets can help a reviewer evaluate a change, while approval from a known person still matters. The guest uses his comfort during a Waymo ride to distinguish evidence from felt trust: both data and the system’s behavior and communication shape acceptance. Regulated enterprises add organizational and regulatory requirements beyond an individual reviewer’s confidence.

The interviewer challenges GitHub to do more as a developer social network. Several possible signals have different strengths: - Sponsorship costs the supporter something. The guest sees financial support as a potentially stronger expression of commitment to a project. - Stars and commit counts are easy to manipulate. They are passive signals, and maintainers differ in how much weight they give them. - Project-specific rules can encode local judgment. An Actions workflow calling AI could assess accepted pull requests, linked social accounts, and account age against a maintainer’s contribution guidelines.

Fixed thresholds give attackers a target. They can create accounts and wait for them to age, inflate stars, or exchange pull requests among manufactured repositories. The proposed direction is configurable trust tools with defaults, rather than a universal reputation score. Proving who controls an online account remains unresolved.

Welcome new developers without hiding the code

Rapid star growth has another possible explanation alongside manipulation: a larger audience. The guest describes people who started building software with AI discovering projects and using stars to participate in technical communities. GitHub removes detected spam accounts, but he characterizes enforcement as a continuing whack-a-mole problem. These explanations do not establish the authentic share of any particular project’s growth.

A claim of more than 200 million developers prompts the interviewer to ask whether that means developers or simply GitHub account holders; no counting methodology is given. The guest’s position is inclusive: turning an idea into a runnable app qualifies as development, including with AI assistance. Learning databases and fixing bugs can follow. The interviewer recalls having an account years before learning to code, showing why account age need not indicate experience.

Spark makes an app easy to build and run while keeping its code visible. The guest says its main value for most developers is an easy runtime—a place to run what they build. Further simplifying the interface is less useful for those pursuing broader software development. His light-switch analogy captures the accessibility goal: people should feel able to make a useful modification without first mastering the entire system.

Scaling breaks when the unit of work changes

The interviewer then presses on reliability. He cites one billion commits in 2025 and a subsequent rate of 275 million per week, projecting roughly 14 billion for the year under a stated linear-growth assumption. The guest broadly confirms the pace and says it is accelerating. The roughly fourteenfold annual comparison is a projection, not a completed-year result; the weekly measurement window is unclear. The interviewer asks for the mechanism behind the outages: which systems broke, and how are they being repaired?

The guest describes three distinct pressures: - Actions needs more CPUs. More tools, agents, and pull requests produce more builds. GitHub is expanding capacity through Azure and additional cloud compute. - Permissioning still depends on shared storage. Many permission layers remain in a database internally called MySQL 1, despite years of extracting functionality and using technologies including Vitess. - Deployment configurations complicate infrastructure changes. GitHub supports Enterprise Server on premises and data-residency configurations, with differing storage and permissioning arrangements.

Repository workloads are changing too. The guest reports more large repositories and monorepos, sometimes containing very large blobs. Git infrastructure improvements for these cases can benefit other repositories, while job-queue technology is also changing. Earlier assumptions treated growth largely as more users submitting similarly sized work. Now push sizes and pull-request workloads themselves have changed, and some technology choices have produced unacceptable slowness.

In this account, enlarging databases or adding servers no longer suffices: compute constraints and changed workloads require revisiting services that have run for ten to fifteen years. Webhooks provide a useful comparison. A prior rewrite was reportedly holding up, while novel permission problems were forcing changes elsewhere. The guest qualifies this as an overview of work outside his daily responsibilities, allowing that some technical details may be imperfect.

Actions also supports general processing and automation, beyond software build and deployment pipelines; the interviewer runs a daily scraper on it. Additional compute is expected to relieve a substantial share of the pressure, particularly for Actions. At the time of the conversation, the guest reports improved availability over the preceding few weeks and expects fewer incidents over the following three months as larger changes take effect. He gives neither availability percentages nor a completion date for the database work.

Work on modeling and testing scale had been underway since roughly November, after growth accelerated around October. The guest also commits to more technical explanations from engineers as improvements are completed. His account of GitHub’s earlier reticence is that uptime is GitHub’s responsibility to deliver. The company runs its own work through the same product, so outages disrupt internal operations too.

Copilot moves from completion to a shared agent runtime

Copilot’s strategic retrospective starts with its first year to year and a half of code completion. The team then pursued fine-tuning to improve larger completions and next-edit suggestions, both for general use and individual customers. The guest’s explanation for lost momentum is that better base models overtook some of the value being added through fine-tuning, while enabling competing coding tools.

Code completion still receives investment in underlying models, post-training, and language-specific models. Alongside it, the coding agent, command-line interface, desktop app, and cloud agents share an agent harness—the runtime used across these experiences—and a software development kit. The guest highlights multiple model choices and support for users’ own provider keys as part of the newer experience.

The intended applications extend across repository maintenance: - Security remediation: use coding agents to fix security problems. - Issue handling: attempt incoming issues to see whether an agent can resolve them. - Documentation maintenance: inspect repositories for mismatches between documentation and implementation.

The guest anticipates some developers moving directly from an idea to asking an agent to build it, compressing the separate issue-creation step. Existing projects still use issues to direct agents. Coordinating multiple agents remains central to the Copilot infrastructure and coding experience he describes.

Context must influence implementation

A longer-term goal is for GitHub to act according to an individual’s preferences, captured in rules and memory. Both participants acknowledge this as an open research problem. The guest also wants Copilot to understand a team’s changing practices without someone explicitly codifying every convention, together with relevant dependency and open-source context.

He calls the broader opportunity ambient AI: assistance that uses surrounding work context to make implementation decisions. Specifications, email, conversations, teammates’ knowledge, and business priorities should affect how a feature is built. Capturing, organizing, and recalling information does not satisfy that goal. Context must change the implementation. Excellent code alone, he argues, has never supplied all the judgment software development requires.

OpenClaw connects information sources a person cares about, which makes it interesting to the guest as a starting point. He imagines an agent downloading this podcast conversation, recognizing an app he might need, and recommending it. Building that app could draw on the person’s or team’s accumulated taste and expertise. This remains a hypothetical workflow.

The interviewer raises inversion of control: instead of waiting for instructions, proactive AI could start telling people what to do. The guest draws a boundary between a welcome reminder to drink water and an unwanted change to a car’s destination. His immediate ambition is for assistance to use relevant information and previously expressed preferences without requiring him to repeat them.

Workplace agents need usable platform components

A workplace agent would combine access to work assets with computer use. Running it on a personal or work device creates a concrete requirement: stronger operating-system sandboxing. The guest describes Windows and cloud sandboxing as parts of Microsoft’s investment, alongside continued contributions to OpenClaw and other open-source projects.

The technical argument extends down the stack. Building for builders means exposing reusable components and explaining how they work. Agent workloads require reconsidering operating systems, infrastructure, and Azure’s silicon requirements: which kinds of inference and compute do these workflows need? Increasing inference capacity alone does not answer that design question.

The guest frames Microsoft’s Build announcements around developers’ daily computing environments and the ability to build, deploy, and run agents at work. The enterprise goal is weekend agility within workplace requirements. In a large organization, a generated app still has to pass security and compliance requirements before deployment.

WorkIQ and FoundryIQ provide a context layer for asking questions about work information—the guest explicitly calls “context engines” an oversimplification. He reports making them available to GitHub employees and describes FoundryIQ as connecting existing data stores without requiring a tool migration. The practical requirement is that this assistance be usable within a large company’s constraints; a powerful tool employees cannot use does not solve their problem.

When the interviewer suggests putting the WorkIQ and Copilot teams together, the guest says collaboration has already been happening for several months. Code and code assets have somewhat distinctive needs, but they sit within the same broader context problem.

The closing discussion turns to a proposed question for Satya: what does he expect to be true in two or three years, and why will Microsoft’s approach pay off? The guest connects that question to inference, tokens, future work practices, and organizational changes intended to reduce fragmented products and missing context. The interviewer wants a direct answer that addresses external doubts about Microsoft’s direction. The conversation ends with that question still open.