Sean Tibor on how Mondelēz and AWS Are Using AI Agents to Transform Software Engineering

Hey folks, thanks for the drone. We're here today with Sean Tyer, who's director of Global Cloud Engineering for Mondelez International, and we're talking about how they are making use of AI and their software engineering workflows. Sean, welcome to the show.

Thanks, Mike. It's great to be here with you today. I'm looking forward to talking about all the fun things we're doing at Mondelez.

So I'm not sure everybody knows who you guys are, and yet you are a household name. It's just that nobody knows it under the name of Mondelez, but explain to us a little bit the background of the company and what you guys are all about. Sure.

So we're actually a very old company in many ways under a very new name. Uh, we've been known as Mondelez for about the last 12 years, and all you have to do is walk down the snack food aisle at your local grocery store and you'll encounter many of the brands that you know and love. We make Oreo, we make Chip soho, all of the Nabisco brand treats everything from Lorna Dunes and Animal Crackers, and we also have a, a widespread chocolate business in other parts of the world, um, operating as, uh, Cadbury in the rest of the world and Milk a Chocolates.

Um, so pretty much, uh, a wide range of snacks and we've even gotten into some active healthy brands like, uh, cliff Bar over the last few years as well as part of our acquisition strategy. Alright. Every one of those brands is in my house, by the way.

I know exactly where they're Well, we thank you for your business. You are also working closely with AWS around AI agents and Amazon Q developer, and a lot of folks are trying to figure out, well, where does this AI agent fit within my DevOps and software engineering workflows? So what is have you seen or experienced so far?

How did you guys get started and and how far along are you on the journey? Yeah, it's a, it's a great journey that we've been on with AWS. We actually have been partnered with AWS for a little over three years now as part of our strategic cloud transformation.

Um, I think it's a lot of people are surprised to realize that the company makes, that, makes Oreos does a lot of software engineering and cloud engineering, but I really don't think you can run a, a global business like we do without having a pretty large IT footprint and be looking for opportunities to be innovative. And AI is a part of that strategy. Um, like many other companies our size and larger and smaller, um, the ai, uh, transformation that's been occurring over the last three years has been pretty exciting in terms of the, the possibilities and a little bit scary in some of the other possibilities.

So as we were looking to move forward in AI and make our our progress, we, um, were very interested in a WSQ developer, and I think when we started with it, it was branded as Code Whisperer. Um, but one of the things we really liked about it was that it gave us the ability to control a lot more of our AI usage, especially with our developer teams and control the, the data that we have within our space, especially the source code and the configuration that we possess on the cloud engineering team could be considered sensitive information. So we started about a year and a half ago bringing that, um, Amazon queue developer capability to our software engineers, and since then, gone pretty far with it all the way to the point of developing some of our own, um, MCP interfaces for, um, for interacting with Amazon Queue developer and some of our internal systems.

And some of my developers right now are working on some Amazon bedrock implementations, um, to tie into some of our other systems and build some, um, some chat models that they can use across the rest of the organization. So in, in terms of our journey, we started off small and and experimental and have looked to grow it over the course of the last 18 months or so into something that we can now turn around and offer to the rest of the company in a smart, secure and powerful sort of way. Everybody's talking about what are the implications for the future of application developers.

And, um, on the one hand, some people will say it's just gonna make the developers more efficient and they'll still be with us, but they'll be in a different kind of role, more of an architect, and more, and much more of the code might be written by a machine and others are saying, you know, eventually the machine does everything, but where are you on that spectrum? I think I'm probably leaning more towards the, we're always going to need people who are really good problem solvers and are able to define problems in a way that they can be solved effectively and securely and efficiently. Um, the actual work of a software developer or a cloud engineer on my team has already begun to change, where we're relying on AI agents and assistants to do more of the work with us and for us.

And I think for me, in many ways, I'm seeing my team use these tools to help automate kind of the boring, tedious work, right? Reapply the things that we've already learned. It's hard to predict.

I don't think anyone can, where this is going to go in the future, but I'm leaning more towards the, uh, uh, side of I'm always going to need engineers. I'm always gonna need people who know how to solve problems, how to define them well, and regardless of the tools that they're employing and I'm providing them with, I'm gonna still need those kinds of individuals in my organization. Are you or have you seen your organization actually not just writing more code, but building more applications and deploying more applications because of AI and maybe doing that in a way that doesn't require a huge army of people?

I think where it's probably the most apparent to me because our, our organization has been through a period of growth over the last three years where we've scaled up from a handful of senior engineers to now more than 30 engineers around the world. It's kind of hard to separate how much of our productivity is coming from the growth of our organization versus the growth of ai. What I can tell you with, you know, a hundred percent confidence is that onboarding that many engineers in that short of a time and having them come up to speed as quickly as they are wouldn't be possible without an AI assistant like Amazon queue because it, in addition to writing code, we're seeing our engineers use this as almost like a a an assistant or a tutor that can answer questions for them.

So whereas five years ago they might've gone to Stack Overflow, now they're popping over to the side window of their IDE and asking, uh, q questions about how do I do this thing or explain this AWS service to me. And that level of interaction, that kind of fast loop that we've created of, I need to figure out how to do something and I have the answer for how to do it, is shortening and that is improving their ability to onboard into our code base and to be effective faster. So I'm seeing, uh, engineers become productive, contributing members of our team within a matter of days or weeks rather than months, uh, uh, as it was before.

Do you think the overall level of burnout will be reduced as well? Because one of the dirty little secrets of software engineering is there's still a lot of tedious stuff that people do, and over time it just kinda, they, they get tired of it and they want to do something else. I don't know that it's going to be alleviated tremendously.

I think burnout still requires the recognition that these are human beings, right? That, that are, they're not, they're not components in a, in a big machine. They have limits and they have things going on outside of work.

And I think you still need to build that sense of culture, um, and community and support for one another that helps prevent that burnout. Um, it may like the ability to hand off some of the tedious, boring work to an AI agent may help, um, relieve some of that pressure, but I think the real solution is, is better management and better support for one another in the workplace. Yeah.

Otherwise known as empathy, right? Um, Yep. As you kinda look at this, we're all obsessed with the technology, but I happen to wonder these days, maybe the bigger issue as we go along here isn't gonna be the technology, but it's the cultural issues and the change management issues.

And so how did you approach that? Yeah, It's, it's a really good question. I mean, in a prior life before I was an engineer, um, at Mondelez, I was actually teaching middle school computer science and robotics, and we talked a lot about the ethics of software development, the ethics of AI and machine learning.

And I, I think one of the things that I took away from that, um, being a teacher and expecting and, and having accountability for my students was that the work that they turned in was their own, they were accountable for it, right? And I think one of the things that is especially important in an AI driven engineering organization, uh, or AI assisted engineering organization more accurately is that there's still that same level or even a higher level of accountability for the code that you generate and, and contribute, right? So when, when we think about you, you know, this, this culture and we think about what we're creating, I have the same or higher level expectation of my engineers that the work that they're doing is secure, it's safe, it's efficient that what we're generating actually does what it intends to do because we're running an enterprise grade IT organization, right?

It can't be any less than that. So things like change management become especially important as you mentioned, because we have to make sure that we don't generate thousands of lines of code that actually take us backwards instead of forwards. There are a lot of AI coding tools out there, but how did you wind up with Amazon Queue developer and or prior to that code whisper?

What was that decision like? So it was, it was interesting. We looked at a handful of tools and I think about 18 months ago and when, when we were looking at this, it really came down to co-pilot built into, you know, GitHub and Microsoft suite of tools, especially with VS code.

Um, we tend to be a very heavy vs code sort of shop where that's our primary ID for most of our engineers. Um, we looked at Q developer and it wasn't one that was particularly, you know, it didn't show up on a lot of people's hype lists of like, these are the best, you know, uh, coding agents. What attracted us to it was the fact that we have an AI review board that we go through at Mondelez to ensure that every bit of AI technology we bring in is compliant with our policies.

It protects our data, it's, it's handling all of the things in a secure, uh, way so that we're not exposing data, especially in those early days of ai. When I looked at, at Q1 of the things that was appealing was the fact that it was another AWS service. Everything lived within my account.

I could provide my own customer managed key to encrypt all the data. So when I went through that process of the review board and looked at all of the different criteria that they had for accepting AI into our organization, Q checked all of the boxes and the conversation was, yeah, that makes sense. I, I see how that works and it, it meets our needs.

Let's move on to the next question. And that to me was appealing because it meant that I could be compliant and I could get it implemented quickly, which meant that my developers could get their hands on it faster. So what do you know now that you kind of wish you knew 18 months ago when you started this whole adventure?

I would say the, the biggest thing is to move as fast as the technology is. Like, there has been a number of times in this process over the last 18 months where I realized I was three to six months behind what the latest capabilities were. And, you know, turning that on and enabling it caused the organization to jump forward even faster, right?

So MCP built into the, um, the command line, right, where you can talk to our Terraform module repository and get the exact template for generating some code is amazing. Now, uh, we're looking to add some features with our observability platforms where you can ask questions about the infrastructure and see if it's performing, if there's a health outage, all those things. So it means that, again, sort of that same, you know, idea that I had before about the developer going to stack overflow a few years ago and now they're going to their, um, to their AI assistant.

If they want to find out if their service is up and running, they can ask their Q agent, you know, or their CLI, Hey, is this service up and running? Instead of having to jump to a different system and log into, you know, another portal to see if the, the metrics are there. So that part of being up to speed with everything that's happening and being current and staying with or, or as much as possible ahead of the curve is something I wish I had done a little bit more of early on so that we could continue to evolve this faster.

The other thing I'm finding that I wish I had done was do more training and more knowledge sharing with the team because we're all finding and discovering new capabilities of the, of the AI platforms that we're using in the AI tools, and that knowledge isn't evenly distributed. Some people know really well how to use an MCP server or how to build one other ones didn't even know that that was a, a possibility that you could work with. So that knowledge sharing and and poll cross pollination, I think would've been really helpful to do maybe six months ago, and we would've been farther ahead than we are now.

One of the issues that keeps coming up is there's concern that, um, a lot of the entry level tasks will soon be automated by AI and we won't have the next generation of developers 'cause the old guard is now using AI instead of assigning that out to the younger developers per se. Although, but you know, conversely, you hear arguments that says, you know, younger developers now can do a lot more because they're using AI agents and it maybe benefits them more, but how do you see this kind of playing out? Or are we, are we gonna have a, a generation of developers that are kinda lost?

I don't know about lost. I think each generation is going to use the tools that are there when they came aboard, right? Like when I was learning how to code back in the late nineties and early two thousands, it was even before Google, right?

So my, I still prefer learning how to, how to code a new language or a new technology from a hardcover book laid out on the desk next to me with a cup of coffee, right? But I, I, I think what's going to, what we're going to see over time is that our, our newer generation of developers is going to become extremely proficient using AI as part of their workflows, and they're going to be the ones that are the most likely to come up with innovative and creative solutions, just like each generation of developers has done before them. What I do worry about is there's no shortcut for that struggle of acquiring new information, right?

That struggle is real. That's when you really get into, I know some things because I've got the scars to prove it, right? Every engineer or developer that has that tale of the time that I brought down production or the time that I, I dropped the database table, right?

I think the opportunities for those are still there with ai, right? There's still the, the opportunities for painful learning by our new generation of engineers. What I worry about is that sometimes they can make such quantum leaps with what they can do with AI agents and a AI coding that they skip over a lot of that valuable learning in the middle.

Like sometimes they miss the opportunities to have those painful but important lessons in becoming a fully fledged grownup software engineer. There's many leaders of software engineering teams such as yourself that are kind of trying to find their way through this transition. So what's your best advice to them?

'cause they're trying to figure out how to pull all these teams together and insert maybe AI agents and sometimes they augment teams and sometimes they're gonna be members of the teams. And how do you kind of manage all that? I mean, for me, and, and the only experience I have is my own, for me it was getting involved in getting my hands dirty, right?

Get in there and be the one to set it up. Learn everything you can about it so that you know where the edges are, right? Where the rough parts are, what doesn't work.

It doesn't mean that you have to be the, you know, the Spock supporting it forever, but be the person who really knows it well and start small with your implementation. Start your ambition small, start your, your deployment small. Get with a group of people that you can, you can talk through all the, the experiences together with and learn it together.

And then as you learn that, start scaling it up and scale fast. Because as I, as I mentioned before, the one thing I wish I had done was scale faster and share that knowledge earlier so that more people had the ability to use it and, and learn from it. All right, folks.

Hey, you're heard it here. There's no substitute from for leaning from the front, right? Yep.

Get right in there. I mean, you've got a keyboard and a mouse. Go use 'em.

Alright, there you go. Sean, thanks for being on the show, Mike, it's been a pleasure. Thank you very much.

All Right. And back to you guys in the studio.