Most developer tools were built for human-to-human collaboration. In this interview, Mario Rodriguez, Chief Product Officer at GitHub, explains how AI coding agents are pushing GitHub toward a new agent-native engineering system: from macro-delegation and agent-generated PRs to Copilot, AX, and the future of developers.

Mario Rodriguez, Chief Product Officer at GitHub, explains the inflection point that hit in December 2025: models finally got good enough that you could "macro-delegate" to agents without constantly correcting them. 

What happened to GitHub then? Record acceleration across commits, PRs, Actions, and security scans – and a fundamental rethink of what GitHub even is.

In this interview, we discuss:

We also talk about the redefinition of "developer," why creation (not efficiency) drives human progress, and how GitHub plans to serve both the first-time builder and the Picasso-level craftsman on the same continuum. Watch it!

We prepared a transcript for reference, but the full experience is in the video. And as always: like and comment. It helps us grow on YouTube and bring you more insights.

Ksenia:
Hi, Mario, and welcome to Inference Show by Turing Post. Thank you for joining me.

Mario:
Thanks for having me. It’s a beautiful day outside. Yesterday was a little cloudy, but today the sun came out, so I’m really happy.

Ksenia:
It is a beautiful day. But let’s get to GitHub.

According to Similarweb, GitHub has over 630 million monthly visitors. That’s an enormous surface area for development and experimentation.

So since late 2025, when agent workflows really started working, what changed at GitHub? What did you notice?

Mario:
It’s interesting. Around December, one of the key things we noticed was that model capabilities took a real jump.

Before that, if you were going to do what I call a kind of macro-delegation to an agent, you constantly had to correct it. You’d say, “No, you took this path – you shouldn’t have taken that path,” or “You did this other thing – you should have done that instead.” It was a little bit like dealing with a toddler: “No, no, don’t go that way. Do this instead. Be safe over here.”

What changed in that December timeframe was that you could actually say, “Go ahead and play – it’s safe,” and you would get an output with very high quality.

In my opinion, that unlocked two things.

First, in the developer workflow, people could macro-delegate significantly more and then micro-steer only when they needed to. And that micro-steering didn’t feel frustrating. It didn’t feel like, “Oh my God, I just wasted a bunch of tokens, and now I have to explain everything you did wrong.” Instead, it felt more like, “Okay, you did that – now let me work with you in a loop to make it better.” It became an iterative creation process rather than a correction process.

Second, as agents started running more autonomously in automation, they could go longer. And that meant you could give them better and better tasks. In other words, the ROI of the task went up.

Then, as the industry caught up – people came back from break in January, got settled after the holidays – both things started happening at once. More individual developers started using these newer models with stronger agent capabilities, and more automation started happening too.

And if you think about GitHub, we span the whole development lifecycle. It’s not just the repo and getting code into the repo. We also have issues. We also have pull requests. We also have Actions to build things. We also have security. And they all intersect and build on each other.

So if you get more commits, you’ll probably get more PRs. If you get more PRs, you’ll get more Action runs. If you get more Action runs, you’ll need more security scans. Everything compounds.

We’ve published some of these numbers. I think in March alone we saw 17 million PRs from agents. We can get into more stats if you want, but everything really shot off from there. You probably heard Jensen mention that in the keynote too – we’re all feeling this overall acceleration.

What changed is that more and more people are coming into the platform at a faster rate, partly because the floor of entry is now lower – or at least lower than it used to be. We can talk about that more later.

From a human perspective, that’s exciting. Because as more people create commits, more people create PRs, and more Actions run, all of our services are seeing record acceleration. To use made-up numbers, if we were expecting 5% growth, suddenly we’re seeing 3x that.

And that’s amazing. It really proves that we’re starting to see real value from these agentic workflows – which is why we’re all here.

What Scale Looks Like at GitHub

Ksenia:
What are the main problems with traffic at that scale?

Mario:
I wouldn’t call it a problem. I’d call it a set of engineering challenges that come with operating at that scale.

Some of them are the obvious ones. If you have more load, you need more machines to take that load. That means more servers. One of the key things we’re doing right now is shedding more load into Azure, because we’ve basically hit the limits of how much we can grow in one of our data centers. By moving more repo load and PR load into the public cloud, we can keep expanding.

That helps because if growth goes 3x, 5x, or even 10x, we can still serve it, and we’re no longer constrained by a single region.

Then there’s the broader infrastructure question. You have to talk to providers outside your immediate stack. There was one case where network infrastructure on the West Coast started getting saturated. We don’t own that infrastructure, so we had to work with those providers and tell them they needed to plan for a lot more traffic. There’s a lot of developer activity on the West Coast, so we have to collaborate across the ecosystem to make sure all of it can handle the load.

Then you get the classic scaling effects: at this level, even a tiny issue can have a lot of ripple effects. So you have to invest much more in the fundamentals of good engineering – caching, new storage approaches, different ways of acquiring and serving data. It’s very involved engineering work. But it’s also really rewarding.

A New GitHub: Lower Floors, Higher Ceilings

Ksenia:
Do you reimagine the role of GitHub now that you basically have two different audiences?

Mario:
Yeah, I’ve been thinking a lot about that. I was speaking with John Maeda, our head of design at GitHub, over the weekend, and we were exploring what’s really happening and how GitHub needs to evolve.

He shared this design analogy they had at MIT: low floors, high ceilings. I loved it, because I think that’s exactly what’s happening now.

What coding with AI is doing is lowering the floor of entry into software creation. AI – and these models in particular – like to code. That means many more people now have access to tools for creation that were previously out of reach.

And if you think about GDP growth, it happens because humans create things. Not just because we become more efficient. Progress happens when someone creates something that someone else values. That’s how human progress moves forward: creation through tools.

Right now, we’re lowering the floor. And I think we’re just at the beginning. The 630 million number you mentioned – I think what comes next will be much larger still.

Sometimes I think about Mozart. There were probably ten other Mozarts in the world at the same time, but maybe they never had access to a piano. What’s happening now is that we can reach so many more people. Yes, some of us are sitting in front of a laptop – and that’s already a privileged position in the world – but through mobile, through AI models, through GitHub, we can lower the floor of entry for creation. And I think that means we’ll see significantly more innovation in the world.

The second thing is that while we lower the floor, we also raise the ceiling. Professional developers – people who are already highly skilled – are going to be able to create better and better things. They’ll be able to push the frontier forward.

That matters too. Innovation doesn’t only come from newcomers. It also comes from experts at the frontier of the craft. Einstein didn’t start by developing relativity. He built on a lot of prior physics. He became a craftsman before he made that leap.

So you lower the floor, get more people in, more of them become professionals or craftsmen, and then you raise the ceiling of what they can accomplish.

You called it two different audiences. I think of it more as a continuum.

The mission of GitHub is advancing human progress through developer collaboration. Maybe now we should say developer and agent collaboration. That’s what I obsess over every day: how do we lower the floor, and how do we raise the ceiling? And yes, that may require a new GitHub.

From UI to UX to AX

Ksenia:
That’s very interesting. If you can share more – did that conversation lead anywhere concrete?

Mario:
Yes. John has this visual where there’s a user, and then a bunch of barriers, and the user has to jump through each one. Every barrier is a UI click, or some sort of processing step.

We were talking about what a new GitHub looks like from a design perspective. And to me, a new GitHub is one that has an agentic experience.

A lot of our core primitives today are based on human-to-human collaboration. Now we need to extend those primitives into human-and-agent collaboration. But the primitives themselves won’t be enough. The API layer will need to evolve to become agent-centric. And the UX layer will need to evolve too.

We announced the Copilot app, and I’m really excited about it because it introduces this idea of canvases. I think canvases are the beginning of AX – agent experience.

You have a UI, but that UI is bidirectional with the agent. The UI exposes tools, the agent can read them, and it can affect the UI. That means I can simply tell the agent what I want, and it can do what it needs to do. I don’t have to jump through 50 poorly designed screens if the agent already knows the right API to call.

But the beautiful thing is that it also works in reverse. I can interact with the UI and affect the agent. I can click a button that says “summarize,” and the agent receives that and returns something useful.

So instead of the old model – where you only talked to the agent and waited for something to come back – now creation becomes bidirectional. You have a canvas where, like an artist, you’re shaping something in real time, and the agent is helping you shape it.

That’s what I think the new GitHub will be about: a bidirectional, agentic experience.

And the beauty of that is that it works on both ends of the spectrum. It lowers the floor because people can just chat with the agent and get things done without 20,000 clicks. But it also raises the ceiling, because if you’re highly skilled – like Picasso in your own medium – you can operate deeply in the canvas, and then ask the agent to help exactly where you want. You get both, without leaving GitHub.

So yes, a lot of that conversation was really about moving from UI to UX to AX, and how that could meaningfully improve the experience.

Who Becomes a Developer Now?

Ksenia:
That sounds very creative. Which leads to my next question: who does a developer become now? A creator? A person who clicks a button, accepts, sends the PR? What is the role?

Mario:
Funny enough, I already consider you a developer. You’ve probably already interacted with agents, and those agents have probably written code for you to achieve the intent you had. So in my definition, you’re already a developer.

If we want to generalize, we could just say builder. But I do think the definition of developer is reshaping itself. A developer increasingly becomes any creator or builder who, through AI and through platforms like GitHub and Copilot, can turn intent into an outcome.

And I’m pretty excited about that, because it means many more people in the world can become creators.

Ksenia:
My concern is that you still need to manage these systems – basically be a leader – and not that many people can be leaders.

Mario:
Interesting. I don’t really see it that way.

Let’s say I know how to cook, but I’m not a Michelin chef. That doesn’t stop me from making an omelet. I don’t wake up and think, “Well, I’m not going to open a Michelin-starred restaurant, so I guess I shouldn’t cook.”

I think the same logic applies here. Creation doesn’t require you to become some grand orchestrator of 50 parallel systems. In fact, I think the industry has leaned too hard into that narrative, and for the good of society, I think we should shift away from it.

To me, this isn’t mainly about parallelization.

What matters is creation: what are you making, where are you exercising judgment, where are you shaping something meaningful?

A better analogy might be a self-driving car. You’re not manually controlling all the sensors. The system is doing that for you. What matters is where you want to go. That’s how I think GitHub should work too.

Young Developers and the New Skill Set

Ksenia:
I’m thinking about younger people. More young users will come to GitHub, and they’re worried about their future. If they want to become developers, how should they think about their skill set?

Mario:
For me, it comes back to that canvas and the agent working together. That combination can make you a builder, a creator, a developer.

Then you can choose where you want to go deeper. Maybe you want to become really good at Rust – then we should help you do that. Maybe you want to become very good at building websites. Or backend services in Go. We should help you there too.

But even in those examples, the core thing is still creation.

We need to shift the narrative toward creation, because that’s what actually drives GDP and human progress. GitHub doesn’t create GDP. GitHub enables people to create it. That’s what matters.

So yes – you’re a builder, you’re a developer, and our job is to help you do more of that.

Delegation, Micro-Delegation, and the CAD Analogy

Ksenia:
You mentioned delegation. A lot of talks were about delegation. How comfortable are you with it, and where is the balance?

Mario:
Yeah, I do a fair amount of macro-delegation now. And yes, in some sense I’m parallelizing some of those things. But honestly, I usually only have about three things going at once. I can’t deal with fifty things happening at the same time.

There are some automation-heavy tasks that I micro-delegate a lot. But when it comes to creation, I usually only keep one to three things in flight.

The analogy I like is a 3D printer. You spend a lot of time creating the CAD drawing, and then you hand it over to the printer. It prints it. At the end, you do quality control. You tweak it. You improve it.

That’s how I think about micro-delegation. I spend more time creating the CAD drawing – and then I give it to the agent, or to Copilot, and say, “Okay, now go turn this into the printed thing.” It uses the tokens; it does the work; then I quality-control it and keep refining.

So I spend much more time steering the drawing than the printing. That’s where I want to be involved.

Usage-Based Billing and Token Discipline

Ksenia:
Copilot moved to usage-based billing on June 1. Agent sessions consume a lot of tokens, and many people weren’t very happy about it. What should cost teach developers about how to think about coding now? Is this the end of token-maxing?

Mario:
There’s definitely a lot of “maxing” going on.

One of the key things we’re trying to do is help people create across a wide range of use cases more intelligently. That’s why we have the auto setting. It does semantic routing. So if you ask, “What’s the weather in San Francisco?” we really shouldn’t send that to the biggest frontier model. That’s just not the right tool.

Instead, we can route it to a smaller model. We also just launched MAI Code One Flash, and I’m really excited about that because it packs a lot of power into a much smaller model. That makes it great for simpler development tasks.

Then we have larger frontier models – Opus, GPT, and so on – that we route to when the task really requires that level of intelligence.

The other thing we launched is Chronicle, which I think is really important. Chronicle saves your sessions into the cloud, and then lets you query them. So you can ask for things like: “Help me reduce cost,” or “Help me improve my workflow,” or “What am I doing inefficiently?”

I did this yesterday myself. It told me what I was doing wrong from a cost perspective. Even I get lazy sometimes – maybe I should have switched models and didn’t, or I should have managed context better. Chronicle can point that out.

That’s going to matter not just for individual developers, but also for enterprise FinOps. The industry needs to get to a place where predictability is key. That’s a hill all of us need to climb together.

AGI, Creation, and Staying Focused

Ksenia:
What is your understanding of AGI? What is it for you?

Mario:
Honestly, I don’t think I have a great answer for that. If I had to say something quickly, I’d say I don’t think it’s one huge event. I think it’s more of a continuum. You move through time, and at some point you cross a threshold.

It’s kind of like computing. There wasn’t one singular day where it suddenly became computing. It evolved, and then you realized you had crossed into something new.

But I’m not the right person to define AGI. What I care more about is: what can we do with this amazing technology to empower people to create? How do we lower the floor? How do we raise the ceiling? That’s where I spend my time.

Agent PRs, Human Judgment, and Production Quality

Ksenia:
I have another question about collaboration between agents and humans – specifically pull requests. Have you learned anything from agent-generated PRs? Are they different?

Mario:
Yes, definitely. Let me use an analogy.

Imagine giving a six-year-old a recipe for a cake. The cake is probably not going to turn out very well. If I make the same cake, it’ll probably be decent. And over time, my daughter, through repetition, will get better and better at making it.

That’s what I notice most. With the power of an agent, what matters is what you’re creating, and how good the human is at guiding that creation. As the person gets better and better, the output gets better too.

Now, there are really two worlds here.

One world is: I’m working on my own app, I’m prototyping, I’m exploring. In that world, it’s okay to write some sloppy code and come back later to improve the architecture. We do that all the time. If I’m a PM and I want to create a prototype, do I need every part of it to be production-grade? No. I’m just trying to get something from my head onto the canvas so I can iterate on it. That’s totally fine.

But then there’s professional software development. That’s a different world. There, you absolutely have to care about quality, maintainability, security, and all the things that make professional software trustworthy. You do not want your bank app built carelessly. You do not want your autonomous car making decisions without security and judgment.

So the key is understanding the difference between exploration and production.

Will the Human Stop Being Necessary?

Ksenia:
Will there be a moment when the human is no longer necessary?

Mario:
We named it Copilot for a reason – not pilot.

We believed from the very beginning that the human would stay at the center. That hasn’t changed since 2021, when we first started having these conversations.

I’m still very bullish that creation will always include the human in the loop. The exact shape of that loop will keep evolving, just like it has with self-driving cars. But I think it will still be there.

And some people also love the feeling of direct creation. There are people who love driving a Porsche because they feel the road, they feel the turn, they know when to downshift, when to press the accelerator, when the tires regain traction. Developers feel something similar when they’re building something and really connected to the flow of it.

We want that feeling to remain part of the ceiling – part of what people can still do and enjoy.

Books, Physics, and Agatha Christie

Ksenia:
That’s very inspiring. My last question is always about a book. What book influenced you? It can be from your childhood or more recent.

Mario:
I don’t know if it’s one single book.

I’ve read basically every Agatha Christie book – including the shorter ones. So if there’s an author who really inspired me, it would probably be her. I was very into mystery.

To answer your question a little differently: physics has also been very influential in my life. My father studied physics, and that shaped me a lot. I studied electrical engineering, and if I weren’t doing this, I’d probably be designing circuits. I really love that side of engineering too.

So for recreation: Agatha Christie. For shaping my career and how I think: physics.

Ksenia:
You like solving mysteries.

Mario:
There you go. That’s true. I hadn’t thought of it that way.

Ksenia:
Physics and Agatha Christie. I’ll use that somewhere else.

Well, thank you so much. It was a pleasure.

Mario:
Thank you as well. Thanks for having me.

This interview has been edited and condensed for clarity.

← Previous Interview: Hugging Face’s Clem Delangue: Stop Comparing Engines to Cars / Related interview: When Will We Fully Trust AI to Lead? →