I sat down with Jay Parikh the day of his GitHub Universe keynote. Jay leads CoreAI at Microsoft, the organization building the tools, platform, and infrastructure for AI-native developers, GitHub included. I wanted to ask him the question I've been chewing on all year: if agents are writing more and more of the code, where does the software engineer fit?
His answer wasn't "you're done." It was "your time just moved." The hours you get back from implementation and verification are supposed to go into ideation, creation, collaboration, and what he called "picking right." Then into checking whether the thing you shipped actually moved the business.
The line between engineer and PM is situational
I asked Jay whether product engineers are just becoming product managers. He didn't want to be draconian about it. Some enterprises and industries really do benefit from distinct roles and handoffs: pricing and packaging expertise is different from scale, security, and observability expertise, and those don't blur together overnight.
But he was clear that getting closer to the customer is all upside for engineers. Your customers will like your thing better if you know what they're experiencing. I agree. I don't think you can build a good system without understanding who the system is for.
What does matter is the learning loop. Small teams with the expertise they need can make that loop smaller and traverse it faster, and the team that learns faster than its competitors compounds that learning.
Activity metrics got people moving. Outcomes are the point.
This was my favorite part of the conversation. Jay puts lines of code and PR counts in a box his teams call activity metrics. They were genuinely useful early on, when the goal was getting people past static friction with new tools. You wanted to see broad-based activity.
But that's not the goal. His teams now watch things like:
- PR velocity divided by incident rate
- Cost (including routing work through Copilot Fusion to optimize for the task)
- How long it takes an idea, bug report, or production signal to become a shipped change
- Focus time vs unfocused time and toil, reviewed for every team in CoreAI
That last one stood out to me. They measure the friction: the repetitive, tedious, click-a-lot-of-buttons-and-talk-to-a-lot-of-teams work, and then automate it (sometimes with AI, sometimes not) so people can go think about the product.
I shouldn't have to pick the model
I've felt this forever: the computer can choose the model for me. Jay agreed, and walked through the thinking behind Copilot Fusion. You express your intent, your budget, and the quality you need, and the system orchestrates the right sequence of models and agents. It's not static either. The harness, the product, and the models keep changing, so the patterns will too.
Combine that with Copilot projects and you can flow at the speed of thought across repos, research, docs, and demos while the system figures out which agents and sub-agents to send where. For me that's the next level of leverage: instead of managing a bunch of agents, have an agent manage the project.
Homework
Jay gave two pieces. First, whatever level of ambition you have with these tools, raise it. Find the edge, try different tools and different ways of working, and be bolder than feels comfortable.
Second, go define the outcome metrics for something you're working on. Be explicit. Know which are leading and which are lagging. Put them on your dashboards and wire them into your agents. The agent won't make the decisions for you (you're still accountable), but it's very good at helping you make them when it has that context.
