Bart Farrell: Where does code quality break down first when changes span application code, Kubernetes configs, and CI pipelines in the same PR?
Mauricio Salatino: That's good. I think that's a very good question, actually. So I think that the bigger the context and the more projects and technologies you include in the same prompt, the more issues you are going to have with the things that are generated there. I think that in order to get better results, you need to split down into three different tasks, probably changing code first. then changing the manifest that reflect the code changes in some way, and then making sure that the CI pipelines are stable enough that can support testing all these changes all at once, like integration testing and end-to-end testing is really important.
Bart Farrell: Why do YAML and Helm changes consistently escape the same scrutiny as application code? What does that cost teams in production?
Mauricio Salatino: So the difference between configuring an app and coding app is quite considerable, right? And the lifecycle of these resources is completely different as well, right? And I think that the friction point between who owns the Helm chart definitions and who is in charge of maintaining them while developers maintain the code of the application is a clear responsibility separation that needs to be implemented in companies to make production and release cycles shorter. So I think that teams need to define the roles, who owns what, And I'm in favor pushing Helm Charts to be owned by the operations teams.
Bart Farrell: As AI writes more of the code going into Kubernetes deployments, what does good governance of that code actually look like?
Mauricio Salatino: so if you're thinking about a code generation for Kubernetes Manifest, I think that we need to think about how do we test all this code that is generated, right? Because, again, you can just test it in the same way that you're testing your applications. So using tools like Kine or even Bind from vCluster now that it's becoming quite popular. is something recommended to check that these manifests are still working in your clusters before like moving that release in the chart or something like that so i strongly recommend people to run the charts before and test that as much as they can before like letting ai do all the changes and validations that it cannot do unless you run them on a cluster where are engineering teams getting ai code review right today and where are they still flying blind so i think that like engineering teams nowadays that are producing application code with Gen-AI. they are having challenges reviewing all the code that gets generated. I see a lot of people submitting generated pull requests to open source projects, and it's very hard to pass the reviews in that space, and you're generating a lot of load for the maintainer teams. I think that internally in companies is similar. When you think about making changes on the Kubernetes manifest or Helm charts, it goes beyond testing and reviewing pull requests. Again, people will need to test this manually. and validate that these charts can work in a production environment. So I think that it's quite important for people to realize that you can generate a lot of things, but in order to generate the right things, you need to provide the right context. And that usually means providing the right examples of good patterns with Helm, for example, or creating skills for Helm that can help you to produce quality charts without pushing, like beating new stuff from the ground up. So try that. Give it a try and see if that works.
Bart Farrell: What would it take for you to trust an AI recommendation on a production-bound infrastructure change? What's the bar?
Mauricio Salatino: So if you're thinking about looking into AI recommendations for changes in a production environment, my bar would be to make sure that we look into the metrics, like all the things that we can observe on the application behavior so we can compare with how the application was working before. I think that if I can see that performance-wise and the responsiveness of the application is the same as before. I will probably implement those automatic releases gates. I think that the validation should be more user focused. Like if the user is not seeing any impact on the application, we move forward. So implementing those tests is kind of key for allowing multiple releases, faster releases, and releases that are based on generated code.
Bart Farrell: Kubernetes is over a decade old and still accelerating. What does the next era look like for teams trying to maintain code quality at that scale?
Mauricio Salatino: That's good. I think the larger the project is, the more difficult it is to put it all up into an LLM model just to make changes. So I think that on order to keep up, what we need to do is we need to be more modular in the projects that we create and try to start separating responsibilities of who owns what. So you need to have experts behind LLMs making sure that whatever they generate has enough context to be a quality goal. And at the end of the day, having the right experts inside your company is still the most important part of this whole thing.
Bart Farrell: What are you working on next?
Mauricio Salatino: So I think that like what I will be doing next is building like an AI stack on top of Kubernetes and building all the observability story on top of it. I've been working with agentic frameworks for the last six months. And I think that there is a big difference between the infra that these agents need to run and the frameworks that people are using to build these applications. So I will be building some tools on that space for sure.
Bart Farrell: How can people get in touch with you?
Mauricio Salatino: So I'm at Salaboy in X, but I also have this blog that is salaboy.com. So you can drop me a comment there if you're interested in the topics that I write or just reach out in LinkedIn. I'm always there.
