CloudBees VP Loreli Cadapan on How Anthropic’s MCP Will Reinvent DevOps Workflows

Hey guys, thanks for the throw. We're here when Lorela Kaan, who's vice president of Product for CloudBees, and we're talking about model context protocol, MCP, otherwise known as also MCP servers, and CloudBees has one, and they've also made it available on the AWS marketplace. Laura Line, welcome to the show.

Thank you, Mike. Everybody's talking about MCP. I think you cannot walk down the street these days without somebody talking about how they just added an MCP server to their thing.

But from the perspective of DevOps and the perspective of software engineering in general, what does all this mean? Put some context around it. What, what are we gonna be able to do today that we couldn't do yesterday?

Yeah, absolutely, Mike. Um, so the, the MCB server that we built today, really, um, it's, it's a glue for, um, you know, model, um, sorry for LLMs, um, foundation models, um, to the actual unify, um, solution that we, uh, have built today. It's, um, essentially a DevSecOps, uh, solution.

Um, and it really, um, it's more of a really a control plane for your DevOps, um, infrastructure as well as your CICD tooling, your testing, um, providing you analytics and, and so forth. And, um, it essentially the, we understand, you know, we are trying to, um, be aware our customers are at, um, we know, especially on the enterprise side, um, enterprise, um, have very complex needs when it comes to software development, um, delivery, um, whether they are using different tools such as, you know, CI engines such as, uh, GitHub actions or, um, GitLab, um, harness or Jenkins, right? Um, and also needing to be able to have, um, more flexibility around having analytics and being able to have, um, a more holistic view in their software delivery.

Um, and providing, um, us providing insights to our customers on, um, where they're at, providing them, um, you know, uh, real time, uh, data around their pipelines, real time data around their security vulnerabilities and, um, their testing, uh, results and so forth. So the MCP, um, reduces, reduces that, uh, context, um, contact switching for developers, for practitioners, um, being able to allow them to stay at the tool that they, um, desire, whether that's, um, their IDE, their CLI or, um, AI command, command lines or such as Amazon Queue, um, and be able to connect to, um, our solution. So I think with the MCP server, it's really providing that simplicity for our, uh, customers to be able to be much more productive.

Um, and, but at the same time, being able to have that governance and security that they know is very important as well. Mm-hmm. As I understand it, it's essentially bi-directional in this regard.

I'll be able to query data that sits in the CloudBees platform using MCP protocol, but I'll also, from your platform, be able to access and pull in data as well. Uh, is that kind of how you see this evolving? Yes, absolutely.

Um, and, you know, being able to pull in data, whether that's insights, um, whether that's, you know, um, you know, very, very basic use cases such as, you know, what's going on with my bills? Are they failing? Are my tests failing?

What tests should I be running? Um, what security vulnerabilities are impacting my applications today? Um, and then also be able to orchestrate, right?

Um, be able to orchestrate your, um, entire software delivery end to end from building to testing, to actually delivery and deployment of your application, to whatever environment you're, um, looking into, whether that's, you know, your staging, your production and, and so forth. So it's not just necessarily insights, it's also the ability to orchestrate, um, and, you know, being able to orchestrate and have, um, specific agents, if you will, for the different types of use cases, depending on the stage of the software delivery that you're at. Now, it seems like we're starting to see the rise of AI agents that are gonna be added to DevOps teams, and they'll either be assigned tasks or will augment existing humans in those teams.

But, um, how will we orchestrate all those AI agents? You hear a lot of people talking about things like the agent to agent protocol or, um, but from a CloudBees perspective, how do you envision all these things being brought together in a way that looks like they are a member of the DevOps team? Yeah, absolutely.

The, I think the MCP protocol has really, um, addressed this, this complexity, right? The, the way I see MCP servers is it, it orchestrates these AI agents in a way where AI agents can be very specific in the kind of the problem that they're solving. Um, if you think about, for example, in a factory, um, you know, within a factory, you've got AI agents that may be representing the workers, um, that are, um, doing specialized tasks, if you will.

Um, and the MCP server are essentially your floor managers in those factory that's orchestrating, um, the jobs to be done. They might have the master plan, they might have the blueprints and so forth. And so this MCP server will, uh, provide the context, um, it's stateful, um, and then it's providing the necessary information to the, the ages, um, to do the work, to actually do the tasks at hand that the, your developers or your, um, CI administrators, um, uh, will need in order to get their job done.

I'm trying to figure out how this is gonna play out, and in my mind, it may work out one of two ways, or who knows both, but are there gonna be a bunch of AI agents that are assigned a specific task as part of the DevOps team, and they'll do the same thing over and over again? Or will each engineer kind of have their own set of AI agents and they'll be doing tasks, but eventually we're gonna have to kind of coordinate those AI agents with other members of the human DevOps team that have their own AI agents? I mean, how complicated can this get?

Yeah, it can be complicated for sure. Um, the way I see it, you know, you have AI agents really assisting, um, different personas. Um, you might have AI agents to specializing a specific, um, build, for example, on the build side, um, AI agents that essentially takes the data, looks at the logs of your bills, helps the developer, um, figure out why a build failed, right?

So I think it's in some ways, um, specialized in certain, um, tasks and job to be done. Um, you don't necessarily have an agent per se, uh, per developer. I think it, it really kind of el um, it's more elevated to the, the kind of, um, tasks that need to be done.

Um, so I, you know, and that's where Amazon queue plays, uh, uh, you know, place, uh, with the, um, with this workflow, right? Where you got developers that are using Amazon queue, for example, to, um, gather the data and assist the developer to, um, figure out, um, you know, what to, what bills are failing, how to fix a build, what tests are failing, what tests should be run, um, and help them be a lot more productive and, uh, reduce that, um, kind of the tasks and the time, um, spent in those specific tests that they normally spend a lot of time on without, um, any kind of AI powered assistance. And one of the things that I think is maybe a little underrated is I'm not just gonna kind of get a bunch of AI agents and turn them loose.

They're only as smart as the amount of data that they gain access to. So, um, before I put the proverbial cart, before the horse, do DevOps teams need to go back in and kind of say, what is that framework for providing these AI agents access to the data that they need to actually make an informed decision? Yeah, for sure.

Um, for example, in, in, uh, we are, we are working on certain, uh, capabilities that's, uh, really leveraging ai. One of them is, for example, uh, the offering that we have smart tests. Um, the other one is around more about ci triaging and remediations, kind of like your AI DevOps first responder.

Um, and exactly to your point, it's, you know, a garbage in, garbage out. So, um, the way we are tackling this is ensuring that, you know, we use the knowledge base that we have acquired in the last 10, 15 years, for example, in the CICD space. Um, and so providing that kind of input and data to our agents to ensure that, um, it's learning, um, and then also getting feedback, um, from the users, um, you know, and, and really training it and, you know, doing some evals and, and so forth.

I think that's absolutely important. Um, you know, one of the things that I always think about when we're building these solutions is the three Hs, right? Um, is it being honest?

Is it being helpful? Is it being harmless? Right?

Um, and I can talk a little bit more about the, um, that philosophy, but for sure, this is something that we, uh, take to heart, um, in terms of, uh, ensuring that the outcome of these solutions are, um, are useful to our customers. Hmm. To that point, well, just how smart are these AI agents?

I mean, are they essentially junior developers or are they more like, you know, helpful high school students or, you know, where are they on that spectrum of intelligence? Because I think folks are trying to figure out, well, how much can I rely on them or should I rely on them versus, um, you know, how much time do I need to spend validating and checking what they do? You know, I think it, it, it's, uh, across that spectrum is how, you know how much you rely on them.

It really depends on, um, how much of the training you put onto these agents, um, and how much, um, evaluation you're doing to these agents. Um, you know, it also depends on where our customers are at with AI adoption, right? Um, are they comfortable with, uh, you know, allowing an AI agent to be able to just automate end-to-end their workflows, um, without the human in the loop?

Um, or, you know, are they currently still kind of dabbling with ai, um, and, you know, just looking for, um, solutions to solve, um, their problem, but still be in the loop, uh, per se, right? Um, I think it's important also to understand where the, our customers are at in their journey, um, and, um, providing them the kind of solution that is, um, that works for them in terms of governance and policies and, and so forth. We see some customers that just want, um, some sort of copilot, for example, right?

Um, but we also see customers who are kind of pushing the, uh, the limit, um, and pushing the envelope in terms of, um, allowing agents to just be able to, to do their job and to end fixing, um, fixing builds, um, issues and, and so forth. If I look back in time, every time there's a major innovation, we use it to do what we're currently doing faster, but at some point we kind of take a minute and we reinvent the whole thing altogether. And I cannot help but wonder, as we look at all this AI stuff, are we on the cusp of reinventing software development life cycles as we know it on an end-to-end basis?

And from your perspective, what might that look like? Oh, man, Mike. Yeah.

Um, it's the, the space is, uh, so dynamic and it's evolving so rapidly. Um, I think it, you are so right to your point. It, it really is changing the playing field altogether, uh, changing the way, uh, developers write code and innovate, changing the way, uh, DevOps engineers actually build their pipelines.

Um, it really is changing, uh, the way we work, um, even on the product management side, right? Uh, changing the way, um, product managers also, um, write their PRDs, uh, write, you know, uh, write their requirements and, and so forth, and validating, um, the problems to be solved and validating, uh, the solutions for these problems. I think it really is a, a game changer as we stand today.

Mm-hmm. Are you worried that we might have something that feels like an impedance mismatch because we have all these AI coding tools generating more code than ever, and then all that's gonna come flowing through our pipelines that today are, shall we say, uh, a little brittle? And I don't think it's gonna be enough just to kind of add more pipelines.

So what do we need to think about here? I agree to hear Mike, uh, uh, and we are seeing that already a lot, you know, a lot more commits and commits, um, coming through, uh, code assistance and, and so forth, uh, copilot and, and so forth. Um, and maybe at some point it will push the bottleneck from the developers to the reviewers to the pipeline bills and, and so forth.

And I think the way I see it is, um, you know, finding where the bottlenecks are, and then also solving where, how can a, how can we leverage ai, uh, to solve that next bottleneck as part of your software delivery. Mm-hmm. So what is your best advice to folks right now?

I think this is such a fast moving space that a lot of folks are kind of like, they're watching it, they're seeing it, they are definitely getting experience with some of the tools, but from a management perspective, what should they be thinking about right now? I think in some cases, a lot of folks are just overwhelmed to the point, like maybe they feel like deer in the headlights Agree. Um, I think, well, one, for those that are still curious about ai, just learning more about ai, um, you know, whether that's, uh, training, uh, leading up more, uh, staying in, um, up to, you know, the, the latest and greatest technology out there.

Um, today is MCP servers. Tomorrow is something else. Um, and even on the MCP protocol is changing quite rapidly.

So staying, um, up to speed with technology, I think is, is really important. Um, and the other is, um, don't necessarily trust AI right away, right? Um, and, and, um, you know, it's, it's also something that we need to take into consideration.

Um, look and make sure that it's doing the right thing, that the outcome is, uh, is what you expect it to be, that it's reliable, it's deterministic, and, and so forth. All right, folks here, heard it here. As always, there's a lot of exciting things going on, but just remember, look before you leave, hey Lala, thanks for being on the show.

Thank you, Mike, really appreciate, great to meet you. All right, and back to you guys in the studio.