How to buy an AI tool: What to know before you invest

[Kalle] (0:03 - 0:09)

Hey, sometimes you just need to buy the tool and get it into use, but sometimes you can't even predict the use cases.

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

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. Previously in this podcast, we have discussed at many lengths how an organization should start their transformation. And we have said that it should not come from a tool selection, it should come from the actual needs of an organization.

But at some point, eventually, the decision of what tooling you should be using, if you're actually transforming and transitioning to another tooling set, that needs to be done. So today we're going to be talking about now what? So you need to buy the tools.

What do you need to do? And to join me in this discussion, we have our Eficode Field CTO, Kalle Sirkesalo. Hey, Kalle.

Welcome.

[Kalle] (1:17 - 1:59)

Hello. So I decided to join here with Pinja or actually proposed the topic because I've been working with customers around purchasing tools for 12 years. I've been both selling tools and buying tools lately.

So I've been helping customers on the procurement part and figuring out like, what is the why? Like, why are we doing this? What are the use cases?

What are the NFRs? What are we actually requiring to support the transformation side? The big recommendation before this discussion is, of course, follow the previous discussion which we had that actually explained why you should transform first and why you should bring the tools afterwards.

Because otherwise, this is going to be something that you can follow and then you can buy the wrong tool.

[Pinja] (1:59 - 1:59)

Yeah.

[Kalle] (2:00 - 2:03)

So we're going to be talking heavily about the tool purchase today.

[Pinja] (2:03 - 2:37)

We will be. The previous conversation about the Why of the transformation, you can find it with myself and Jess Fraser-Darling from our previous episodes on our podcast list. But as you say, we're kind of starting with the assumption that the organization already knows why they're changing.

And then, of course, the follow-up question is, what needs to change? Obviously. And then the how.

How do they make the change happen? So transforming this into a tool conversation. What is the question or the questions that the organization needs to ask themselves when they start thinking about the tooling?

[Kalle] (2:37 - 4:20)

So theoretically, really simple. It's an exo game that you play, because you're going to look at the use cases that you have. You're going to have to list down what are the things that the tool needs to support?

What are the critical paths that we're going to have? What are the business needs that we have? And what are the topics that we're going to be needing?

So it's again like looking at, for example, version control. We're going to need a GIT protocol. We're going to want pull requests.

We're going to control who's going to approve those pull requests. That's the technical use case that we want. Then we have the NFRs.

Like, okay, we want out of the thousand requests, 99.9% go through. So we want 10 failing maximum. We want to have these kinds of things that we can confirm that these are the things that we are okay with the tool doing.

We want to look at our security requirements. What are our regulations, security, sovereignty? I'm not going to go into detail about what, how do you map those.

Because we have an episode about that earlier, but you need to kind of map out those sovereignty requirements in there to figure out, can I go to the cloud? Because that's cheaper. Or do I need to run it on-premise and actually figure out the on-premise requirements that we have?

Because then you start talking about operational requirements, security requirements, and so on, on a self-host model versus cloud model. And both are important to take into account and think about, but both require topics. And this kind of creates this requirement that like, what capabilities do we need?

So it gets us to the point that like, what are the capabilities that the organization needs? Which then leads us to thinking about what we should be buying? So what are the tools that even give us this capability?

So let's talk about version control again, taking it simpler than AI, because AI is such a field of like, by the time we release this, there's 10 new tools.

[Pinja] (4:20 - 4:20)

Exactly.

[Kalle] (4:21 - 5:35)

So on the version control side, you're basically at GitLab, GitHub, Bitbucket in a big organization. So what should we buy? Like, what are we trying to do?

Are we looking to the future? Are we looking past? Are we looking on-premise?

Are we looking for sovereignty? Are we looking cloud first? Are we looking at startups coming in and integrating to our system?

Or are we looking at corporate governance controls? And the question then becomes, how do we make this good technology investment correctly? Because no matter what you do here, the technology investment is going to be a small part compared to your human investment.

So if you have a thousand people, and you say a thousand people take a day off during this tool, a day is a very little amount of time to run GitLab, GitHub, or, well, Bitbucket is pretty simple, but like, theoretically, Bitbucket also. So it becomes this thing that you are going to spend a thousand days learning a tool. And that's going to be a big cost to your organization, because it affects everybody using that tool.

And then after that, we come back to the point of how do we know if we actually delivered the value? So if we go back and we look at the capabilities that we estimated as needing, the transformation that we thought that we know, we can at least map those against, did we take this into use? So then we can at least prove, did we as an organization even think about it?

[Pinja] (5:36 - 6:37)

And this becomes a problem if the feedback loop is way too long, to be honest. If this is like a thousand workdays, it might actually be one workday, calendar-wise, for a thousand people. But can we actually have this hypothesis in the meanwhile during this process, like after this one day for a thousand people, can we prove something at this point in time and check back?

Are we doing the same thing? This is something, Kalle, you wrote on LinkedIn a couple of days ago. This was actually really fitting for this conversation, where you said that the AI native does not start with tooling, it starts with changing how the work flows.

And this is again, going back to what you just said, what are the capabilities that are needed? It's not maybe just about being AI native, but any other tool, as you say, it can be GitHub, GitLab. And is this a problem that we're solving?

And maybe also this question that I want to ask, do the organizations know that their current tool is not actually solving the problem already? Is there evidence? Are they collecting evidence that they could actually solve this by changing something else than the tool?

[Kalle] (6:38 - 8:56)

So the answer is kind of multifaceted, because it's always in consulting, it depends. Like, welcome to our life. I guess I need to print a t-shirt that just says, it depends, because I always start with that.

But based on our anecdotal evidence, based on the cases and discussions that we're having, customers are not measuring their tool performance, in honesty. Like many of our organizations are possibly getting some technical measurements out, like uptime, but they're not measuring, for example, pull requests, mean time to resolution, for example, or comparables. We're trying to guide them, and we're doing a lot of this, for example, with Atlassian’s DX or comparable tools, like Flow from AppFire and so on.

But the question becomes like, hey, are we changing our workflow? So the most common thing that we do is, we go and talk to a customer and they're like, we have this Bitbucket, it's arriving into end of life with their license, and we would need to decide between the cloud, cloud on-premise solution from Bitbucket, or GitHub or GitLab, because we need to now do a decision. And this leads to a conversation around, hey, you should change your workflow.

And they're like, no, no, no, no, we just want to change the tool. And this is what gets most of the organizations, like this is where the organizations get stuck. Like they go and buy a coding assistant, but they don't want to do any training.

Then they do a prompt training, but they forget that we are already in agentic development. They forget to create internal champions, and they forget the whole thing, that like those internal champions are supposed to champion workflow chains. And they skip all kinds of acceptable use guidelines, and then people are making their own web pages or own games with the company tokens, and they're wondering where the tokens go.

But your organization needs way more, because it needs to actually change how the work is being done. You're not supposed to be, as in AI terms, we call it meat proxy. You're supposed to actually be the person driving the business there.

You're supposed to think about the workflow, the needed work from the customer organization. And if you're not thinking about the things, if you're just pressing auto approve, you could just put a meat proxy in there or remove the meat proxy when I put the auto approval on, because you're gonna get the same result. So it's again, like you need to do it structurally well and organized and change the workflow.

But that is very difficult, and it requires the why, it requires knowing what are we changing to, and why did we make the decision to change to this tool?

[Pinja] (8:56 - 9:32)

And this is something a couple of weeks ago, I discussed in the previous podcast again with our CTO, Marko Klemetti, that many organizations they measure them, again, taking this from the AI world. So they measure this AI nativeness or AI maturity with just implementation rate. Well, we have the tools, we have implemented the GitHub, we have GitHub Copilot for our developers, but as you say, it doesn't change how the work is being done.

And did we already get the evidence that this was actually providing the value? Because if we're actually measuring token usage, is the same old saying that, will you get what you measure? Isn't that true?

[Kalle] (9:33 - 11:10)

Yeah, so most organizations that I talk to about AI system tools or AI agent tools or AI coding tools, they have 100% consumption on tokens, like their credits, tokens, whatever you call, implementation is always 100%. The problem is, then you ask them, like, then you ask like, what happens if we increase this number? And they're like, I don't know.

Like, they can't tell you what they would do if we would double the token count, for example. Can we, do we speed up more? And that creates the question, are you ready to buy?

Like, are you at a point where you understand why? Are you actually understanding what you are getting blocked at? I'm at the moment looking at one customer's AI reports and I'm like seeing, I can already tell, I'm gonna be writing it into today, hopefully, like, hey, your pull requests take two days to resolve.

You're gonna have no impact from AI if you're not putting it against the pull request, because you're at the moment looking at the problem that is not the problem that you're trying to solve. They're trying to put the AI tokens into use by making more lines of code or more merit requests or more pull requests. They're not, but at the same time, they're getting blocked by the pull request themselves.

They are trying to solve a wrong problem with the AI tokens at the moment. I have a model that I'm working with them, that I have, I like working every few, every month of day with them so that we're looking at their numbers and I'm working with their CTO and like, what are we actually tuning from those numbers or what are we measuring next month? And now I'm gonna go back to them and be like, okay, these are the teams, these are the people that we're gonna be going to.

Let's go and talk to them about these agents that we've created against the code reviewing. And we're gonna see next month, does it go up?

[Pinja] (11:10 - 11:16)

So have you defined together with this customer, what does better actually look like? Is that what you've been doing?

[Kalle] (11:16 - 11:56)

So the problem is they didn't have the metrics in place. So we defined first, what are the metrics? And we started by measuring, what we want to measure?

So that was last month. That was my last month with them. And now we came back one month later to look at measurements.

And now we're doing an actual tackling of the problem. So now we're looking at what we are trying to fix in the capability that they're having? So what is the capability that they're missing?

And in this case, it's code reviews being automated. They have an agent for it, but it's not enabled for every team. It's just in a few beta teams.

So we're testing it out and we're now running it upwards on those teams. It will consume more tokens, but it will save time because we have faster feedback loops.

[Pinja] (11:57 - 11:57)

That's nice, yeah.

[Kalle] (11:58 - 14:40)

Yeah, and it's again, like it enables us to think about the evidence itself. Like what are we trying to solve? In many customers, for example, this is the thing that you're not looking if you're just looking at one solution point.

You have to look at a multitude of solution points and try to find the bottleneck. And in this case, it's a pretty clear case, but in many places it's a clear case when you actually look at the pipeline. My favorite is Jev came out, which is like the way to do thinking models or like the decision models.

And you can really easily put that in place on a gap process. And anybody who knows me knows that I hate the gap process over everything in my life. And it comes from the fact that the gap process theoretically is about changing the approval board.

And its job is to find critical changes and prevent critical changes. But at the moment, how it works in most corporations is that you have this committee that doesn't know anything about the thing and you go and present to them a slide deck about what you're changing and can you go to production? But they have no idea what you're changing because they don't know the whole thing.

So it becomes a coin flip. So now if you would have these thinking models, we're gonna have an article coming out of this, very well written. You could put that thinking model in there first or the decision model.

And the decision model would say, this is a non-risky change, just do it. And we could get the standard change into use across the whole corporation very quickly. And that would create evidence that the current tool is not doing this.

And we could very well make it into a technology problem and we could solve that technology problem. And we could even see what the better looks like because we would get faster to production. We would have less problems in production.

And the people in the tower making that decision would only get the critical decisions on their hands and they could actually prevent stupid things happening. Because I'm not saying the whole process was created for preventing changes. It's there to actually evaluate really critical changes.

Like let's say that we change our payment APIs and we have external partners using those. That's how we build those things. But now they're making decisions like they're planning to change the schema in the background at the bottom of this database that they only use.

And you're like, why would this go to the gap process? They're planning to add disk space. I've seen these kinds of things going to the gap.

It shouldn't, it's a zero risk change. So these are the kinds of things that we can remove by technology, by procurement, by purchasing and doing correct agents. These are the things that we're doing with Eficode at the moment.

But you have to know where the problem is so that you can answer the why. You can answer, what are you buying? Because you could also just buy service now and get all of these tickets arriving and then have a few hundred people creaking around and being like, yes, yes, this is okay.

[Pinja] (14:41 - 15:09)

Those are very critical questions to go through. And if we assume that an organization has now gone through a couple of these decision points, like, okay, why are we doing this? What are we after?

How do we measure the value? So let's say they have now decided to buy GitHub Copilot for all of their developers. Many of the organizations already have.

So what are they actually buying with this purchase? Yeah, you're getting the licenses, but what else is there? I mean, it is not just the licenses that you're actually buying when you get it.

[Kalle] (15:09 - 17:26)

Yeah, and GitHub Copilot is really funny because you have to basically buy GitHub Enterprise with it to get all of the benefits out of it. Because you want the single sign-ons, you want the enterprise management, you want the audit trails. You don't want your data to be training AI most of the time with your source code.

So you're basically starting to buy a whole platform at that point. You're buying this whole thing for your version control. So now you're not actually buying just Copilot licenses, you're actually buying a way bigger thing.

So then the question becomes, okay, what is the ecosystem that we're living in? So I've done these toolchain analysis for like a hundred companies, and it's always about the ecosystem of your SDLC. What are the tools that we are using to operate in this?

What is the operational model inside this ecosystem of the SDLC? What do we actually remove from here? What are we integrating to?

What can we remove? How do we govern this whole platform there? Like, do we turn on all of the governance models, or do we want to just use the Copilot and accept that we're paying a certain amount for that and not using all of the features?

Sometimes we want to do that. It becomes this question of what are the things that we want to use? What's the way of working?

And we also have the whole thing. Okay, GitHub is owned by Microsoft. So what's our vendor relationship with them?

Because I've seen so many organizations where we end up in this conversation that like, we were planning to buy X, but our management has actually informed us that we're buying Y because Microsoft has purchased 30% of our stock, or we are very heavily reliant on Amazon, or we are a Google house, so we found these collaborations with Google, or our system is so big of a mess that Claude Code is the best because it integrates to our specific mess the best.

So you have these different things where you look at these different tools, where the vendor relationship might actually overpower all of the good things, or it might actually turn it into negative, for example, in some companies. I remember when the retail companies in Finland, for example, were very much against Amazon because they were afraid that Amazon would come and compete with them in their local area. So they were running most of the stuff in Azure at the time.

That has changed over time, but I remember these conversations where they were afraid of Amazon using that data. And it is again, like a valid question.

[Pinja] (17:26 - 18:13)

It is. So it comes with all these connections that maybe as a first thought, you might not be as an organization, you might not actually be thinking about, it's like, how do I govern this? So it might be simple workflows.

Not everything is possible to modify to your specific workflow or way of working. Let's say if we compare Atlassian's JSM, and you mentioned ServiceNow, there are many organizations who say that, well, JSM doesn't fit our needs because we want to do it this way. So if you take JSM instead, you need to modify the way you're working that comes with it.

In the same way as you say, well, there is an ecosystem that comes with, there's a platform that comes with GitHub Copilot, you need to have the enterprise licenses. So it's not just that, well, we're just gonna buy 500 GitHub licenses for our developers.

[Kalle] (18:14 - 19:50)

It's never about that. And it's like ServiceNow versus JSM is such a good example because you can't just buy one and replace the other. It's gonna be a change in your ways of working.

JSM is not ServiceNow, and ServiceNow is not JSM. Both are massive projects to incorporate into your organization. They're expensive in terms of comparing to Copilot licenses, for example.

So it becomes this question of how do we actually get the benefit out of buying that license and customizing it? It's the same as, if you buy Salesforce versus HubSpot, there is a very big difference between those two. Both are CRMs, both follow your customer data, but you don't want to just like, you can't just take one-to-one the process, or you can actually, but it's gonna be really bad if you do it.

So you really want to think about how you get the best out of this? And it also creates this question of like, do you want to avoid all of this vendor locking or like comparable? Because like I have customers that love vendor locking.

So they have gone to the Microsoft train 20 years ago and they're like, yeah, we're gonna be full on Microsoft. Everything works. It does, it's not the best, but everything works together because it's all Microsoft.

So if you look at Microsoft's Defender suite, for example, which is their security suite, if you take a piece out of it and put it in another tool, it's not that great. But if you're fully in the Microsoft Defender ecosystem, it just works like everything. You can track everything in the system everywhere immediately because it's focused on every data point that you have in your corporate network.

It has your authentication, authorizations, your logs, your management, your access points, and you can see the whole picture of the system.

[Pinja] (19:51 - 19:54)

The whole context network is basically built in.

[Kalle] (19:54 - 21:47)

Exactly. But if you remove the end devices, for example, what do you now have? You lost half of the points of data because you don't know where this data came from, from our end devices.

So if you had this end device tracking, you can really easily see that, okay, Kalle arrived from here and then his laptop did this stupid thing. It's very easy versus if you don't know it's my laptop, then you start figuring out where this IP came from? Who is this IP?

Who is this person? And then you have to cross-reference between systems. So you don't always want to avoid vendor locking, but then if you look at Eficode, for example, we are a small company originally.

We started with a very small company and then we procured six to seven companies in the between and we unified that into our system, which created a mess of an IT organization. Any time when you do that, we have been fixing it. Our IT is fantastic at fixing it, but it doesn't remove the fact that our best of the best tools are from a multitude of different sources originally, because we just took the really good working workflow and built it in use.

So we don't have this, like everything from Microsoft topic. We have everything from everywhere kind of thinking at the beginning. So now we have multi-tool selection.

So if we would take Microsoft scope out in use, it wouldn't have any context. So instead we go with something like Claude Code at the moment as our enterprise solution, because it can integrate to all of the different things that we have, because it's planned around integrating to all of those things. So again, you have to look at your enterprise architecture and compare that against the vendor locking, because sometimes you want to vendor lock in and sometimes you already have a mess, so you can't actually vendor lock in even.

And I'm not saying that our system is a mess, it's actually really good now, but it was a mess a few years ago when we started thinking about this topic. And like we started figuring, hey, we shouldn't buy every tool under the sun. We should actually have an opinion on tools entirely.

[Pinja] (21:48 - 22:51)

Yeah. And that's a really good example, because we're currently based in 10 different countries. And as you say, we've had multiple different organizations join us via acquisitions.

So if we think about this decision-making, we already discussed this very briefly earlier in this episode, that there are different kinds of needs. Of course, we need to look at the security. We need to look at, do we need to take into account sovereignty requirements, et cetera?

But then we also have different kinds of needs when we're trying to figure out the why and the what. So different parts of the organization have different kinds of problems to be solved. So let's take a CIO.

They need to standardize the tools and they want to be in cost control. We talked about the token prices and the token usage. So developers just don't want their life to be made miserable, basically.

And then there's security needs controls. How do we have this conversation in an organization? So who gets to decide and who should own this decision of a tool when there are different kinds of motives and needs in an organization?

[Kalle] (22:51 - 25:04)

I think it's also critical to understand the roles of these people. CIO is mostly a cost control role nowadays. The developer is mostly the end user.

So you collect the end use cases from there. Security, in a well-functioning organization, usually security doesn't care what tool you buy. They care, does it follow the security guidelines and policies that we've done?

If it doesn't, have we made a risk out of it? And does the risk read someone else's name than security's? Because again, security is about risk management, risk control, and risk avoidance when possible.

And risk mitigation, of course. So the question becomes, how do we actually cover those topics? And in my opinion, the decision should come from business.

So who is buying the thing is at the end of the day, the business that has to work with that topic. Because if we have one, let's take Eficode as an example. We have a tech unit, tech consulting unit, which has technological people.

We have very specific needs to deliver topics to our customers. If our IT decides everything that technology unit does to the customer, we're no longer delivering according to our business. So we have to follow the CIO, developer, security, and so on, of course.

But we have to be the ones making the decision because otherwise we are not enabled to do the business decisions. And this is why usually CTOs, for example, sit on top of some kind of business role. So they have an R&D unit, for example, under them or comparable so that they can actually make the business decisions that affect the technological journey of the company.

So the person who should own the decision is the business owner most of the time. There are decisions that should go higher because like, for example, if we're a Microsoft house and we want to buy a competitor product, like Google, for example, it should probably be a CEO or board decision at that point. But like, that's a very different question at the moment.

That's a strategy question at that point. But like, if it's a business tool for the business use cases, it should be the business owners doing the decision. If it's an operational framework for the organization, it should be the very top of management.

But that's, again, strategy versus operations. And usually we don't buy operational tools most of the time, or sorry, strategical tools most of the time. Usually we buy operational tools.

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

No, usually those kinds of decisions are not done on an annual basis. They're not done very, very lightly to migrate away as you say, let's now decide we're a Microsoft house. Let's now decide that we're a Google house because it's going to change the whole platform upon which we have our file system.

And everything that we use basically is built upon that decision.

[Kalle] (25:27 - 25:44)

It affects so many things because it affects your AI choice. It affects your integration choice. So it's massive where you actually manage your emails.

As funny as it is, it sounds the most stupid thing ever, but it's a strategic choice even though we don't think about it as such.

[Pinja] (25:44 - 25:58)

We might not think about it, but I know everybody has their own personal preference. First of all, myself, I do not like Outlook, but that's a personal preference. Is it like, as you say, it might not seem that deep, but it is actually a big decision.

[Kalle] (25:58 - 26:20)

Yeah, it's a decision. It's something where we compare options and capabilities, scenarios, requirements, products, whatever. It's how we come to these big decisions.

There's a reason why we have enterprise architects in enterprises. And it's not just politics. It might just look like politics, but it's not just politics.

It's about actually understanding why we did this? Why did we do this?

[Pinja] (26:20 - 26:30)

And maybe then you have to review the role of an enterprise architect if that is the only sole visible thing, is the politics. But usually it is not. As you say, it should not be.

[Kalle] (26:31 - 26:36)

We'll see. It might just be that AI agents are now also political if you try to do things with them.

[Pinja] (26:36 - 26:37)

No, that's true.

[Kalle] (26:37 - 26:53)

They will start making all kinds of political decisions where they don't trust other AI agents and start doing things again because they didn't trust it and so on. It's a weird word where we are thinking about, because we're training AI on human patterns, are we just training the bad patterns to those AIs?

[Pinja] (26:54 - 27:28)

It depends who you ask, I guess, depending on your lookup. So, hey, we have now come to the conclusion that, hey, there's somebody who needs to decide, depending on the decision level, there's somebody who owns the decision. So in the end, how do we actually compare these options against each other?

So we have our why, we have our what, we're thinking, we're comparing, like, yes, this is now impacting the core of our, let's say, connections if we go to GitHub versus GitLab and we have decision makers. So where do we start the path of comparing these options?

[Kalle] (27:28 - 28:55)

You start by defining basically scenarios. And the scenarios are basically outcomes, capabilities, requirements, and products together. So you make a scenario, for example, we have 500 developers moving to GitHub, how would that look like?

How would we do that during the day? And we test the platform ideology against that ideology. Like, what would it look like?

What would be the challenges that we're gonna face? Are we gonna get the benefits out of that? And how are we actually building the structure?

Like, what would our solution architecture description SAT document be? It's a very SAT document if you actually write one. The ideology being that, like, we build scenarios that we can then battle test on simulations or even build against to figure out would this be the useful tool.

And overall, if we look at the whole buying pattern, it becomes a very expensive process done right. Which reads to the fact that, like, if you look at the public sector, for example, and their procurement process, there's a reason why it costs so much because it's so heavy to try and buy something in a very structured manner and have it described fully. So it becomes like this thing where you try to get these different scenarios on the paper and then reality hits and most of those scenarios go to Traskan and you have to customize towards something else that you didn't know.

But you have to have outcomes, capabilities, requirements, and products defined so that you can actually somewhat know what is the scenario going to be and what is the end scenario that we want to be in. And then surprises happen.

[Pinja] (28:55 - 29:20)

They always do. But as we said, then we need to have the feedback loop, right? So of course, it might...

The worst case scenario, of course, is that we have just signed the deal for the licenses and we realized that this was the completely wrong decision for us. But in many cases, we realize that, okay, this is not the use case we're using it for. So maybe we divert, we get the feedback again, saying, is this the case?

Is it actually providing us the value and could we be using it in a different way?

[Kalle] (29:21 - 30:09)

Yeah, and it's also about, hey, sometimes you just need to buy the tool and get it into use. Sometimes you can't even predict the use cases because everything we said, sometimes it's not the thing. If you don't know how the organization is going to use the AI agents, just get some kind of AI tool into use and see how they use it.

Because sometimes they don't even know how they're going to use it. I know it sounds stupid after talking 30 minutes about buying tools, who's figuring things out, but sometimes you just have to go with, we know it's going to integrate, we have a plan how we're going to roll it out, but we don't actually know until we run it, what are people going to use it for? Because they don't know themselves.

So sometimes you just have to take a leap of faith in a specific context. It's rare, but sometimes that's the truth.

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

That's really, really good advice from actual real use cases. And I think on that note, I think we're going to end our episode with that. Kalle, thank you so much for joining me today.

[Kalle] (30:18 - 30:19)

Thank you.

[Pinja] (30:19 - 30:29)

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.

[Kalle] (30:29 - 30:56)

Hello, my name is Kalle Sirkesalo. I work as a field CTO in Eficode at the moment. I've been here for over a decade and I'm at the moment mainly focused on AI powered tooling, especially in the SDLC pipelines.

I'm building very stable platform engineering platforms and DevSecOps practices. And my biggest job is scaling CI/CD and SDLC in industrial and regulated industries.

[Pinja] (30:56 - 31:11)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode. Thanks for tuning in.

We'll catch you next time. And remember, if you like what you hear, please like, rate and subscribe on your favorite podcast platform. It means the world to us.