BUILD

SUCCEED

David DeRemer:

Hi, I'm David. This is Build to Succeed from Very Good Ventures. Today, we speak with Andrew Brogdon, DevRel lead for Flutter and Dart at Google. In this episode, we'll discuss the unique nature of DevRel, Andrew's unique journey, how DevRel is changing in an AI-enabled world, as well as some exciting and inspiring ideas for the future of software and app development. I hope you enjoy it and now let's go talk with Andrew. Hi, Andrew. Welcome to the podcast.

Andrew Brogdon:

Hey, thanks for having me on.

David DeRemer:

Yeah, thrilled to have you. I've known you for a while. You're obviously a face of Flutter, which we're big in, and so it's a great pleasure to have you on and be able to talk with you. Maybe to get us started, get us warmed up, I want to know a little bit more about you. So, is there a non-tech hobby or interest that you've picked up over the years that maybe people wouldn't expect from someone in a technical role?

Andrew Brogdon:

Sure. Previous to my current career, I was actually a poet, which is it's always the first question people ask when they see my resume because I have two degrees in creative writing rather than computer science. Long ago before I had children and ran out of free time, I used to write poetry. I went to grad school for it. I don't know how much time we have in the podcast. I can actually give you the 30-second, 60-second story.

David DeRemer:

Let's hear it. I want to hear it.

Andrew Brogdon:

Yeah, sure. So, I originally went to school a long time ago. It was a physics major, switched to computer science, left that, and went to work as an engineer. This is back during the .com era, which will tell everybody immediately how old I am. It didn't seem that dumb to leave school to go to work, and that's what I did. Then it became clear that I needed to go back to school and get a degree. Around that time, I was reading a book on the Java programming language and they were showing how to print text to the screen and the text that they used in the example in this just 400-page Java book was a poem by a Beat poet, a guy named Lawrence Ferlinghetti. Some of the folks listening to this may have heard of him. He's the patron saint of San Francisco Beat poetry.

I read that and realised I was more interested in it than anything else in the book. So, I went to a very early version of Google at the time and I threw the first line in. I found out what poem it was, who had written it, what book, ordered the book, then ordered a bunch more and a bunch more and eventually went back to school as a poet. So, then met my wife, realised we were going to get married. Poetry doesn't pay the bills. Even famous poets like T. Elliott was a publishing executive and all of them seemed to have side hustles back in 100 years ago. So, I went back into software engineering, moved out to California for my wife's job as a professor of English, and ended up working at Google.

David DeRemer:

That is an amazing story. I love that. So, you have this interrelationship between your love of poetry and software engineering based on even the origin story of that.

Andrew Brogdon:

A little bit. Yeah.

David DeRemer:

That's very cool.

Andrew Brogdon:

It sounds too cute to be real, but that is the true story.

David DeRemer:

That's awesome. I mean poetry, right? It's writing a succinct text that creates meaning and value, not software, right?

Andrew Brogdon:

Yeah. The smaller it is, the better it is. When there's nothing else that you can take out, that's when it's finished. I like that, that same thing with software engineering.

David DeRemer:

Do you feel like the poet in you still gets to express itself in the profession you've taken on?

Andrew Brogdon:

Very rarely. My creative outlet these days is the jokes that I manage to squeeze into our YouTube videos, I think. So, when we did the thing with Rivers Cuomo last year, for example, I got to write that intro. So, I was writing jokes for Rivers to say, and I have those occasional moments where I'll have a creative outlet like that. Maybe if we do it again, I can get them to read an epic poem or something about Flutter. I don't know.

David DeRemer:

Well, knowing you and getting an opportunity to see some of the work that you've done, the content you've created over the years, things like that that you did with Rivers, it's actually really interesting background and insight to know that you come from that creative writing and that poetry background because now that you mentioned it, I see it in your persona and how you communicate. So, it's something to be said for that and it seems like it has helped you in your career.

Andrew Brogdon:

Yeah, I am by no means the world's greatest poet. I was far from even the best poet in my class in the programme that I was in. So, it's not like going through the MFA programme for three years was setting me up for a poetry superstardom, but I do think there's something useful in my whole identity was about creativity and craft for three years, those three years. What can I come up with that nobody else has come up with? How do I make something new out of the same words everybody else is using?

‍

I think being focused on something like that for a significant length of time helps you develop some new skills and a new way of thinking about what you're doing for your own work. So, even though I'm never going to go win the Walt Whitman Prize or a Pulitzer or something for my poetry, I definitely benefited from it. If I am providing value to our community and to the world through the work that I'm doing now, the work I'm doing is probably better for those three years that I had.

David DeRemer:

I love it. That's super interesting. I mean, I think one of the things that's been really fun in my own career, given what we do, meeting in a lot of different people in a lot of different industries, the backgrounds that lead to what we do, everything in our space, we are building software, building applications, but there's so much creativity that goes into it. So, creativity is a skill in and of itself, and you can practise and learn that in many ways. It doesn't just mean designing a file or writing some beautiful concise bit of code. It can come from creative writing and everything else.

Andrew Brogdon:

Yeah, well, I'm sure you need it in your job. You have to lead and motivate and inspire not only the people in your company but also the people that you're talking to as potential clients. This is the future that we can get to together and stuff like that. I'm sure being able to convey that succinctly and correctly is important.

David DeRemer:

Communication, conveying ideas, and in a way, software applications are communication and conveyance of an idea. You sit down with an idea, creativity. I actually want to rewind back to that statement you said because as you were describing what you were doing in those three years, it sounded like you could have been describing a CTO at a startup bring that creativity and thinking, "How do I create something interesting no one's ever done before with words?" Same idea. So, you're in DevRel now, which actually seems like the perfect intersection of these things, of being able to actually convey ideas to people effectively. We know you started in creative writing and poetry and then you got into Google. What's been your journey through Google to your current role?

Andrew Brogdon:

So when my wife got her job offer, we were living in Ohio. The first thing I said to her after congratulating her was like, "I'm going to go work at Google." I made that a life goal. Specifically the thing I wanted to do was be one of the people on YouTube. I had seen the folks that were... I think it was Polymer at the time that they were advocating for and teaching people how to use and the idea that I might be able to do that and have that scaled effect on the developer community, that was something that I wanted and be one of those people that was helping everybody was something I very much wanted. So, I applied as DevRel to Google. It took me two tries to get in the company. I was so nervous for my first interview. I [inaudible 00:07:19] screen.

‍

I could not have told the guy my middle name if he'd asked. I was so nervous. But the second one, I did a little better. DevRel just seemed technical, but it also just seemed fun and it seemed like you would be able to see when you helped somebody. In a lot of ways, you would see somebody be like, "Yeah, that helped. Thank you for that." That was the thing that I wanted more than anything to know that I'd done something to help other folks. So, I started in Ads DevRel a long time ago. This is like 2014. I was a wide-eyed Noogler and I was hired by a great manager, a guy named Adam Rogal who immediately left for Uber and now I think is in Door Dash, but he taught me the ropes. I had another good manager there.

‍

At a certain point with Ads, I think a lot of people, they get to a point where they're either going to stay in Ads forever or they're like, "I've done this for a bit and I want to go do something else." I got really, really lucky and saw an internal job posting for Flutter. So, this was winter of 2017 and they were looking for an engineer on the DevRel team. So, I went and talked to Matt Sullivan at the time, who you would remember.

David DeRemer:

Oh yeah, Matt Sullivan.

Andrew Brogdon:

Great manager Matt and schemed out a way to work on the AdMob plug-in for Flutter as a way of testing it out and also trying to play my way onto the team. So, as soon as I started coding with it, I was like, "Well, I don't want to code with anything else. I'm ruined for other forms of development. I just want to do Flutter now." So I stuck with that and joined the team as the first peer engineer on the DevRel team. Eventually, Matt moved on to another role and the management job opened up. This is right at the start of COVID that happened. So, I ended up in the manager role.

‍

So, I stopped working for a living as I like to say and just started doing spreadsheets and emails and reports and stuff. Now the job is very different because I ended up enjoying the DevRel work vicariously through others. There are a lot of wonderful folks in the DevRel team and I get to watch what they do and occasionally give them advice on how they can get more out of their work and stuff like that and then go tell people how great they are, get them promoted.

David DeRemer:

So as the poet Andrew, do you miss doing that actual work? One of the things about being a manager, you do have to live vicariously through it, and I like that phrase scaled effect and that idea of what you were hitting on there for DevRel, how you can have this scale and impact on there. I think the same thing applies to management, your ability to magnify and amplify through your team and make your team more productive than what you alone could do, but sometimes we want to get into the work. I mean, I struggle with this. I haven't written a line of code in a long time and I miss it. I miss it. So, where are you in that journey?

Andrew Brogdon:

You bring up a good point. There's a positive and a negative to it. On the positive side, I love the access to information that being a team lead gets me and the ability to be in certain conversations about where are Dart and Flutter going in general or what is Google doing in general about this thing and being able to know what's up and to earlier in a work stream be able to affect it and to be able to slot people on my team into it in a way that's beneficial for them and whatever we're trying to do. That part, I'm really grateful for. What took me a long time to get used to is while you're doing that, you're slowly losing your knowledge of certain other things.

‍

There was a point where I felt like I'm a really good expert level Flutter developer, and now I've had to give up some of those skills. I haven't had as much time with hands-on keyboard. Similar to you, building things that way. So, if you asked me to do certain things that are very recent Dart language features or Flutter features, I'd have to stop and go read one of the docs that my team created to review it and then go in first. I was joking somebody the other day, it used to be if you asked me how to do something with Flutter, I could give you an answer. Now if you asked me, I'm like, "Well, I know somebody you can talk to," and my job was to make sure there was somebody that you could talk to who's an expert in that thing. But I have to deal with the fact that I am no longer that person and that's been a challenge.

‍

David DeRemer:

Yeah, it definitely changes, but you need people like you to be rising up so that the next generation can be amplified and know how to be successful effectively. We've also here talked a little bit about DevRel in general and I think people can maybe piece together a little bit about what the role is. Maybe take a step back and how would you define DevRel in terms of what you do and its impact on the world?

Andrew Brogdon:

Sure. I think every company and even teams within a company as Google, they all have different definitions of it, it seems like. I tend to think of myself as the engineer closest to the door. So, if you come in to talk to Flutter as a thing, at least the Flutter team at Google, I'm the first person you would see and I would be there to say, "Hey, thanks for stopping by. What can we do for you?" and figure out what problem you're trying to solve and how we can help with it. Hopefully, as a metaphor, that's not too bad, but I think the only reason Flutter matters in the world is that people use it to build things for actual users.

‍

There's a joke that sometimes goes around the office that the folks working on Flutter don't actually spend a tonne of time building apps because they're not application engineers. They're SDK engineers. That's just the job that they have. The thing that, like I said, makes Flutter matter is and causes it to be like how many minutes a day are you spending with Flutter on a device as a user? The only reason that's not zero is that people outside the Flutter team have built things that matter. So, they can't do that unless we connect the people with the technology.

‍

So, there's outbound ways of doing that where we're making sure that we can explain the value proposition of Flutter and help you make a decision about whether you'd want to use it and we can help you get started as quickly and easily as you can. We can do things to help make sure the community that you're joining either explicitly or implicitly when you start using Flutter is a healthy one that you can be proud of being a part of. Because there are certainly tech communities that people aren't proud of being a part of and things like that and then there's also internal work that we do. Every time that we go to an event like a FlutterCon or a Flutter event like that, we would want to hold a listening session. We have notes that we take from conversations.

‍

We talked to somebody who had this problem or where they were happy about this change and things like that. All of those get funnelled back into our engineering and product teams to make sure that that connection from the person who we're trying to help by making a tool like Flutter and the people making that tool are as in sync as we can make them. So, it's a lot of communication. Now as I'm stopping and thinking about it, it's a lot of two-way communication and a little bit of teaching and a whole lot of engineering thrown into the same time.

David DeRemer:

Sounds like a lot of care too for the community, making sure you do right by them and you listen to them and engage them. Kudos to you and the others on the Flutter team, both current and past. I think one of the most exciting and interesting features of Flutter has been the community and the general positivity of it. You mentioned that some communities, it's maybe not as aspirational to be a part of it or they're a little bit more confrontational or something like that. For the most part, I think Flutter community has been very welcoming, friendly, and engaging. That has to be by no small part or from no small impact of you guys.

Andrew Brogdon:

It is funny, like Philip and Emily who were two... They're no longer on our DevRel team, but they were a few years ago. I remember they were working on a blog post to define what made the Flutter community a little bit different and what were the principles that we'd want to see. It's like 2018, 2019, where everybody in Flutter just looked at each other and they're like, "We're not going to screw this up. We're going to spend time actively making sure it stays this way."

We all just agree and everybody agreed, and that's not just DevRel. The engineering team, the product leaders, everybody knew that the folks that had already started to gather on Flutter, they weren't a typical developer community. They were far more welcoming. They're far more creative and fun and all of those positive things. It was pretty clear even at that time inside Google that it would be a crime not to make sure that we kept that going.

David DeRemer:

I love that. How has it changed over the years, DevRel as a profession and with the tools that you use and the approaches and how you engage the community? How has that changed and how do you see it changing into the future?

Andrew Brogdon:

It's changing a lot right now. That's a good question. I think a lot of things we do still would've been the same. We'll do them slightly differently now, but they're the same things that we would've done eight years ago. I wanted to make YouTube videos the day I got to Google, and I've mostly been making them this whole time. The facilities have gotten a little bit better definitely. The first studio I worked in at Google, we'd occasionally have to stop in the middle of the take because someone would walk by in hard-soled shoes outside because it was just a random meeting room that they put sound insulation in and a camera. Now there's a dedicated studio and stuff like that.

‍

So, some parts of it are more sophisticated than they used to be, but the core of it is still just getting out and talking with people and those things have not changed. I think one of the interesting bits now is the entire team exists to help solve developer problems. We want to make developers happy and fast and to help them improve the quality of their software, Dart and Flutter specifically. In the last year, two years, it has become very clear that that experience as a developer is going to be more and more defined by AI powered tools. So, now we're thinking about things like, okay, if a certain percentage of the code is going to be generated by an agent and then reviewed and modified by a human being, that's the near term feature, I think, speaking for myself, just to be clear.

‍

That's the experience that we need to make as good as we can possibly make it. So, one of the things that we're thinking about now is how do we make these agents code better and not just humans code better. We have a bunch of developer resources for human beings to read and use to build their own skills. All of these models were trained on it because it's all out in the open. You can find it all on GitHub and on our website and stuff like that and on YouTube and things like that.

‍

But an example change that we're talking about right now is should we be shipping a markdown version of our release notes so that if you're somebody using an agent, hopefully Gemini, but whatever anybody would like to use, Claude or any of the others, that's not going to be trained on a new stable release of the SDK the day that release comes out. So, for something like dot shorthands, which is a new feature or well on its way to coming out where you won't have to put the class name for an enum, let's put the enum name, you can just put dot and then the value for something like cross axis alignment when you're building a column or a row in Flutter.

‍

You won't have to put cross axis alignment:cross axis alignment.start or something like that and you just put .start at the end of that. If your model hasn't been trained on that, it's going to have no idea that you don't have to do that anymore. So, you're going to generate code. You're going to have a whole bunch of analysis errors where it's like, "Hey, you don't have to do this. You can fix it," or we can get ahead of that by giving you a markdown file with every release. It's like here's the three things your agent needs to know in a markdown format. Go paste this into your AI rules and now we've done that work for you and made that experience better. That is an entirely new challenge for us.

‍

We've never been in the position of needing to upskill AI agents before, but if we're really trying to help developers be happy and effective, that stuff is going to start coming into our work more and more. So, that's a challenge to figure out not only how to do that stuff, but what are the things that would actually matter and will actually help?

David DeRemer:

It's fascinating. So. much of the work that you guys have done before and when you think about tools, how would developers learn things and what were the communities where DevRel would maybe play? The YouTube videos you put out, the content, the blog posts, talks you give in an event, questions answered on Stack Overflow, all this stuff has helped to train these AI models, but it's fascinating to think that in the future, developers will be agents and agents supported.

So, even regardless of where this all goes and obviously it's a hot topic, let's assume that a developer for some class of app will just be AI. Now your target audience is no longer just human developers, but agentic developers. So, the content you want to deliver to them has a different format. What's more efficient for them to ingest it effectively?

Andrew Brogdon:

Yeah, I think it'll also be really interesting too when we get to a place like that and suddenly the bar for software experiences just starts going up. There's that interesting question of, okay, software as we know it, we can now automate more of it and make the same quality up to a certain point more chiefly and efficiently. Do we then keep that model for what we expect of software or does that allow us to now have much better software and just the top end of the quality bar goes up? Now Flutter needs to make sure that we're supporting people all the way up there with things like more workflows that are more adaptive to users and things like that, more personalised stuff like that.

You might remember from Flutter Interact, this would be the way back machine, where Grant Skinner had his vignettes and some of the demos that people were doing. These are radically new UIs that at that moment someone would've to sit down and really work on to get them right. Maybe somebody has time to do that, to really get those bits right, because all of the rest of it that's the well understood part has been done with an agent. So, now people come to expect things that are that much more custom and interesting, something that looks like a television programme written just for you or something like that. It'd be interesting to see if we suddenly need to have resources for this is how you make software that just wouldn't have existed three years ago or something like that.

David DeRemer:

There's a word I've been using recently about abundance. These technologies create this opportunity for abundance where you can just do more things and more interesting things. I think I saw you in the audience at FlutterCon when we had the panel with Lawrence and Michael from Universal, and they said three things about their adoption of Flutter that really stood out to me. One was the opportunity to invest more in animations that were these delightful little things that Flutter's efficiency gave them time to invest in those types of user experience enhancements that maybe they wouldn't have otherwise. It doesn't really necessarily have a huge business case on paper, but it improves the user experience, increase the magic and the things they're looking for.

‍

The second thing was the expansion to the kiosk work where it's got an incremental impact on the business, but to maintain a brand new software application and a different thing with another team, the extra cost of creating it and then maintaining it indefinitely, the ongoing cost, maybe it wouldn't have happened, but because of Flutter's efficiencies and the portability of that code, they could add that extra business value. Then the third was they had space now to maybe explore ways to get agentic experiences into their app because Flutter creates this space.

‍

I just heard you also come to then talking about those same ideas that I've been connecting with Flutter, and I think those of us in the Flutter community have been talking about for a long time, to AI, which is like that efficiency, it allows us to do all this extra new stuff that otherwise we wouldn't have time or resources to do. It's super cool.

Andrew Brogdon:

Yeah, I think it's been a constructive way to frame it, and I'm not the only one doing this where I work. A lot of people have anxiety about how AI is going to come in and change things as we go forward and stuff like that. I think a useful way to frame it is could we use this to make it possible for us to do all the things we wish we could have done over the past several years, all those things we wish we had time to get to? How do we automate away the stuff that we're not excited by so we can work on that?

‍

David DeRemer:

So when you think about the future of DevRel, I mean in a way, on one level, there could be this little intermediate gap where all of a sudden, your workload is doubled or increased a little bit at least because you still need to do things for developers. It's not like you can abandon the human developers and not create content for them, but now you have to also create maybe new types of data or MCP servers or different formats or things that allow the agentic developers to get involved. What's the crossover of that look like? Does that go on forever?

‍

Because one of the things people talk about is you even said in your description, we'll probably be sitting on top of this and observing. At some point, I think for some unclear time horizon, I don't know if it's one year or 10 years, we'll still expect a human to be able to get in there and understand the code. So, you still have to educate them. You still have to make the content available to them. How do you plan that out over the next... It seems like no one knows.

Andrew Brogdon:

If I had a roadmap for that, I'd be promoted immediately, but no, I think of Waymo and when do you take the safety driver out of the car? When do you trust what it's doing enough that you don't really need to have a human being getting into it and checking out the underlying code and at what scope can an agent do that? If you have a top app, and again speaking for myself here, you could not turn that over to an agent right now and just be like, "Yeah, well, there's an agent out there that can go code this top 100 app for iOS or Android." But there is a scope where you can do that, analogous to the little geo-fenced area that these cars go in where they're like, "Okay, we're good if we stay in this box and that kind of a thing."

‍

So I think there will always need to be people and these agents working together when you get to a certain point of quality and size. For my remaining career here, I anticipate there will be a need to be human beings that can get into the source and look at it and diagnose it and a large number of those folks. What I'm hoping is that some of the things that we do in order to make agents better will also make people better in the same way, and I'm going to give you some rope here. I'm going to compare this to accessibility. I remember having a conversation with somebody once about the curb cuts that they have at corners now, which didn't really exist when I was a kid 40-something years ago. You'd go to a curb and you go to the corner. It was just a drop-off.

‍

Now most of them in my neighbourhood have the little ramps with the bumps. Those were put in as an accessibility measure to help folks who use a wheelchair to get around. They can get around more easily, but that also helped everybody with a baby in a stroller, which has been me over the last 10 years, everybody that was carrying boxes on a dolly, something like that. It also helped all those people even though that wasn't the official purpose of it. So, what I'm hoping is maybe by needing to take a step back and say, "Okay, now we're serving these two slightly different populations and trying to upskill them both," how are we going to change our resources and in what ways do we help both audiences at once?

‍

So we have been looking at ways to refactor some of our existing resources, and it's forcing us to think about what were the original principles that went into this six years ago. When we made the Flutter Cookbook for example, which is a resource that's been around for a long time, what was it we were trying to do then? Do we still need to do this? In this new world, what is the right way to do it? And if we plan that out and execute it correctly, we're going to help both of these audiences. That is what I'm hoping anyway.

‍

David DeRemer:

How do you show people what's possible when anything's possible? Because the cookbook, I think part of that was to illustrate, hey, you can do these hard things and here's some ideas maybe to get you started and to illustrate some code patterns and things like that. To some extent, I wonder if when you get to a point where I can just sit down and type something, well, how do I know what to look for anymore? I remember not so much anymore, but when I lived in the city and you'd open Grubhub or DoorDash or something like that.

‍

You go to order and you just have this abundance of choice. There's a million restaurants you could order from. There's 37 Indian restaurants you can order from. You're like, "How do I know which one's good?" They're probably all good. Almost sometimes my wife and I would just be like, "Just forget it. We're just going to cook the chicken that's in the fridge." We can't even pick. You know what I mean?

Andrew Brogdon:

Yup.

‍

David DeRemer:

And so it's interesting to think about when you get to this world where everything is possible, how do you then create inspiration for people? How do you give them a vision of what they can do if already they already have the tools at their fingertips and making sure that those of us in a position to create that inspiration, take that job with respect and honesty and the importance that it is? Because if we stop showing people what's possible because we just assume that they can just do it because everything is possible, that could maybe come back around to stifle innovation. So, it's interesting to think about. DevRel is just such an interesting spot in this whole thing because you guys are educating developers. There's this new era of developers coming in. Everything's changing.

‍

When you think about so much of the anxiety and so much of the change, part of it's on the developer workflow. How do we make things? You're doing that, but also around a framework that has become really popular. A lot of people are using it. How is it changing how Flutter is being thought of and how you think about this going forward in a world where maybe developers aren't directly writing the code as much? What is that impact on Flutter's future vision and where do you see Flutter heading, or I guess another way to think about it would be what's something that excites you the most about where this is all going?

Andrew Brogdon:

That's a good question. I mean, there's some big things and there's some little things in there. I remember having a conversation several years ago with the UX lead for Flutter named Tao. He was very, very smart. This is two and a half, three years ago where he was talking about a lot of code is going to start being generated by agents and it's not actually going to be typed into a keyboard. Does that make readability more important than code terseness, like in the way that Dart's going to evolve as a language? Because do you care as much about how many characters are in use if you don't have to physically type them? And it makes it faster and easier for you to read the code and understand it quickly because we're going to be doing less typing and more reviewing and reading.

‍

He was that far ahead because he's a really smart guy, but I think there's going to be a lot of little details like that that will start popping up in some of the planning and already have to a certain extent. So, that opened my eyes at that moment of how things are really going to fundamentally change as we go through the next however many years. One, I think Flutter's core value proposition is still going to matter. I think Flutter's ability to have a consistent experience across platforms from one code base, that's going to matter whether it's an agent that creates it or a human being that creates it, right? You can go right now to one of the code generation sites and there's a lot of great ones. I use Firebase Studio all the time.

‍

There is still a stochastic thing. If you give it a prompt, even creating the same prompt twice with the agentive prototyper, you'll get two slightly different results. So, if you go and ask the same platform, same tool, you'll get two different results. So, if we're looking at a future where people want to be able to have a vision, express that intent to the machine, and then have that come to life across devices, the core value prop of Flutter is still going to play into that because you're going to have inconsistencies. You'll have a bug over here that doesn't exist over here. By the way, the underlying code that you were trying not to pay attention to is different and all that thing. So, I think there are core things that will absolutely stay the same.

‍

Hopefully, what will happen is we'll start seeing Flutter reaching new types of places and things like that. People have talked about how application models themselves might end up changing. You see every day it seems like the folks working on AI, they have a new way to make mini apps and stuff like that. That's a whole new ecosystem potentially. I have no idea how that's going to inform Flutter and vice versa, but that's probably a thing that will happen as we move forward. So, the reach that you can have as an application developer will change. So, that all I think will be really interesting.

David DeRemer:

Yeah, what's fascinating for me personally about AI is how similar to human interactions and thinking, it's very similar. Even when you think about teams of agents doing things, so I mean, I'm biassed, of course, but I totally agree with you that I think it doesn't make sense for AI to write the same app multiple times either for different platforms. To some extent, I think it actually illustrates the value of Flutter in a way that now I think people can understand because we have new ways to think about it. People understand now that if you ask an AI to do something, it's going to do it differently each time, that it's going to have hallucinations. There's all these things I have to check and make sure it's okay.

‍

When you think about it, that's not really any different than if I go to an iOS and an Android team and I say, "Hey, I need a screen that does this thing." If I give them no more information, they're going to go off and they're going to do their thing. They're going to do their product work, they're going to do their designs, they're going to make this app. The thing I'm going to get back, it's not going to be the same thing in both places. So, agents are doing the same exact thing as human teams would do in terms of permutations and variations. So, I tend to agree with you that I think actually AI plus Flutter I think is a massive win. I think at some point, the world will...

‍

I mean I think us in the Flutter community, we have a bit of a head start here, but I think people will understand the value of, okay, there's hallucinations, there are non-deterministic things that are going to happen here, and I need to reduce my surface area and increase my ability to review what this thing has produced. To some extent, I had never thought about that, what you're saying about Dart before. It's interesting to think about the programme languages evolve to become really, really useful for humans to review the output, not to write it in the first place. That's a fascinating thing to think about. That's really what it should be optimised for in the future world. Now that you've said it, it makes obvious sense. AI's going to write it. I need to review it. It should be optimised for me to review it. Cool.

Andrew Brogdon:

Yeah. Building on that, the whole thing about specification driven development, that's starting to become a new buzzword, spec driven software. That's going to be interesting, I think, too because now you have the source code that is being generated by a model for you to review the actual code that's going to become the executable, but you also have an agreed upon format for this spec that defines what the application is supposed to do and the intent behind it and stuff like that. Then you and an agent collaborate on so that another agent can then go and turn that into code and stuff like that. I remember another smart person I used to work with, Adam Barth, one of the original engineers on Flutter, talking about Flutter a long time ago.

‍

It was like, "How quickly can you express your intent to the machine about what you want it to do?" I think now we're going to end up in a world where we have two different ways that we do that. We have a natural language way of doing it, and then we have the code that is the step where you have to say, "Okay, no, but actually I meant this other thing, so let's tweak this over here." You'll have a code representation and a natural language representation and both of those combine to define the behaviour of the application. But there again, being able to review one set of code to go with your spec is better than three sets or six sets, right?

‍

David DeRemer:

Totally agree. I think actually the Flutter mindset in terms of what it's done, it's very aligned. So, anytime I talk to somebody and they're sceptical or worried about AI and where this is going, I think it's helpful sometimes to root in I think AI in terms of tooling that helps an engineer be more productive is actually the same exact thing as Flutter. It's helping us to be more productive and express our vision and our intent way faster and more productive. Whereas before it was like, okay, how do I reach my users? Well, some of them are iOS, some of them on Android. I have to do that. So, the old way was to do things twice, but now if I can consolidate into one place, it's far easier, more efficient for me to get that to the people I need to have it.

‍

But if AI is another toolkit on top of that that makes it even faster and easier for me to express my ideas and get them to my end users, ultimately, it's solving the same benefit that any framework that makes developers more productive is solving. Yeah, it's super interesting. Yeah, lot of interesting. I know you're also interested in agentic apps in general, and so I know just personally you're interested in those things. Let's talk about that. What are agentic apps actually and AI and agentic behaviours in app experiences? Where does that go? What does that look like?

Andrew Brogdon:

Yeah, yeah, sure. It's another thing. I think if you talk to 10 different people, you'll get 10 slightly different definitions or explanations, but I can give you mine. The best definition I've heard is an agent is a reasoning capability, usually an LLM these days combined with tools and a goal. So, you take an LLM like Gemini. You give it tools to access the outside world and have side effects basically and then you give it a goal for a thing you want to accomplish and you package that up and that's an agent. Then an agentic app would be an application that uses an agent like that for some or all of its functionality. I think we're at different stages right now of what people have actually begun putting into production for what those can look like.

‍

I think this is a thing I'm particularly excited about because I think it's going to be fun and I'm a fun driven developer. Right now, a lot of agentic experiences are a wall of text where you're talking almost directly with an LLM and maybe it might have a function call or two for things that it can do, but you're conversing in natural language by typing things into a phone or stuff like that. There's times when you would still need to do things like that and use text to talk with an agent. But I think in the future, we're going to see things where someone has defined an experience in such a way that the AI can express itself and ask questions using more UI than just text and a text view. So, we had a demo that we did a Google Cloud Next this year that was a plant debugger.

‍

That was the internal name for it, where you could describe what was going on with a plant that was troubled. You could take a picture of it and then it would guide you through what looked like a wizard workflow that was being come up with on the fly based on what you were saying and what you were telling it. So, rather than forcing you to just have an ongoing conversation like you were chatting with tech support or something like that, it was displaying buttons. LLM was given the ability to say, "Oh, I need to ask the user to pick one of three things." The application knows how to ask the user to pick one. So, the LLM would tell the app. The app would throw up some widgets that had buttons and off it would go.

‍

I think we're going to have more experiences maybe where an agent is tracking progress on a workflow and deciding what needs to be done and how to work with the user in order to accomplish that goal. You can imagine I was looking at cars today and I went on a car manufacturer website and was just pricing out if I wanted to buy a new sedan. You can imagine something like that where rather than having a strictly defined workflow, it would guide you through something where it knows what questions to ask at the right times and stuff like that and can on the fly present UI, because the LLM has a chain of thought going.

‍

It knows how to ask the user things because it's been given tools to do so. It knows how to define success and whether it's close or far away. I think you'll have more things like that in the future where the state of the app is both some local state and also the state of what an agent either running on device or in the cloud has stored within its current chain of thought.

‍

David DeRemer:

Interesting. So, app state-

Andrew Brogdon:

Hopefully, that was an answer to your question. That was a bit of a ramble. I don't know.

‍

David DeRemer:

No, I like it. It's interesting to think about app state as context to the user experience that you're creating. There's a bunch of things that I've done and things I've done in the past and maybe something where I'm at right now and feeding all of that to something that can actually influence the user experience as you're using it is pretty exciting. I was at a tech event recently and a prominent member of the community named Larry, he had this interesting insight around as engineers, what do we want to do? We want to give every user the optimal experience, and we have all these tools that have been invented and even like A/B testing tools and things we can do.

‍

We're trying to figure out what's the best experience, but all of those tools, because the way we write software is deterministic and we write things and if-else statements and we got to ship it. Generally speaking, you're optimising for what is interesting to the most people. So, I'm going to test this colour button or that colour button and I'm going to pick the one that the most people like. But what that means is by definition, generally speaking, there's still people that like the other colour, but we just opted to go with the one that the most people liked.

‍

Imagine, you get to a point where these on-device agentic UI stuff can really be hitting every single person with exactly what they want from a personalization perspective and giving developers the ability to actually create experiences that really are one to infinity. I'll put this thing out there with intent and some tools that will help to meet your exact needs. I think that's super inspiring and cool.

Andrew Brogdon:

And if you'll pardon me, a callback, it's that idea again of does the quality bar go up? It used to be that we could just go for some local maximum in terms of pleasing the most of our users as we could. Can we get to the point where everybody has that same experience as you're describing? And then some of the new problems that are cropping up, can you measure? How do you measure whether it's better or not effectively? Because there's a lot of pressure right now to just slap AI onto whatever you're doing, but that's going to fade away over time and it'll be like, "Okay, is this measurably better for our users and therefore for us? Are they able to do what they want to do more efficiently?"

‍

So they're happier. Our business is stronger as a result and stuff like that. Or did we just put AI on it for the sake of putting AI on it? And where are the guardrails, right? If I'm putting an LLM in charge of an experience, I'll be honest, I have a bunch of apps, these chatbots keep popping up in them. The first thing I do is how can I break this? What can I do to get out just to see if I can do it? That's important. How do you secure it? How do you keep it not only in terms of typical information security, but also in terms of your brand security? How do you make sure that you don't end up on Hacker News for your agent driven experience just did something horrible? Those are still problems being worked on right now that I think are really interesting.

‍

David DeRemer:

Well, and this is where we have this dichotomy of things are moving so fast, but there's so much change because I totally agree with you. All the tools we have for testing, analytics, like A/B testing, app performance, all of these things are based on a deterministic paradigm. So, when you think about, okay, I'm going to build this app and I'm going to set up my analytics events and I'm going to track shopping cart conversion flow, right? That's just based on a sequence of events triggering. But if all of a sudden, I'm handing off large parts of my experience to this agent that is non-deterministic, no longer can I rely on these deterministic based tools to evaluate whether the thing was successful.

‍

It's almost like I'd have to hand this thing out to the world and then at the end of the user state, almost ask another LLM, "Here were your business goals and customer experience goals. Based on the state you've observed, was the goal achieved?" Because otherwise, I don't know how you could have a more legit logic-based tool have those outcomes. So, it's fascinating because all parts of the stack, everything about DevOps and testing and customer engagement and analytics, all that stuff has to be updated for things that are non-deterministic now. It's pretty fascinating.

Andrew Brogdon:

It can be unsettling, but it's also exciting, right?

‍

David DeRemer:

100%. So, I want to ask one more question just about general, your experience. One of the things here on what we try to do here is us understand a little bit what helps teams to be successful. I wanted to take some of your experience coming up through all the way from being a poet, which we learned about today, all the way through to being DevRel, getting into management positions, observing the Flutter team grow and the leadership changes and things and then where we go forward. As you think about going forward, what are some leadership principles that you've observed or that you believe in that help teams be successful with technology?

Andrew Brogdon:

Oh, wow. I think empathy is never going to not be important. That is something that I could definitely say. There are lots of parts of being a manager I'm not that great at. I am a creative scatterbrain. I think the team that I lead sometimes reflects that in certain ways, but really knowing the folks on your team and in your community and genuinely caring about knowing them goes a long way to you making smart decisions.

‍

I remember chatting with somebody once and about how one of the things that I've learned now that I've been in various ways in and out of software engineering that I would go back and tell myself when I was 18 if I could is that your ability to work with, inspire, and listen to people will be more impactful on your career trajectory than the technical skills that you're so carefully trying to develop right now. That is something that I definitely had to learn. That's not to say you could be a slouch on the tech. You have to understand the ground truth of the industry that you're in.

‍

But if you know the folks that you work with and especially your reports well enough to know where they're trying to go with their lives and the things the way they tend to conceptualise and think about their own work, you're going to be in a better position to help them by lining them up with the right opportunities. You'll be able to anticipate what they might need from you a lot better than if you just don't take the time to do that. So, I think of the managers that I've had, the best ones, they've always had a really good beat on that.

‍

That's definitely something that not only has helped me in my career because they're giving me a good advice, but it made it very easy to trust that they understand me and that they're looking out for me. So, if that's an answer to your question, that's probably the first thing that springs to mind.

‍

David DeRemer:

Yeah, I love it. I think that's great. Empathy is increasingly hard to find in the world too, unfortunately. I think you're right. I think we might need it more than ever with the machines taking over because at least us humans, we got to get along and got to help each other out along the way. So, I think that's well said. I think that's maybe a good place to stop. So, thanks, Andrew. That was awesome, so many tremendous insights.

‍

I think the DevRel side of this change of AI is something you don't hear about as much because everyone's focused on the models and the pace of change of the developer experience, but I think you guys are right in the wheelhouse of the relationship between the people making things with this technology and the technology itself. So, I really appreciate your insights today and the time spent.

Andrew Brogdon:

Hey, thank you for having me on. I really appreciate it. It's great to talk to your audience as well, and it's always nice to chat with you.

‍

David DeRemer:

Likewise. Thank you for joining us on Build to Succeed, a Very Good Ventures podcast. We hope you enjoy exploring the experiences and insights of leaders that have built successful digital products. Please take a moment to leave us a review, and don't forget to subscribe to get our latest episodes. Thanks again, and see you next time.

‍