Exploring the Future of Open Source and AI in Software Development with David Nalley & Antje Barth | Open Source Summit NA 2025

Hey everybody. We're back at the Open Source Software summit in Denver, and we're talking with two folks from Amazon Web Services. We have Dave Nally, who's the head of developer advocacy for AWS, and Anja Bart, who's the lead developer advocate for AWS.

And we're having a little chat about what's going on at the show, and there's been some big news around the Linux Foundation has now set up a project around the agent to agent protocol, and that seems to be complimentary to MCP and AWS is kind of in the lead in both of these. But Dave, start us out here. What's going on here and, and why are you guys involved in this project?

You Know, so first of all, I, I think it's really interesting that we're in this period of, uh, agen ai. Uh, SRA was telling me earlier that she read someone who had said that we're now in the decade of agen ai. And, and so as we think about agents starting to work, uh, they need ways to connect, hopefully programmatic, uh, protocols to use to connect to both tools and to connect to other agents, uh, so that they can share work and they can pass work off, uh, one another.

So we look at, uh, we look at things like the A two A announcement today, and we think that that's actually showing us a maturation, uh, both around the protocol itself, but also that the industry at large is, uh, recognizing a need to have, uh, to have a standardized protocol for communication. So I think this is a, a necessary step in one of those foundational pieces of technology that helps us drive innovation faster. Uh, we're, we, were super excited to see the announcement and we, we of course participated and we've got folks, uh, we've got employees who are set up to contribute to the project.

We have a member of the steering committee, uh, employed at AWS as well. Uh, but we see a two A as one of the, one of the future standards that's going to come to play as agents have to talk, uh, between other agents. You might have some insights into this, but there's a little confusion about what to use A two A for and what to use MCP for.

And so in your mind, how should developers be perceiving these things? Right? And as developers, you're gonna start out building an agent, right?

So you're gonna start, and then the first thing you do usually is like connecting the agent to, let's say, a tool. And this is like at the core where MCP started, right? Like connecting the models with tools that could be like either data sources in your company that could be specific APIs or systems to call actions to take.

So this is where MCP started out. And then once you're building another agent and you want the agents to kind of, you know, act in a multi-agent system, then there's the need to have those, those communicate. And this is where a two A comes into place.

We do see potential in both protocols to solve a lot of those tasks. And this is, I think, exciting to see where the community will get involved and where those protocols will evolve as well. And we're excited to be part of the community as well and help drive.

I feel like when I put those two things together, I'm kind of looking at, uh, pieces of a, of a larger orchestration framework for agents and how I interact with tools. So as, as this whole area evolves, how should developers be thinking about all of this? And how do I orchestrate not just the tools that I need to invoke for one agent, but also how agents talk to each other to automate a task on an end to end basis, if that makes sense?

Yeah, I, so I, I think back to the Unix philosophy of having one tool, small tool that does one job really, really well. And that resonates a lot with me, mainly because I'm old and I, I remember doing lots of things with unes, uh, but I, I think today, uh, you know, we've got MCP, which is a really simple way to connect tools, uh, to agents. And then we've got a two a when you need to do things like discovery of what capabilities an agent might have so that you can figure out where to pass, what kind of work off to, uh, and I think, you know, some of that's forward looking, but, uh, you know, they're still very, uh, very separate workloads at the moment.

I also think back to the early days of the web, right? So to actually load a webpage on your local web browser, you need more than HTTP, right? The hypertext transport protocol does allow you to ship bits and, and render, uh, render a page, uh, onto a browser.

But you also need HTML as a standard, as the markup language. HTTP is your transport protocol. You need DNS in there, uh, to, to get you through the point.

So I, I think we're probably going to see multiple tools. I don't, my personal belief is I'm not sure that there's going to be one tool to rule them all for all of these agent interconnections, uh, both agent to agent and agent to tool at at least I don't see that on the horizon today. How will in nature of the job of a developer change in this era?

Because I wonder, you know, we've been building artifacts forever, are agents the new artifact and they talk to the lower level artifacts and it's another level of abstraction. How should I think about this as a developer, Right? I think like, to, to add what David said, we've been working in, in the technology space and we're building microservices, we're building web services, right?

For, for the past decade. And this is kind of moving those services into agent services. And not all of that is brand new, right?

Like, especially around how do we deploy those in a serverless fashion, how to deploy those, you know, in a secure API endpoint fashion. So I think there's a lot of things we can learn from the work we've done and then also learn the new skills. So as a developer starting in the field, definitely it's, it's important to kind of understand how agent systems work and then also apply the knowledge you might already have from things you've been building before, right?

So I think it all will come and converge together in a way. At AWS we released, for example, um, the strands agents, SDKA few weeks ago, which is an open source SDK to build agents really, really easy. And we're doing that very, looking at the models that have come so capable, the reasoning capabilities that can perform a lot of things.

So as you're starting building a agent systems, look at those tools available and then combine them with the knowledge you have to help move from, you know, building your applications from the traditional microservices way into kind of the agentic way. Mm-hmm. Can I argue with you for a minute?

Mm-hmm. Sure. Why not?

So, I, I, I'm old, uh, and I remember lots of conversations talking about how software development was gonna change, uh, four Gls baby. Yeah, I, I, I mean, I'm not quite old enough to remember punch cards, but I, I remember mainframes and I remember people writing an assembly and, uh, we don't do that anymore. And that most of us don't do that anymore, I should say.

There, there are still people doing that. We've had tools that have sped us up, and one of those was, we actually got programming languages that abstracted away, uh, then we got higher level programming languages like Java that would automate garbage collection for us. Uh, and so we, we stopped having to do one class of work, which was memory management effectively.

Uh, then we got, uh, we got runtime and object oriented languages that again, sped us up. Uh, I see, I see all of this changing the developer's lifecycle in that it's going to speed them up, and it's probably going to abstract away a lot of the work that they're doing. But I don't think developers are going away.

Uh, I, I, I think that they are going to end up working much faster than they could when they were writing assembly. But, uh, at the end of the day, this is just another abstraction layer. Some folks would say that we're gonna spend a lot less time writing code and more time reading code that might be created by a machine, and that will change the nature of the developer's job.

And some folks are, um, they, they have a, they're a little anxious about that, and other folks are like, great, 'cause I hated writing code in the first place. But, so, you know, as, as my day-to-day experience as a developer, how will that change, do you think? I think developers will still write code because this is what excites us, right?

We wanna build things, we wanna break things, we wanna test out things. So I think that part will still be there. But I do think that AI in general and energetic AI will help us be more, you know, kind of, for some people they don't wanna write documentation, others might, might be excited about it, right?

So I think each of us will find ways where they can use AI to just, you know, tap into the parts they enjoy doing and automate the parts they don't necessarily enjoy doing. So I think it's more of an augmentation, but it's new skills I think that every one of us has to learn, like how to work with those tools efficiently and then effectively as well. And then I think it's really becoming this kind of a team effort, right?

Like you have your AI that helps you do things also like maybe researching things, right? You, you send the AI agent out, maybe you wanna explore a new language to learn, and you're using the AI as kind of, you know, kind of a peer to help you learn the coding, learn the new language. So it's, it's tapping into, yes, automating some parts, which I might not wanna do every day, but also helping me to learn and be much faster in, in learning new things as well.

I remember a quote, I forgot the woman's name, but they interviewed her and she said, I don't want AI that creates art. I want AI that cleans the kitchen so I can create art. And to your point, will each person kind of approach this somewhat differently?

'cause there are things that I don't like doing and others do like doing, and each person and each developer will find the right mix for themselves as to what they wanna do and not do. I, I certainly think that is, uh, the way this is going to at least initially shake out. Uh, I think, I think there are still folks who, for instance, enjoy writing C code.

A number of those might happen to be at this conference, and that's still a valuable skill. Uh, there are other folks who can't imagine managing memory for themselves and don't want the fact that it's so error prone to, to enter in. And so I, I fully expect that we will see a lot of folks gravitate towards the things that they enjoy doing and accelerate the things that they don't, or automate away the things that they don't.

I, the, the core tenant of most developers is that they're lazy. And, and I don't say that pejoratively like, I am lazy. I want things to just work as efficiently as possible.

And so we tend to, we tend to automate away the boring things, and I think people are absolutely going to use AI to automate away the things that bore them. I have talked to a number of younger developers and older developers, and it's funny to listen to them because the younger developers will say, this is great. I don't have to become an expert in that, and I can get this done and I'll do it myself, and this'll be awesome.

And the OLA developer saying, this will be awesome. I don't need all these young kids to assign 'em stupid little things to do, and I'll just do it myself. Are they both right?

I think it's playing into the same thing, right? I think on one hand, AI enables also so many more people to build that might not necessarily have that software engineering background, right? And, and put ideas into life, and like startups being much more like quickly in developing prototypes and experimenting with things.

So I do think there, there is space of, for both, right? Like the younger generations might explore things faster and, and, and might like to the point, like they will do what excites them. And similarly, you know, for people that have been coding and they have been in the industry for some, some time they find different spaces and maybe they, they wanna tap into a different area, they wanna automate some things.

But I think it all converges to, to what David said, right? Like, they will find the space where they see the value of ai. And I, I'm convinced, um, this will shake out.

Yeah, To her point, we've been talking about the rise of citizen developers for a long time now, and, um, you know, the criticism has been, well, you know, on the one hand it's great, they can build software and they don't need all that interaction with a professional developer. On the other hand, it says, you know, the UI experience is usually limited. It won't scale, and it's perfectly insecure.

But other than that, it's great. Um, what will be the dividing line between citizen developers and professional developers in the age of ai? And how do you think that that will all come together?

Well, I, I do think that there remains no shortcut for experience, and that there are a lot of lessons learned that, uh, that we will have to, um, continue to learn by actually running things in operating pace. I, I don't think that's going away. Uh, I, I do think though that this is, again, another one of those abstraction layers.

And you know, we, we've had this before. There are a number of folks who never learned, uh, assembly, they never learned c maybe they started out with their first language being PHP or Visual Basic. They still delivered value.

And I think at the end of the day, we, we tend to gatekeep quite a bit and say, you know, if you're a visual basic developer, you're not a real developer. A real developer uses bi or maybe they use emax and they, they write and see. And if, if you're not one of those, then you're not a real developer.

Uh, so, you know, in many ways this is not new. Uh, there are things, there are definitely going to be challenges with scaling. There's definitely gonna be challenges with resilience, and there is no shortcut for being able to learn those regardless of the language or the tools or the AI that you're using.

Um, and, and so I don't, I don't think that AI is necessarily going to solve all of those problems, but it will make you faster at learning them. This is a theoretical conversation, but there are some folks who say, well, we invented Java and all these other languages to provide a way for humans to talk to machines. But if AI is gonna develop software in the future, won't want a programming language that is tuned more for AI and not for humans, and then all we need to do is just find a way to explain what the machine did to humans, rather than using something like Java, which was built for another construct in another era.

Is that a possibility? It's hard to look into the future. Of course, right now it will happen.

I think at this point in time where we are, we're, we're taking a step, like we're optimizing a lot for, for the user right now, like being able to use natural language to work with systems. I think it's hard to tell on the systems part. I, I do think there is still some formal logic needed also.

Like, you know, we will have human in the loop. We will have people reviewing code still. So I do think there is still this value in, in learning programmatic languages and then developing ways to, you know, have humans verify and have a human in the loop for specific things.

So I dunno, I I actually think, do you, I I actually think it's changed the, uh, the constraint a little bit. Uh, I think you were talking earlier about, uh, being able to recode being a very valuable, uh, talent. And I think that that's probably true.

I think the constraint has moved a little bit from, uh, how fast can we, can we produce code to how fast can we review code? And certainly in the open source ecosystem, and we've got, we've got maintainers who are drowning in their responsibilities to review the code that's coming in. And, uh, in many ways I think that's, that's the struggle and the problem that we've gotta solve next is how do we get people competent to review the code that's being produced and able to, to sign off on it and, and keep up with the flood of code that's being created so quickly, Which hopefully another AI agent will have revered before I reviewed it.

So then that way Least maybe, so, yes. Okay. Yeah.

So they say, and we will build more software in the next two to five years than we have built in the past decade by several orders of magnitude. Is that what's gonna happen? I mean, is the volume of software that we're about to create gonna be that exponentially greater?

Or, you know, are there still fundamental constraints that have to be worked through? Because, you know, there's more to building software than just writing code, Right? I do think we will see an explosion in this first step of like, people trying out ideas, building prototypes, experimenting really fast.

But as we move those projects that are successful into the production stage, I do think this will still shake out most likely, like we see today, right? Like, we need to productionize software. But I do think there will be a larger amount of like, just experimentation, which is exciting, which potentially plays out, you know, like we have some really great projects then that I'm moving into, you know, this world being like maybe complete new ways of doing things, right?

We see a gen AI being applied to, to new ways, like doing research for us and, and kind of coming up with new ways of doing things versus, you know, type of like the first wave where it's kind of automating internal business processes, et cetera. So I do think there's a fair mix of that, but I do think there is gonna be an explosion and really kind of the diversity of ideas to try out where we see this code grow. So you have become the spokesman for the older generation by self-appointed.

Um, what is your best advice to those developers who have been at this for a while and they have certain biases about how they build code and a certain amount of pride for that matter, and as, as they approach the AI era, what should they be thinking about? Well, I, I think number one, I would say be experimenting. There's a lot of cool tech out there right now.

Uh, you know, if I were, if I were going to be prescriptive about it, I'd say you need to be thinking not just about AI and generative ai, but right now you should go look at agents. You should try and build an agent. Uh, I personally, I know I'm biased.

com, uh, to, to go build your first agent. And, uh, I think that's a simple, really, uh, low effort way to build something that will work. And so build an agent, go use MCP to connect that to some data sources.

Uh, and there's, there's scores or hundreds of MCP servers to connect to virtually any tool you can imagine. So figure out how to, how to use your agents to get access to tools, uh, and to data sources. And then start looking at A two A and connect your first agent to a second agent and figure out how they communicate and how they discover about each other.

Uh, I don't think that people are well served by ignoring, uh, all of this change that's going on around. I think the change is coming and, and it's moving really fast. There's some really fun technology to play with, and I say start playing with it.

You know, you may not, you may not, uh, you may not find everything works for your particular personal style, but I bet you'll find something that actually makes, uh, your life a little bit better along the way. Same question, but you get to represent the younger generation. What's your best advice to them in terms of how they approach this whole thing?

Listen to the experienced developers too, right? No, I think it's really about also learning from each other, right? I do think people that are excited about this space, not just generational, but like people that might just be more hesitant and not necessarily immediately seeing value for themselves.

Let's have a conversation, right? Let's all come together in the community. Let's share what we're building, what we're working on, and keep the dialogue.

I think this is important to just, you know, show the rest that might still be looking at where to start. Show them ways, invite them in, and let's build together and learn together. All right, folks, you heard in here.

Hey, at the end of the day, building software, it's about solving problems. So go find an interesting problem and solve it. Thanks guys for being on the show.

Thanks for having us. Thanks so much for aga. All right, we'll be back in a minute.