FinOps X 2026 | Rajeev Laungani, Virtasant & Colby Rozell, Chevron

Clips
More from FinOps X 2026

Rajeev Laungani

Practice Lead, Cloud Optimization

Virtasant

Colby Rozell

Technical Product Manager, IT Optimization

Chevron

play_circle_outline Beyond Cloud Costs: AI FinOps for Token Economics, Model SKUs, and Cost Visibility

play_circle_outline Unified FinOps: Balancing Tool Sprawl with Human-in-the-Loop Oversight and Automated Remediation

play_circle_outline Embedding FinOps guardrails in SDLC and shift-left for costs

play_circle_outline Standardizing Token Costs, Attribution, and Prompt Traceability for Transparent AI Spending and Governance

Info

Rajeev Laungani, Virtasant & Colby Rozell, Chevron

Rajeev Laungani

Practice Lead, Cloud Optimization Virtasant

Colby Rozell

Technical Product Manager, IT Optimization Chevron

search

John Furrier

>> Welcome back everyone to theCUBE's live stream here in San Diego, FinOps X 2026. I'm John Furrier, your host of theCUBE along with my co-host, Paul Nashawaty of theCUBE Research. FinOps X is growing, the community's growing, the tools are changing. We're going to get into it and see where the productivity and the benefits are. Rajeev Laungani, he's a practice lead cloud optimization of Virtasant and Colby Rozell, technical product manager IT optimization at Chevron. Gentlemen, great to have you on. Great to hear what's going on in the field and the tools. Thanks for coming on.

Rajeev Laungani

>> Thank you for having us.

Colby Rozell

>> Thank you.

John Furrier

>> So there's a lot of tool proliferation mainly because it's such a hot market. FinOps has evolved. Costs are very real. The value's very real. It's being created. So obviously it's a feeding frenzy, but there's a lots going on. A lot of evolution. The first question is, what are practitioners thinking about right now? Because it's chaotic and you got a new foundation being launched and that's a good thing. Opportunity. Your thoughts?

Rajeev Laungani

>> For me, FinOps is not just cloud costs and it hasn't been for a long time. And now we're finally starting to see those coverage areas and expanding cost centers. So obviously you talk about the world of AI. Every day there's a new model. Every day there's a new service. Every day there's a new SKU. What is the right model? Are we using it efficiently? And that's the first problem to solve in the world of AI. That's what we're saying.

John Furrier

>> Colby, how's your world?

Colby Rozell

>> Yeah. So I would say cost visibility is definitely an area that we continue to see evolution. As Rajeev was just mentioning, a lot of the different cost models, getting into some of the AI, understanding our token spend, where that cost is coming from and really being able to extrapolate that back to the agent, a user. That's really some visibility that we're starting to miss and gap. So it's really those emerging services that are really the challenge for us.

Rajeev Laungani

>> And I would say that every enterprise is different in the way that they want to measure AI usage. Some just want to see adoption and see where that adoption is occurring. Others want to be the quickest to get to optimization. So the true question is are we using that AI in the right way and how each enterprise attacks answering that question is a bit nuanced.

Paul Nashawaty

>> In our research, we're finding that 75% of organizations are using six to 15 different tools. So there's all this kind of things happening and such. But when we look at this, there's repetitive FinOps tasks that happen that are best suited for AI. The tools are the right tools and sometimes it's siloed, sometimes it's uniform. But a lot of these organizations, actually 54% in our research are indicating that they want to move towards a unified approach. So they want to have a more focused approach, less complexity. But I guess the question is where would human judgment still be required as part of this?

Colby Rozell

>> And you're exactly right. We have multiple tools. We haven't found one platform that can do it all. So it's really this combination of multiple tools bringing those insights together where we can really leverage the insight that we're gaining there. But in addition to that, we actually have opportunities where we need to remove the friction. So you talk about human in the loop in those situations. One of our tools, we have over 20,000 recommendations that are less than $500 of savings in a year. But to orchestrate that change, you've got really some challenges with the engineers in terms of the friction, the level of effort to actually capitalize on that. But in aggregate, that can result in millions of dollars in savings, but we can't capitalize on that just yet. So that's really where I see AI for FinOps removing that friction, helping us get to value faster in those decisions. And it's not just making the decision, still having the human in the loop, but it's all the way through to the execution and modifying their code for them.

Paul Nashawaty

>> And appropriate attribution as well. So what are your thoughts?

Rajeev Laungani

>> I think what you mentioned, Colby, there is super important. It's accelerating value in the areas where you identify those inefficiencies. So reporting, anomaly detection, recommendations, AI is very useful. However, you have to be very careful when you get into production level changes, very large billing construct purchases, because those still present a very large risk to the enterprise. So that is where you need that human in the loop. You need that human to make those business level decisions still because AI isn't groomed enough to do that yet.

John Furrier

>> How do you optimize for value? This comes up a lot because I've been saying cost, cost, cost, but the market of AI is about revenue, revenue, revenue. Now costs, revenue, that's profit. So there's a lot going on in the FinOps world with all the changes. How do you optimize for value? Is there an approach? Is there a mindset? Is it a data driven thing? What's their thoughts?

Rajeev Laungani

>> So each enterprise has their different ways that they want to leverage AI and different goals that they have in the AI space. For me, it comes down to what is the biggest problem you're trying to solve and is that an efficiency problem or determining what that problem actually is from a subject matter perspective. You then use that AI in a very constrained area to solve that one problem first and then extrapolate out because you learn the nuances, you learn how efficient your own enterprise is in that use and administration.

Colby Rozell

>> Yeah. I think I would just add to that AI is not meant for everything. And many enterprises like ourselves over many years have automated optimization already. So you look at orphaned resources, various things of that nature. We've already automated that. We've already capitalized on that value. It doesn't make sense for us to move that into an AI model that potentially is going to cost more. So you really have to layer AI on top of the use cases where you're going to get that value. And so that's where we're really looking at, well, what are the big rocks that we can turn over that we can remove the friction, give better insights, whether it's more observability data or whatever it may be to help those engineers make those decisions faster.

Paul Nashawaty

>> But as you're building this, this is a really good point. When you were talking about it, I was almost jumping in on that because I was like, I really hear what you're saying. This isn't a greenfield like, "Hey, woke up one day, let's do AI." It's like this is happening over time. And so there's things that you build yourself and then there's things for vendors will create that are features that will enhance and have you have better time to value, fast time to value, but there's a cost. So where are the trade-offs here? You talked about this, you evolved to something, but at what point do you stop throwing money at something that you build yourself and just go to a vendor solution versus going and saying, "Well, this is actually doing what we needed to do so we're good."?

Colby Rozell

>> I think one of the challenges that we're going to continue to see as AI continues to evolve is SaaS enter the market because of speed to value. Vendors could create the software, solve our problems a lot faster at a lower total cost of ownership, but they never solved all of the problem. They typically solved 80%. The other 20% we had to put wrappers functions as a service around it to help finish the complete thought. As we see AI developers, I think a big conversation in our C-suite is, do we continue down that pathway of continuing to invest in SaaS offerings or I can now build it just as fast, if not faster from a developer leveraging AI and expand those capabilities. So I think it's a balanced approach, but we really have to have the capability to bring all of those solutions together. So it's the AI that's built in one solution may not meet all of our needs. We need the ability to interconnect and interweave all of those solutions together into on AI architecture.

Rajeev Laungani

>> And I'll give you one very specific example. When you look at something like anomaly detection, SaaS providers have mastered that in most cases in the cloud. So when you're extrapolating that to the AI, it probably makes the most sense to go still use the vendor for that. However, if it's a more nuanced insight where you know that the vendors haven't necessarily tapped into the space, it might bode you well as enterprise to develop an in-house nuance to your own systems. So those are the trade-offs that every business leader is at the table trying to make to determine what have we already done, what are the repeatable patterns we can redeploy, but then what is the level of effort for the new stuff.

John Furrier

>> I love that comment because the cloud game has taught and matured. I mean, look at AWS, Google, Azure, their backend, they're providing a lot of things for that purpose. Now the model providers, let's just say they're embryonic in their stage and so in DevOps we saw shift left for security. Now you start to see FinOps guardrails being embedded in the software life cycle with cost constraints built in. How does that look? Because we saw the shift left for security, that really made the development cycle go faster. So where are we on the progress of the cost constraints? Is it narrow? Is it broad? What does that look like?

Rajeev Laungani

>> It's a great question. And Colby and I were actually talking about this a bit before. The relationship between FinOps and engineering is going to change a bit. Because you're not using insights that happened in the past to inform future behaviors. You're actually business as usual before anything is deployed. So the PR changes. How are we able to translate to engineers that each PR is going to be different or will have a different cost impact. That's the level that we're getting to now.

John Furrier

>> And then where does AI fit into that? Is it pivoting off the native cost constraint?

Rajeev Laungani

>> I would say that AI, it's very similar, but to our point, the governance of it is going to be... The application of it is going to be a bit different. So in that manifestation, each developer now is going to be much more aggressive with obviously how much they're spending with each PR. So the guardrails required for that are going to be much, much different.

John Furrier

>> It's interesting. I can almost see the cost constraint almost as a seed or a placeholder to have some intelligence to know when to go out and get either more data. How are engineers thinking about that? Because I think this is going to be an explosive opportunity to say, okay, we're shifted left a little bit with cost constraints, but every use case might have a different configuration to your point about PRs so you don't want to slow things down, you want to make them go faster. What does that look like? I mean, take us through, because now data modeling and data sets become big, new data sets are coming on board. How does that hook? Play out my word hook, but I guess that's the way I look at it.

Colby Rozell

>> I think it's really the evolution of that integration back into your DevOps tools, GitHub Copilot to be able to make those changes for those in particular teams. So it's really that shift from reactive to really proactive. But I think the other piece of this that we'd have to recognize is there's also this culture shift where many years we've been trying to send this or facilitate this culture change in the organization to say, "Hey, FinOps has to be on the forefront of your mind." which it's not always on the forefront of a mind of a developer of an engineer. They're just trying to produce the software, but it's really shifting that into their workload and really stopping the bleeding upfront.

John Furrier

>> Well, talk about that organizational change because Paul and I were talking about how there's different adjacencies and the expression that become colloquialism for the industry, stay in your lane. It's very silo thinking. You start to look at different departments that have to horizontally connect and engage. Who owns what? I mean, everyone wants to own Claude.

Rajeev Laungani

>> I would also say the way that it's measured is eerily similar to how cloud happened, because initially you had your virtual machines, your databases, and it seemed like, oh, great. But then you have your nuanced services like Databricks, like Kubernetes. How do you truly optimize those? The same way with token economics, you're going to have the first level of models, the main ones, the big players, but then how do you also look at token economics with like Copilot and some of those other nuanced services?

Paul Nashawaty

>> So this is interesting to me because when I look at our research, I see that 24% of organizations want to release code on an hourly basis. That means the SDLC needs to move very quickly. And when you start putting FinOps guardrails in place into the SDLC, this potentially can slow things down. I mean, we've all been there where we're working on something that says, "Oh, you run out of tokens for the day, come back in four hours or whatever." That's a problem. I know that obviously that has to change. What are your thoughts around the cost constraints into infrastructure as code, as into the SDLC? What does this mean across your environments when there's conflicting polls? There's cost constraints, but there's also this, the KPI is to push code out the door fast.

Colby Rozell

>> Yeah, that's definitely a challenge, especially as you move into Copilot. I think some of the things that we really have to think about are how we're slicing that data, dimensionalizing the data around some of our releases. So is this an experimentation? Is this a production release? Is this an enhancement or is it an operational release? Because there could be a situation, I run out of tokens and I can't do my operational release because I did all of this development and experimentation and I ran out of tokens.

Paul Nashawaty

>> Oh, there's so much to talk about there.

Colby Rozell

>> So there's so many personas that we've got to really understand the persona and put the guardrails around those personas. And so if you're creating value, let's give you a larger budget, but do you limit productivity? I don't know that we're quite there yet.

Rajeev Laungani

>> And that's where business prioritization is still so ever important, because with any technology cost center, we need to identify what the business leaders are thinking in terms of deployment and where it truly matters. So if something operational is getting muddled by the fact that some new innovation testing is going on, then we have a problem.

Paul Nashawaty

>> Well, I think that what you touched, you're both touching on here is there's two very different use cases and we treat them as one. The cost of a token's not the cost of a token.

Rajeev Laungani

>> Correct.

Paul Nashawaty

>> So if you're innovating versus your production, there's two different approaches here. You need to innovate in order to be productive, but you also have production code that needs to have attribution to dollars.

Rajeev Laungani

>> And then how does that optimization dollar then go back into innovation? It's a whole cyclical thing.

John Furrier

>> Yeah. It builds on itself. I mean, they have to think like investors and finance people because that's the budget. They can squeeze out of it. I want to ask you guys a question to wrap up because I've heard in the hallways, we see on some of the talks the phrase, the big rocks are gone. What does that mean? Okay. Does that mean the hard problems are solved or does that mean that the big more high level data sets are there? Is it a granularity issue? What does the big rocks are gone mean?

Rajeev Laungani

>> For me, it's a granularity issue. So your large right sizing of instances, your large idle and your large waste, your big SPRI purchases, those days are. But then where is the next level up? It's obviously with the expanding cost centers, but also the granularity that you optimize. So those PRs.

John Furrier

>> Like what?

Rajeev Laungani

>> With every code level change, what is the cost impact of that? With every development or architectural consideration, how is that going to impact the environment five years down the road if you're investing in that environment five years down the road?

John Furrier

>> So you think that's where action is?

Rajeev Laungani

>> 100%.

John Furrier

>> That's where ages might come in. That's where lot of the nuances come in.

Paul Nashawaty

>> But even tactical. I mean, if you're trying to measure towards that KPI of pushing code out the door, that's where there's an impact. So it's an immediate impact.

Rajeev Laungani

>> Immediate impact. And it has to become BAU. Just like security, it has to be embedded in the pre-planning for everything otherwise.

John Furrier

>> You guys are great. Thanks for coming on theCUBE. Final question. I guess I have one more I'll throw out there. For practitioners that are out there and they got the chaos that's managed chaos, things are being figured out, which is where we're at. What's your advice? Because there's a lot of different competing worldviews and it depends on every company's different, but they have the different technology estate. Some are in the cloud, some are not as heavy. What's the best advice for practitioners how to land in with AI, how they enter into AI? Because like you said with cloud, if they come in right, the benefits downstream are significant. Any parting advice?

Colby Rozell

>> I would say it starts with the engineers, human to human interaction, understand their workload, understand the barriers, the friction points that they're experiencing. Then you can evolve that into a human in the loop, human to machine, and then eventually get to that autonomous. But you're not going to build the trust if you're not engaging with those individual teams and those engineers and really partnering with them to understand the barriers and the problems to their success.

John Furrier

>> You really got to get down and dirty and get in with the developers and the engineers because it's not like some, "Here's the new tool, figure it out."

Colby Rozell

>> Exactly.

Rajeev Laungani

>> They're always going to be the ones that own execution. So unless you're able to translate what is needed from an optimization perspective down to their understanding, it's never going to work.

John Furrier

>> And so you need a common language, all the focus, all these things?

Rajeev Laungani

>> We need everyone to be speaking one standard language.

John Furrier

>> I'll give one more final, final question in there.

Rajeev Laungani

>> I love it.

John Furrier

>> The model companies, so the cloud guys have done a great job over the progression of cloud native to provide some of the services that are needed for FinOps. What's needed? What are the gaps from the new providers, whether that's a NeoCloud or say the model providers themselves, what's needed for them? What work do they need to do?

Rajeev Laungani

>> I would say a very clear understanding of how things are costed and scaled. Because right now, if you look at all the different providers, tokens are measured differently and it's a race to standardize that view for business executives and finance executives. So being able to give a clearer picture or model or some sort of forecasting on how that works would be great. But I think that's what us practitioners and vendors are solving for as well.

John Furrier

>> Colby, Chevron, what's the pain relief and what's the steroid growth for growth for you? What do you need?

Colby Rozell

>> I would say from the AI space we can see the expenditure, we see the cost, but I really don't have that visibility down to the individual, I can see the model, can't see down to the user. I need the traceability, I need that observability data to really understand what was prompted, what was the reasoning, what was the output in order for us to further optimize and really understand how we can evolve our AI space.

John Furrier

>> That's great discussion. Thanks for coming on and sharing some great observations and some data. It's a fun time to be-

Colby Rozell

>> Thank you so much....

John Furrier

>> in the industry, a lot of engineering going on, a lot of activity. It's robust.

Rajeev Laungani

>> It's probably the most exciting time to be in technology.

John Furrier

>> Appreciate it.

Colby Rozell

>> Absolutely.

Rajeev Laungani

>> Appreciate you guys having a talk. Thank you.

John Furrier

>> I'm John for Paul Nashawaty. Thanks for watching. We'll be right back here at FinOps X after this short break.

Rajeev Laungani, Virtasant & Colby Rozell, Chevron

search

John Furrier

>> Welcome back everyone to theCUBE's live stream here in San Diego, FinOps X 2026. I'm John Furrier, your host of theCUBE along with my co-host, Paul Nashawaty of theCUBE Research. FinOps X is growing, the community's growing, the tools are changing. We're going to get into it and see where the productivity and the benefits are. Rajeev Laungani, he's a practice lead cloud optimization of Virtasant and Colby Rozell, technical product manager IT optimization at Chevron. Gentlemen, great to have you on. Great to hear what's going on in the field and the tools. Thanks for coming on.

Rajeev Laungani

>> Thank you for having us.

Colby Rozell

>> Thank you.

John Furrier

>> So there's a lot of tool proliferation mainly because it's such a hot market. FinOps has evolved. Costs are very real. The value's very real. It's being created. So obviously it's a feeding frenzy, but there's a lots going on. A lot of evolution. The first question is, what are practitioners thinking about right now? Because it's chaotic and you got a new foundation being launched and that's a good thing. Opportunity. Your thoughts?

Rajeev Laungani

>> For me, FinOps is not just cloud costs and it hasn't been for a long time. And now we're finally starting to see those coverage areas and expanding cost centers. So obviously you talk about the world of AI. Every day there's a new model. Every day there's a new service. Every day there's a new SKU. What is the right model? Are we using it efficiently? And that's the first problem to solve in the world of AI. That's what we're saying.

John Furrier

>> Colby, how's your world?

Colby Rozell

>> Yeah. So I would say cost visibility is definitely an area that we continue to see evolution. As Rajeev was just mentioning, a lot of the different cost models, getting into some of the AI, understanding our token spend, where that cost is coming from and really being able to extrapolate that back to the agent, a user. That's really some visibility that we're starting to miss and gap. So it's really those emerging services that are really the challenge for us.

Rajeev Laungani

>> And I would say that every enterprise is different in the way that they want to measure AI usage. Some just want to see adoption and see where that adoption is occurring. Others want to be the quickest to get to optimization. So the true question is are we using that AI in the right way and how each enterprise attacks answering that question is a bit nuanced.

Paul Nashawaty

>> In our research, we're finding that 75% of organizations are using six to 15 different tools. So there's all this kind of things happening and such. But when we look at this, there's repetitive FinOps tasks that happen that are best suited for AI. The tools are the right tools and sometimes it's siloed, sometimes it's uniform. But a lot of these organizations, actually 54% in our research are indicating that they want to move towards a unified approach. So they want to have a more focused approach, less complexity. But I guess the question is where would human judgment still be required as part of this?

Colby Rozell

>> And you're exactly right. We have multiple tools. We haven't found one platform that can do it all. So it's really this combination of multiple tools bringing those insights together where we can really leverage the insight that we're gaining there. But in addition to that, we actually have opportunities where we need to remove the friction. So you talk about human in the loop in those situations. One of our tools, we have over 20,000 recommendations that are less than $500 of savings in a year. But to orchestrate that change, you've got really some challenges with the engineers in terms of the friction, the level of effort to actually capitalize on that. But in aggregate, that can result in millions of dollars in savings, but we can't capitalize on that just yet. So that's really where I see AI for FinOps removing that friction, helping us get to value faster in those decisions. And it's not just making the decision, still having the human in the loop, but it's all the way through to the execution and modifying their code for them.

Paul Nashawaty

>> And appropriate attribution as well. So what are your thoughts?

Rajeev Laungani

>> I think what you mentioned, Colby, there is super important. It's accelerating value in the areas where you identify those inefficiencies. So reporting, anomaly detection, recommendations, AI is very useful. However, you have to be very careful when you get into production level changes, very large billing construct purchases, because those still present a very large risk to the enterprise. So that is where you need that human in the loop. You need that human to make those business level decisions still because AI isn't groomed enough to do that yet.

John Furrier

>> How do you optimize for value? This comes up a lot because I've been saying cost, cost, cost, but the market of AI is about revenue, revenue, revenue. Now costs, revenue, that's profit. So there's a lot going on in the FinOps world with all the changes. How do you optimize for value? Is there an approach? Is there a mindset? Is it a data driven thing? What's their thoughts?

Rajeev Laungani

>> So each enterprise has their different ways that they want to leverage AI and different goals that they have in the AI space. For me, it comes down to what is the biggest problem you're trying to solve and is that an efficiency problem or determining what that problem actually is from a subject matter perspective. You then use that AI in a very constrained area to solve that one problem first and then extrapolate out because you learn the nuances, you learn how efficient your own enterprise is in that use and administration.

Colby Rozell

>> Yeah. I think I would just add to that AI is not meant for everything. And many enterprises like ourselves over many years have automated optimization already. So you look at orphaned resources, various things of that nature. We've already automated that. We've already capitalized on that value. It doesn't make sense for us to move that into an AI model that potentially is going to cost more. So you really have to layer AI on top of the use cases where you're going to get that value. And so that's where we're really looking at, well, what are the big rocks that we can turn over that we can remove the friction, give better insights, whether it's more observability data or whatever it may be to help those engineers make those decisions faster.

Paul Nashawaty

>> But as you're building this, this is a really good point. When you were talking about it, I was almost jumping in on that because I was like, I really hear what you're saying. This isn't a greenfield like, "Hey, woke up one day, let's do AI." It's like this is happening over time. And so there's things that you build yourself and then there's things for vendors will create that are features that will enhance and have you have better time to value, fast time to value, but there's a cost. So where are the trade-offs here? You talked about this, you evolved to something, but at what point do you stop throwing money at something that you build yourself and just go to a vendor solution versus going and saying, "Well, this is actually doing what we needed to do so we're good."?

Colby Rozell

>> I think one of the challenges that we're going to continue to see as AI continues to evolve is SaaS enter the market because of speed to value. Vendors could create the software, solve our problems a lot faster at a lower total cost of ownership, but they never solved all of the problem. They typically solved 80%. The other 20% we had to put wrappers functions as a service around it to help finish the complete thought. As we see AI developers, I think a big conversation in our C-suite is, do we continue down that pathway of continuing to invest in SaaS offerings or I can now build it just as fast, if not faster from a developer leveraging AI and expand those capabilities. So I think it's a balanced approach, but we really have to have the capability to bring all of those solutions together. So it's the AI that's built in one solution may not meet all of our needs. We need the ability to interconnect and interweave all of those solutions together into on AI architecture.

Rajeev Laungani

>> And I'll give you one very specific example. When you look at something like anomaly detection, SaaS providers have mastered that in most cases in the cloud. So when you're extrapolating that to the AI, it probably makes the most sense to go still use the vendor for that. However, if it's a more nuanced insight where you know that the vendors haven't necessarily tapped into the space, it might bode you well as enterprise to develop an in-house nuance to your own systems. So those are the trade-offs that every business leader is at the table trying to make to determine what have we already done, what are the repeatable patterns we can redeploy, but then what is the level of effort for the new stuff.

John Furrier

>> I love that comment because the cloud game has taught and matured. I mean, look at AWS, Google, Azure, their backend, they're providing a lot of things for that purpose. Now the model providers, let's just say they're embryonic in their stage and so in DevOps we saw shift left for security. Now you start to see FinOps guardrails being embedded in the software life cycle with cost constraints built in. How does that look? Because we saw the shift left for security, that really made the development cycle go faster. So where are we on the progress of the cost constraints? Is it narrow? Is it broad? What does that look like?

Rajeev Laungani

>> It's a great question. And Colby and I were actually talking about this a bit before. The relationship between FinOps and engineering is going to change a bit. Because you're not using insights that happened in the past to inform future behaviors. You're actually business as usual before anything is deployed. So the PR changes. How are we able to translate to engineers that each PR is going to be different or will have a different cost impact. That's the level that we're getting to now.

John Furrier

>> And then where does AI fit into that? Is it pivoting off the native cost constraint?

Rajeev Laungani

>> I would say that AI, it's very similar, but to our point, the governance of it is going to be... The application of it is going to be a bit different. So in that manifestation, each developer now is going to be much more aggressive with obviously how much they're spending with each PR. So the guardrails required for that are going to be much, much different.

John Furrier

>> It's interesting. I can almost see the cost constraint almost as a seed or a placeholder to have some intelligence to know when to go out and get either more data. How are engineers thinking about that? Because I think this is going to be an explosive opportunity to say, okay, we're shifted left a little bit with cost constraints, but every use case might have a different configuration to your point about PRs so you don't want to slow things down, you want to make them go faster. What does that look like? I mean, take us through, because now data modeling and data sets become big, new data sets are coming on board. How does that hook? Play out my word hook, but I guess that's the way I look at it.

Colby Rozell

>> I think it's really the evolution of that integration back into your DevOps tools, GitHub Copilot to be able to make those changes for those in particular teams. So it's really that shift from reactive to really proactive. But I think the other piece of this that we'd have to recognize is there's also this culture shift where many years we've been trying to send this or facilitate this culture change in the organization to say, "Hey, FinOps has to be on the forefront of your mind." which it's not always on the forefront of a mind of a developer of an engineer. They're just trying to produce the software, but it's really shifting that into their workload and really stopping the bleeding upfront.

John Furrier

>> Well, talk about that organizational change because Paul and I were talking about how there's different adjacencies and the expression that become colloquialism for the industry, stay in your lane. It's very silo thinking. You start to look at different departments that have to horizontally connect and engage. Who owns what? I mean, everyone wants to own Claude.

Rajeev Laungani

>> I would also say the way that it's measured is eerily similar to how cloud happened, because initially you had your virtual machines, your databases, and it seemed like, oh, great. But then you have your nuanced services like Databricks, like Kubernetes. How do you truly optimize those? The same way with token economics, you're going to have the first level of models, the main ones, the big players, but then how do you also look at token economics with like Copilot and some of those other nuanced services?

Paul Nashawaty

>> So this is interesting to me because when I look at our research, I see that 24% of organizations want to release code on an hourly basis. That means the SDLC needs to move very quickly. And when you start putting FinOps guardrails in place into the SDLC, this potentially can slow things down. I mean, we've all been there where we're working on something that says, "Oh, you run out of tokens for the day, come back in four hours or whatever." That's a problem. I know that obviously that has to change. What are your thoughts around the cost constraints into infrastructure as code, as into the SDLC? What does this mean across your environments when there's conflicting polls? There's cost constraints, but there's also this, the KPI is to push code out the door fast.

Colby Rozell

>> Yeah, that's definitely a challenge, especially as you move into Copilot. I think some of the things that we really have to think about are how we're slicing that data, dimensionalizing the data around some of our releases. So is this an experimentation? Is this a production release? Is this an enhancement or is it an operational release? Because there could be a situation, I run out of tokens and I can't do my operational release because I did all of this development and experimentation and I ran out of tokens.

Paul Nashawaty

>> Oh, there's so much to talk about there.

Colby Rozell

>> So there's so many personas that we've got to really understand the persona and put the guardrails around those personas. And so if you're creating value, let's give you a larger budget, but do you limit productivity? I don't know that we're quite there yet.

Rajeev Laungani

>> And that's where business prioritization is still so ever important, because with any technology cost center, we need to identify what the business leaders are thinking in terms of deployment and where it truly matters. So if something operational is getting muddled by the fact that some new innovation testing is going on, then we have a problem.

Paul Nashawaty

>> Well, I think that what you touched, you're both touching on here is there's two very different use cases and we treat them as one. The cost of a token's not the cost of a token.

Rajeev Laungani

>> Correct.

Paul Nashawaty

>> So if you're innovating versus your production, there's two different approaches here. You need to innovate in order to be productive, but you also have production code that needs to have attribution to dollars.

Rajeev Laungani

>> And then how does that optimization dollar then go back into innovation? It's a whole cyclical thing.

John Furrier

>> Yeah. It builds on itself. I mean, they have to think like investors and finance people because that's the budget. They can squeeze out of it. I want to ask you guys a question to wrap up because I've heard in the hallways, we see on some of the talks the phrase, the big rocks are gone. What does that mean? Okay. Does that mean the hard problems are solved or does that mean that the big more high level data sets are there? Is it a granularity issue? What does the big rocks are gone mean?

Rajeev Laungani

>> For me, it's a granularity issue. So your large right sizing of instances, your large idle and your large waste, your big SPRI purchases, those days are. But then where is the next level up? It's obviously with the expanding cost centers, but also the granularity that you optimize. So those PRs.

John Furrier

>> Like what?

Rajeev Laungani

>> With every code level change, what is the cost impact of that? With every development or architectural consideration, how is that going to impact the environment five years down the road if you're investing in that environment five years down the road?

John Furrier

>> So you think that's where action is?

Rajeev Laungani

>> 100%.

John Furrier

>> That's where ages might come in. That's where lot of the nuances come in.

Paul Nashawaty

>> But even tactical. I mean, if you're trying to measure towards that KPI of pushing code out the door, that's where there's an impact. So it's an immediate impact.

Rajeev Laungani

>> Immediate impact. And it has to become BAU. Just like security, it has to be embedded in the pre-planning for everything otherwise.

John Furrier

>> You guys are great. Thanks for coming on theCUBE. Final question. I guess I have one more I'll throw out there. For practitioners that are out there and they got the chaos that's managed chaos, things are being figured out, which is where we're at. What's your advice? Because there's a lot of different competing worldviews and it depends on every company's different, but they have the different technology estate. Some are in the cloud, some are not as heavy. What's the best advice for practitioners how to land in with AI, how they enter into AI? Because like you said with cloud, if they come in right, the benefits downstream are significant. Any parting advice?

Colby Rozell

>> I would say it starts with the engineers, human to human interaction, understand their workload, understand the barriers, the friction points that they're experiencing. Then you can evolve that into a human in the loop, human to machine, and then eventually get to that autonomous. But you're not going to build the trust if you're not engaging with those individual teams and those engineers and really partnering with them to understand the barriers and the problems to their success.

John Furrier

>> You really got to get down and dirty and get in with the developers and the engineers because it's not like some, "Here's the new tool, figure it out."

Colby Rozell

>> Exactly.

Rajeev Laungani

>> They're always going to be the ones that own execution. So unless you're able to translate what is needed from an optimization perspective down to their understanding, it's never going to work.

John Furrier

>> And so you need a common language, all the focus, all these things?

Rajeev Laungani

>> We need everyone to be speaking one standard language.

John Furrier

>> I'll give one more final, final question in there.

Rajeev Laungani

>> I love it.

John Furrier

>> The model companies, so the cloud guys have done a great job over the progression of cloud native to provide some of the services that are needed for FinOps. What's needed? What are the gaps from the new providers, whether that's a NeoCloud or say the model providers themselves, what's needed for them? What work do they need to do?

Rajeev Laungani

>> I would say a very clear understanding of how things are costed and scaled. Because right now, if you look at all the different providers, tokens are measured differently and it's a race to standardize that view for business executives and finance executives. So being able to give a clearer picture or model or some sort of forecasting on how that works would be great. But I think that's what us practitioners and vendors are solving for as well.

John Furrier

>> Colby, Chevron, what's the pain relief and what's the steroid growth for growth for you? What do you need?

Colby Rozell

>> I would say from the AI space we can see the expenditure, we see the cost, but I really don't have that visibility down to the individual, I can see the model, can't see down to the user. I need the traceability, I need that observability data to really understand what was prompted, what was the reasoning, what was the output in order for us to further optimize and really understand how we can evolve our AI space.

John Furrier

>> That's great discussion. Thanks for coming on and sharing some great observations and some data. It's a fun time to be-

Colby Rozell

>> Thank you so much....

John Furrier

>> in the industry, a lot of engineering going on, a lot of activity. It's robust.

Rajeev Laungani

>> It's probably the most exciting time to be in technology.

John Furrier

>> Appreciate it.

Colby Rozell

>> Absolutely.

Rajeev Laungani

>> Appreciate you guys having a talk. Thank you.

John Furrier

>> I'm John for Paul Nashawaty. Thanks for watching. We'll be right back here at FinOps X after this short break.