Bart Farrell: So first things first, who are you? What's your role? Where do you work?
Henrik Rexed: My name is Henrik Rexed. I'm a Cloud Native advocate and a CNCF ambassador, and I'm working for Dynatrace for about five years now.
Bart Farrell: Now, Henrik, where does code quality break down first when changes span application code, Kubernetes configs, and CI pipelines in the same PR?
Henrik Rexed: I usually prefer smaller PRs because it's always easier to review big PRs. I think that's the big thing because there's a lot of aspects between code between YAML structure and quality, and then also if it's a specific object to review it. I think from a code perspective, I think we have a good code reviewer. But then if you delegate the reviewing for some third-party process on specific Kubernetes resources that are not well-known, that is a different topic, I would say.
Bart Farrell: Why do YAML and Helm changes consistently escape the same scrutiny as application code? And what does that cost teams in production?
Henrik Rexed: I think from a YAML structure file, especially if we talk about Kubernetes resources with the API support and everything, this could be a breaking change. So if you apply a new release and you don't see it necessarily on the review, and then you apply it, that could have a breaking change. Same thing from Helm charts. especially if you have any CRDs involved and you need to upgrade it. So that could be, from a visual perspective, there's no changes. But then once you are actually deploying on a test environment or whatever environment you are, you could have failures. So I think it's more about testing it. And maybe if you have a GitHub Actions, maybe you have a Codespaces where you can at least try to deploy it to make sure that it's actually running as expected.
Bart Farrell: As AI writes more of the code going into Kubernetes deployments, what does good governance of that code actually look like?
Henrik Rexed: I'll make a pause on this question. I think if you take an AI agent that do everything, then there could be some limitation. I think as of now, maybe one year from now, things will be completely different. I think having specialized agents for specific narrow down tasks. So we will talk about Kubernetes configurations, so more like something more like ops people or someone that is specialized on this or someone that is more specialized on observability, for example. And then that will basically provide better and higher quality standards, specifically in the Kubernetes environments. So then when they are preparing the commits, then you can also involve a specific reviewer that at least track the PR of one of the specialized agents, if it's more operation side or if it's more the observability side. So then they are reviewing the right aspects and not having someone very generic and very general, and maybe they could miss some patterns. But I think from a general perspective, I think having a first reviewer that clean up the hard work and then having a human being going through the review and then at least validate that it's confirmed, I think that's good.
Bart Farrell: Where are engineering teams getting AI code review right today? And where are they still flying blind?
Henrik Rexed: I think I'm more a GitHub user. So I think having a flow where when you have a PR, you involve already agents that review those PRs directly. And I think that is a good way of getting the work, at least a part of the work done. But usually on the process, when you have AI agents, like I said, with specialized agents having a cycle where you have a code, you have some sprints, everything defined, but then the code, the AI coder takes the implementations. And then after that, you run the AI testing agent. And then after that, you are all the AI code reviewer. At least before they made a PR anywhere, you have already cleaned up part of the issues. And then once they are hitting the source control, then you can also review it with third-party agents, simplifying the peer review.
Bart Farrell: What would it take for you to trust an AI recommendation on a production-bound infrastructure change? What's the bar?
Henrik Rexed: I think to reframe your question and say there's no production change, there's always going to be a third-party environment. So I think if you are doing a change, then you will anyway go to testing. So I think you minimize the risk. But taking in AI agents and implementing a hotfix in production, I don't know if I would be very comfortable about that.
Bart Farrell: Now, Kubernetes turned 10 years old almost two years ago. What does the next era look like for teams trying to maintain quality at that scale?
Henrik Rexed: I think with the Kubernetes being more and more stable, I think for teams, more from the infrastructure perspective, what is very difficult to keep up the pace is if you have versions that are out of support, so you have to keep up on the upgrades of the clusters. So if you are in the cloud, that's quite easy. But if you are in-house, it's a different story. So I think that's more about the speed of releases, That could be something challenging. So if we delegate that task to an agent, maybe it's going to be simplifying the world. But I think anyway, with Kubernetes and going more on the AI front and AI era, I think there's a lot of very promising things. So everything will be on Kubernetes, releases, inference and networking and everything. So that's very super promising.
Bart Farrell: Henrik, what are you focused on building or solving next?
Henrik Rexed: The thing is, with this AI agents movement and everything, the only thing that's blocking me is the lack of creativity. And for now, I'm more tired than anything because I keep up building things and maybe I'm building too much. It's to make sure that before we start building something, we make sure that there's nothing already existing. So to challenge our ideas instead of just doing it, because otherwise I'm afraid of the impact on open source for those reasons.
Bart Farrell: And if people want to follow your work or reach you, what's the best way to do that?
Henrik Rexed: I'm active on LinkedIn, most on LinkedIn. You can also reach me on GitHub. Henrik Rexed. And also I have a YouTube channel, so Is It Observable? So you can check it out and ping me on YouTube or whatever. I will always respond.
