In this episode of PLATO Panel Talks, host Mike Hrycyk is joined by Arash Taheri (Central One Credit Union) and DJ Sicoli-Khull (PLATO) for a deep dive into the evolving intersection of DevOps, automation, and artificial intelligence. The panel explores how DevOps has shifted from a culture-driven practice to a more integrated, platform-oriented ecosystem in which AI and automation are no longer optional but foundational. From the rise of platform engineering and DevSecOps to AI-assisted test selection and predictive pipelines, the conversation highlights how modern DevOps is becoming smarter, more adaptive, and increasingly developer-focused.
Whether you’re a DevOps practitioner, QA engineer, or technology leader, this episode offers practical insights into how automation and AI are reshaping software delivery, and what it takes to stay ahead.
Can’t use the player?
Listen to this episode on Spotify (opens in new tab)
Episode Transcript
Mike Hrycyk (00:03):
Hello everyone. Welcome to another episode of PLATO Panel Talks. I’m your host, Mike Hrycyk, and today we’re going to talk about DevOps, but not just DevOps. We’ve seen a lot of things happening in the past few years with automation and AI. And so, today, the topic that we’re going to talk about is the intersection of DevOps, automation and AI. To make that interesting, as always, I brought in a couple of speakers who have great experience. So, Arash, tell us about yourself.
Arash Taheri (00:29):
Thank you, Mike. My name is Arash Taheri. I’m the Director of Quality Engineering and Quality Assurance at Central One Credit Union. I have over 19 years of experience in the QA space, and I don’t know how many, many, many years of working and integrating with DevOps for various reasons.
Mike Hrycyk (00:46):
Thanks! DJ?
DJ Sicoli-Khull (00:47):
Hi, I’m DJ, and I’m a Senior Consultant at PLATO. I come from an automation space, and for the past 15 years, I’ve been working in cable, games, and ed tech, interacting with a variety of DevOps systems. So, I look forward to bringing my perspective, from an automation standpoint, on how it’s evolved from just being a tool back in the day to what is now, more of a living and breathing system.
Mike Hrycyk (01:15):
For me, old school and DevOps mean you worked on Hudson. Did you ever work on Hudson?
DJ Sicoli-Khull (01:19):
Unfortunately, no, I have not.
Mike Hrycyk (01:21):
Alright. So, let’s kick it off. We’re going to assume that everyone knows what DevOps is. And so, let’s start with the evolutions you’ve seen in DevOps over the past few years. And let’s kick off with you, Arash.
Arash Taheri (01:34):
For sure. So, I’ve done many talks around DevOps as well. I remember many, many years ago, during my first talk, I did mention that DevOps was originally brought to different organizations as a mindset or a culture, but it used to bring the entire organization together, different work functions used to work together, have different representatives to work as a culture and bring some improvements around technology. But that doesn’t really scale in the modern DevOps, as we say. So, originally, DevOps was focused on building, let’s just say, CI/CD pipelines, automating builds, and making sure that we can hook up our automation scripts, for example, into our pipeline and have CI/CD in place.
(02:15):
But the evolution that we see, at least a couple of important ones that I can talk about, is one of them is this rise of, as we call it, platform engineering, where I think I can say that organizations realize that having it running as a silo, it’s no longer efficient. So, we should have a platform engineering team when we kind of build internal tools for our technology. And when you think about it, you can refer to DevSecOps, where security used to be a very late-stage activity, if you will, and very functional and fully integrated into the pipeline. The other one I can think of is AI integration across the lifecycle because previously we used to run full regression every single time, but now organizations are able to apply AI-assisted tooling to segregate what kind of tests need to be executed in this version of the build. So, I guess what I’m trying to say is that the main evolution I can think of is that kind of removing that silo focus portion of DevOps and also bringing AI into it.
Mike Hrycyk (03:14):
Okay. DJ, same question to you. What evolution have you been seeing?
DJ Sicoli-Khull (03:18):
Arash pretty much nailed it on the head. There’s one more thing I’d like to add to it, which is that it’s also adding more of a developer experience to the whole process. He mentioned adding more security and having AI integrated into that pipeline, allowing it to be smarter in test choices, but it’s also giving the developers more flexibility and more control in the actual environments and what they’re actually developing in as well.
Mike Hrycyk (03:43):
Okay. I can agree with all of that. I mean, one of the bigger changes I’ve seen since it started was really about the CI/CD integrated build. I like that it’s moved into; it’s a mindset of having everything integrated together. One of the things I like about that is that the DevOps pipeline can install its own environment and update its own environment. So, I like that. So, I’m not hands-on every day playing with DevOps. And so, I have a question for you guys. To me, it looks like when I look at Jenkins, we’re probably going to talk about Jenkins a lot today. When I see Jenkins, it looks like the things that change in Jenkins is it adds an integration for a new tool. It’s like, oh yeah, there’s this new special tool now we’ve integrated, so it lines up better. But when you guys look at the DevOps tools, and we just started to talk about this with AI, have the DevOps tools really been evolving and changing? Is there movement there? And we’ll start with you, DJ.
DJ Sicoli-Khull (04:37):
Not as much as people think. They don’t really change, as you mentioned. They’re being more optimized for developers’ experience, not just pipelines. Like with Jenkins, it is still widely used. GitHub Actions still has the same core ideas as Jenkins. Kubernetes is still dominant. What has really realistically changed is that the tools are becoming more integrated. More movement towards like platform over tooling. Less EML chaos and more like abstraction layers to make it more flexible. So, we’re really going towards that really developer experience, in my opinion.
Mike Hrycyk (05:12):
Arash?
Arash Taheri (05:13):
Yeah. As DJ mentioned, they’re not changing as much, but I guess the main differentiating factor that I’ve seen over the years is that they’re just becoming more assistive and predictive, if you will. So, for example, there used to be all these tools, which still exist, but they used to be isolated; now they’re integrated, as DJ mentioned. And they used to be, for example, reactive, but now we can say that they’re predictive or more intelligent. We can say that they used to be very focused heavily on manual. Now they’re self-serve, AI augmented. So, again, my summary is they haven’t changed really, but are becoming more integrated, more smart and more self-service.
Mike Hrycyk (05:54):
Interesting. And I like what you said there, DJ, and it’s more focused for the developer experience. But one of the things that I’ve seen is that when we look at evolution from CI/CD to DevOps, there is a movement to be more inclusive of the team. So, there was a point when DevOps first started being a term, I don’t know, six, seven years ago, whatever it was, suddenly QA was there, and there were developers who were saying, “Oh yeah, QAs have to own this now.” And suddenly they’re trying to script together these things, and QA were all pulling out their hair and being afraid of it. And then there was also a throw-it-over-the-fence because this stuff really should belong to the IT folks, since they’re the ones who put these tools and systems together and own the environments. But one of the big movements for me, DevOps, was that all of those people were misunderstanding, and it’s about team ownership. Everyone should be able to do some of it, and the people who know things better do the things that they know better. It’s a very agile perspective. It’s like everyone should just own success and move it forward. And while the idea of the whole integration, I think, is developer-focused, I think what we’re seeing, with the evolution and the addition of AI, etc., is that the skills are broadening nicely, the way DevOps, in theory, was meant to be successful. Would you guys agree to that?
Arash Taheri (07:09):
Yep, absolutely.
Mike Hrycyk (07:11):
Cool. So, we’ve covered this. I’m just going to bring up the question, though. How have automation and AI been a part of the evolution we’ve been seeing in the last couple of years? Arash?
Arash Taheri (07:21):
I would say that they’re actually the two biggest forces that shape the evolution of DevOps, because DevOps can’t really be optimized without the existence of automation, and AI certainly enhances it. When we think about automation, early DevOps success came from automating repetitive manual tasks, right? Building and deployment of pipelines, infrastructure provisioning, regression testing, and whatnot. So, we can say that automation executes where AI actually decides to optimize it. What AI does, it can analyze code changes and decide which tests we actually have to run. It can detect anomalies, especially if you’re thinking about the financial sector, where I am, it can actually detect a lot of fraudulent activities just by just looking at the logs. Quickly, I mean, when you think about fraud and banking, every second counts. And again, AI kind of enhances that from that aspect. In summary, the way that I want to put it is automation gave DevOps speed and consistency, where AI gave it intelligence and kind of adaptability.
Mike Hrycyk (08:20):
Another thing to think about is that DevOps is really what gave us the movement of pushing to production multiple times a day, like real-time development. Without automation integrated with build and delivery, you just can’t have that. And I guess, AI is now slating into that. I haven’t seen that as much. It seems like part of the trend analysis and things that AI can do really would help with that, I think.
(08:44):
So, next question: how is or is AI reshaping traditional DevOps practices, especially in CI/CD and release management? DJ?
DJ Sicoli-Khull (08:55):
Yeah. AI is making the pipelines more adaptive instead of just static. So, there’s smarter test selections as Arash has mentioned previously, predictive failure detections in that pipeline. Also, there’s the auto-healing aspect. So, the recovery. In terms of the release management side of things, too, you could have risk-based deployments, like AI-driven analysis on those pipelines and releases. And also, like the rollback decisions based off of like real-time signals. So, if something fails in real time, AI will just understand exactly where the failure is and roll it back. Whereas before, during the manual process, you had to wait for it to fail. The whole system isn’t starting? Well, now you have to go through the logs, troubleshoot what’s going on, and then roll it back to a previous version, or you have a fail-safe that just triggers a rollback. But that’s how AI is reshaping the DevOps space in general.
Mike Hrycyk (09:47):
Man, I’m not sure I’m ready for AI to auto-rollback yet, but okay.
DJ Sicoli-Khull (09:52):
That’s fair enough.
Mike Hrycyk (09:53):
Arash, same question.
Arash Taheri (09:55):
Yeah. When we think about like traditionally CI/CD pipelines were kind of deterministic, right? You committed a code, and the pipeline runs all the tests. If everything passes, you go to the next stage, from I guess, pre-QA environment to QA to UAT2 production. It was pretty deterministic. Now, AI is actually making these pipelines smarter. For example, AI can enhance these pipelines to analyze code changes and determine again which tests you should actually run. That way, it kind of makes decisions for you. If you, for example, plug in the historical data that comes from different modules of your code base, if you’re having a release that doesn’t really impact other areas of your application, it can actually look into the new changes and tell you which set of tests you actually have to run, which does what? It increases the efficiency.
(10:47):
So, the impact is really on speed. But there is this trade-off between speed and quality, but AI kind of helps to reduce that trade-off by optimizing your test execution and predicting your risks. It can kind of predict what the upcoming risks are to mitigate and improve the decision accuracy. So, efficiency at the end of the day.
Mike Hrycyk (11:06):
Great. And an example that comes out of that for me is that when we were releasing multiple times a day, we’d run the automation, and when a test broke, you’d have to go back to a human, and the human would have to fix it. And I’m making this number up, but 50% of the time, the tests that broke were things that weren’t caught when the developer made changes, and that was going to change the effectiveness of the test or the way it was run. When we talk about self-healing, that 50%, most of those can be knocked off by the system understanding that, oh, this change shouldn’t have broken the test. Let’s fix the test. Because our goal was that you have to pass all the tests to go to production, or you have to figure out why that test isn’t working and fix it. And sometimes there was a real thing, and you had to go back and figure it out. But a lot of the time, it’s the code that changed the way it works, and you have to alter the test so that it still works. And so, auto-healing integrates with that, and I’m okay trusting AI to do that.
(11:57):
And this is where you get to put your thinking hats on and predict, and because this is now or in the future. When DevOps automation and AI come together. At its intersection, what new capabilities have become possible or you think will be possible soon that weren’t achievable before? And maybe we’ve answered this a bit, but we can tackle it. Arash, you can start.
Arash Taheri (12:20):
Yeah, for sure. You brought up a good point about self-healing systems just a minute ago. So, when these three main functions kind of intersect, obviously, they bring and introduce more capabilities. With automation and AI and platforms such as Kubernetes, for example, system can, again, detect anomalies in real time. It can automatically trigger rollbacks. If you push something into production, and this whole system worked together to kind of predict issues, it can automatically roll back. It can restart services or reroute traffic, for example. And also, you’re thinking about, again, when these capabilities come together, you can kind of introduce dynamic and adaptive testing. Like previously, test execution was static. We had a set of tests, let it be manual or automated. You always run the same thing. You always have the same set of tests every time, the same set of results every time. Now, AI can select what kind of tests you have to run based on the impact analysis that it provides for you. It can prioritize test scenarios based on the risks that are associated with risk scores, and it can also detect and isolate flaky tests. These are just a couple that I wanted to bring, and I’ll let DJ talk to the rest.
DJ Sicoli-Khull (13:31):
Thanks, Arash. Yeah, just to add on, the other thing that comes to mind is continuous optimization. So now with AI, we could do performance tuning without actually having human input on a given environment or system. So, that would make things much more obviously smoother, efficient, also quicker. Depending on the system, if we’re dealing with video games, for example, load times could also benefit from it. Now that we discussed previously, like the predictive quality from it, self-healing and more anonymous testing will come from it as well. So, everything is going to be maintained by the AI, the test generation. So, you have quicker responses and failures, just adding onto what Arash said.
(14:12):
It just opens the doors for more efficient development in the long run. So, we’re focusing our time less on the manual tests that we did in the past, on supporting and maintaining that pipeline. From my perspective, the automation side and dev side of things, we’re now focusing more on the development. A lot of stuff is hands-off. Even though they’re hands-off doesn’t mean that we still don’t need to understand how things are done.
Mike Hrycyk (14:37):
One of the key strategies in continuous deployment is using feature flags. And the concept is you don’t have to test as hard, you release the feature, and if there’s a problem, you could turn off the feature. You don’t have to do a full rollback; you can turn the feature off quickly. One of the things that I see AI, of an agentic nature, being able to do is spot the problem a lot faster and turn it off a lot faster. You don’t have to wait for a human, and there’s not a lot of risk in turning the feature flag off. That’s what it’s for. So, you can trust Agentic AI to say, “I’m seeing this trend. It’s a scary trend. We have this new feature. I can turn the feature off.” And so, I see that as a very big capability that will come out of it.
(15:15):
All right, DJ, I’m going to throw this question at you because you said these words: How does this intersection between DevOps and QA change the role of quality assurance? I.E., We’re moving from a traditional testing model to a more embedded continuous quality engineering model. What does that look like?
DJ Sicoli-Khull (15:31):
QA is no longer just a phase. Like before, it was development, then over to QA and then deployment. Now it becomes more of a system capability. So, whereas like old QA, we would do manual testing, we’d do end-of-the-cycle validation; essentially, QA would be the gatekeeper. With the new QA, which is like quality engineering, we’re embedded in the pipelines, we own the test architecture, and we focus on risk coverages and system health. We have more responsibility in the actual overall health of the pipeline. To me, it’s a key factor that this movement and growth and change, I should say, from the old way to the current QA standards allows us to be more integrated into the whole software development lifecycle, which allows us to be more knowledgeable in different areas. Whereas before, if you’re a manual QA, you weren’t really concerned with the pipeline, you’re just concerned with the actual built product. So, the changes are moving in the right direction, in my opinion. We’re becoming more unified as one whole cohesive unit rather than just being in different phases and having just silo responsibilities.
Mike Hrycyk (16:40):
Cool. Arash, anything to add?
Arash Taheri (16:43):
DJ mentioned everything pretty well. To summarize, I would say we’re kind of moving away from the testing phase into quality everywhere, right? As DJ mentioned, we used to finish development, give it to QA, and QA test it, whether in a sprint or a waterfall model, like agile waterfall. But in the DevOps model, the separation kind of dissolves, disappears, because the way that we’re looking at quality right now is we’re literally designing quality during the requirements phase. And then we’re building it into development, where DJ talked about quality engineering, which means, again, integrating quality from the get-go during the development phase and then starting to validate it throughout the whole pipeline process. Not only that, but we’re also monitoring it in production. So, it’s basically, we’re talking about deep integration into DevOps pipelines. Where QA used to be just a phase, now it’s throughout the entire development lifecycle.
Mike Hrycyk (17:35):
Alright. So, we talked at the start about DevOps tools. We’ve said they haven’t changed that much. So, looking to the future, looking at what’s to come and how AI is going to be part of it and how automation continues to be a part of it, how do DevOps tools need to change? How do we keep that intersection moving and growing and then continuing to build? What do they need to do to step into the AI future? I guess that may be a good way of putting it. Arash?
Arash Taheri (18:04):
I would say that yes, there has to be a DevOps tool that needs to be slightly changed or let’s just say modified in a way that we have to think about as evolution that goes from tools that used to or currently are executing workflows into platforms that kind of understand, predict, optimize and guide through those workflows. So, because traditionally DevOps tools were designed to execute tasks. You know, run builds, execute tests, deploy the code to different environments, and do software delivery to production deployment. So, for example, instead of just running the pipelines, tools should recommend which pipeline path we should take. Instead of just reporting failures, they should also do our root cause analysis and figure out what the problem actually is. So, technically, the way that I want to rephrase it is that tools need to embed AI as a first-class capability, not just thinking about it as an add-on. It has to be a first-class capability that’s embedded into the system.
Mike Hrycyk (19:04):
Yeah. DJ, anything to add?
DJ Sicoli-Khull (19:07):
No, Arash pretty much nailed that. I don’t think we need more tools. We just need smarter abstractions. Platforms, in my opinion, will become more dominant, whereas the tools will become more – they won’t disappear, but they’ll just become invisible in the background of that whole process.
Mike Hrycyk (19:22):
Yeah. I mean, I think we need to see the tools embracing agentic AI better. Our build systems and our delivery systems are things that really lend themselves to the easy decisions that need to be made. I’ll just come back to the example I made about the feature flag. Right now, it would not be easy to tell Jenkins how to do what I described with the auto-turning off of the feature flag. So, let’s improve and not have to add on an entire other layer of tools to help it. Let’s make it so that Jenkins can help you just tell it. Let’s do this thing. Here’s your limits, here’s your thresholds, and away you go. I would like to see that.
(19:58):
Alright. How does combining DevOps automation and AI optimize the entire STLC [Software Testing Life Cycle], all the way from requirements through to production monitoring? Big question. You can give me a little answer if you want. DJ?
DJ Sicoli-Khull (20:12):
Sure. Let’s break it down. For requirements, AI will help refine and generate test scenarios. At the development level, like automation plus AI-assisted coding validation, is there. Testing is continuous, it’s automated, and it’s intelligent. At the deployment aspect of it, you have risk-based and adaptive releases. At the production level, you also have observability plus AI-driven insights into it. So, that’s how AI, automation, and DevOps will be optimized in the entire STLC, in my opinion. Just keep it short and sweet since it’s such a large area topic.
Mike Hrycyk (20:51):
Alright. Arash, go ahead.
Arash Taheri (20:53):
Yeah. It’s a very interesting and great question because my team actually, back in December, did a proof of concept through AI that actually showed the executives how much efficiency and improvement AI-assisted testing can bring to the entire organization throughout the software testing lifecycle. Because, as DJ mentioned, testing the whole STLC starts from getting good requirements. Now, if you think about at every single stage of testing, AI can enhance it. From the get-go, when the requirements are given to you, when you have an AI model, you feed the requirements to it, because this is all part of POC [Proof of Concept] that we did. Feed the requirements to it, and it actually generates test scenarios based on those requirements.
(21:34):
The next step is, okay, you’ll have the test cases, now you want to document them. Now, every single organization that I’ve been to, I’m sure they’re still the same thing. They have different standards, right? So, you feed that template or standard that you want to follow, and then you ask your model, now get these test scenarios and use the same template to spit out the test cases and build a test plan. It does that; we actually provided that. Now, the next step is to actually execute them. How do you want to execute them? Through automation, most likely. Now, the AI model that we built could actually look at every single test case and spit out an automation test script. Doesn’t matter how you want to do it, let it be Python, Java, C#, it generates the test cases. Then the next one is, okay, put it in a pipeline, execute it, and then report issues through Jira or whatever system that you’re using. All you have to do is to plug it in and integrate them together. Send reports.
(22:24):
So, when you think about it at every stage of the software testing lifecycle, AI can definitely introduce a lot of efficiency. So, we can have faster test cycles and releases, we can detect defects a lot earlier in the process, obviously reducing manual effort, and we can have predictive insights as we talked about it. So, again, AI, there is nothing AI cannot provide as an efficiency or improvement throughout a software testing lifecycle.
Mike Hrycyk (22:50):
Here’s what I’d like to see in ten years, five years, whatever: monitoring sees something happening in the interactions coming from customers and in public. And it’s not sure if that’s good or bad; it’s a flag. It’s able to spin up an environment, a Kubernetes instance that mimics production. It’s able to pick a selected set of tests. It can run them and get a response that says, “No, it’s working fine.” And then decide what to do. Maybe leave it to grow some longer, maybe involve a human, but it’s that from a monitoring response, deciding that it should do something, not being sure, but being smart enough to play a set of tests. But for all we know that could be next year. AI is moving so fast that I don’t know when it’s coming, but I think that would be really powerful, and I’d like to see that.
(23:41):
Alright. This is our wrap-up question for this talk. What are the biggest challenges organizations face when they’re trying to integrate DevOps, automation, and AI? DJ?
DJ Sicoli-Khull (23:52):
This could be a hot topic question. Depends on who you ask that. But to me, it’s like the culture over technology. Where it is teams are still siloed. There’s resistance to change because we know people are set in their ways. They like habit. They like what they know. And some folks are afraid of change. They’re uncomfortable. Another thing I could see is adding too many tools. There’s no strategy behind it. So, we need to find a strategy that will work for the general scope of the organization, but then at each level, you could break it down. Each department could refine that.
(24:26):
Another biggest challenge that’s come to mind is poor automation foundations. So, if you don’t have a strong automation foundation, the whole life cycle is not going to provide the results that you require. In my opinion, you always have to have good foundations, starting from testing all the way to the deployment, all the way to the actual development of the product. A lot of organizations don’t have the proper foundation set in place. Mind you, all separate, they might do wonderful jobs, but hooked in together, it’s not quite there yet. So, there’s some learning curves there.
(24:57):
Another thing that comes to mind is the misuse of actual AI. People treat AI as a magical solution and answer to solve all. AI is not the smartest thing out there. It knows about everything slightly, but it’s still learning, it’s still adapting. It makes us more effective in our day-to-day jobs, but you still have to know what the exact question is to prompt it to give you the correct answer. It doesn’t give you the correct answer 99% of the time.
Mike Hrycyk (25:24):
Alright, Arash.
Arash Taheri (25:25):
Thanks a lot, DJ. It was a very comprehensive answer. I agree with DJ. Actually, one of the biggest ones is the cultural resistance and the organizational silos that exist. Because when you think about it, DevOps originally required breaking silos between different work functions: QAs, devs, ops. Now, on top of that, we’re adding automation engineers, we’re adding data scientists, AI teams, and capabilities. So, if organizations are still in silos, integration becomes way more difficult. A lot of teams may resist trusting AI decisions. And that I’ve seen it in my own organization or any organization that has a lot of regulations around it. Speaking of, for example, government agencies, the financial sector, and healthcare organizations. So, data ownership becomes, again, very difficult to navigate through AI.
(26:12):
The other one is, again, data quality and availability. That’s something that kind of DJ also spoke about because AI is pretty much as good as the data that we feed into it. Many organizations lack clean and historical data or a consistent matrix. Or even proper observability. And also another big challenge is the skill gap. I’ve seen a lot of organizations that are actually kind of mitigating that portion of the risk very well, where they’re saying that, okay, everybody, they’re actually training their staff, and they’re saying that everyone should use X percent of their work through AI, which means that – and they’re monitoring you. If you’re not actually applying AI to finish your coding, testing, whatever, I don’t want to say you get penalized, but you are being tracked because they want to make sure people kind of treat that as their day-to-day activity to kind of mitigate that risk because that skill gap has to be narrowed down very quickly.
(26:59):
And also, the other one is that everyone talks about it, again, trust. Do we need another AI to test the AI that we’re building or using? So, these are some of the main challenges that I faced myself, my colleagues in different organizations, some of the common ones.
Mike Hrycyk (27:13):
Agreed. Yesterday, I was talking to a person from a multinational SI solution provider, with over a hundred thousand employees, and AI familiarity is so important to them that they’re also tracking how much people are using AI, and it’s part of your performance metric.
(27:29):
One of the things I’ve been thinking about that we don’t talk about too much is fear-based decision-making, which, to me, doesn’t mean you’re just not going to do it. What it means to me is when people look at it, when they look at the idea of integrating AI into DevOps or the DevOps journey, that they say, “Oh, this is too much. This is too big. Let’s do this tiny little piece.” And that’s valid. That’s a good way to get started. But if you do that too much, you don’t get the value that we’ve talked about getting. And if you don’t get the value, you don’t get engagement. You have to be willing to discuss those decisions so that you pick the right scope. So, maybe it’s not too much risk, but at least it’s going to provide enough value.
(28:09):
Alright, I lied. I’m going to ask one more question. This just popped out. Where do you think it’s essential to have the human-in-the-loop piece in the DevOps, automation, and AI interaction? What should we not give away too quickly, DJ?
DJ Sicoli-Khull (28:23):
That’s a very good question. I think realistic to me is the push to production. Even though, yes, the majority of systems I’ve worked on, after they pass a certain quality gate, it gets automatically pushed to production. But there’s always an intermediate environment where the builds get deployed to, it sits there, and then at a scheduled time, it happens, and stuff gets deployed, triggered by someone, but it’s done automatically for you with the click of a button. Having that, I think right now, where we are with AI and the technologies, I don’t think it’s quite there yet to be smart enough to handle the full deployment. I’m perfectly fine with pulling up to UAT automatically and having AI control all that. But to real systems, I feel like let’s kind of hold off, like you mentioned earlier, can you really trust it right now? To me, I don’t think we’re quite there yet.
Mike Hrycyk (29:17):
Well, it makes me happy that you’re not too gung-ho, especially given the projects that you’re working on.
DJ Sicoli-Khull (29:21):
That’s true.
Mike Hrycyk (29:23):
Arash, same question. Where’s the human-in-the-loop still necessary?
Arash Taheri (29:27):
Absolutely. I mean, DJ mentioned exactly what I was going to mention. And the reason is I’m actually one of the victims or clients of this whole system, when we say that we have to have a human monitoring what’s getting pushed into production, because again, I am in a financial area where it’s heavily regulated. We have SLAs [Service Level Agreement] with Interac with a lot of different third parties. So, even our releases to production can’t happen anytime we want, right? It has to be a set time slot where our clients are aware, where third parties are aware, so that if something goes south, we get notified quickly. Having said that, there are a lot of organizations who are having continuous deployment and delivery twenty-four-seven, which is amazing. I mean, it has to exist, but adding the AI element in the loop, there has to be definitely a human who looks after it because again, myself, I can’t trust it 100%.
(30:20):
Definitely, we can trust it, definitely adds a ton of efficiency, but are we in a stage where we can absolutely trust it, close our eyes and just basically ship everything to production to AI? I don’t see it. So, that’s where we definitely need to keep the human in the loop.
Mike Hrycyk (30:33):
Alright. So, thank you to our panel for joining us for a really great discussion about the intersection of DevOps, automation, and AI. And thanks to our listeners for tuning in. I think this is a great conversation. It wasn’t meant at the start to be just an AI conversation, but AI is everywhere, and it’s a really big part of the intersection. So, I think this was a great conversation. It’s the right time to have it.
(30:52):
If you had anything you’d like to add to our conversation, we’d love to hear your feedback, comments, and questions. You can find us @PLATO Testing on LinkedIn and Facebook or on our website. You can find links to all of our social media and website on the episode description. And if anyone out there wants to join in on one of our podcast chats or has a topic that they’d like us to cover, please reach out. If you are enjoying listening to our technology-focused podcast, we’d love it if you could rate and review PLATO Panel Talks on whatever platform you’re listening on. Thank you again for listening, and we’ll talk to you again next time!