Berk Yilmaz Podcast Transcript
Berk Yilmaz joins host Brian Thomas on The Digital Executive Podcast.
Brian Thomas: Welcome to Coruzant Technologies, Home of The Digital Executive podcast.
Do you work in emerging tech? Working on something innovative? Maybe an entrepreneur? Apply to be a guest at www.coruzant.com/brand.
Welcome to The Digital Executive. Today’s guest is Berk Yilmaz. Berk Yilmaz is the co-founder and chief technology officer of Noah Labs, where he’s building Sentinel, an AI-native IDE designed for secure, regulated, air-gapped, and mission-critical software environments.
His work sits at the intersection of agentic software engineering, legacy code modernization, AI systems, formal verification, compliance tooling, and aerospace-grade software reliability. At Noah Labs, Berk leads product and engineering architecture for a secure development platform that includes AI-assisted migration pipelines, deterministic audit trails, agent runtimes, compliance automation, formal verification integrations, and cross-platform desktop deployment.
Well, good afternoon, Berk. Welcome to the show.
Berk Yilmaz: Thank you. Glad to be here, Brian.
Brian Thomas: Absolutely, my friend. I appreciate it, really do. I know you are in the San Jose, California area. I’m in Kansas City. Appreciate you hopping a couple time zones and several calendars to get here today. That’s just so special to me when people take the time out of their day to do this, so thank you.
And Berk, if you could, let’s jump into your first question. Your path runs from dual undergraduate degrees at New Jersey Institute of Technology and Istanbul Technology University through electrical engineering at Columbia and into NASA-supported space research before co-founding Noah Labs. What through line connects those experiences and led you to building Sentinel?
Berk Yilmaz: Of course, and first of all, thank you. I’m glad to be here, Brian. And, you know, looking back, the thread was actually pretty simple. I kept up ending in places where software failure wasn’t an option, and the tooling actually never matched the stakes. For example, at NGIT and Istanbul Technical University, I was splitting time between electrical engineering and computer sciences, which sounds a little scattering, but it gave me something that is important.
I learned to think about the software the way hardware engineers do. You, you don’t ship circuit board and hope it actually works. You verify it, you prove it, and that mindset actually stuck with me through my whole university life. And Columbia actually deepened that. And then NASA, NASA research really finalized this pushback.
And when you’re working on systems that might end up in space where you can’t just push the hotfixes you learn the fast that the gap between the… it compiles and it’s actually correct is just enormous. And most developer tools just don’t care about this gap, and thus, that’s what led to Sentinel.
At Noah Labs, we’re building the development environment for engineers who work on software where the consequences of getting, getting it wrong is actually real. Defense systems, critical infrastructures, Eurospace the kind of code where you need a provable audit trial and just not a green check mark in CI.
So, the through the line is I kept seeing high-stake software built with low-stake tools, and Sentinel is the tool that I wished existed at every step along the way
Brian Thomas: That’s amazing, and I appreciate that. The backstory here, essentially, and, and, you know, looking at your resume, it looks like a lot. You had to juggle both electrical engineering, computer science in school, but that actually brought everything together for you, which I think is awesome, and it has definitely gave you that line or that path to what you’re building today at Noah Lab.
So, I really, really appreciate that. Berk, Noah Lab’s legacy code modernization is central to Noah Lab’s pitch to defense and federal teams. What makes modernization decades-old regulated code bases so difficult, and how do AI-assisted migration pipelines change that equation?
Berk Yilmaz: Great question. So let me paint the picture.
There’s an enormous amount of critical, critical software out there. It’s in defense, aerospace, in the financial tech sector that was written in C in COBOL, in Fortran decades ago, and it actually works. These decades of operational use have shaken out the bugs that, that actually matters. But the engineers who wrote it, in many cases retired, and engineers inheriting the code often don’t know the source language well enough to verify that rewrite is the correct thing.
So that’s the first problem. A generational knowledge gap on the both sides of the migration. But the harder problem is, for these customers, a migration isn’t finished when the new code compiles. It’s finished when a external reviewer can be pursued that the new code is equivalent. That means that a, a paper trial, every prompt, every model response, every input, every proof certificate, if you can produce that trial the migration doesn’t count.
Legally, no one have the good code of this. So what Sentinel does is we pair an AI translation engine with formal verifications and a deterministic audit bundle. We break the code base into translation units and translate each one. To verify it through the differential testing, we literally put the old program and the new program against the same inputs and compare the outputs.
When very applicable, we dispatch formal obligations to check mathematical equivalence, and every large language model call is cached deterministically, so any run can be replayed byte by byte. So the AI changes the speed, and we know that but the verification and the audit trial change whether the results are actually usable for these regulated customers.
And that’s the equation actually we’re solving with Sentinel.
Brian Thomas: That’s awesome. Appreciate that. And Berk, just so you know, I worked as… started my career as a developer, but I… Looking back, I had a lot of exposure to Fortran, COBOL, C, mostly C. But, you know- Yeah … that stuff’s been around since the ’60s, ’70s, ’80s, and it’s hard to believe that it’s still being used, especially in the critical areas of, like, Department of Defense.
But I like what you’re all doing. You’re obviously translating those old code bases where it can be verified byte by byte to make sure that the testing and the translation and then the testing that you’re doing is 100% accurate, which is so important in these critical areas. So again, thank you. And Berk, you’ve written about moving away from the assumption that AI must process everything all the time, pointing toward sparsity and energy efficiency for edge and space applications.
How does that philosophy influence your approach to building developer tooling?
Berk Yilmaz: Yeah, this is something I think about a lot, and it directly shapes how we architect the Sentinel. The dominant approach was, in AI tooling right now, the, the biggest available model, send it everything all the time, and that works fine if you’re in the cloud or…
and latency is nice to have. It completely falls apart when your customer’s operating an SIC fee or in an air-gapped facility where the model runs on a local hardware and every watt matters now. So our approach is we don’t use AI where we don’t need to. Our compliance checking, for example, is entirely de- deterministic.
No large language models involved. We map the findings to control frameworks using a rule engine, not a, not a language model because a regulator doesn’t want to hear your compliance assessments was probably right, right? It needs to be the same answer every time. So for this, we have to get a deterministic approach.
On the model side, you’re designing for right sizing using smaller, faster models for our orchestration and routing, and larger model only when the task actually demands it. The goal is that the system gets more efficient as it m- m- matures, and not less. The more you use it, more of the pipeline h- hit escap- hits the cache, the fewer m- expensive models calls you need.
And efficiency isn’t a perf- performance optimization for us. It’s a deployment requirement. If it doesn’t run on a custom hardware behind a locked door, we, it doesn’t ship, basically
Brian Thomas: Wow. Amazing. Really is. And you’re, you’re absolutely right. Everything nowadays is connected, internet connected, cloud-based.
You talked about AI tooling, and that just doesn’t work for, you know, your customer base, which works in very sensitive top secret environments in a lot of cases. And what’s great about your platform is you … Everything works local, especially in those air-gapped environments we talked about. But you do use those smaller, faster models that do improve over time and of, of course, get more efficient.
And you use the large language models you know, when needed of course. But really appreciate those insights. And Berk, last question of the day, as we look ahead, how do you see AI-native development environments reshaping how regulated and national security software gets built over the next five years?
And where does Noah Labs aim to lead that shift?
Berk Yilmaz: I think we are at real inflation point. Right now, the way regulated software gets built is basically you; you write the code, then bolt on a compliance at the end. You write the software, then you spend months assembling authority to operate package your system security plans, your security assessment reports, your SPOM your checklist files, and the list goes on.
And it’s all manual, and it’s very painful, and it’s basically disconnected from the actual development cycle. What AI native environments make it possible is flipping that entirely. Compliance becomes a byproduct of the development process and it’s not a separate work stream anymore. When Sentinel translates the code, the audit bundle every prompt, every model response, basically every test and every proof we generate automatically.
So, when you scan for vulnerabilities, the findings map directly to NIST controls SDI, FedRAMP baselines. And the AoT package isn’t something you assemble after the fact, it’s something that platform produces as you work. Over the next five years, I think the organizations that adopt this model where security, verification, and compliance are built in the developer’s daily workflow rather than they’re layered on top, are going to be move more drastic- dramatically faster than the other ones that do not use these.
And the gap is going to be visible in the pro- procurement timelines, in the time, time to ATO, and how fast you can modernize legacy systems and actually get into the production. And where does this Noah Labs lead? We’re building the platform that runs entirely customer’s hardware behind the security boundary with no data leaving the building, and that’s not a feature, actually.
That’s an orchestrati- orchestrational decision that most of our competitors structurally cannot make it because they are cloud first. And we made it on day one. And the government and the defense community ask for a tool that treats their constraints as features, not limitations, and we’re just the ones who, who are building it.
Brian Thomas: That’s awesome. And, you know, the platform itself, Sentinel, you know, works directly with the customer’s hardware. I thought that was amazing. It- ’cause you’re right, everything, again, we talked about that, is internet connected in some way. So, I think that’s phenomenal. And of course, today, regulated software is built, and then you add the compliance part afterwards, right?
It’s always the afterthought, and that doesn’t work. And I like how your platform, Sentinel, you’ve built in that compliance governance security from the ground up, which means that it is more robust, and it has taken into account everything along the way when it comes to those really sensitive and highly regulated environments.
So, I appreciate your insights on that. And-
Berk Yilmaz: Thank you, Brian.
Brian Thomas: You’re welcome. Berk, it was such a pleasure having you on today, and I look forward to speaking with you real soon.
Berk Yilmaz: Thank you so much.
Brian Thomas: Bye for now.
Berk Yilmaz Podcast Transcript. Listen to the audio on the guest’s Podcast Page.
