Bart Farrell: Okay, so first things first, who are you? What's your role and where do you work?
Viktor Farcic: I'm Viktor. I'm a developer advocate probably in an Upbound company behind Crossplane.
Bart Farrell: Where does code quality break down first when changes span application code, Kubernetes configs, and CI pipelines in the same pull request?
Viktor Farcic: Where does it break in the same pull request? It starts breaking the moment people touch it. People are the problem, the reason in all the breakage we're having.
Bart Farrell: Okay, so as much as we might be looking to AI, you think that human error is really the key point?
Viktor Farcic: the human error. But human error is on many different levels, right? Lack of knowledge, lack of direction. It could be just as much a management issue as an engineering issue and so on and so forth, right? But, you know, the only system that doesn't break is the system you never touch. The moment you start touching it, the moment you start upgrading or releasing something new and so on and so forth, you start having issues. That's the nature of the business.
Bart Farrell: Why do YAML and Helm changes consistently escape the same scrutiny as application code? what does cost teams in production?
Viktor Farcic: I feel that that's the problem we have across the board in terms that in most of the cases, teams that are not application developers are always in some kind of a catch-up game, right? And those teams can be operations, like in case of your question, can be testers, can be management, and so on and so forth. Because developers tend to be, application developers in this case, tend to be the first ones to adopt most of the practices we use today. It took probably 10 years until operations, and I'm not talking about the past, realized that actually version control is a good thing. We shouldn't be doing willy-nilly stuff in our servers. It's not because it's YAML, necessarily, but it's because It's an artifact done by teams that do not necessarily have the same practices as some other teams like application developers.
Bart Farrell: And as AI writes more of the code going into Kubernetes deployments, what does good governance of that code actually look like?
Viktor Farcic: I feel it's similar to what I would answer to that same question without AI. And that's that you have good managers, you have bad managers. When I say managers, I mean in a broad sense of the word, like product owners, tech leads, so on and so forth. And we are all becoming that role now, right? We are managing people in the past, and now we are managing agents. And that's a very different game than what we were doing before, right? And we need to start thinking, when it comes to governance, is how do we govern our employees right now? It's just that those employees are digital, but they're not different from people, really, right? Bad distractions result in a bad outcome. Not enough governance results in nasty things that shouldn't be happening, right? Too much governance results in not being able to do stuff. I feel that the story is the same. The actors that are jumping into roles are different.
Bart Farrell: Where are engineering teams getting AI code review right today? And where are they still flying blind?
Viktor Farcic: Code reviews, we cannot do code reviews anymore like we were doing them before. Let's start with that, right? Because if you have SDLC, you have software development lifecycle, and you speed up one part of that process and everything else stays the same, the whole process stays the same, right? Now, what we're seeing right now is adoption of AI across the board. But where it gets the most adopted and where we see the most, the biggest increase in the speed of delivery is writing code itself. And AI means that if I can do double, triple, quadruple, whatever is the multiplier right now of code that I was doing before, and somebody does the code reviews in the same way as they were doing before, the only result will be that we are queuing more work in that stage of the process. And that means that we need to start picking our battles well. We need to start saying, okay, I should review this, and that, but this is something that requires special attention and I'm going to look at that. So instead of reviewing all the pull requests that we were doing before, we need to figure out how do we focus on things that really require special attention. And let everything else be done with AI, which is essentially the same as what we do with writing code. Hey, I might not be writing 100% of the code, it might be writing 90% or 80% or whatever the percentage is, and my job is to figure out what is the part I should do myself.
Bart Farrell: And with that in mind, what would it take for you to trust an AI recommendation on a production-bound infrastructure change? What's the bar? When is it good enough?
Viktor Farcic: It's good enough when I realize that it is saving me more time than the time I was spending before, right? Which is probably very different than what people would normally say it's good enough and it stops making mistakes, it's good enough and this or that. What I'm really looking for, I see AI on any level as extensions of me. If I can delegate 10% of my work, that's good enough. Now, some other people might be looking, hey, good enough is when it can be fully autonomous, I don't think we're there yet. Whether we are 99% or 10%, I don't know. But it's good enough as long as it saves more time than the time it increases.
Bart Farrell: When we're thinking about the next era for teams that are trying to maintain code quality at the scale of folks running things in production Kubernetes, what does the next era look like for teams trying to maintain code quality at that scale?
Viktor Farcic: I feel that code quality will be one of the things that will be done fully by AI. Because very often people think that code quality is the same thing as whether this makes sense, which is a very different thing. Code quality is relatively straightforward it's relatively easy. Does this code, is it written well? Does it pass all the checks? Is it performant? And so on and so forth. That's an easy part and I think that will be fully automated, fully done by AI, plus some tools and so on and so forth. The real challenges are more, do I know what I want? Do I know the direction I should take? And so on and so forth. So code quality, I consider it almost done, or close to being done, right? Not our problem anymore.
Bart Farrell: And Viktor, what are you focused on building or solving next?
Viktor Farcic: My biggest problem right now, and this is personal, so not necessarily from a business perspective, is just that I cannot handle the cognitive load that is happening right now on top of my brain. I literally cannot work for more than an hour without having to stop and watch something on Netflix or play a game. And the reason for that is because before we had the combination of thinking and manual labor and that we were iterating between those, and those are very different skills, then we switched, in my case, at least to most of the things I'm doing is thinking what to do next while AI is doing something. It's like playing a chess game, right? It's making its move and I'm already thinking of the next move that I should make myself. And now we are in a phase, at least in my case, that I'm working on five to ten projects in parallel. And the amount of context switching and cognitive load that is producing is just overwhelming for me. I cannot do it for more than a couple of hours. So what I really want is to figure out how can I keep that pace without going crazy.
Bart Farrell: Okay, could you comment on what Netflix series you've been watching lately or what games you've been playing?
Viktor Farcic: Oh, Netflix series. What am I watching now? I don't remember anymore. It's often some silly comedies that, you forget immediately. Just kind of watch so that your brain does not work. And games, Nioh 3.
Bart Farrell: All right, good to know.
Viktor Farcic: It's like Souls-like.
Bart Farrell: Okay. I think it's interesting, though, what you're talking about, the cognitive load and the context switching. As someone with ADHD, that's often seen as like a benefit, but at the same time, it still can be very tiring because the very nature of context switching, it's like having to reset, jumping through different scenarios. And while from a digital user experience, it can be seamless. I go from one tab to the next. So it seems like, oh, it's just a short distance. But all the recalibrating that I have to do and the things I have to be thinking about, the distractions, things like that can be very taxing. So it's something that While technologically we're very advanced, at a human level there's probably some work to do.
Viktor Farcic: My current goal work-wise is I hope to retire sooner than somebody else does it.
Bart Farrell: Now Viktor, if people want to check out and see the work that you're doing when you're not watching Netflix or playing games, how can they follow you or reach out to you?
Viktor Farcic: Everything I do is public. You literally Google my name, you will find me on GitHub, on X, on Twitter, no, that's the same thing now. LinkedIn, I don't know. CNCF, I'm everywhere. Just Google me. That's easiest.
