Leon Kuperman, CTO at CAST AI, on cloud automation, GenAI adoption, and scaling developer velocity

Host: Lucas Hendrich, CTO at Forte Group
Guest: Leon Kuperman, CTO at Cast AI

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group.

Today I have the great pleasure of talking with Leon Kuperman, CTO of Cast AI, about Cast AI and other things. Let me see if I can describe it in a way our less technical business listeners will understand: Cast AI is a cloud optimization solution that orchestrates Kubernetes workloads in hybrid cloud environments to reduce cloud costs. Tell me what's missing.

Why Cast AI Exists

Leon Kuperman: First of all, Lucas, thank you very much for having me. I really appreciate it, and I'm looking forward to a fun conversation.

When you promote a product like ours, there's the direct, immediate, ROI-driven benefit, and you described it really well. One great outcome of our platform is that it reduces costs. But the bigger reason for being — you know the "Start with Why" idea? You've probably seen that TED Talk a million times; it's from about 15 years ago. We went through that exercise to understand the core reason for our platform, and I'll lay it out for you.

We believe software powers the world, which I think you'll agree with as a CTO, and we exist to make our customers' software better, faster, cheaper, more resilient, and more secure. We do that through automation, because we believe there won't be enough humans to drive all the software evolution coming over the next decade or two.

People think AI is going to take all the software jobs. I think the opposite is true. There will be such an explosion of software projects that, yes, AI will be an accelerant, but software will be a great and interesting place to work for the next couple of decades.

We started our journey with Kubernetes because it has rules of engagement; it's a very structured orchestration platform. But we've now expanded our product line into AI enablement and database optimization. We believe any area of software that can be automated at the lowest level should be, so humans can elevate their participation in the software development lifecycle and solve the hardest problems, not the low-level grunt work.

Lucas Hendrich: That makes total sense, and it confirms a view I express pretty consistently on this podcast. There are two general views of AI and automation. One is the scarcity view: we'll automate ourselves out of jobs. That creates a lot of fear, and people react out of fear. The other is the growth view — really a demand-side view — that all this automation will increase demand for more interesting projects.

Another way I think about it: by automating low- to mid-level tasks that don't require much cognitive lift, imagine all the cognitive space we open up. I think that space is still unique to humans — how humans solve problems, which are essentially human problems, not machine problems. Platforms like yours will free us to tackle harder problems.

Velocity and engineering culture

Leon Kuperman: The way I look at it: what's the number one downfall of most software projects? I frame it in two buckets. The first is technical debt, which is measured in velocity. If you stop releasing code, you're on a death march.

People think releasing code less frequently is safer. It's actually much more dangerous. The phrase I use is, "The antidote to change is more change." Go faster. That means you need the rails to go fast, the test structures to go fast, and everything automated.

At Cast, we release our core platform hundreds of times a day. When legacy or more enterprise customers ask us for our change schedule, I can't give them one. There's no versioning. The software is continuous and changes 24/7. So velocity and technical debt are one big bucket we try to solve through automation.

The second is engineering culture. We can help with that indirectly, but fundamentally it comes from human leadership. How you think about engineering problems, and how you think engineers should engage with them, starts at the top. But it's also a grassroots movement. If your engineers don't believe what you believe, you'll have a dysfunctional team.

AI Adoption on the Engineering Team

An open tooling policy

Lucas Hendrich: I love thinking about belief. I can't cite where I read it, but there's an interesting idea that code is actually a belief system. Everything in a product starts with a set of core beliefs, which creates a whole reality.

As for your engineering teams: how have you adjusted over the last year or two to the potential productivity gains, and the potential risks to productivity, from generative AI, specifically in code creation?

Leon Kuperman: We have a very open policy for our engineers. They don't have to use OpenAI, or Claude, or JetBrains. There's a plethora of tools in the environment, and that's very purposeful. In fact, we asked them to buy their own licenses, which we'll probably have to change for compliance reasons. But in these early days: buy the licenses you want, play with what you want, and see where you get.

I see two camps. One is highly skeptical and still believes coding is a handcrafted art. I have my opinion about what will happen to those folks. And by the way, age isn't a good predictor of that belief system. Right now, I find it highly uncorrelated.

The second group is leaning in more. They're still skeptical, but highly curious and playing at the edge.

My team is mostly in the Baltics and Poland — roughly Eastern Europe. They already come to the table with a highly skeptical mentality, shaped by hundreds of years of history. Battling that is my internal challenge, but I think we're getting there.

A self-solving problem

Leon Kuperman: We did performance reviews literally last week, and in one-on-ones with my engineering managers I asked: Who's adopting? Who's stagnating? One of our rock-star EMs, Jolanta, said, "Look, Leon, I think it's a self-solving problem."

As a non-AI-assisted engineer, you might have a couple of great rock-star days — you're over the moon for a couple of days — but eventually your energy levels return to normal. What we see is that people who've dialed in their prompt engineering and their skill with Cursor, Windsurf, JetBrains, whatever IDE they choose, consistently outpace handcrafting engineers.

So her view is that it'll be a self-selection problem. Eventually, through performance management, we'll see it clearly. It's not something we have to force.

Lucas Hendrich: An analogy I use a lot: you can make candles and be very good at it, but you're not going to light your house with candles. Someone — I think it was Andrew Ng, though someone can fact-check me — compared AI to the new electricity. I think AI will become so pervasive and ubiquitous that at a certain point it won't even be considered AI anymore.

There's a lot of talk about AGI and some big singularity moment. But the tools are already good enough to do so many things that I'm almost not interested in the next benchmark. The utility is so clear and so pervasive that it's more of a shift in ways of working, with a long tail as it spreads beyond software development.

Models, Benchmarks and Stickiness

Leon Kuperman: That's true. It's such a useful tool for so many applications. Lucas, do you think we'll see a flatlining or deceleration, where people say, "Why pay $700 for a model when the $20 one is just fine?"

Lucas Hendrich: I think it's already happening. AI has always been a loaded term with so much cinematic baggage, but there will simply be acceptance. The same way Excel is everywhere, LLMs are becoming ubiquitous.

Leon Kuperman: I've been studying machine learning for probably half my career. My first machine learning courses in college used nothing like today's techniques, but ML has been central to my last couple of startups. When the transformer model with attention came on the scene, I thought, "Cool, another neural network that's really good at language processing." The leap was in the outcomes for people who hadn't been big students of machine learning. For me, it's all a machine learning problem — a prediction problem. I love that we're at this point in history, because there's so much good we can do with the capacity that's been unlocked.

Do you use the higher-end professional models? I have the GPT Pro subscription, and I'd argue that if there were a higher tier, I'd probably pay for it. It's been a game changer for how I work.

Lucas Hendrich: Absolutely. And evaluating them is a constant challenge. I'm not solving Math Olympiad problems day to day. I do some hard problem-solving, but it's usually ideation and strategy, drawing on a corpus of knowledge beyond my own gray matter. The foundation models all do relatively well at that. In some ways it comes down to style and nuance.

Leon Kuperman: I think there's stickiness, and I'll explain. I was just thinking about why I don't use Grok when others do, or Gemini — I really don't like the experience. I think I understand why.

But back to your point on benchmarks. To keep it clean, the benchmarks are a little bit BS. Nobody works in a clean-room environment where only the model weights count. It's the model weights plus the MCP server plus the tools available to agentic workflows that combine to produce an outcome. I don't necessarily care whether a model has all its knowledge embedded in its weights. In fact, the more extra dead weight it carries, the slower it is at generating tokens.

Lucas Hendrich: Absolutely — it creates deadweight loss. The real utility of a foundation model is handling natural language. Going back to that higher-level utility: how much easier is it to ask your data a question, without caring where it lives, and get an answer, than to send a user to a BI tool or SharePoint to find something and write a query? That small leap in natural language processing is huge.

Leon Kuperman: There are a million business use cases, but code is the perfect one. I think LLMs and reasoning models have become so pervasive in coding because code is just language. It's essentially a language problem, and these models understand Go, Python, and Java extremely well. They have a huge corpus to learn from.

Where AI Fits in Cast AI's Product

No LLMs in the core product

Lucas Hendrich: Your solutions at Cast AI predate the generative AI boom of the last two years. With any big technological advance, there's a lot of buzz and noise, and at a certain layer of abstraction people don't really understand what they're talking about.

When people ask how your product is AI-driven, are they asking from the recent mental model of generative AI, or do they appreciate what you've been doing in machine learning? There's a dichotomy between deterministic and non-deterministic. I believe many people asking don't have a fundamental technical understanding of what they mean by AI.

Leon Kuperman: We state very clearly that our core products don't use LLMs — foundation models — though I'll explain where a little of that creeps in. Using them is a procurement nightmare. It's already a complex sales cycle: people are buying automation, there are internal personas asking whether it will work for their use case, and there's general resistance to automation in some circles.

Lucas Hendrich: Or just the challenge of adopting a subscription solution in a large enterprise.

Leon Kuperman: There's a procurement lift and a compliance and security lift. All of that is true. So we state that when you buy our core product — those three or four SKUs — we don't use large language models. The next generation of tooling we're releasing at KubeCon North America in November does leverage them heavily.

Foundation models for time series

Leon Kuperman: I want to talk about that stack, because there's a tokenomics element that I think will make or break adoption, and people should know about it.

I believe in using the simplest algorithm that solves the problem. Where a graph-based heuristic works, great, let's use it. Where a traditional machine learning classifier works, use that. Where we need a regression model, or traditional time series analysis, my position has always been: use what's proven.

I've changed my position a little, though. We're all familiar with language models, but there's another class of foundation models for time series data, which is great for operational time series. If I need to predict a metric's value at a future point in time, I'd normally have to model that metric, feeding it historical lags to predict future values.

There's Chronos and several other foundation models in all different sizes. Datadog just released one trained on all of their operational data. These give us what we call zero-shot inference on time series, without pre-training on customer data, and I love that. A number of our anomaly detectors and seasonality forecasters now use those foundation models.

The Economics of Cloud and GPUs

The fox guarding the henhouse

Lucas Hendrich: That's interesting. Let me think about how to ask this. Part of the initial value proposition, at least as people see it, is the optimization you get from your platform.

Leon Kuperman: Come for the savings, stay for the automation.

Lucas Hendrich: Right. That always raises a question for me, maybe a naive one, from a pure economic standpoint. You'd think there's some price equilibrium where the hyperscalers can't keep sustaining a cottage industry of companies that optimize away their inefficiency and friction. Some of that is customer choice and preference: multi-cloud implementations are hard, and the providers obviously want all your business. But is there a future of optimization based on tokens? That whole pricing model is different.

Leon Kuperman: Yes.

Lucas Hendrich: In ten years, it could be the pricing model for so many things as AI expands. It's an interesting scheme.

Leon Kuperman: I was really worried about this. I started thinking about it about a year and a half ago, and I want to tell you what we've built so far.

Lucas Hendrich: Does the question make sense?

Leon Kuperman: Totally. It all comes down to cost per input and output token.

Lucas Hendrich: Exactly.

Leon Kuperman: And I think it's more existential than you think, because we're in a "crossing the chasm" moment, if I can date myself for a minute. The gap between early adoption and real production use cases will come down to this: "I built a great prototype, but when I tried to scale it for production, I blew the budget." I think we're in a prolonged period of GPU scarcity, and that won't change in the short term.

I want to share what I think the clouds are doing with the economic model, and what I think customers should do — independent of Cast — as a mental model for finance. But first, one point. Yes, under customer pressure, cloud providers will try to lower your bill. It's in their long-term interest not to force repatriation — moving software back to your own data centers.

But there's tremendous gross margin in those businesses. It's in the public reports; there's no hiding it. And in a few places, clouds act very monopolistically, which I think proves they won't fully optimize in the customer's best interest.

The analogy I use is the fox guarding the henhouse. A provider will optimize enough to retain customers, not necessarily to the maximum. So beyond the technology we deliver — some of which I think is years ahead of what the cloud providers are even considering — you need a neutral, reliable third party across all hyperscalers that sees all the data and tells you the ground truth about what's possible in optimization. Does that make sense, Lucas?

Lucas Hendrich: It makes sense. And I think one way that third-party view could emerge is through energy consumption. Existentially, beyond whatever's in my IT budget, there's the question of how much energy is available to consume.

Inference, self-hosting and GPU commitments

Leon Kuperman: That's right — that's the ultimate existential question. But let's talk about the tokenomics part of your question, because it's really interesting.

As an enterprise, you have a choice. Do you buy a SaaS model — just pay for API calls to Anthropic or OpenAI, or Groq, which hosts open source models on specialized hardware that's really good at what it does — and stay hands-off? That's basically SaaS.

That model is great for many use cases. But when customers get serious, a couple of things stop them from using it for everything. For most use cases, companies won't send their intellectual property or customer data outside their perimeter, and existing laws and regulations often don't allow it.

Take HIPAA and medical records. If I'm an insurance company, am I really going to send sensitive customer information out to these providers? Whatever guarantees the SaaS provider offers, contractual or otherwise, you won't send that data outside your perimeter.

That naturally leads to self-hosting the model weights and runtimes in some fashion. Now you're moving from pure dollars per token in and out to a proxy for it: how much do the GPUs I'm using for inference cost? And inference is the vast majority of these cases. No one is training in the enterprise. Anyone who says they're training their own models is full of it — I'm trying to keep it PG, Lucas.

So it comes down to GPU cost. Hyperscalers, neoclouds, and GPU-specific clouds charge for GPUs by the hour. To get a really good deal, you have to commit, typically for three years. Here's the insanity: AWS or GCP asks me to commit to, say, an H100 for three years, with no flexibility to roll my commitment when the H200 becomes available. You're stuck on a platform.

Think about NVIDIA's rate of innovation, which will only accelerate. We're used to Moore's Law doubling every 18 months; by comparison, that's going to look like a flat line. So if I buy H100s today for three years, there's a huge risk of overpaying in the long run. The cloud provider uses that financial mechanism to cap its capital expenditure risk. They're pushing depreciation onto customers, and I think that's outrageous.

Project Omni: hunting for GPU capacity

Leon Kuperman: So part of the Cast platform tries to solve this. Internally we call it Project Omni; marketing will rename it by GA. That's fine — we're not very good at naming things.

Kubernetes is a regional concept: you have a cluster in a specific region — US East in Ashburn, or California. But there are GPUs everywhere, including in clouds that aren't your first, second, third, or fourth choice. With Omni, you have a central cluster that can reach that capacity. I think the scarcity problem is partly artificial, a result of pockets of capacity and regionality.

So we tell customers: don't fall into the three-year booking trap. Be opportunistic. Hunt for GPUs where they're available, and spin them up and down as you need them. That's a 70–80% cost reduction.

Take Oracle Cloud, where I used to work — not directly relevant here, but OCI has great GPU capacity. We'll leverage that capacity for our customers, even if they've never done business with Oracle Cloud before.

Who Adopts First: Startups or Enterprises?

Escaping proprietary ML stacks

Lucas Hendrich: I want to move to a part of the conversation about organizations, and your experience in both large enterprises and startups. The world you're describing is incredibly attractive to startups willing to move fast and take risks. It seems really challenging to explain to a procurement department used to long-term contracts, with no incentive beyond strict bottom-line cost — and you can argue about that all day. Then there's explaining the difference between training and inference to a non-technical person.

So which market do you capture first? Is it startups, which eventually build momentum? When do you see large enterprises moving to that model?

Leon Kuperman: I think it'll be small, scrappy companies at first, and there will be thousands of them. That's a slightly different ICP from the one we're targeting now.

The product in our suite is called AI Enabler. It came out of frustration with very proprietary platforms. On Google Cloud you're in Vertex AI, a completely locked, closed ecosystem. Amazon has SageMaker, and Microsoft has its own. But machine learning has one of the most prolific open source communities out there.

Lucas Hendrich: It's based on statistical methods that are 200 years old or more.

Leon Kuperman: And the open source community is amazing — PyTorch and all these tools are fantastic. Why lock me into a proprietary data-flow stack? That's how AI Enabler was born.

Yes, it's working with small companies right now. But I'm seeing an ICP shift. We're working with a large networking company that's seriously considering this model, because the alternative is a $10 million commitment for one small project, versus being able to prove out much more.

I think enterprises are moving to more agile methodologies to stay competitive. You have to be agile to survive, and that brings lean-startup-like techniques: try, fail fast, iterate. That's how I worked on many of my projects at Oracle, and it was successful. I think you'll see more of that from large enterprises.

With the GPU market specifically, I'm surprised to see green shoots in enterprise, even while we're getting huge traction and product-driven feedback from smaller companies. I think the small companies will drive the product, and the big ones will be there to catch it.

How Oracle Cloud changed

Lucas Hendrich: I think we're talking about a specific kind of enterprise, though. You're not talking about HSBC; you're talking about Oracle — a digitally native, technology-native company.

Leon Kuperman: But I don't think it was ten years ago.

Lucas Hendrich: Tell me why. What's the shift?

Leon Kuperman: Think about the sales motion — and I think it's reflected in the stock price. Everything used to be driven by enterprise software licenses and slow cycles. Oracle's first shot at a cloud didn't succeed. OCI, which they sell now, is version two, and it's much more successful because it's based on consumption pricing. There's no good-old-boy handshake: "Let me buy $10 million of this from you," and then that revenue churns. They've done a much better job of honing in on the product that matters to customers at a very affordable price, and that's why they're winning. OCI is very agile for a large company, whereas the Oracle of ten years ago just wasn't.

A Kayak-like experience for compute

Lucas Hendrich: That makes total sense. A broader question about AI's impact: when do you expect that to trickle down — second or third order — to Oracle's customers, the large enterprises, which I assume include some of yours? I won't say brick-and-mortar, but technology-enabled companies that aren't technology companies.

Leon Kuperman: I'm working with a large pharmaceutical company right now, and it's something of a passion project for me. They simulate drug outcomes on patients. On premises, they can only run a certain number of virtual patients — say 100,000 per run — and it takes a long time. This isn't what I'd call a technology-first company. They're a pharmaceutical business.

Lucas Hendrich: Digital technology isn't the core of what they do.

Leon Kuperman: Right. So to go from 100,000 virtual patients to 10 million, what difference in scale is required, without their scientists having to significantly change how they work? We're seeing green shoots from companies whose internal DNA is less digitally native embracing these innovations: automation in the cloud, and leveraging GPUs wherever they can get them, in very non-traditional ways.

That customer's original ask was: "Leon, we want a Kayak-like experience. We have a heavy computational job to schedule. Tell us what it'll cost to run it now with the best available resources. Or, if our scientists are OK waiting until the Sunday-midnight flight, what will that cost? Then let us decide when to run it based on our cost and time sensitivity." That was the highest-level ask, and I found it super intriguing.

Lucas Hendrich: Absolutely.

Leon Kuperman: It was a consumer analogy.

Lucas Hendrich: It's like electricity — the same thing.

AI and the Shift in Ways of Working

Self-selection and velocity

Lucas Hendrich: Let's go back to how your engineers are adopting AI. I'm not sure whether we discussed it before we started recording, but it's super interesting how your teams are using AI and how it's changing ways of working.

I'll preface it: I think this will be orders of magnitude larger than, but comparable to, the move from waterfall to Agile. It creates tension. It starts with making software — I say "obviously" because I've been in software development — and then spreads to other parts of the organization: sales, HR, or marketing working in sprints and planning the same way.

It's a long question, but I'm curious about your view on that adoption and change, given your experience in large enterprises where you saw it happen with Agile, and now managing it — for lack of a better word — with all the options generative AI offers.

Leon Kuperman: We talked about it a little, and I gave you the example of one of my engineering managers…

Lucas Hendrich: Which I think is great, and I'd love for you to repeat it.

Leon Kuperman: We're recording, so I'll tell the story quickly. I think people will self-select in or out based on velocity. A rock-star engineer without AI just won't keep up with a rock-star engineer using AI. It's not fair — it's like anabolic steroids in sports. You'll have to adapt your tools and ways of working to maintain top-performer velocity.

Moving design out of Figma

Leon Kuperman: Having said that, here are some interesting statistics — and I'm going to say something provocative. I've asked my user experience team to stop working in Figma. It's a very aggressive end-of-year goal and a hard shift. It means much higher-order thinking and much more automation. We have our design system, our layout conventions, and all our components. There's no need for high-fidelity mock-ups of everything we build.

Lucas Hendrich: So were you surprised by the Figma IPO?

Leon Kuperman: Not in the short term. I think Figma will iterate on its AI and improve. Right now it sucks — sorry, guys. But there are better tools for the job.

Another interesting statistic: for my UI team, the people responsible for our user experience, over 40% of the code is now fully automatically generated. We don't touch it once it's generated, and it's pretty clean. It comes with unit tests, integration tests, and end-to-end tests. My challenge to that team is: how do we increase that coverage so you're thinking at a higher level?

On the other side of the company, we're building tooling that shifts automation left. I'll give a specific example from what we're releasing. Not only do we have to be believers; we have to make our customers believe, and that's a tall order. You're thinking about how to get your team to take the lead; I'm thinking about how to make this a viable business.

And it goes beyond vibe coding, because vibe coding always starts with a prompt. I'm thinking about automated processes that run without human management, or at least without human monitoring, and are expected to produce high-quality outcomes. How is that quality verified so we don't introduce really big problems? That automation can now take action; it's not just a recommendation engine.

Measuring What Matters

Vanity metrics

Lucas Hendrich: You mentioned velocity, and everything starts with metrics. I've found it a huge challenge, because we're automating things that weren't automated before. What's your baseline? I think there's still a lot of noise here. It comes down to the right use case, and you have to be very prescriptive.

I'm trying to remember research I read last week, but I think it found something like 37% lower productivity from vibe coding, because of the amount of rework it requires.

Leon Kuperman: Two steps forward, one step back.

Lucas Hendrich: Exactly.

Leon Kuperman: You're getting more done, but rolling back more than you used to.

Lucas Hendrich: Right.

Leon Kuperman: But I think the net result is that you're still moving forward more than you would have.

Lucas Hendrich: Yes.

Leon Kuperman: I look at these metrics from a human perspective. There are a bunch of vanity metrics, and we threw those out a long time ago.

Lucas Hendrich: Give me an example. What are the vanity metrics?

Leon Kuperman: I'll start with the very worst, then move up to some people may not think of as vanity metrics. Lines of code: a vanity metric. Nobody cares. In fact, it's an anti-pattern — the more lines, the worse you are.

Lucas Hendrich: It's nuanced, though, because you want clean, readable code.

Leon Kuperman: That's true.

Lucas Hendrich: Maintainable code.

Leon Kuperman: Yes.

Lucas Hendrich: Which LLMs are great at.

Leon Kuperman: Which LLMs are great at. They comment code well and write great docstrings. They also write fairly elegant, Pythonic code — sometimes too compact for me to understand. I'll say, "Give me a more verbose version. Don't do it all in one line with a lambda. Help my brain process what you're doing."

Here's another vanity metric that might surprise people: test code coverage. We don't measure it, because you get what you measure. You'll get a bunch of nonsense test cases that appear to cover edge cases but aren't actually valuable.

DORA metrics, rollbacks and developer happiness

Leon Kuperman: What I measure are velocity-related metrics. There's a whole school of thought called DORA metrics, which are DevOps-related. I look at things like time from commit to review.

Lucas Hendrich: So you're looking at overall throughput.

Leon Kuperman: Rollback time is a key metric for me. Anything under 30 minutes, I love. Better still is a canary rollout, where a small percentage of service traffic is affected, we spot the error, and it automatically rolls back, which we do very effectively today with GitLab. I don't like penalizing people for making mistakes. A rollback is a great thing in my book, especially if it takes under 30 minutes.

We combine that with developer happiness. My VP of engineering hates when I use the word "happiness," but that really is how I think about it. The happier your engineers are, the more closely they'll be tied to your mission and the more they'll lean in.

So we run a developer experience survey once a quarter. How much time are you wasting in your local environment? How is testing? How is our documentation? What's the onboarding experience like? It probably takes 20 minutes to fill out. We track our weakest points on a heat map and spend the next quarter having our tooling team fix the red areas, then move on to the next ones.

Over time, you get a very happy and loyal engineering team, and you measure that through unwanted — or regrettable — attrition.

Lessons From the Mat

Lineage

Lucas Hendrich: This next question is totally unrelated to software development. I read that you practice Brazilian jiu-jitsu. I do as well.

Leon Kuperman: Where do you train?

Lucas Hendrich: At an academy in Brooklyn, New York, called Brooklyn Brazilian Jiu-Jitsu. There are a few locations, and I train at one of them. I'm a purple belt.

Leon Kuperman: What's the lineage? Who's the professor?

Lucas Hendrich: That's a great question. Honestly, I know my professor, and I know Brian Glick is one of my professor's professors. I know he's trained with a whole cast of characters, including John Danaher.

Leon Kuperman: In New York?

Lucas Hendrich: Yes, in New York. Next time I mention it, I should come with more facts in my head.

Relaxation and organizational anxiety

Lucas Hendrich: What I was thinking about as you talked about happiness: I also started Muay Thai a couple of years ago, and I used to box. In sports, and particularly combat sports, being relaxed is fundamental to performing well.

Leon Kuperman: Yes.

Lucas Hendrich: I often feel the same about solving hard technical problems. I don't necessarily have to be happy in the classical sense, but my mind has to be relaxed. If it isn't, I shift to lower-cognitive tasks to keep myself busy. Organizationally, that shows up as a whole bunch of anti-patterns.

Leon Kuperman: Yes.

Lucas Hendrich: People set up meetings…

Leon Kuperman: Yes.

Lucas Hendrich: …and status reports. To me, all of that represents a kind of organizational rigidity and anxiety. If you think of an organization as a living organism, you want to unleash its productivity, and a relaxed organizational state does that — people not operating out of fear, for example. Then there are the vanity metrics, many of which are yardsticks that can be gamed or used threateningly.

This is a long preamble to my question: What parallels do you see between your experience as a martial artist and how you approach organizational and technical problems?

Leon Kuperman: For the audience: Brazilian jiu-jitsu is a relatively new sport. The legend is probably larger than the actual person at this point, but it started with a Japanese judoka, Mitsuyo Maeda, traveling through Europe and taking on all comers — boxers, any martial art. The legend says he was never defeated. He ended up in Brazil, where a wealthy man named Gastão Gracie asked him to stay and train his sons. That's where Brazilian jiu-jitsu begins.

As practitioners, we're not far removed from the sport's founding, so we should all be able to trace our lineage back to its founders. I was very fortunate. I lived in LA for many years, and LA has been a hotbed of Brazilian jiu-jitsu over the last couple of decades. I started training at Jean Jacques Machado's academy.

JJ is a legend. If you listen to Joe Rogan, he's been on the podcast multiple times. Joe got his black belt from Eddie Bravo, who got his from Jean Jacques. I was privileged to train with JJ and his whole team in LA. If you're ever in the area and want to try it, absolutely hit up the Machado academy.

Doing hard things

Leon Kuperman: To your question about parallels: I think it's important for people to do hard things. BJJ is one of the hardest things you can do, in my opinion. When you're getting choked, or a 250-pound guy is on your face and you can't breathe, you're not thinking about your latest work problem or an argument you had. You're just thinking about survival.

So you get into a flow state unlike any other, where in the best case you're just surviving. As you get better, you learn to control your breathing under very tenuous circumstances. I'm listening to my opponent's heartbeat to understand how much energy they have in reserve, and therefore what my next set of moves might lead to.

I'm a brown belt, and I'm not a very athletic person, but the sport has saved me because it's so interesting. It's like a chess game. I get bored lifting weights, but I never get bored going to train. My road to black belt will be long, because I have a really bad shoulder that needs repair. I want to prove to myself that I can still compete.

It's mostly a race against yourself. People think of it as a combat sport, but it's more than 99% an inner battle. Once you solve yourself, you can solve the externalities — every opponent, every outside skill — if that makes sense.

How does that apply to how I think about business and software? It used to be that engineers weren't very athletic. I find that's changing drastically.

Lucas Hendrich: I totally agree. It used to be the Simpsons-style IT administrator: typically overweight and sedentary.

Leon Kuperman: One hundred percent. In our Vilnius office, we have kickboxers, swimmers, triathletes, mountain climbers, and mountain bikers. Everyone does something physical, because you need that release. You need something physically hard — BJJ or anything else — to clear your mind. That clarity leads to much less anxiety and clearer thinking when you approach problem-solving.

Meetings kill flow

Leon Kuperman: And I agree that nervousness and lack of confidence show up as bad anti-patterns. I hate meetings. I tell my team to cancel them at all costs. If you attend a meeting and don't participate, don't join again.

In a distributed world, flow state is super important for engineers to be productive and happy — and I say both, because they go together. Meetings are the ultimate anti-pattern. Imagine just three meetings in your day: you won't reach a flow state.

Lucas Hendrich: It reminds me of Paul Graham's famous essay on the maker's schedule versus the manager's schedule.

Leon Kuperman: That's right.

Lucas Hendrich: I wonder how incorporating AI into some of the harder tasks — and I wouldn't say I'm skeptical; I know everything is solvable, and there's an equilibrium at some point — might allow better orchestration of the hard cognitive work in organizations, and maybe expand that time. And to your point about physical activity, Mark Zuckerberg is now an example.

Leon Kuperman: He jumped on late, but he's pretty good. I've watched a couple of his matches. He's pretty good.

Lucas Hendrich: It'd be fun to spar with him. I'm sure a lot of people say that.

Breaking problems into steps

Lucas Hendrich: I'll draw a distinction. I used to run a lot, and to me running is more like a task that can be automated than an intellectually challenging one. You're just enduring a certain level of discomfort over time, and you lose yourself in other things. Running used to be a good way to chew on a complex problem, because no one would bother me while I was out for a run.

Leon Kuperman: You're not really meditating, are you?

Lucas Hendrich: I've tried meditation. That's a whole topic.

Leon Kuperman: I mean during the run, when you get into that state.

Lucas Hendrich: Yes.

Leon Kuperman: One perspective is that it's a meditative, repetitive state. By the way, I don't know how to run well at all, and it's something I want to get better at. There's a whole technique to it that the average spectator misses. When you're in a tough spot on the mat, you don't have time to think about the problem you're solving. I think that's the difference between the mat and a run: on a run, your body is in repetitive motion, and your brain is free to go anywhere.

Lucas Hendrich: Correct, and I think that's a very important distinction. That's where I see many parallels between jiu-jitsu and solving a complex technical problem. You can't boil the ocean, and that's the first mistake people make: implementing something without thinking the problem through correctly or sufficiently.

If you rush to a technique — and I'm a purple belt, so I'm still on that journey — it wasn't long ago that I was rushing without going through each step. Rock climbing is another great metaphor. To solve a complex problem, you have to think about the small thing you're doing first and break it into very discrete steps. If you try to do it all at once, you'll gas out and never get the outcome you want.

Leon Kuperman: You look for the little things. I'm in a tough spot: Where are my frames? Where's the leverage? How much gas is in the tank? How much time is left on the clock?

Lucas Hendrich: Before I let go of this point of control, do I have another firm point of control?

Leon Kuperman: And those things become instinctual. Then you start thinking about second- and third-order reactions. You automatically know: I'll push the body that way, he'll post out, and the opening will be there. Those things are learned.

But back to where the value is for individuals: you learn patience, you learn not to rush, and you learn to dissect problems. Some of the best ideas I've ever had came right after a hard roll. I have to grab my phone and record the thought. It didn't come during the roll. It came in the moment of clarity when you're relaxing and breathing, and the problems you couldn't solve during the day come flooding back.

Lucas Hendrich: Yes.

Leon Kuperman: And suddenly there's a solution.

Is Intelligence Just Weights and Gates?

Lucas Hendrich: Which is why I'm skeptical about any AGI resembling human intelligence. I think people confuse the two. Cinema has given us very fantastical ways of thinking about it, because that's very human. There's no easy scientific or technical explanation for how that thought came to you after physical exertion while solving something else.

Leon Kuperman: Let me challenge you a little.

Lucas Hendrich: Please.

Leon Kuperman: Let's do a thought experiment. Suppose we're really just a bunch of neurons connected with different weights in a cognitive network. The inputs are still there. In our case, we have chemical barriers: we don't have enough dopamine to want to do the task, or we're too anxious. There's some hormonal imbalance, or another mental blocker, preventing us from trying.

Physical exertion temporarily opens those gates. The neurons are still there; they just need to be allowed to connect to an answer. The LLM analogy is that you have to ask the right question, or set of questions, with the right tools to reach a solution.

When I hear people say AI doesn't work for them or can't be an effective tool in their lives, I say: look at your prompts. Your prompt engineering sucks. Either you're too low-level, too dogmatic, or too prescriptive in what you ask, or you're so fluffy the machine doesn't know where to start. Finding the middle is an art.

Lucas Hendrich: I forget what I was going to prompt the other day, but I found myself going through many iterations in my head to arrive at the best possible question. It's a real challenge. I think my children will be natively better at it than previous generations, because it's becoming part of their lives. And anyone getting in the way of that from an educational standpoint is creating a huge challenge.

Will the Next Generation Know How to Ask?

Leon Kuperman: I worry a little about that for kids. When did you start coding, Lucas?

Lucas Hendrich: I guess in second grade, making games for the Commodore 64.

Leon Kuperman: So we're in the same ballpark. I think I was nine, and my first computer was an Apple IIe. Those are thousands of hours we put into those games, or whatever we were building. My favorites were text adventure games like Zork.

Lucas Hendrich: Oh, yes.

Leon Kuperman: All that background and those thousands of hours inform how we approach prompt engineering today. Our mental model of the world, and of how computers work, is embedded in how we ask questions. When a younger person hasn't gone through that toil, are they capable of asking questions the same way? Do they even have the context to ask the right questions?

I won't call it doomsday, but one negative path I see is that we as a society become so dumb that we no longer know how to use AI effectively. That's something I worry about from a young person's perspective.

Lucas Hendrich: I totally agree, and I see both doomsday and utopia. On the doomsday side, I've used this example before: I spend 20 minutes creating a 50-page business plan, and it's good enough. It'll then be read and analyzed by LLMs. So I'm creating a big block of content that will be decomposed by the same model that created it. What are we actually transmitting? Where's the idea — the kernel — in all that noise?

Leon Kuperman: That's a great point. When you use LLMs to generate documents, they come with all kinds of marketing fluff and words like "alignment," which I hate, and "crucial" and "strategic." My prompts strip all of that out. I ask for very basic, simple English — nothing beyond high-school-level language. If I have three or four ideas I want in a one-pager, it should be a very simple transformation that adds just enough context and background around those four bullets. That's it.

Lucas Hendrich: There's something very Zen Mind, Beginner's Mind about that. Maybe our children, without the context and intuition we've built over the years, will arrive at it from a totally naive standpoint.

One thing I've learned from experimenting with vibe coding is that there's a middle zone where you really screw things up if you introduce anything that isn't very simple and close to the core idea. You create a bunch of other stuff — cruft all over the place.

Leon Kuperman: Vibe coding is no different. If you don't create unit tests or a good CI/CD pipeline, you'll end up with the same crappy, non-refactorable legacy code you'd get by hand. You'll just fail much faster.

Lucas Hendrich: Precisely. That's why I think a great use case is throwaway code. If you want to throw spaghetti at the wall, there's no better way.

Leon Kuperman: I love Lovable for that.

Lucas Hendrich: I've just started using it.

Leon Kuperman: Now, when I read a product definition and want to envision a UI that looks like our console, it's a 30-minute problem. And it's getting better. I don't know how they're making money at 25 bucks, but we'll take advantage of it while it lasts.

Closing

Lucas Hendrich: That goes back to the economics question from earlier. This has been a ton of fun. I hope you enjoyed it as much as I did.

Leon Kuperman: This was a lot of fun. Thank you for the great questions, Lucas. I really appreciate it.

Lucas Hendrich: It's been a pleasure. That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.

‍