Your competition is going to production in 5 minutes

[Marko] (0:03 - 0:11)

When you start optimizing parts of the process with the means of AI or automation, you are not actually getting any better.

[Pinja] (0:14 - 1:35)

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development. Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

Hello and welcome back to the DevOps Sauna. We've talked about AI quite a bit. We’ve talked about the feedback loops that are getting shorter.

We’ve talked about how AI has transformed the whole software development lifecycle. But one question to start this with. If you think about how long it takes right now for your organization to take an idea and take that into value, how long does it take?

So we have a couple of steps here. So we identify the idea or the need. We create some requirements and the documentation.

Somebody has to prioritize this as well. Okay, then in comes R&D. That creates a feature.

And then comes testing. Security gets involved. Eventually that's deployed and we get the value out of it.

But what if we claimed that this could actually take five minutes and not just the five minutes to write this code in the age of agentic AI. To talk about this subject today with me is our very own Eficode CTO, Marko Klemetti. Welcome, Marko.

[Marko] (1:35 - 1:35)

Thank you.

[Pinja] (1:36 - 1:47)

Good. So five minutes sounds very short. Are you for real with this?

Where is this coming from? And is this literal? Is this something aspirational?

Or are we just being provocative with this one?

[Marko] (1:47 - 3:23)

I think the key concept here is that 20 years ago when I started at Eficode, continuous integration was a big thing. And in continuous integration, the idea is that the code changes that developers create are integrated continuously. So every time a developer makes a change to the code, synchronizes it with everybody, it's integrated automatically.

So there's build and testing and different automated stages. The idea was back then, 20 years ago, that there would be as short a feedback cycle as possible. The concept was when you make a commit, synchronize it and go grab a cup of coffee, you come back and you see either red or green.

And if you see red, you go back, you fix what was broken. And if you see green, you can move forward with the next change of code. And picking up the cup of coffee roughly takes five minutes.

So the continuous integration concept was originally five minutes. And as you introduced, it definitely has to do with code, had to do with code. But now today, in the AI era, I really see that organizations should be a bit more forward looking.

And when you start looking at what AI enables for the organizations, not only in the software development, but in all of the other phases as well, I believe that we can start talking about the five minute loop, not only for the developer feedback, but for the whole organizational feedback. So to answer your question about the utopia, I think for most of the organizations, it's definitely utopia.

[Pinja] (3:23 - 3:53)

But then if we think of models, any kind of model, we've had Scrum as a model. We've been implementing DevOps practices. Let's take SAFe as an example as well.

That is aspirational for many organizations. But now technology has changed quite a bit in the past couple of years. So actually going into a five minute loop might not be utopia for many organizations.

So what are the changes in technology that you've seen in the past couple of years that has made this possible for some of the organizations?

[Marko] (3:54 - 4:52)

So usually when you start looking at new ideas and new ideas applied in a traditional place, you go and look at the fresh organizations, the new organizations, the startups. And if we go to the startup scene and we start looking at how new organizations would do software development, it looks quite a bit different to how traditional organizations are doing it. And if we look at Agile or Lean or SAFe or similar practices, they have never even considered that you could go from idea to value in five minutes.

Instead, you have lots of manual steps, handovers, quality gates, manual discussions happening behind the software development life cycle. What I want to challenge the organizations with is that if you conceptually start looking at five minutes, you're anchoring the aspiration into a whole new level.

[Pinja] (4:53 - 5:13)

Yeah. And that's something that we see the frontier doing right now. Everybody can go on LinkedIn and see what somebody has been doing with their agents and agents talking to agents.

So how can we benchmark this at the moment? So what are the best organizations doing? What are they able to do at the moment in terms of going towards the five minute loop?

[Marko] (5:14 - 6:39)

Yeah. Interestingly, a big part of the so-called magnificent seven organizations have been able to do similar cycles already in the past, mostly automating the process from changes into the deployed features or features for customers as a new value. What I see that organizations are slightly lacking with is the prioritization requirements and documentation.

So traditional organizations tend to have this kind of prioritization and requirement setting separated from the R&D organization. And even if it was part of the R&D organization, it's usually still different people. We have roles such as project manager, product owners, Scrum master, lead architect that have been created as human loop, as human communication layer to understand what needs to be done and how.

And now suddenly, if we define everything correctly and use the means of AI to make it good enough, in a sense, the process, we can start looking at more aspirational levels of automation within not only parts of the software development lifecycle, like development or testing, or even parts of the security, but holistically, the whole software development lifecycle, as you said, from idea all the way to value.

[Pinja] (6:40 - 6:59)

And that's now a very interesting part when we look at how different parts of the organizations are actually working together. Isn't that the whole thing anyway? We've always, as you say, tried to minimize the loop time.

We've always tried to minimize how much feedback we get. But even back to, let's take Toyota and the lean practice back in the day.

[Marko] (7:00 - 9:26)

Yes. Yeah, exactly right. And feedback loops are everything.

And now we're talking about the software development ultimate feedback loop, where you actually can trace the whole organizational feedback in mere minutes. The point is, most organizations serve customers that don't even want features in five minutes. So if we look at our customers in the regulated, semi-regulated industries, they usually tend to have release cycles of three months.

And then, of course, there are hot fixes and patches on top. But still, the expected release cycles are very different from what they are talking about here with the five minute loop. However, I believe that organizations benefit quite a bit from looking at their current way of doing software development lifecycle and imagining all of these longer phases, which usually take time, like prioritization or then defining the documentation together with the whole team and moving the code from code to actual testing, maybe even manual testing in between before going into security and compliance teams, let alone the release and release cycles. And traditional organizations tend to excuse themselves from this inefficient way of operating by saying that these are steps that we simply cannot change or we cannot accelerate.

Whereas the competition are the organizations who have just natively decided that we'll have AI run everything for us. And I'll give you an example from the security point of view. So one of my favorite sites, Zero Day Clock, is looking at the vulnerabilities that are exposed on the internet.

And when there is a vulnerability publicly available, how long does it take until there is a public exploit that can be used to attack this vulnerability? And 2023, it was still 53 days. So if you deploy your software and there is a vulnerability found, roughly 53 days.

So the mean time between the vulnerability and exploit, it took for anyone to create a public exploit that can be used against that vulnerability. Now 2026, in the AI era, the time has gone down to eight hours.

[Pinja] (9:27 - 9:40)

So that's quite a difference in just three years. When I was expecting you to start this, well, back in the day, like the 90s, it took this amount of time, but you actually were talking about 2023, which was three years ago, right?

[Marko] (9:41 - 10:47)

Yeah, exactly. It's kind of the eve of AI, of course, Copilot had been, GitHub Copilot had been out for two years already, but 23 was the time when we had our first democratized LLMs, such as ChatGPT out. And kind of this concept of AI doing something for us instead of just assisting in it is a good benchmark, because then if we backtrack a few more years, it was in hundreds of days until there was a public exploit available to me.

And now that we're heading towards the eight hours, sub eight hours, if we look at any of the significant providers of public applications, either phone or operating system, your laptop, even your vehicle, if there is a vulnerability, we already know that in mere hours, there will be a public exploit available. This is of course a mean, but it still means that there is a high risk of exploitation, even months before traditionally these kinds of vulnerabilities would have been fixed.

[Pinja] (10:48 - 11:03)

Do we have any data on how fast can current organizations in their current way of working patch these kinds of vulnerabilities? Because if the other side is now going faster, what do we need to do? What is the current time?

Do we have any statistics on this?

[Marko] (11:04 - 11:25)

Yeah, actually CrowdStrike has published this global threat report 2026. And also IBM has created their cyber resilience reports. And they state that the average time to identify a container breach is still 276 days.

[Pinja] (11:25 - 11:26)

Wow. 

[Marko] (11:26 - 12:12)

Yeah. This matches quite well with the organizational way of thinking.

Like if we find a vulnerability and we go through the traditional software development life cycle or release process of the organization, it does take a long time. And that's one of the key reasons why we want to challenge the thinking in organizations to start looking at with, as I said, a different anchoring point, like different aspiration level all together, where if you start designing your organization into five minute loop, that essentially means that you have to start both automating and removing the different bottlenecks and quality checks and handovers in the process.

[Pinja] (12:12 - 13:15)

There are a couple of elements here that this makes me think about. So there's, of course, we need to move fast because there is a vulnerability. It might even be that, yes, you're in a regulated industry, you work in the finance sector, and yes, we need to fix this as fast as we can.

But then there's also the other element. This is something that I've encountered with a lot of customers when they say that, well, our customers don't want this to be pushed into their products. Do I want five new features or releases on my phone, updates on my phone, on a daily basis?

I do not. But then we need to figure out the CI/CD pipeline, of course, it's not about whether we push it onto the customers, but do we have something that we can provide the feedback loop on the value internally as well? So yes, it's always a business decision to go and release towards the customer.

But we need to also think about the so-called internal releases, which we talked about a couple of years ago with many of our customers. Do you actually deploy? And then do you get the feedback loop out of that?

So that's also the kind of angle that I would like to challenge some of the organizations who say that, well, we just can't do it.

[Marko] (13:15 - 14:29)

Yeah, exactly. And that's one of the key thoughts behind DevOps, which was born slightly after continuous integration, continuous deployment becoming this kind of mainstream thinking in modern organizations. And I still think that one of the key thoughts behind DevOps was separating these two words, which is a delivery and a release.

And continuous delivery, continuous deployment creates a difference from agile, the traditional agile, where you create new features. Yes, but most often you just shelf the new features until they're released. Whereas in continuous deployment, you create a flow where these new features are actually deployed all the way to the production environment.

They just might not be visible to the users or the customers of the service. And then there is a whole industry behind what's called feature toggles or feature switches, like where you turn on the features as part of a release as a different business-based decision instead of the delivery or software development capability decision.

[Pinja] (14:30 - 14:51)

So I guess to summarize this part of the conversation is that even if you feel that you don't want to get part of the FOMO, that we're not going fast enough, maybe there might actually be a reason to start the road towards maybe not a five-minute loop, but maybe going down from hundreds of days of being able to respond to an incident.

[Marko] (14:51 - 16:40)

Yeah, and if you look at, for example, Volkswagen, when they started creating the ID vehicles, they created a whole different organization behind that called CARIAD. And the idea of CARIAD was to kind of rip out of the organization the culture of new creation, which means that when you start afresh, you can leave some of the legacy behind and start from new tooling, new processes, fresh thinking, and maybe a more, I use agile in the sense of really being an agile thinker in the organization. And most organizations, even the biggest organizations, have these kinds of ventures within their organization already today.

That's part of what's called developer experience and platform engineering that you're able to learn from the best within the organization. And I started with this startup thinking, like, let's go and see how the startups do this. But you can actually start a startup within a bigger organization as well to show what is possible and what is not possible with the current process and tooling.

If you start a whole new product as a, let's say, a spinoff or an internal tool, and you try to create it following this five-minute concept, you start seeing that this is where it took a week for us to advance. But how about if we get the, like, our policies correct or we get these mandatory things set with AI, probably we can skip this two weeks waiting time. And then when you start creating this aspiration of five minutes, you can really start applying the learnings from there into the organization or the bigger organization processes.

[Pinja] (16:41 - 17:08)

Yeah. That's something we do a lot with our customers, to make it visible. Where are you actually spending your time right now?

It's just a very simple value stream mapping. We still have organizations who say, well, part of the process is to send this email to Jack's email, to his inbox, right? So basically, we can speed it off in many ways, even though the first result is not five minutes, right?

That is not, of course, the main goal here, is it?

[Marko] (17:09 - 18:06)

No, absolutely not. And that's kind of the point. But I'll give you an example of what trying to get to the five minutes, what would it mean, for example, with the discussion with the security team?

Most organizations have some sort of security and compliance before you can go to a production environment. Before that, you'll be living in this, some sort of a staging, testing, pre-production environment. What if, instead of just sending the change for security and compliance, you create a common language between security and compliance on what they are actually requiring from you as an R&D organization to produce so that the security checks would go through?

And once you know that you've created the common language, you actually start applying both processes, but also AI tooling into doing this pre-security scanning by the security organization mandates in the software development phase.

[Pinja] (18:06 - 18:09)

So basically, shifting left once again, right?

[Marko] (18:09 - 18:45)

Essentially, shifting left, yes. But even more than just shifting left is building this vocabulary across the software development lifecycle. So some of the things might still happen on the right side of the process loop, but if it's pre-prepared and you know that, let's say, 95% of these changes are something that you've verified already because you can use, let's say, an AI tool for that, or you have automation that you've put in place to do that, you actually, in the security phase, just push red or green button.

[Pinja] (18:45 - 19:11)

Yeah. And that's one of the ways we can go and prepare our organizations for this shorter loop. What else does this require from an organization?

If somebody, let's take, an organization in a financial industry, a heavily regulated, usually more traditional ones, where do they start from actually getting this? Do we start looking into some AI strategies, some kind of models? Where do we start?

[Marko] (19:11 - 21:25)

Yeah, in all honesty, most organizations have already started and are already on the way. So there is a board level strategy on both AI implementation and R&D effectiveness, whatever it means for the organization. The way I encourage organizations to start is to build prototypes within the organization.

And this could mean, for example, a startup-ish product that is created with the new way of working and then applying these learnings into the bigger organizational products. We use this AI adoption model to map organizations and their maturity in their AI capabilities. And the interesting part of this AI adoption model is that the assistance agents and multi-agents that most organizations are today applying in the organization, they are trying to only enhance the existing business processes the way the organization already works.

And this is where I see most organizations going wrong. They kind of build, so what I would call, legacy AI. So trying to build efficiency of the current organization and the current organizational processes.

But the actual benefits come from the business transformation, which means that the organization is brave enough to start looking at not how does AI enhance the current processes and the current way of working, but how do we actually change the way we work because we're enabled by something that's in some cases equally smart as we humans are, but is just able to process over and over with massive amounts of information. And kind of this business transformation for me is where the five-minute loop steps in.

So the organization can really start looking for a target that seemed completely impossible before and applying practices and tools that enable them to work in a more efficient way when you look at it as a pipeline through the whole R&D organization all the way into customer value.

[Pinja] (21:26 - 21:46)

And I see many organizations start with this, maybe a workshop with the agents and actually thinking, okay, I have a repetitive task in front of me, where can I apply an agent that could take away this repetitive task from me and help me with this? But as you say, this is part of the creating the legacy AI process and legacy AI organization, right?

[Marko] (21:46 - 23:16)

Yeah, we've done, I think we've now somewhere around 350 different workshops, hackathons, tool adoptions across different organizations that we tend to see the same trend is the buy-in happens only with the group of people who have been involved in this particular project. But organizations, when they start into changing how they work, they really need to have not only a connection through the organization, but also horizontally looking at when we apply this, what is the implication for the whole process left and right of us? So once again, I'll give a simple example.

If the business part of the organization is creating requirements for a new application, the requirements probably could be auto developed to an extent by some sort of AI automation. And many of the big organizations have already taken this into use. So already from the requirements, they create prototypes based on the requirements only.

The prototypes might never end up in a production environment, but it enriches the communication between the people who are responsible for developing or creating this software and those who try to define what needs to be done. And that already removes one step between which usually might take literally weeks.

[Pinja] (23:16 - 23:45)

Yeah, and that's something we've talked about hackathons internally as well. But now bringing that maybe a little bit of like a hackathon or pretotyping mentality with the power that AI is giving us is actually a lot faster. We don't have to just have this, hey, let's have a quarterly hackathon or a prototyping session, but it can actually be part of their process.

And I think this sounds like it is actually changing the role and the value in a very significant way right now.

[Marko] (23:45 - 25:50)

Yeah. And as you said, adding to the existing process, it might mean that that's the new process. I still think that organizations with developer teams are not going to see lead architects, product owners, or project managers anymore.

It will be one person. Also, I don't believe in eight person teams in the future, because then the slowest part of the software development life cycle will be inter-team communication. So building an understanding between the humans where AI can actually do the understanding in mere seconds, which probably means that the organizations will move towards the direction where there will be roughly three person teams.

They will be working on individual full software features or even applications. And this old concept of continuous integration becomes an application integration or application ecosystem integration, where the decision will happen on the level of these are the applications or full features that we will release today because they are ready. We've verified that they've been integrated into the application ecosystem.

And then that team can move forward with the next applications or full features. Whereas now we've been thinking, if you look at traditional SAFe organizations, they literally might have a month of release trains going on during which time we try to map out which features we add on the train and which ones are released. Whereas literally these kinds of decisions can happen on an hourly basis in an organization that has just decided that we give a full freedom to the developer teams and we add the layers of verification using AI and some very, very mild level of manual approval on the code review, testing, compliance, security, which has been all pre-prepped by automation.

[Pinja] (25:52 - 26:34)

Even before this current age of AI, when we're talking about autonomy for a development team, we've been talking about giving them or enabling them to make the decisions that they know the best. So again, we can now even go further with that. The context is here.

Here's your why. We have a product intent that is visible for everybody and has been communicated. It is context-wise, it is available to the AI tools that we're using.

So it doesn't have to be all you need to go and look at it every single time, but rather the agents are actually able to fetch it every single time automatically. So it makes it even faster because yes, humans are the slowest part of this loop, right?

[Marko] (26:34 - 28:02)

Yeah, yeah. And still you and I are talking about software development like it would exist in two years time. How do we, like I see that the new models are so good at creating software that there will be a higher level of abstraction on how we define what we want to get done.

And today, of course, like we work together with Atlassian on requirements and documentation. Most of our customers are using those kinds of tools across the organization. It might actually mean that we have very well-defined requirements and documentation of the application.

And then there's just an engine somewhere that spits out a working software for it. Having gone through the five minute loop of software development and test creation, security and compliance based on some rules set and automation, and then the delivery preparation all the way to then the telemetry observability and service management. In all honesty, I think this is something that will happen relatively soon for a certain set of applications.

So simple browser applications, mobile applications and similar. We only define the highest level of abstraction of these applications using natural language and some sort of an extension of that. And the code itself will become irrelevant.

[Pinja] (28:04 - 28:39)

And now if we start thinking about what did we start to talk about in the beginning of this conversation? So yes, there's a five minute loop. Yes, there are some organizations who are able to do this right now.

And this is also an encouragement to the ones who are not doing it at the moment, but are also saying that we cannot go in that direction. But like some of the perks, we've talked about this during this conversation. So of course, speed, if your competitors are doing it, you're going to be left behind, but also the advantage of being adaptable to changes.

So any other words of encouragement that we can send to organizations that are now kind of on the fence with this one?

[Marko] (28:40 - 30:38)

Yeah, a colleague of mine gave me this nice thought experiment. If we see a habitable planet, let's say 10 light years away, and today we could travel there with 0.1 light speed, it would take us 100 years to get there. And if we send the probe now, we know in 100 years it will be there.

But what if in 30 years time, we come up with a mechanism that can drive 0.5 light speed, so half the light speed. The probe sent 30 years earlier will arrive on a planet that's probably already inhabited. And this is exactly what's happening with AI today.

So if we start a new venture today, and we fix it to let's say two years, no matter what the application, let's take a big integrated systems application so that it's complex enough, two years. And then AI advances in the next six months in such a way that we can actually deliver this kind of an application in three months. We're going to be ready in production, customer use, when the other project is still trying to finish what they started way earlier.

And this is how I want the listeners to think of the AI transformation and the pace at which it's happening. Every day there might be a fundamental change in the way that software is created, or a level of automation is applied. And if the organization isn't prepared to take that into use, they will lose in the market. And when I say prepared to take into use, I really do mean that does the organizational process enable going faster or not.

And today, almost 100% of regulated, semi-regulated organizations would be in the not category.

[Pinja] (30:39 - 31:09)

That's what I would also vouch for in thinking about, as you say, the readiness. It's not that you already have it, but we just got yesterday, a couple of days ago, we were getting new models, and we're getting new tools that are going to be used in a whole different way. So when that comes, it's about organizational agility once again.

So it's not just about, well, can we do two-week sprints? That's not what organizational agility is about, but can we actually take a new thing, implement it, and get better at it?

[Marko] (31:09 - 32:07)

Exactly right. And are there old things that are blocking us from getting the benefit out of it? In many of the keynotes I've been giving, I've said that most R&D organizations spend only 5% developing code.

95% of the time and effort is going somewhere else. So even if you now in the AI era removed the 5% from the equation, which sounds crazy, you still would have improved as an organization only by 5%. And that's kind of the concept that organizations I see simply do not realize as of yet, is that when you start optimizing parts of the process with the means of AI or automation, you are not actually getting any better.

The only way to get better is to build some sort of a pipeline and some sort of a mapping into the organization, which enables you to aspire to the so-called five-minute loop.

[Pinja] (32:08 - 32:29)

And I think on that note, we're going to end this discussion. I think, Marko, you and I, we could have continued for another one, two, three episodes more on this, but thank you so much for joining me here today. 

[Marko] (32:18 - 32:18)

Thank you.

[Pinja] (32:18 - 32:29)

All right. And thank you, everybody, for tuning in, and we'll see you in the sauna next time. We'll now tell you a little bit about who we are.

[Marko] (32:29 - 32:58)

My name is Marko. I'm the CTO of Eficode, already been there for 20 years, seeing the world change from the traditional automation of software development into the AI-driven world of automated software development lifecycle. I'm a nerd at heart, so I still do software development myself.

And at the same time, I sit on the C-level discussions almost daily with our customers, advising them on how organizations should change.

[Pinja] (32:58 - 33:05)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode. Thanks for tuning in. We'll catch you next time.