Why Agentic Coding Needs Governance at Scale

Hey everyone. Welcome back here to another "Techstrong TV" segment. This particular segment, I had it marked in my calendar because I was really looking forward to it.

com, well, I founded it in 2013. We started publishing in 2014. The second sponsor, we had two sponsors to start, AppDynamics and CloudBees.

I started this business with CloudBees. And at the time, DevOps was Jenkins, DevOps was CloudBees. And we featured an awful lot of CloudBees content back then.

We were just starting out and a lot of the DevOps companies you read about today, they were dreams in some founders' eyes back then, but CloudBees was already serving the world with Jenkins and everything. I remember them buying a small company in Europe, and I had a chance to interview this gentleman I'm going to introduce you to. He was the founder of that, or co-founder of that company.

He then joined CloudBees and was on their executive team a few years, and then he had moved on. He's now back. Right?

Back as the CEO of CloudBees. It's my friend Moritz Plassnig. And first of all, Mo, congratulations on returning as CEO.

It's good to have you back. Yeah. Thank you so much.

I filled in a little of the story, but give people a little more color than that, if you can, on your personal journey. Yeah. The simple story is, I think I never stopped thinking about DevOps and CloudBees and CodeShip.

I think if you start a company, you ultimately started to solve a problem, and I think we solved some of it, but not all of it. Spent some time at CloudBees, we solved a little bit more, but we never finished the mission. That's my opinion.

So never stopped thinking. I left for five years, but then one thing led to another, and now I'm back and I'm very excited about it. I'm excited for you.

I'm excited for CloudBees. It's funny, I've started a few companies myself, and you're right. You put a little bit of your soul, of your guts into every company you've found and that you're really passionate about.

So I know where that comes from. Well, let me ask this. Between leaving CloudBees and coming back, what have you been doing?

Yeah. I worked at an interesting company called Immuta. Different space, not DevOps, not developers.

It was in a data space. Interestingly, worked with a lot of the same customers. Ultimately, if you solve big problems for large organizations, you keep working with the same companies and customers, which was good.

And it was all about controlling and governing who can access what data, especially for very large organizations that have lots of sensitive data, whether that's financial services, the government, healthcare, pharma, life sciences, where the data is really powerful but also needs to be protected. And I think in that world and in that space, I saw large language models change everything. I saw how it changed how we built software internally, but then it also changed how our customers just worked with data.

Instead of maybe going to a BI dashboard, suddenly you just ask Claude or ChatGPT for an answer, and you get the answer. I think in that world, it changed rapidly. But then by just using the tools, playing with them, and being exposed to, well, how do you build software in this new world?

I think the fire came back. com in 2014. I think 2014 was the first time I came to the US for CodeShip.

So it's been a while, and I felt when I left CloudBees, I really thought that we did a good job. DevOps, it is a thing now. Companies are practicing it.

They're really thinking about how can they better deliver software for their customers. I thought we got quite far, and it will only get better, and it's all good. I think ultimately, a lot of the same problems are still unsolved when I talk to customers now, and then I think the world just changed.

I think for many years, we spent a lot of time thinking about, well, how do humans build software? How do humans test software? How do humans release software?

How do the humans then run the software and make sure it's actually working and doing what it's supposed to do? And all of that is different now, because suddenly, instead of having hundreds or thousands of engineers doing it for you, suddenly you have software, AI doing it for you, and I think it changes everything. I agree.

It does change everything. It's interesting, I just finished a book I've written and I'll be publishing shortly, and it talks about when things become kind of built into the grid. They become indispensable.

Fiber optics in the internet, the telephone system, electricity, the railroads before that. Huge amounts of infrastructure, but they get built in, and when things get built in, they almost become invisible. Mm-hmm.

And that's when you know they're truly accepted almost. And DevOps has sort of had that. Yeah.

Where look, when you and I first met, we were still convincing people that DevOps was a real thing. Everyone knows DevOps is a real thing now. Yeah.

Now they want to know, well, how does that play with cloud native? How does platform engineering come into the picture here? And of course, the question everyone's asking now is, well, what does this mean in an agentic world?

Right? What about AI and how is that affecting or changing DevOps? Yeah.

If I didn't say it before, I'll say it again, I'm thrilled you're back at CloudBees. But it's a really interesting time to come back because I think that's the biggest question people want to know right now is, agentic AI, how is this helping? Is it a tool we use with DevOps?

Is it something special we have to do DevOps for? Is it a threat somehow from a security point of view? Maybe all of the above.

How do you view it and how do you tell the large enterprises that are CloudBees customers about the relationship, if you will, between agentic and DevOps? Yeah. I think it's all the above, as you said.

I think what's interesting is I would've said, like, "DevOps, we solved this. Everyone is doing it right. " What's interesting now is when you talk to companies is they never truly and fully adopted it because I think when you now talk to them about agentic coding, what holds them back is that they didn't truly automate, for example, their pipelines.

They still struggle releasing software. When you think about things like developer productivity, it's still a big problem. Builds or tests are running too long, right?

They're flaky tests. The release process is too manual. They don't do continuous delivery or progressive delivery.

It's still very manual. So I think what we realize now is the companies that truly embrace DevOps, that have truly great engineering culture and great developer productivity, they are also the ones that can get the most ROI out of agentic coding right now because everyone else, I think, just patched together certain things and they said, "Yes, we are doing it. " But under the covers, they didn't do it well.

And so I think that is what holds a lot of large organizations back now because when you talk to them and they're trying to introduce agentic coding, the first thing that they realize is, well, an agent needs a quick feedback loop, right? The reason why agentic coding is possible is because you can automate everything that's verifiable, and building software is verifiable because you know when it compiles, you know when the tests run and fail or not fail. So there is this feedback loop, but in many large organizations, that feedback loop is incredibly long because their builds might run for hours.

And so that annoyed the humans, that annoyed the software engineers. But I think companies, some obviously paid attention, right? And they did a lot of work around developer productivity.

Others didn't do enough work there, and now they're struggling because the agent, right, if the agent has to wait eight hours to get the test results, and then maybe there are some flaky tests, and then they need to rerun the build, and they need to wait another eight hours, that doesn't work in a world where you want to truly automate and where you ultimately also want to control the cost for those large language models, right? So if you have an agent do a lot of unnecessary work because the foundation isn't there, that really hurts you. So it's really interesting to see, because I would've said, "DevOps, it's a thing.

We are all doing it. " But what we see now is actually many large organizations weren't truly doing it. They were maybe just saying they are doing it.

Well, Moritz, I used to have this saying that in large organizations, DevOps existed in bubbles. You would have lots of tiny bubbles of different teams doing DevOps, and each team probably did it a little differently, used a different tool set, and had a different view of things. It's when you try to homogenize that across an entire enterprise that I think you started running into issues, scale issues, issues around settling in on tools.

You can't use 12 different tools to do the same thing. And so there was a lot of friction around that. And quite frankly, I think the whole platform engineering movement is somewhat of a reaction to that, right?

" It plays better at the enterprise, and that allows your DevOps teams to do what they want to do, which is go fast, develop code, deploy code. Right? So I think there is that, but I think the whole agentic AI thing is almost like a second bite at the apple or a second chance to maybe correct some wrongs.

What's your advice to people with that? My theory is that I believe now in retrospect, DevOps, it was incremental improvements for a lot of companies, right? I think everyone at some point said, "We are a software company.

Software's eating the world. We are a bank-" Right ... " People said that, but what happened under the covers is it was like a little bit of digital transformation, a little bit of automation, better collaboration, right?

Again, dev and ops, better working together, all of that. There was some incremental improvements, but I think no company truly, with some outliers and exceptions, but the average company didn't truly believe they didn't do that. I think what's changing with agentic coding now is That everyone currently believes this is changing everything, and if we don't get on board, we might go out of business.

Nobody thought that about DevOps. " Maybe there were some people in the organization that thought that, but it's not that the CEO or the board thought that. " Everyone wants an announcement with NVIDIA, with OpenAI, with Anthropic.

" I think in reality, what's happening is there's a lot of-- I'm very bullish on AI. I believe every code will be written, or the vast majority of code will be written by AI, so no question there. But the reality of where we are today is, I really like what you said about we did DevOps in pieces here and there, in certain areas of the company.

We see the same now with agentic coding. I think it will ultimately penetrate each company much faster, and being used in every part of the organization much faster. " Everyone will obviously say yes.

" And it's very little to nothing. Because everyone is trying to figure out how to do it. " And then to your point, how do we do it securely, and how do we govern it?

And I think the governance is extremely difficult because you have all those different tools and different tool chains. And maybe one group of your business standardized on those three tools, and then another group standardized on three different tools. So I think what you need as a company, and maybe that is where my old world of working at Immuta and doing this in the data space shines through is, I believe you need to take the rules that you have in your organization, rules that say things like, you need two humans to review any code change.

You take those rules and you bake them into policies, and you manage them, and you version them, and you control those policies centrally, and then you make sure that those policies are being enforced through an automated system in whatever tools you use. Those tools might be CloudBees, they might be GitHub, they might be GitLab, they might be something else. Doesn't matter.

You have this centralized governance engine, and through that, you can control whatever the company is doing, and through that, you can also still give some flexibility to the company. You can't use every tool, but if you use one of the three approved tools, you're good, and then we can govern all the changes you are making, and we can see how changes, whether they are done by a human or an agent, flow through the system. We can make sure they're well-tested, they've good test coverage, good code quality.

The human signed off before they move into production. We have the whole audit trail, and we know who did what. So I think that is my advice to companies and customers.

But yeah, everyone is still trying to figure it out. Absolutely. I think that's excellent advice, Mo, and I couldn't have said better myself.

Let me ask you a question, then. How does this manifest itself in CloudBees' products going forward? Yeah, in various different ways.

So obviously, we are using AI internally to build our software. So I think that's important because it helps you understand how the world changed. I think what is so interesting about large language models and agentic coding is you can read about it all day long, and just you don't fully grasp how it's changing the world until you really use it.

Until you, yeah. You need to use it and- You got to get it under your fingernails. Yeah Exactly.

And then you feel, "Oh, it's working here. It's not working there yet. " You need to figure out all of that, and then you need to figure it out again, like two weeks later, because something changed.

A new model got released, or something else changed. The space is moving so quickly. So we're doing a lot internally to build software ourselves with those tools.

Then, we're doing obviously all the standard things. When you think about MCP servers, a chat interface, all those things, I think they are pretty standard at this point. You currently have, when you look at software, you still have a lot of people that prefer the traditional UI-based approach.

You have a growing number of people that just prefer to be in whatever agentic coding tool, could be Cloud Code, and they want to interact with your software just out of that tool. And so an MCP server, good APIs, CLIs, all of that help there, and we're doing a lot of work there. And then we are starting to use large language models for certain features, and they create a lot of value for the customer.

But I think what's most exciting is just because the whole software delivery process changes if the code will be written by AI, I think that is what we are really optimizing for. Because we have so many of the right building blocks. CloudBees, obviously Jenkins.

We've done this for a very long time. That is why we have all those customers. But then over the years, we acquired different companies.

We have things on the release automation side, and those products are now utilized heavily, which is great because I really believe you need to look at the end-to-end automation. Because what's happening in the world is, I think software development is getting industrialized. In the past, it was a lot of craftsmanship, and I think we'll keep some of the craftsmanship, but in the past, it was a lot of you have all those humans writing code manually.

And I think going forward, that's not the case. The code generation is automated. The craftsmanship happens around Well, what code do we want the machine to write?

What ideas do we want to implement? Implement it, I will give feedback. The craftsmanship happens there, not with the manual writing of the code anymore.

But if that is getting automated, I think you really need to industrialize the whole process, similar to how with the Industrial Revolution or in other cases in history, we just automated the whole end-to-end process. I think that is what's needed. And so we have the right building blocks.

We help you test and do that at very large scale. We help you then release the software. We do the feature flags for you.

But most importantly, we can help you govern all of that, and not just govern it with the tools we provide. Obviously, if you use Jenkins, we can help you govern what happens with Jenkins, but we are also expanding this governance to any other tool. Again, you can use GitHub Actions, you can use GitLab, but we have a governance engine that helps you govern, and I think that is really needed because you mentioned we try to standardize, and I think we are still trying to standardize, but I think people are also giving up on standardizing because they realize the moment you standardize, the company buys another company and acquires someone, and then you have another set of tools.

Right? Or you standardize on something that changes it. Exactly.

It's a never-ending battle. Exactly. And I met a customer, very, very large bank, and the person I met made a really interesting comment.

He said that the pace of change is increasing, and so how the bank now thinks about technology is like, well, whatever we buy, whatever we adopt, it's for the next two, maybe three years. And two, three years is very short for a large organization. Because you know what it takes for them to buy and then adopt, then roll it out, and train everyone and get everyone to use it.

So the largest companies in the world are now thinking about how everything just needs to change much faster, and it's not like just today. It will stay like this. Software and products will change much faster, and you need to be more agile, more nimble, and more flexible as an organization.

And I think that's because you see, if you look back a year ago, everyone was using Cursor, and then Thanksgiving, Christmas last year, everyone discovered Claude code is so much better. And then at some point, Codex from OpenAI caught up, and then everyone went back to Codex. And it does shift again in the future, and open source models are not sleeping, and there are new open source models getting released.

" That's like how we bought software in the past. Suicide. Yeah.

It's suicide because their models might not be the best models next month, and then maybe in three months they catch up. But maybe for that period where their models aren't the best, maybe you want to use something different. Or then much worse, what if, for whatever reason, you are not allowed to use the models anymore, or your employees in Europe are not allowed, or your employees outside of the US are not allowed to use those models anymore.

Or the employees in the US are not allowed. Exactly, because it's not just the US doing it. China is getting much more protective as well.

And so- Yeah ... I think something fundamentally changed, and I think not everyone is truly appreciating it yet. I think it fundamentally changed how companies are buying software, how long they're willing to commit to one solution.

I think we're moving away from standardization to embracing diversity, and not like everything is okay. Not every employee and every developer should pick whatever tool they want, but, hey, here is the menu list, and that's the menu list that you're allowed to use, and there's more on it than in the past we would have put on it. But we need to do that because different tools are better at different times, and different vendors have something better.

But everything that's on the list is governed centrally because what we are also seeing is supply chain risk is much bigger. There's a lot of security risk when you truly buy into this automated process of building software. There absolutely is.

Yeah. And that's the whole governance piece of it. So I call that AI scale.

If you're going to go with AI scale on this, you've got to be able to AI scale your governance, because otherwise you get that mismatch- Yeah ... and it's a catastrophe waiting to happen. Yes, exactly.

And it's so- Well, I'd love to talk to you about this. No, go ahead. You finish.

Yeah. My last thought, it's so interesting to see because I think what you're seeing is, well, if code is not writing the bottleneck anymore, you just discover the next and the next bottleneck. And I think you made a comment around that where, well, actually getting it into production, running it, and knowing it's doing what it's supposed to do, that's still the bottleneck.

We tried to solve that with DevOps. We didn't fully solve it. Now we are feeling it even more that it's the bottleneck because we can suddenly write so much more code.

So I think we need to solve that, and it will be better for everyone if we finally solve it. Agreed. Well, look, promise me you're not going anywhere again soon.

Let's continue this conversation over the next weeks and months, okay, because we just peeled a few layers off the onion. We got a lot more- I agree ... to peel back and discuss.

This is a great conversation to have. But in the meantime, hey, man, seriously, congratulations. It's great to have you back here at CloudBees.

Looking forward to big things and great things again at CloudBees. Come back and visit us soon, okay? Sounds good.

Glad to be back. Thank you. All right.

Moritz Plassnig, newly installed CEO, newly minted CEO of CloudBees here on Techstrong TV. We're going to take a break. We'll be back in a little bit.