Filip Kuncar: The Real Compute Cost Shows Up Before Production

AI makes pipelines cheap to build. It does not make them cheap to run.

In fact, the demands on infrastructure are so great that sometimes Filip Kuncar’s team at ShipMonk just plain run out and deployments are delayed. Part of his job is to keep an eye on budgets and get the most out of the infrastructure. In the age of AI, he has found some interesting changes in where the gotchas hide.

Surprisingly, AI has massively increased spend in places we barely used to even track it: in pre-production and CI.

Filip Kuncar leads the platform team at ShipMonk. Based in Prague and working mainly with US companies, Kuncar works where speed, governance, and compute cost meet. On The Compute Layer, he explains where data and AI cost actually accumulates, why the stack choice has not had much impact on budget, and how his organization keeps budgets from drifting.

The surprise budget challenges when AI is making pipelines in a day

When development was slow and manual, we could watch the budget as products went to production.

"It took forever for the development to get it there.... Today you can do the whole cycle in one day."

That constraint that allowed budget to catch up is gone.

"So, you are piling up all the production pipelines, and it starts to be really heavy on the costs, on the infrastructure underneath.... And basically even the maintenance is ten-fold, fifty-fold, you name it."

The bill grows before production

Traditionally, cost conversations are about the cost of production workloads. Kuncar’s team recognized that AI development is adding steep cost increases much earlier, during testing.

"So the first point when you actually see that the cost is increasing heavily is all the checks before you get to production."

CI pipelines validate everything repeatedly, precisely because AI-speed deployment makes it easy to stop paying attention. Each check consumes compute running the pipeline.

The production itself is obviously expensive, but what's happening before the production, that's where the real cost is, at least for us. And we've been fighting that since AI took off.

The consequence is not only financial. When compute resources are exhausted, delays ensue.

"At some points it takes so long to do anything in the pipeline that you are queued because you don't have the additional compute that you need, and that's actually what hurts the team."

Old habits keep the costs high

Part of the pre-production cost is architectural, and part of it is inherited thinking.

"I think people are used to the fact that they need to have everything under control in the relational way."

Relational databases are not the problem. Kuncar is adamant that they are well designed and here to stay. The problem is not recognizing where their model ends, especially once analytics and AI enter the picture. Teams carry relational-style validation into pipelines that are no longer relational, and the compute bill absorbs it.

"And then it adds to the cost. If you change the thinking of people, it gets a little less expensive and a little faster."

Budget ownership belongs to the team

One technique that Kuncar uses is to make the budget part of the operation team’s responsibility and to put it on the dashboards. Spend is measured and visible.

"You need to show them like it should be visible on the first page, and it should be really clear."

Then it is enforced like reliability.

"If you're close to the budget or over the budget for a certain period, you treat it almost the same as if it was a production incident. You create a support ticket, and then you have SLA within which the team needs to really resolve the issue."

The process frames the budget as a production service level.

You are responsible for your budget.

A budget handled this way behaves like a bug count or an incident log, and engineering teams are familiar with those. Obvious spikes get an immediate reaction. The steady AI-driven climb, which is the most common pattern, usually gets caught within a month, followed by root cause analysis and backlog work.

The stack matters less than the compute underneath

Asked where the tech stack plays into rising cost, Kuncar moves the focus one layer down.

"So it actually doesn't matter that much, like what stack you're using. The infrastructure underneath will be priced accordingly because the whole market realized, hey, the infrastructure is in demand, and that's what you'll be paying for."

Comparable platforms behave comparably.

"What we are paying for the most is actually the compute underneath."

Which leaves exactly one lever worth pulling.

If you had something that could use the underlying infrastructure much more efficiently, then it would make the real difference in the whole data cost, or the data and AI cost.

What a modern compute layer has to deliver

Kuncar’s requirements are specific: efficiency in the layer that everything else runs on, visibility into how that layer is used, and a cost line predictable enough for a team to own.

Capacity-based annual licensing, priced by maximum concurrent cores with no burst pricing, turns an unpredictable line item into a number a platform team can plan against and defend.

That does not eliminate the need for the discipline Kuncar describes. It gives that discipline more room to work.

The takeaway

A faster development cycle is not free. It moves cost into the part of the process nobody instrumented, multiplies maintenance, and eventually queues the teams it was supposed to speed up.

The fix is not slowing down. It is finding visibility into where compute is actually consumed, ownership close to the teams consuming it, and infrastructure efficient enough that the checks before production stop being the most expensive thing you run.