Transcript: GitHub’s CEO On Getting 15 Million Developers To Trust AI With Their Code

The transcript of AI & I with Thomas Dohmke is below. Watch on X or YouTube, or listen on Spotify or Apple Podcasts.

Timestamps

Introduction: 00:00:38
Copilot’s place in the AI coding agent race: 00:07:40
Inside the product decisions behind Copilot’s new agent: 00:10:42
How Dohmke thinks about shaping Copilot’s personality: 00:16:18
How GitHub supports both AI-native developers and legacy enterprise users: 00:20:29
Dohmke’s predictions for the future of software development: 00:26:57

Transcript

(00:00:00)

Dan Shipper

Thomas, welcome to the show.

Thomas Dohmke

Thank you for having me.

Dan Shipper

Great to have you here. Psyched to get to talk to you about GitHub. You just launched GitHub Copilot agents, which is awesome. How do you feel about it?

Thomas Dohmke

I feel amazing. It’s the moment after the keynote when everybody on the GitHub team and a lot of our friends at Microsoft worked really hard over the past few weeks or days to get everything ready. All the announcements today actually shipped, so there's no wait list this time around, and so we can just try using it. And the keynote went well. And so we are really happy about that moment. And now the next phase starts and collecting all the feedback and listening to what people have to say and hopefully we have a lot of positive reactions.

Dan Shipper

That's awesome. The place I want to start is: I remember Copilot as the first AI application of this wave of AI, even before ChatGPT, where I was like, wow, this thing is awesome. And Copilot actually quietly has a ton of users. You have 15 million users or something like that. But when I think about the ecosystem of next generation AI coding like the Cursors or the Windsurfs or the Claude Codes or whatever, GitHub doesn't come up as much. So take me through that evolution and sort of where we started with GitHub Copilot, how that ecosystem has evolved and how you see yourself as part of the whole landscape of AI coding tools.

Thomas Dohmke

Yeah, absolutely. And you mentioned ChatGPT. While we were before ChatGPT, we were not before GPT. So the GPT-2 was kind of the first model that had an impact. Then GPT-3 came five years ago at this event, although we ran it here in Seattle, due to Covid everything was online. But, Kevin Scott and Sam Altman had a session talking about transformers and large language models. And shortly thereafter we got access to GPT-3 and we were playing around with it together on the call and somebody at the keyboard. Others were typing dictating prompts and we were seeing code and in different programming languages. And we had these moments, we were like, holy shit, this actually works and can separate Python from Javascript, and so we had this original idea for Copilot, which was actually three different concepts.

One was code-to-text—have code explained in natural language. And we felt this was cool, but not good enough. And many developers would try that and say, this isn't working. It describes something that doesn't really work in a chat interface where you would highlight things and then right-click and say, explain this to me. But that wasn't good enough. And so we figured, okay, we parked that for now. Chat was the second idea. Conversational coding is what we called it back then, which was in the concept paper. But we felt the model was not there yet and we were very worried about developers trying this out.

And then you have a negative response, or you see the description or the response in chat doesn't match what you ask. And then you stop using it, right? That's always the danger and developer tools to try something and it's not good enough. And then you move on and you always remember that moment instead of what the tool has evolved to.

And that kind of gets back a little bit into the beginning of your question and then auto-completion or effectively text-to-code, but you write something in the editor and the prompt provides a suggestion of what comes next. And that worked fairly well and we had a lot of confidence that the use case would work. Because if you think about what developers do every day when they're writing code in the editor without auto completion, they also have imperfect code either because they're missed it themselves because they don't remember what the API looked like or because they took code in a bit of Stack Overflow or Reddit or some block or what they saw in your channel or some open-source project.

And more often than not, that code snippet that they're taking from somewhere else and putting in their code isn't perfect, right? It might have different variable names or it might be for a different version of the library that you're using. And so you still have to make that work.

So the initial idea behind auto-completion was we can make that work close enough to the real developer workflow to actually provide some real value. And that's how this all started five years ago and ultimately created this market that we are now all in.

We have all these developer tools. I've been in developer tools for 15-ish years or so. I've been a developer for 30 years. I've never seen anything like that where there's such an explosion of startups in different spaces. And you already mentioned Cursor and Windsurf to just look at that space of IDE extensions. There's obviously a dozen or more other startups. There’s all the hyperscalers invested into that space. All our traditional competitors like Bitbucket and GitLab or Atlassian. And so there's this one space of competition and that gives developers a lot of choice and they can pick the tool that— There are things like Lovable and Manus at some part of that spectrum that compete if you want to go from a palm straight to a web application.

There's open source tools that are looking at the evolution of what that could look like. But you have an open-source extension and then you bring in your own model. And GitHub plays in all of these and, in fact, you always place in continuous integration, continuous deployment, right? I mean, traditionally there were lots of competitors in CI/CD that were there before we were in CI/CD because we added actions. Only in late 2018, when CI/CD was already a thing for like a decade or so, we are in the security space where we're competing against companies that are finding secrets or code vulnerabilities depending upon those kinds of things.

And so as GitHub, we've always seen ourselves as long as we are part of the developer ecosystem, where we provide a platform that all these companies integrate with, that all developers come to collaborate with. And our agents and developers collaborate. We are part of the. the developer ethos, developer ecosystem, and that's where we see ourselves.

And so Copilot evolved from our auto completions to chat. We added voice, we added CLI. We looked into customization code search bringing more context into the prompt to agents where we have agent mode and VS Code where you synchronously work with the agent. And where we have the coding agent on GitHub we assign an issue or task to it, and then it does the thing in the background.

You can actually run 10 or so of them in parallel and where we'll look at the pull request and review all that code. And so I think that journey will continue where we provide an end-to-end experience across our platform on GitHub and across the corporate experience between the IDE, and the DevOps lifecycle.

Dan Shipper

I think maybe what I'm asking is: You had developers at the very beginning. And now you're launching this agent, which seems like it's actually really right at the edge of what all those other companies are doing. But for the last couple years, I feel like personally I just haven't seen that much in my world. I know you guys are shipping tons of stuff in the enterprise that has a huge impact. Internally, for example, we use GitHub all the time. That's where all of our code is. We have 50 GitHub or repositories or something like that. But most people at the company are not using GitHub AI tools. So I'm curious what you think happened? What has been going on for the last couple years? And how are you repositioning with this agent launch?

Thomas Dohmke

Well, look, if you go back a year to Build 2024, at that time those competitors were still in a group of competitors. And it was always clear there's going to be a number two and a number three. And with us being the number one that created that market. And we knew that at some point as everything in technology, like Windows, Mac or iPhone, Android, and whatnot, there's always two or three players that define a market. And over the last year, it has clearly turned out to be that race between Copilot, Cursor, and Windsurf. We believe we still have the biggest user base across these three. And as with every competition whether that's in sports or elsewhere you constantly need to keep reinventing yourself.

Just because you won the championship or in the season this year doesn't mean you're going to win next year. And so I think for us the most important thing is that we are able to move really fast. We shipped over 100 things to change locks for Copilot just yet. Now in 2025, and it's only May, we're going to keep shipping and we're going to evolve our platform from VS Code where we announced today that Copilot is going to be open-source. But we also have Xcode support and Eclipse and of course the old school Visual Studio all the way into our platform.

They not only have the coding agent, we have a code review agent. We have an auto-fixed agent that fixes security vulnerabilities, and you can actually already stitch them together and have one agent create the pull request and the next agent review the pull request and look at security vulnerabilities. And then have the SIE agent monitor your cloud resources. So I think the race is on and very excited about the competition because we ultimately believe and develop our choice. It's great that there's many tools out there. and developers have the choice and they can pick the editor that fits them best. And then as you mentioned they're still coming to GitHub and store their code there and then hopefully use Copilot as part of that journey.

(00:10:00)

Dan Shipper

Tell me about the Copilot agent you just launched. Tell me about the architectural and product and UX decisions that you made and why you think it's a better agent solution than Codex or some of the other more popular agents on the market right now.

Thomas Dohmke

It all starts with GitHub Actions, and as I mentioned earlier, we brought Actions to market back in 2018. What are GitHub Actions? Conceptually, you can understand it as our way of implementing continuous integration for continuous deployment or simpler. You have a trigger and you commit and you issue a new pull request or comment on a pull request. And there's lots of these triggers that you can define that then runs a script on a compute instance, a.k.a virtual machine. And GitHub Actions offers you that integrated into GitHub. And so you can define it within the repository workflow file. It's a Yammer file and you say, okay, on every commit I want to run this build script or this test script in this Actions ecosystem. So develop our automation if you will.

You can run something on an event. Push code back, run something for you, or say this pull request, it breaks the tests. And so you're not allowed to merge that back into the main branch. And that ecosystem has now existed for almost seven years and has over 25,000 Actions within our marketplace. And so the cool thing about Actions is that you can compose it from other Actions. And so there's Actions for everything that you can imagine including for what it's worth. Also, lots of AI scenarios connecting to model APIs and a lot of open-source projects and enterprise customers are using Actions for their engineering stack for their platform. And so we have the compute layer available, customers already trusting that compute layer, right? Because ultimately what happens is that whenever you run Actions, you're cloning your source code, your intellectual property onto something else, a virtual machine. And then you're trusting that a virtual machine exists during the runtime of your script.

And then in the virtual machine when the script is done, and then the virtual machine gets shut down and everything gets deleted, and so you're not having your source code. It's outside of your compliance boundary or your permissions who has access to the code base. So we think that's one of the advantages of our agent, that we're already integrating it into the existing ecosystem where people are already running their CI/CD. The second thing is that we believe that the best place for agents to exist is where developers already do their work. And so you know, we already mentioned the IDE with VS Codes, you can just trigger the coding agent from Copilot chat in VS Code and say, add GitHub create a pull request to add tests to the method that has written. And then that spins it off in the background and it does its thing on GitHub Actions and it opens a draft pull request describing what the plan is and then commits changes into that polygraph. And that's very similar to how you would delegate a task to one of your coworkers, right?

So you're basically taking the exact same workflow that you're already doing with your team and applying it to agents and bringing those two worlds together. And that also means that three years from now you can go back to that pull request and it doesn't matter whether a pull request came from a human developer or from an agent developer. What matters is that you still have everything together in one place. And it also means that you have a session log that is stored together for repo. So again, that session log survives as long as you'd like. You have audit logging so when the agent starts its work and it stops its work.

And lots of enterprise customers stream that audit log into their threat intelligence so they can kind of monitor, a lot of the questions they're getting is how do I trust the agents? In contrast to CI/CD where you have a script and you describe exactly what. What the job does, download a library, run tests, upload the test results into the log file with agents. That process is not described because it's a model that is inherently non-deterministic. And depending on the time of the day you get a different outcome.

And you see that when you're using agent mode and you're following it along in VS Code and how you can give it the same task multiple times and it does different things and maybe calls different tools or finds a different file in your code base to get started with. So we believe this integration of the agent in the same workflow that your team is already doing is incredibly powerful because you don't have to relearn how you're reviewing code. How you're testing code, how you're proving code to get merged into the main plan.

Dan Shipper

Do you think at all about the personality or taste or style of the agent? And if so, how did you think about shaping that?

Thomas Dohmke

Yeah, I think part of that shaping is the reason that we are supporting multiple models. Since last year's Universe we no longer have just the OpenAI models, which we still also offer. And a lot of those models have been added since Universe. But in addition we also have Anthropic’s CLO series. We have Google Gemini. We have bring your own key as you can actually just connect to OpenRouter or the Anthropic API, put in your key and connect to these models, including Deepseek as another example. Because we believe that developers want choice in the same way that they want choice when they're picking the pro language and the open-source library or the JavaScript framework whether React or Next or whatever favorite framework you have, right? And the same is true for models because the models they have benchmarked, but the benchmark never tells the whole story. It might be better for one language than another. It might be better or worse for your personal style. And so developers by trialing and erroring these models will figure out what's best for them. And some of that is obviously influenced by social media and podcasters and the news and whatnot, right?

You're trying things out because you heard about it somewhere else. Sure, but somehow we believe from experience, you're going to gain more and more experience learning how these models work. And just like how you are building your craft over the course of your career and you're getting better because you have been in this situation before and you know how you dealt with it then and maybe you learned something last time and now you're doing it better. The same is also a tool for these models. You know how Claude 3.7 Sonnet behaves, and so you pick that because this is the easiest way I can write these test cases. Now the other part of that is what we call custom instructions. We have for all these features, you have a system pump, oftentimes either the pump is directly provided or leaked, and it's in a GitHub just already. And then developers can customize that behavior by creating their own POM files within the repository. And so we support that across all the different surfaces. And so you can customize the model behavior and maybe tell it I only want responses in German and the code of calls and the comments should all be in English because I'm sharing that with my team.

But then the action with the code, with the Copilot should be in German. And in a professional environment here in the United States, that's probably relatively uncommon because once you work in a tech industry, you kind of like to at least be very proficient in English over time, but if you're early in career or if you are in school and you grew up like my kids with German parents, that may not necessarily be the case.

But that still doesn't mean that you don't want to share that code with others, right? And so in the demo, we are democratizing access to software development with these Copilots being able to speak any major human language, not just English. And I think that's dramatically different to the time in the nineties when I learned coding and where, when you wanted to engage in the internet you had to have a proficient level of English.

Dan Shipper

I think there's a serious advantage to being able to use GitHub’s agent inside of GitHub where you're already collaborating. I feel that pain already, just like if you're reviewing PRs and there's a separate interface for an agent, and then you have to go to GitHub to talk about it, it sucks. So I'm excited to try this. And it sort of strikes me that at GitHub, that's a huge advantage for you and it's a huge advantage to be used by millions and millions and millions and millions of developers every day.

One of the things that I'm kind of curious about is how you think about making product decisions when you have to satisfy millions of developers that have a way of doing things that they know how to do and they like it. vs. there's probably this sort of growing contingent of AI first developers who maybe were technical before but are really just like leaning in, basically writing 90–100 percent of their code in a non-enterprise environment. Maybe they eventually will be running a big enterprise, but it's mostly just them in their apartment or in their college dorm, just using these tools to write 90–100 percent of their code with AI. Those seem like sort of different profiles of users. And how do you have so many big enterprise users and that's such a big part of your business. How do you think about serving both of those audiences and doing that?

(00:20:00)

Thomas Dohmke

First of all, I would say while enterprise customers are a big part of our business from a business perspective, where the revenue comes from at the same time the larger part of our user base is the open-source developers. Or those that have some form of free account on GitHub with a public repository, whether that's technically open-source under some proper open-source license or whether it's just a hobby project where you want to put the code out there for others to use. And you're not caring so much about the thoughts behind open-source licensing and whatnot. And both of these audiences have historically been equally important to GitHub. In fact if you go back to the early days of GitHub, it was only public repositories first and then private repositories were added, and then you can still find those threats.

People were begging the founders to actually introduce a payment model, and so they can pay for their GitHub account and earn trust that GitHub will survive and not become an ad business and things like that. And so I think for the longest time, actually was very focused on this today, we call it growing the developers that love using GitHub and the enterprise came second. And we encoded this within the GitHub culture of one of our most important principles is that we always put the developer first. So we're not putting the enterprise first. We're not putting a foundation first. We're putting the actual developer first, right? And that actually goes as far as that everybody at GitHub and not only the engineers, but every role spending in our finance and HR and product management sales, they all are using GitHub for everything.

So we have lots, tens of thousands of repositories with all kinds of information that are not necessarily products that we build or microservice services that we run, but it's folks using GitHub issues and pull requests our terms of service in the repo. And you can see every change in the terms of service for pull requests. So we're using our product every single day and I think that really helps everybody in the company to understand what is important to GitHub. And now what you alluded to is that the developer audience itself is no longer as kind of narrow as it used to be.

Dan Shipper

That’s what I’m trying to say. I think what it means to be a developer is changing in certain ways.

Thomas Dohmke

So I think it's still writing code at the end of the day, whether you're using AI to generate code or you knew how to write code without AI and now you're trying to figure out how do I combine by coding, with writing code manually doesn't matter as much because at the end of the day, the artifact that you're creating is still code. And as soon as your project becomes more and more complex, you gotta have some fundamental understanding of that code. I don't believe in a world where you can create something like GitHub without knowing what the code actually does. Now this doesn't mean that low-code, no-code doesn't exist, right? It has actually existed before AI. And so there are going to be scenarios where it's just vibe code a webpage or using Manus? I met the founders last week and they showed me how they used Manus to create a page to find an office in Tokyo. And it basically visualized all the available offices on a map and so that was a very specific webpage just for them, for that period of time where they're looking for an office in Tokyo.

So this kind of micro app or personal software, I think, will play a big role in the way we are interacting with those agents because every answer an agent can give you is going to be effectively visualized with just a text response. The agent's actually more powerful. It creates a little bit of software that you can interact with and maybe pick up on the flight, trying to put in the other office you're trying to find. And so in those scenarios, you might not need the code because that isn't relevant to you because you're not actually creating software to produce software and sell it, but you're creating software to solve tasks for you. But the counter example is that you can ask ChatGPT how many airplanes were sold last year and it renders your chart. And then you look in the code and you realize it didn't actually pull the source data from some source, but it just filled the source data into a static variable with some random data. And it might even tell that to you in the text, but how it is. Who reads all that text? You just look at the chart, it looks cool. And so looking at the code the simple example shows us that it is still important to understand what the technology does.

And as soon as you get into complex software projects where software is your business, you've gotta understand what the code does. You've gotta have software developers that review this code and approve it before it gets merged because otherwise you're going to have security vulnerabilities. You're going to have functional issues. You might actually lead a feature in a complex application without noticing it. And ultimately, look businesses corporations exist, you know because teams of people are more efficient than a single person. But they exist to sell products and ultimately make a profit for that group of people. And I think AI can not make all these business decisions for itself. The team has to do them. They have to set the parameters of the business to ultimately return money to the founders to the corporation or the shareholders.

Dan Shipper

Last question and I'll let you go. I'm really curious, if we're back here a year from now, what are your predictions for where you guys are going to be and where are you focused? What are you going to shift? And what do you think you want to do to sort of win this future of coding with AI race?

Thomas Dohmke

I think in a TV show— I don't know, but I think it was Star Trek. There was a line, the more things changed, the more they stayed the same. I feel like it was in Deep Space Nine. And, I think on the one side, a lot of things will automatically change, and you see that with agent mode and or white coding as a discipline. Although I think Andre also recently had a blog post kind of like saying white coding maybe wasn't as good an idea as I originally thought. But we are going to have these coding agents, code review agents, security agents, SIE agents they're going to have those available to developers and those that are on the forefront of the field and then know how to adjust their project to be very efficient with these agents are going to get a lot of work done. At the same time we still have lots of companies that have code on mainframes—COBOL and things like that. We still have huge code bases in old school languages like C, C++, Perl. And those things don't go away. And while there is certain progress on app migration, we showed the Java.net upgrade agent today as well. There's a lot of work to be done before we get into a world where everybody's just working with agents and no longer has the right code and IDE.

And so I think the IDE will still be there. There'll be more and more agents on GitHub. And a lot of folks will still scratch their head and try to find the bug preventing them from going home at night or they go home with a bug in their head and then hopefully by the morning when you have a lot of sleep you can figure it out. But, I think we will definitely see a world where you have agents across the whole developer life cycle. In fact, I think there's going to be a lot of opportunity for small companies to use agents for everything, designing a feature, prototyping it, doing customer research, using something like Deep Research to do competitive analysis, maybe even write the business model, implementing the feature, testing the feature, deploying the feature, monitoring the feature. The full stack builder, I think, will become a thing, but there will be thousands if not millions of professional software developers that will still code like we will code this year.

Dan Shipper

Well, thank you so much for your time. It was great to chat with you.

Thomas Dohmke

Thank you.

Thanks to Scott Nover for editorial support.

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn, and Every on X at @every and on LinkedIn.

We also build AI tools for readers like you. Automate repeat writing with Spiral. Organize files automatically with Sparkle. Write something great with Lex. Deliver yourself from email with Cora.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Get paid for sharing Every with your friends. Join our referral program.