# Android's AI Evolution: Dual-Mode Development and Agentic Orchestration

**Podcast:** Dev Interrupted
**Published:** 2026-05-19

## Transcript

Today, we have a very special guest joining us, Matthew McCullough, the VP of Android Development Experiences at Google.
And Matthew leads the engineering teams responsible for the foundational tools and platforms and architecture that millions of mobile developers and honestly millions of just people across the world rely on every day to bring order to their lives, to get information when they're not at home, when they are at home, and everywhere in between.
And today we're going to dive into the massive evolution that's happening right now in the Android ecosystem.
You know, it's Google I.O.
and we're going to be getting an exclusive.
look at what is coming down the pipe, but also understanding the shifting engineering strategy from a leader at Google, how they're thinking about aligning to these new challenges.
Because as we all know, the device is the frontier.
The more that we can bring models and technology and AI into the hands and the wristwatches and the ears of everyone around us.
the easier and better that all of our ships are going to rise.
So this is a really high stakes kind of environment to be building for.
Matthew, we're so excited to dive into this chat.
Welcome to the show.
Well, thank you very much, Andrew.
And I'm so excited to, as I said, even in our prep for this, that anytime somebody says, would you like to talk about development and specifically Android development, they don't usually get to finish their sentence before I've said yes.
So I'm really passionate about this space and I happen.
also have a job in it, which is just kind of like a second part of the luck.
Yeah, that's just the bonus on top.
You know, I would be obsessed with the things I talk about, even if I didn't have my job, but then getting paid to do it is just like, oh, this is amazing.
So I'm glad all your planets are aligned.
And I want to start by talking about the current landscape and how you're seeing things change in the development pipeline and what your team really had front of mind, top priority.
What did you need to address and to make possible to bring to the stage of Google I.O.
to make AI power development easier for Android?
devs?
It's a great question.
And it requires us to just do a very quick look back at history.
I always like to point to how we got here and then where we're going as a contrast.
I think three to four years ago, pick your line on this.
If we said, hey, we need to be thinking about tools that don't just serve humans, you get the most quizzical, confused, possible look from an Android dev.
And now if you don't bring that into the conversation, you get a quizzical look like, do you even read?
Reddit, Hacker News, or the like.
And so this is a huge change in three or four years.
Some of you might even argue that's like a year and a half, so we've been more compressed.
So I think the top line thing that we should think about most, Andrew, is that anything that we're building this year, the thematic change that we're telling our devs is if you still want to do this in a hands-on UI button inside the IDE way, we have you.
If you are on your journey because companies are at different stages of this adoption and evolution, if you are working towards an agentic ecosystem, whether it's in a chat window to just get answers or whether it's in actual short-term agentic flow to get some code recommendations or it's long-running tasks, we are building everything for a dual mode, both the humans as well as the agentic flows this year.
So you can expect all the announcements to cover both of those two modalities.
So you're delivering it for anyone in the way that they want to work because the idea is that your ecosystem is so big.
that you have to provide all of these entry points that are seamless and easy, but also intuitive and interchangeable across a huge ecosystem.
Like, that's a really big challenge to do that mental shift.
You said it happened in a compressed timeline.
I think that speaks to, like, the rapid cycle that we're all in.
And so I'm curious, too, like, what do you, when you say as somebody from a perspective at Google, like, that companies are in these different stages of adoption.
Like that couldn't be more true.
We cover that all the time here.
We see people at all ends of that.
What are, do you think, those bounding ends that you're really building for?
Like what do you think are the most forward-thinking kinds of ways that people are using your technology right now?
But then also, how are you making sure that the folks way back at the starting line are still getting started?
I'm going to answer in an upward kind of swing.
So for your last part to your first part in reverse order here, I think I can do it.
From the kind of entry point to this, there are definitely still some of our app devs that are basically using this as an answer engine.
They're looking for help me look up documentation.
How do I kind of little tips over on the side.
And that's okay because that's where they're comfortable, but they are including it.
I do want to note, yes, for bounding conditions, I think...
of our respondents, of our advisory board, of our developer population, we really don't hear anybody saying, oh, I'm not using it at all.
But there definitely is an entry tier, which is just more kind of the Q&A chat kind of approach giving answers.
I think we've watched gravity move over the last six months, and I would really say the inflection point was either November or January, if you wanted to give it a specific calendar month.
And where it flipped from, oh, I'm getting good answers.
This is helping me go faster instead of pop over to the browser and look up stuff and forums or like or chat with my colleagues, to over to it's helping me get work done.
And that's a pretty big shift.
Answers and tips are nice.
We could get that at the coffee station at our offices.
Actually moving work forward is a radical change in a loop because it means that you're staying right inside here.
That little circle of a loop got much tighter.
And then I think at the frontier, you asked me to give you boundaries.
That's kind of where the middle of that bell curve is right now.
But on the frontier end, we are starting to get some of our developers for some leading applications saying that the vast majority of code they write is done in an agentic fashion.
And they're changing the actual role in how they participate to be more one of...
orchestrate, make a plan, describe the product deeply, think more PRD, give oversight and overview to the output of the agent, but less that kind of like inspect the curly braces, ankle brackets, and quoted strings kind of inside.
That's kind of thin, heavy, and thin in the three that we just covered.
Right.
Really what you're seeing is something that definitely gets, I think, echoed a lot about the new skill set of engineers and the kinds of tasks that they are doing.
Because there was this dramatic shift.
I experienced it too, where you come back from like winter break and suddenly you feel like, oh, this stuff is actually kind of doing a lot of my job now.
And it's interesting, but also kind of scary.
And you try to get closer to that and understand it.
And in doing so, you realize that you play such a pivotal role in preparing all of the stakes and the pins as they fall.
There are so many new skills to build and figure out to get more out of this.
And it becomes like a new level of learning and building.
So how are y'all thinking about the new generation of builders?
Like what kind of skills do you think are going to be most important that people right now, since the top of the year, have been using to get more work done?
There's a funny thing that you talk about.
kind of new and frontier, then at the same point in time, you know, I've been in this, you know, coming on three decades, there's a humor to this too, that CLIs and text user interfaces are cool again.
I have so many feelings about this, like...
old me is proud of new me or new me is digging up skills from old me.
So there's lots of fun with that.
But I think what it actually comes down to is that some of the fundamentals, this is the comforting piece in a very disruptive time, is that some of the classic foundational good practice approaches that we've had are still durable.
This is for all the headlines.
This is not necessarily throwing out everything and starting over.
It's If you ask me, it's kind of like coming back to core longstanding good principles.
Code review is now more important than ever.
There's a humor in this.
Like you want to make sure what's going in is known, understood quality.
You're adding to the quality of the code base, not diminishing it over time.
Second, you want highly composable tools.
And one of the concrete examples that I wanted to mention to you is to point at Android CLI.
Now, some of our audience is like, wait a minute, didn't...
Didn't you have that a ways back?
And then we went to IDEs, but we actually brought this back in a new and updated fashion so that you can manage builds, you can create new projects, you can manage your SDK installs from this.
And...
CLIs are very usable, like from an efficiency typing perspective, but they're also very usable for agentic workflows as well.
So really what I'm seeing from this from the beginning of the year is make sure that you have composable tools, make sure that there's a command line or API equivalent interface, MCP being all the rage, and that you're serving.
that kind of curve.
We have such a big developer community, 3 million devs that are active here, that we can't leave any part of that curve out.
We can't just say, oh, sorry, we're no longer serving.
So we've got to make it user interface viable for the folks that are still there.
But we've definitely got to make sure that it's accessible for the people pushing the frontier because they're also the ones who tend to lead in innovation on the platform.
We've got to do something for the move fast, write it mostly in agentic loops.
That's kind of where the most innovative applications are often built as well.
Yeah, we have to support those really tight loops that people find and they manage to get these like really...
huge gains that we can't even envision now.
Because as we get these new things, we get new platforms to stand on that let us see new levels of innovation.
And folks maybe underestimate the level of exponential kind of learning and opportunity that's available if you do kind of unlock those things with like what you said.
It's an invitation to go back to basics, go to the primitives, and find the composable ways to work.
a newly imagined way of like how maybe it was done in the olden days because really what's happening is we're still we're still in this painful In this painful place where, you know, the agent and the LL can speak machine code and be in the machine world, and that's where they live in, but we have to live in user space, right?
So we need to get, like, as all the way down to the bottom of the tank in the user space.
Like, we spent all of these decades building up, like, TUIs and then web UIs and then apps and then, like, all this level of abstraction.
And then you build all—we're working up there, we're constructing up there.
It's like, you know, a floating city.
But, like, we have to— to go down and like find those bare metal basics for working with the technology while still being able to interface it in a natural language.
And obviously the terminal is on a resurgence.
I'm back in the terminal now for all of my work, which I never thought would happen because while I've used the terminal plenty, I was never like, oh, I'm going to be in Vim.
I'm going to be like in Tmux.
But now that's like exclusively where I spend my time in it.
Yeah.
At the same time that, that was an invitation to, strip away complexity that once I got rid of it, I realized wasn't helping me and I could find new ways of working.
And so while folks, I think, get tempted in an agentic era to add complexity, to add newer things on top, I think that's also like the invitation to go to your stack and rip things out and find a way to simplify so that you and it can have a lingua franca that's much more portable.
Andrew, I've got three things you hit on such stuff that's so important to me.
One, there was an element in there you almost hinted at it, which is like, prove it though.
There's like a higher bar with so much coming at us.
There's like marketing, meh, prove it.
is kind of like a new mantra to some degree, even if it's not said explicitly.
And one of the ways that we're trying to do this to say like, is this helpful?
What can you strip away?
What can you keep is Android bench just to give a little pointer at this.
We kept hearing like, which model is the best, you know, for Android development.
And everybody has an opinion on the internet and YouTube comments and Reddit and every other place.
But then let's go to numbers.
Let's measure.
Let's let people repeat this themselves.
So we came up with an open benchmark a couple months ago and released it.
And you can actually see the evals.
It's working on real code bases.
You can see the change and we provide those scores on a monthly basis.
So that hits two of the items you raised.
One, give us hard numbers.
Let us measure.
Two, let us verify it.
It's maybe 1A.
Let us verify ourselves.
And two, strip away unnecessary complexity.
Hey, pick the winner.
Cut just to that.
Use that for your loop.
Get to the tool that works.
You don't need, you know, 17.
There's one other element of this, too, that's interesting as well, because you talk about the complexity.
We're shifting just even over the last six months from managing single long-running agentic tasks to now managing them in parallel.
And you talked about the role change as well.
We've got to adapt this inside our IDEs and our text user interfaces, because six months ago, spin it up.
grab some coffee, come back, see if it did a good job, do the code reveal.
Insufficient.
for the current era.
Now we need a queue of these.
This one's working on a bug backlog.
This one's working on a feature.
This one's, you know, prototyping something forward looking that we may not, you know, decide yet to land in the application.
And those are all running on the side.
So we've got user interface evolution that's also happening inside the IDE to be able to manage these type of things in parallel, these long running tasks as opposed to a one to one.
And that goes back to your other element about the role change of even an Android developer.
are effectively getting a promotion to a manager, even if that is a manager of agents, not necessarily a manager of people.
And that pushes one last time to draw the full circle.
If you're a newly promoted manager, even of agents, simplicity and stripping to the essence of is the only way you'll survive the change.
Exactly.
Otherwise, you're just going to get clobbered in all of the noise and the meta of everything that's hanging around, working with all those agents and all of these disparate systems and tools.
You're back in this context-switching hellscape that we were all trying to escape from.
And so it's truly like the challenge to simplify.
Like you said, everyone is now in a manager.
role.
You know, you made a comment earlier about like you're no longer going in there and manicuring like the curly braces and whatnot inside of the code.
That's completely true.
It's like we've talked about that extensively of how you now the responsibility is to get deeply aligned about what needs to happen and then have a system to enact it with these loops and levels of orchestration.
I want to get your mindset on that first part, you know, getting aligned.
to do stuff.
I think that's the biggest challenge for large companies right now that have a lot of resources, have a lot of people, have a lot of opinions about what they need to do in order to be successful in an agentic era.
How do y'all think about getting deeply aligned on something before you throw agents at it?
Or do you just throw agents at everything and then get aligned after you see what they do?
How do you think about it?
This is an interesting question, and we can speak about it from the Google perspective.
Then I can pull out a nameless large partner that works in the Android space and then kind of blend the two.
So starting from the Google angle of this, I think...
at scale, it causes us to refocus back on being great at coordination.
Once again, you know, ebbs and flows, but we're back on coordination.
And I think about what are the highest fidelity vehicles?
And this changes from company to company, but what are the assets?
You can answer this for yourself, Andrew.
Like what artifacts, what forms give you highest information, highest quality signal for the lowest cost of actually reading?
Is a 20-page PRD where you really get awesome understanding at an efficient point in time.
I don't know.
Some of us are starting to question that.
But have you ever had an opinion?
I think most of us have, so I'm going to presume here.
When you play with the prototype, for some reason, all of us who've worked in software have a lot of opinions really quickly about playing with the prototype.
You should move this.
This should be second in the flow.
This is not performing enough.
Don't reveal this too early.
I need this to actually be pre-populated.
So I suggest...
that as it's gotten cheaper, at least from a time, maybe not from a dollar's perspective, but from a time perspective, to put together prototypes, there's a real push.
This is a bit of an insight into our customer advisory board and the like, but there's a real push for working touchable prototypes.
over that same amount of time or energy being invested in long documents that are pros.
And I think that's super cool because in some ways, that's the thing that our users, if we're thinking user-centric software, are going to have in their hands anyway.
So you talked about being grounded.
This is grounding ourselves in what they're going to have, what we're making for them, much sooner in the cycle than we would have under the previous era.
We're changing the IDE.
I mean, the mapping for this then is Google.
What are we doing?
And then back to our partners, we're changing the IDE to make prototypes like the super easy AI Studio, which people are like, wait a minute, I didn't think that's Android Studio.
Did you misspeak?
No, I spoke correctly.
AI Studio is gaining increasing capabilities to be a prototyping surface for applications.
Stay tuned for...
more and more over there.
We're making it easy to take existing assets, web applications, React Native, Flutter, iOS applications, and bring those over as starting points.
So instead of, you know, if we're talking a platform or a kind of game, you're not starting here anymore.
We're just letting you, dare I say, Donkey Kong or Mario Jump up to like Platform 7.
That's your new start to the game.
You can just start at that point.
And then it's...
That's your composability layer.
Going back to what you said earlier, that's the composability, going back to what you said earlier, because you're letting people bring in what they need to work within the ecosystem.
That's exactly right.
And then just to finish on that, I think what our audience is seeing is, okay, as we bring these tools to bear, they're having to rethink, where do I have an asset?
Where do I have a prototype?
Where do I have a screenshot?
Where can I empower somebody who doesn't have...
software engineer or SWE in their title to help me get to platform seven.
So now it's actually more inclusive software development because it's not just limited to a couple of letters in your particular title at your company as to whether or not you can participate.
And I got to say, like, if that was the only thing we got to mention in this whole podcast, that's the most exciting piece.
I love software development.
I love people being in it.
I love building stuff.
And we may have just unlocked the biggest participatory welcome.
banner for people to come in and actively, actively participate in that act of creation.
We're trying to do it through our tools.
Back to you.
I'm just excited about this as you are.
I see the same opportunity for companies.
And you're exactly right that the economics about getting invested in your product and putting yourself in the perspective of your customer, your user, has never been simpler.
You hold out to obviously maybe it is simpler in terms of time versus cost or whatever the case.
But the fact is that folks can get aligned around the same point and see the same thing and play with it and immediately develop those opinions, those outside of this tradition.
traditional software engineering role can develop those opinions.
And now everybody...
Everybody in a company can have a hand at building the product, at being customer obsessed, at understanding how people really use the output of their organization because now the ability to collaborate is one bounded by natural language.
It's one bounded by alignment and by cohesion and by knowing where the North Star is.
And that's all the stuff we should have been doing the whole time.
It's just that we were always distracted by having to deal with, like, you know, manicuring the curly braces.
And so I completely agree that the companies that wake up and realize that it's about bringing everybody into that builder conversation and then getting everybody in the same stakes, those people are going to create just like these cohesive builder-obsessed organizations.
And the upskilling, I think, is going to be amazing as folks are able to collaborate.
You get designers that will ship stuff.
You'll get...
product managers that are in customer calls.
You'll get engineers that are in customer calls because now engineers need to be closer to the customers than ever before.
So I'm really excited to see the kinds of things that come out of the announcements, what people take from the developments and build with it.
Is there anything else burning in your mind about what might be exciting at Google I.O.
that you just have to squeeze in and are a few more minutes left?
There's always a bunch, but one comes from something that you mentioned.
So specifically, part is sparked by something you just said before, which is around what are we building?
Do we kind of get to rethink this from first principles and then specifically the phrase natural language?
And I think you were unpacking it with me a little bit around the developer side.
What are we prompting our agents?
What are we telling them to build?
But there's an...
And to this, that's pretty important too, with Android 17 announcements having just come out from the Android show and then more to come at IO.
I think that consumers' expectations of how they use these devices are also rapidly evolving, which then dot, dot, back, dot, dot, back means that developers and product managers also need to be updating how they're thinking about what they're building as well, not just how.
how they're building, which has been a lot of the focus of the show.
I think some of the rethinking that we should think about is like a couple of simple prompts just to get folks started.
Number one, where is the input modality ripe for changing again?
Design is a super easy one to at least get the conversation started.
Whereas before we, you know, do pixel drags and changes and we point arrows to like color that needed to be changed.
What if you just had a mock and you're like less.
less purple, more blue, slightly more, you know, modern, deeper shadows.
I'm looking for the aesthetic.
That's usually pretty easy to get out of folks.
But then when you ask them to mechanize that onto the screen, that's where the time takes.
Maybe that's an input modality that can change inside a design application that somebody was building.
And then second, you have different modes.
People are on the run.
They're on a moped.
They're on in a car.
In those moments.
input on a small keyboard type in characters is not optimal as well.
Do you have like a simple choice menu that could be voice activated, ABCDE?
Can you actually have full open crompt text input?
These are things.
And then lastly, where is interface?
baggage in wizards, you know, we've lived since the 90s with this of like step one, press next, step two, and so on, where can you just kind of express all of the needs in your application?
So as you're thinking about your application design, in kind of a one shot fashion, and Android 17, I think is a great example of this, we put a lot of automation in this kind of moved the operating system and platform forward in this way.
And I'm excited to see apps need that moment too, where you're just like, Can you just do that?
I know I'm aggrandizing, but a little bit like how excited I am about this.
But can you just do this thing?
Just go figure out how, figure out which apps and tools, figure out which step in the flow.
I want this to transact, to buy, to purchase, to search for.
Just get me to the result.
Leave out all the middle part.
Just get me to the really good part.
That's kind of the exciting future of software and mobile.
Just get me to the good part and leave out.
And you take all the digital laundry and shorts.
Exactly.
It's like, we have to remember as developers and as software leaders like that, you know, just...
As much as we have this huge opportunity to build with this new level of technology and unlock all of these huge gains and do things we couldn't before, our customers and our users have the expectation and knowledge and understanding of what this technology is and what it can do and what other your competitors are doing with it.
And so there's an expectation that is like, oh, just do it for me.
What do you mean I have to do a manual wizard?
Any level of friction is going to alienate in a world where your taste is an immediate action.
for things that you want and do, it's going to completely change how people interact with software.
I think right now we're still thinking in like an old way of how people would onboard for stuff.
So I'm excited to see what kinds of experiences people build with the technology, especially like you said, to make it work in all sorts of modality.
And I know we're at time here, Matthew, but I just wanted to ask, where could folks go to learn more about what we talked about today and follow you and keep in touch with the stuff you're doing?
Well, I think the core part of this is developer.android.com.
That's the best deck, as we friendly refer to it here inside the Android community.
We keep that refreshed.
It's not just API guides, but this is opinions, blog posts about the latest releases, how tos on somebody using these latest tools, and then even occasionally explainers as to why we're going in this direction because I'm a big...
I'm a big fan of explaining like why things are changing and then giving you the how to make it possible is kind of a yin and yang to this.
So that is the central place for it.
And I would also just say like encouraging our audience is super exciting.
If you wear a dev hat or a PM hat, if you identify as a SWE or a UXer or the like, this is actually a pretty exciting.
opportunity for you career-wise.
Because I think these things that even Andrew just unpacked here at the end, give you the opportunity to change business outcomes, stickiness, user retention, higher user acquisition through the funnel, higher completion rates, upsells and purchases.
Like there's so much business goodness that quite frankly, you just got like a free upgrade in your role for the leverage that you can have at your company.
But Andrew, simply thank you.
We covered from CLI to 30 years ago, transformation of the industry, curly braces, user impact, even finished with a business hat.
I don't know that there's opportunity to pack anything more into these 27 minutes.
I know.
What a journey.
It's been a great chat.
And we're going to get all of those links in the show notes as well for our listeners.
So be sure to check out the Google I.O.
keynotes.
And we'll be following along here at Dev Interrupted as well.
Matthew, thanks again for coming on the show.
Thank you, Andrew.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the APEX framework comes in.
APEX is a new operating model for engineering productivity designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
APEX is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.