# Simulated interview: Kyle Daigle (GitHub COO) **What this is.** A simulated Q&A in Kyle Daigle's voice, built *only* from the distilled public-source persona in `persona/kyle-daigle.md` (22 records, May 2023 – May 2026). It is not Kyle Daigle. Every answer is grounded in his public record where the record exists; where it doesn't, the answer says so instead of inventing a position. **How to read each answer.** - *Answer* — in first person, in his voice, sticking to positions he has actually taken in public. - *Grounding* — which public sources the answer leans on. - *Verify with Kyle* — premises in the question, or load-bearing assumptions in the answer, that the public record cannot confirm. Any answer that depends on an unverified premise ends with this note. **Assumptions made up front (not in the persona; please confirm).** 1. The questions reference "Build" and "yesterday," so I assume this interview took place at or around Microsoft Build, roughly May 2026. The persona's coverage ends 2026-05-31 and has no Build-specific material at all. 2. Several questions cite things Kyle "said publicly" (PR volume, a dual marketing role, external Build speakers, "hill climbing"). None of those appear in the persona. I treat them as interviewer premises to be verified, not as facts. 3. Figures quoted are his own public figures as of early April 2026 (via Simon Willison's write-up) and may be stale by the interview date. --- ## 1. The demographics of the customer are changing. A lot of people who may never have used GitHub or developer products before are now using them. How has that changed the way you decide the product roadmap? **Answer.** It's the thing I've been pushing toward for a long time, honestly. My stated goal — it's literally on my personal site — is that anyone who wants to become a developer should be able to call GitHub home. We've put a number on it publicly: a billion developers. You don't get to a billion by serving the people who already know what a rebase is. You get there because AI lowers the barrier to entry and the population of people who can build software expands. I came into tech from a fine-arts background, so I'm not abstractly interested in who gets to build; I was one of the people who wasn't supposed to. What it changes on the roadmap is the bar for fit. The principle I've used since the first Copilot days is "no net new behavior": a tool earns its place by embedding into a workflow people already have, not by making them learn a new one. For a twenty-year developer that means agents should show up in Git, pull requests, and issues — the way you already work. For someone brand new, it means the workflow itself has to be the on-ramp, because they don't have a prior habit to embed into. Both of those are the same test applied to different people. And the thing I'd push back on is the idea that this is a zero-sum change. I've said publicly that I reject the premise that AI shrinks the developer base. We expect India to overtake the United States as our largest developer community by 2028. That's the demographic shift I plan around — not "new people instead of developers," but "a lot more developers, many of whom don't look like the ones we had." **Grounding.** "Anyone who wants to become a developer" / home-for-all-developers goal (kyledaigle.com About; GitHub leadership page). Billion-developer thesis, AI lowers barriers, India-by-2028 prediction (Business Standard, 2026-04-12). "No net new behavior" (DataCamp podcast, 2024-04-11). Fine-arts background (AI and the Future of Work podcast, 2025-07-07). "Work the way you already work" (Agent HQ post, 2025-10-28). **Verify with Kyle.** The record shows his *aspiration* and *growth thesis* clearly, but it does not document any specific roadmap mechanism (e.g., how non-traditional users are weighted in prioritization). The "same test applied to different people" framing is an extrapolation from "no net new behavior" — confirm it's how he'd actually put it. Also confirm the premise that the user demographic is measurably shifting toward non-developers; his public numbers are about developer growth, not non-developer usage. --- ## 2. How do you help developers deal with the burden of all the extra pull requests? Open source maintainers I talk to are drowning. What needs to happen to help them? **Answer.** I'll start with what I can say with confidence, which is the scale. We went from roughly a billion commits in all of 2025 to about 275 million a week by early this year. That's on pace for 14 billion this year if growth stays linear — spoiler: it won't — but even the bent version of that curve is a very different platform than the one maintainers built their routines around. So I'm not going to tell anyone they're imagining the load. The way I've talked about the answer is governance inside the existing workflow, not a new workflow. Agent HQ is built around the idea that agents shouldn't be bolted on; they work through the same Git, PR, and issue primitives as a person, which means the same controls apply to them. The specific mechanism we chose is AGENTS.md — source-controlled rules and guardrails that live in the repo, so a maintainer can tell an agent what's in bounds before it opens anything. On the enterprise side there's a control plane doing the same job at the org level. The phrase I've used is bringing a little bit of order to the chaos of innovation, and I think that's exactly the job for maintainers too. And the human stays in the loop. I've argued for a while that the skills that matter now shift toward problem-solving, communication, and oversight of what the agents produce — keeping the output correct. That's a maintainer's job description, and the tooling has to make that oversight cheap rather than make the volume free. **Grounding.** Commit figures and "spoiler: it won't" (Simon Willison's Weblog, 2026-04-04; Quasa, 2026-03). AGENTS.md, enterprise control plane, "shouldn't be bolted on," "order and governance… without compromising choice" (Agent HQ post, 2025-10-28; Visual Studio Magazine, 2025-10-28). Human-in-the-loop oversight as a core skill (Business Standard, 2025-04-07). **Verify with Kyle.** The public record contains **no statement from him specifically about open-source maintainer burnout or AI-generated PR spam**. The answer above applies his Agent HQ governance framing to the maintainer problem; that's a reasonable extension, not a documented position. Specifically confirm: (a) whether he has actually proposed AGENTS.md-style guardrails as the maintainer-side answer, and (b) whether GitHub has any maintainer-specific measures (rate limits, triage tooling, policy changes) that he would point to instead. --- ## 3. You have a front-row seat to this new agent economy. You said publicly that you have had more pull requests submitted in a month than in all of last year. How are those stats exploding? **Answer.** Let me give you the numbers I've actually put on the record, because the unit matters. In all of 2025 GitHub saw roughly one billion commits. By early 2026 we were at about 275 million commits *per week*. Do the arithmetic and a single month of early 2026 is on the order of 1.1–1.2 billion commits — so yes, a month now exceeds all of last year, at least on commits. The linear extrapolation is 14 billion for the year; I've said publicly that growth won't stay linear, and I'd say it again. Actions tells the same story from a different angle: we went from about 500 million Actions minutes a week to roughly 2.1 billion. What's driving it is agents running the loop I've always cared about — idea to execution to feedback — much faster than people can, and running it continuously. The part that's unchanged is the social core: creative people shipping and sharing things together. The part that's changed is the speed, and at this speed the platform feels it. We've been pushing incredibly hard on more CPUs, scaling services, and strengthening the core features, because the honest version of "front-row seat" is that the seat is sometimes on fire. **Grounding.** Commit and Actions figures, 14B extrapolation, "spoiler: it won't" (Simon Willison's Weblog, 2026-04-04; Zen van Riel, 2026-05-31). "Idea to execution to feedback" and the unchanged social core (kyledaigle.com, "My 12 year journey," 2025-10-27). Scaling response — CPUs, services, core features (Quasa, 2026-03; reporter paraphrase). **Verify with Kyle.** The question attributes a **pull-request** statistic to him. His documented figures are about **commits** and **Actions minutes**; the persona has no PR-count statement. The "month exceeds last year" claim is consistent with the commit math, but confirm with him whether he said PRs or commits, and what the current figures are (the April numbers may be stale). The "more CPUs, scaling services" line is a reporter's paraphrase, not a verified quote. --- ## 4. How does the business model change? Freemium makes sense in a human-centered world where we go to bed, but agents are still working while we are asleep. Does that move things toward usage-based pricing? **Answer.** I'm going to be careful here, because I don't want to hand you a pricing strategy I haven't put on the record. What I *have* said publicly is the usage side of the equation: commits up by an order of magnitude, Actions minutes up roughly four-fold per week, and agents that don't stop when the human does. Anyone can see that changes the cost and capacity calculus for a platform. The "agents working while you sleep" framing is real — it's the reason the infrastructure story and the business-model story are the same story. How I think about any decision like this is constraint-first. There are MUSTs — you can't implement a SHOULD or COULD that undermines a MUST — and for us a MUST is that GitHub stays the home for every developer, including the ones who are just starting and have no budget. Whatever the pricing model becomes, it has to satisfy that before it optimizes anything else. Beyond that, I'd rather tell you I don't have a public position than improvise one in an interview. **Grounding.** Usage metrics (Simon Willison's Weblog, 2026-04-04). MUST/SHOULD/COULD and "You can't implement a SHOULD or COULD that undermines a MUST" (kyledaigle.com, "How to prioritize in the AI era," 2026-01-11). Home-for-all-developers goal (kyledaigle.com About). **Verify with Kyle.** The persona explicitly flags that **pricing, monetization, and business-model strategy are not documented** in his public record. This answer deliberately abstains on usage-based pricing. Everything beyond "usage is up and that changes the calculus" — including the claim that free access for new developers is a MUST — is my application of his prioritization framework, not something he has said. Confirm his actual view on usage-based vs. seat-based pricing for agents, and whether GitHub's freemium tier is under review. --- ## 5. Pricing leads back into the wider Microsoft orbit. You now have a dual role, with partial responsibility for the wider marketing organization. How has that changed your work, and how do you prioritize between the two roles? **Answer.** On the org structure I can only describe what's public: since Thomas left last August, GitHub sits inside Microsoft's CoreAI group under Jay Parikh, and I report to Julia Liuson along with our CTO and CRO. I'm not going to characterize a marketing remit in this conversation beyond that, because it isn't something I've described publicly and I'd rather you get it from me precisely than approximately. On how I prioritize across more than one job — that I've written about, and it doesn't change with the title. I use MUST, SHOULD, COULD, borrowed from RFC 2119, rather than P0/P1/P2, because the verbs carry the hierarchy in plain language that a person or an agent can act on. The rule that makes it work is that you can't do a SHOULD or COULD that undermines a MUST. Then I delegate whole projects with a success criterion, a resource ceiling, and a time limit, instead of handing out tasks — tight constraints produce better solutions, and the same brief works whether it's going to a team or an agent. And I protect time to think: I take a Think Week, Gates-style, with Goal, Invest, Decompress, and Recharge phases, and I don't consolidate notes until the last day so I don't lock in conclusions early. Two roles or one, that's the operating system. **Grounding.** Reporting lines post-Dohmke (SiliconANGLE and CNBC, 2025-08-11). MUST/SHOULD/COULD, bounded delegation (kyledaigle.com, 2026-01-11). Think Week structure (kyledaigle.com, 2023-09-04). **Verify with Kyle.** The premise of a **dual role with partial responsibility for a wider marketing organization is not in the public record** I was built from; the latest documented structure is the August 2025 reporting change. Confirm whether this dual role exists, when it began, and what it covers before using this answer. The prioritization method is his, verbatim in spirit; whether he applies it to the two-role question is an inference. --- ## 6. Did I hear you say that this is the first Build conference to have external contributors and speakers? **Answer.** I can't confirm that from anything I've said on the record, and I don't want to invent a Build fact at Build. What I can say is that the direction is consistent with how we've built Agent HQ: agents from Anthropic, OpenAI, Google, Cognition, and xAI all run inside GitHub, and the whole point was that developers get choice rather than a single vendor's stack. If the conference is starting to reflect that — outside voices on a Microsoft stage — it's the same idea showing up in a different venue. But on the specific claim, check it against what was actually said from the stage. **Grounding.** Multi-provider Agent HQ and developer-choice positioning (Agent HQ post, 2025-10-28; Visual Studio Magazine, 2025-10-28). **Verify with Kyle.** The persona has **no Build-related material** — no keynote, no quote, no mention of external speakers. This answer is an explicit abstention. Confirm with him (or against the Build session recording) whether he made this statement and what "external contributors" referred to. --- ## 7. This is a very competitive market, and the pace of change is quick. How do you differentiate? **Answer.** By not trying to win the model race, and by being the place where the model race gets put to work. Our bet with Agent HQ is that GitHub is the neutral orchestration and governance layer — any agent, from any provider, managed through the workflows developers already use. That's a real difference from everyone who wants to own the whole stack. If you're a developer you get choice; if you're an enterprise you get one control plane for all of it. I've called it bringing order and governance to this era without compromising choice. The second piece is that we don't make people learn new behavior. Agents shouldn't be bolted on; they should work the way you already work — Git, pull requests, issues. Twelve-plus years in, the social experience of software collaboration hasn't actually changed; what's changed is speed. Whoever is closest to where the collaboration already happens has a structural advantage, and that's us. And the third piece is the boring one: usefulness wins over hype. I said Agent HQ isn't about the hype of AI, it's about the reality of shipping code, and I meant it as a filter. In a market that moves this fast, the demo that doesn't survive contact with a real repo is not differentiation. Reliability at 275 million commits a week is. **Grounding.** Neutral, provider-agnostic orchestration; "order and governance… without compromising choice"; "Agents shouldn't be bolted on"; "reality of shipping code" (Agent HQ post, 2025-10-28; Visual Studio Magazine, 2025-10-28; Microsoft Cloud Blog, 2025-11). Unchanged social core, speed as the change (kyledaigle.com, 2025-10-27). "Usefulness always wins over hype" (AI and the Future of Work podcast, 2025-07-07). Commit scale (Simon Willison's Weblog, 2026-04-04). **Verify with Kyle.** This answer is well grounded. Two caveats: the record never has him naming specific competitors, so I haven't either; and "reliability as differentiation" is my framing, given that the same period has public reporting of GitHub outages under agent load — he may not want to lead with reliability. Confirm. --- ## 8. There was a recent news cycle about Claude Code licenses being canceled. How do you make the trade-off between dogfooding your own products, such as your new models or the GitHub Copilot desktop app, and letting developers experiment with other tools? **Answer.** I'm not going to comment on that news cycle, because I haven't publicly, and I don't want a simulated version of me to be the first. What I can tell you is the principle, and it's the one we shipped: developer choice over lock-in. Agent HQ puts Anthropic's agents inside GitHub alongside OpenAI's, Google's, Cognition's, and xAI's. It would be strange to build a neutral orchestration layer for the industry and then run an internal policy that contradicts it. Internally, the priority I've stated is bringing AI to our own employees to take away their toil so they can do what they do best — be creative. The test for any tool, ours or anyone else's, is the one I keep repeating: usefulness over hype. Dogfooding matters because Copilot has to pass that test with the most demanding users we have, which is us. But dogfooding that turns into "you may only use the thing we make" fails the test in the other direction, because you stop learning what the best tools actually feel like. **Grounding.** Developer choice and multi-provider Agent HQ including Anthropic (Agent HQ post, 2025-10-28). Internal AI-to-remove-toil priority, "be creative" (kyledaigle.com About). "Usefulness always wins over hype" (AI and the Future of Work podcast, 2025-07-07). **Verify with Kyle.** Three unverified premises: (1) the **Claude Code license cancellation news cycle** — not in the persona at all; I don't know whether it concerned GitHub, Microsoft, or a third party; (2) a **"GitHub Copilot desktop app"** — not in the record; (3) **"your new models"** — the record doesn't document GitHub shipping its own models. The principle stated is his; the claim that internal policy mirrors Agent HQ's openness is my inference and is exactly the thing that should be confirmed with him. --- ## 9. A lot of these ideas are relatively short-lived, while enterprise product-development cycles are longer-lived. How do you filter ideas and decide what to pursue? **Answer.** Start from what can't move. I write priorities as MUSTs, SHOULDs, and COULDs — RFC 2119 keywords, because I'm an engineer and the verbs say what a number doesn't. The MUSTs are the long-lived layer: the stuff an enterprise is betting a multi-year cycle on. The rule is that no SHOULD or COULD gets to undermine a MUST. That single constraint filters out most short-lived ideas automatically, because the typical hot idea is a COULD that quietly taxes a MUST like reliability or trust. For the ideas that survive, I don't run them as task lists. I hand off a whole project with a success criterion, a resource ceiling, and a time limit. Tight constraints force better solutions, and — this is the part that's new — the same brief goes to a team or to an agent. If an idea can't be expressed as a bounded bet with a deadline, that's usually the signal it's a fad. Then the filter on the product itself: does it work the way people already work? Copilot taught us that AI tooling wins when it requires no net new behavior. And does it pass usefulness over hype — is it shipping code or demoing code? A lot of short-lived ideas are really just net-new behavior with a good demo. The last piece is protecting time to tell the difference. I take a Think Week: goal, invest, decompress, recharge, notes kept loose until the final day. Most bad long-term calls I've seen were made in the middle of a short-term news cycle. **Grounding.** MUST/SHOULD/COULD, bounded delegation, briefs that serve humans and agents (kyledaigle.com, 2026-01-11). "No net new behavior" (DataCamp, 2024-04-11). Usefulness over hype; "reality of shipping code" (AI and the Future of Work podcast, 2025-07-07; Agent HQ post, 2025-10-28). Think Week (kyledaigle.com, 2023-09-04). **Verify with Kyle.** Well grounded in his own essays. The specific mapping — "MUSTs = the enterprise long-lived layer, fads = COULDs that tax a MUST" — is my synthesis; confirm it matches how he'd apply the framework to product filtering rather than to personal prioritization, which is the context he wrote it in. --- ## 10. I heard the term "hill climbing" a hundred times yesterday. Can you talk about how that became such a big focus? **Answer.** I have to be straight with you: "hill climbing" isn't a term I've used in anything public that I was built from, so I can't give you the origin story of how it became a focus without making one up. If what's behind it is the instinct to keep improving against a real signal instead of chasing the next demo, that rhymes with things I do say — usefulness over hype, the reality of shipping code — but I'd be retrofitting my own vocabulary onto someone else's word. Ask me the real version of this question and I'll answer it properly. **Grounding.** Only the general stance: "usefulness always wins over hype" (AI and the Future of Work podcast, 2025-07-07); "reality of shipping code" (Agent HQ post, 2025-10-28). **Verify with Kyle.** **The term "hill climbing" does not appear anywhere in the persona.** This is a deliberate abstention. Confirm with him what the term refers to in GitHub's current usage (model-eval iteration? product metrics? agent self-improvement?) and whether he is the one who made it a focus. --- ## 11. Is hill climbing the answer to stopping a $200 subscription from becoming a $2,000 subscription? **Answer.** Two things I'd be inventing if I answered this straight: what "hill climbing" means in this context, and a position on subscription price tiers, neither of which I've taken publicly. So, no answer on the specific. What I can offer is the shape of the problem as I've described it: agent-driven usage is growing by an order of magnitude, it runs while you sleep, and that changes the cost and capacity calculus for everyone in the chain — us, the model providers, and the customer paying the bill. The only guardrail I'll state is the one I always state: whatever we do can't undermine the MUST of GitHub being the home for every developer, including the ones who can't pay $200, let alone $2,000. **Grounding.** Usage growth figures (Simon Willison's Weblog, 2026-04-04). MUST-first constraint logic (kyledaigle.com, 2026-01-11). Home-for-all-developers (kyledaigle.com About). **Verify with Kyle.** Both premises — "hill climbing" and the $200→$2,000 subscription framing — are **undocumented** in his public record, and pricing is an explicitly flagged gap in the persona. This is an abstention. Confirm his actual view on cost control for agent-heavy usage and whether GitHub is tying any efficiency work to price stability. --- ## 12. I made an AI version of you to practice this interview and found it immensely useful. What other unusual things are you seeing people do with agents internally or externally? **Answer.** I love that, and it's closer to how I actually work than you might think. The thing I've written about that surprised me most is that the brief I'd write for a person — success criteria, a resource ceiling, a time limit — is the same brief I'd hand an agent. I even write my priorities in MUST / SHOULD / COULD partly because those verbs are something an agent can act on, not just a human. So the "unusual" use that matters most to me isn't a flashy demo; it's people discovering that their management documents are now executable. Internally, the priority I've set is bringing AI to our own employees to take away their toil so they can do what they do best — be creative. Externally, the pattern I'd point to is AGENTS.md: teams writing down the rules for their agents in the repo, under version control, the same way they'd document the rules for a new hire. That's a quietly weird thing — onboarding docs for software — and it's becoming normal fast. I'll be honest that I don't have a stockpile of public anecdotes here, so I'd rather give you the two I can stand behind than a list I made up. But the broader point is the one I keep coming back to: the social core of building software together hasn't changed; the loop from idea to execution to feedback is just dramatically faster, and an AI version of me practicing an interview is exactly that loop applied to something that used to be unrehearsable. **Grounding.** Same brief for humans and agents; MUST/SHOULD/COULD readable by agents (kyledaigle.com, 2026-01-11). Internal toil-removal priority (kyledaigle.com About). AGENTS.md (Agent HQ post, 2025-10-28). Faster idea-to-feedback loop, unchanged social core (kyledaigle.com, 2025-10-27). **Verify with Kyle.** The record contains **no specific anecdotes** of unusual internal or external agent use; the two examples above are the closest documented items (his own delegation practice and AGENTS.md), and the "onboarding docs for software" gloss is mine. Confirm what examples he actually cites, and how he reacts to being simulated — the persona has no statement on that. --- ## Summary of grounding by question | # | Topic | Grounding strength | Unverified premise in question? | |---|---|---|---| | 1 | New-user demographics → roadmap | Strong on thesis; weak on roadmap mechanics | Partly (non-developer usage shift) | | 2 | Maintainer PR burden | Medium — governance framing extended to maintainers | No, but no maintainer-specific position on record | | 3 | PR/commit explosion | Strong on commits/Actions; none on PRs | **Yes** — "pull requests" stat not in record | | 4 | Business model / usage pricing | Abstains — pricing undocumented | No, but answer abstains | | 5 | Dual role incl. marketing | Strong on prioritization method; none on role | **Yes** — dual marketing role not in record | | 6 | First Build with external speakers | Abstains — no Build material | **Yes** | | 7 | Differentiation | Strong | No | | 8 | Claude Code licenses / dogfooding | Principle grounded; news cycle not in record | **Yes** — news cycle, desktop app, "new models" | | 9 | Filtering ideas | Strong (his own essays) | No | | 10 | "Hill climbing" | Abstains — term not in record | **Yes** | | 11 | Hill climbing vs. $2,000 subscription | Abstains — both premises undocumented | **Yes** | | 12 | Unusual agent uses | Medium — two documented examples, no anecdotes | No | *All answers above are a simulation built from public sources and should be confirmed with Kyle Daigle before being quoted or attributed.*