# BAML: New Programming Language for AI Era

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-07-16

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I'm your host, Tobi.
And my guest today is building a programming language for a world where humans don't read code anymore.
He's an early riser, which I appreciate because our pre-roll ran past 10.30.
in my evening and now he's letting me record this before his breakfast.
Is that correct?
Well, it doesn't look like that, Vaibhav, right?
It's a little later right now, but yes, I do tend to wake up a little bit earlier.
So welcome to the podcast, Vaibhav Gupta.
You're still quite young, right?
What did you do so far in life?
What have you achieved?
I mean, I've done like...
A few things, but not too many.
But most of my time was, at least professionally, was spent working over at Microsoft back in 2015, where I worked on the original augmented reality headset that Microsoft released, the HoloLens.
Built some of the most fun computer vision algorithms I've ever had the opportunity to work on, on very limited compute environments.
I then went on to help.
Worked with the augmented reality team over at Google, where we worked on getting systems running on extremely low compute environments, helped with things like Face ID and other systems like that.
And then eventually I went to go work at DeShaw, where I did really weird performance optimization work to make code run incredibly fast.
Most of my career was writing assembly code on bespoke ASICs, as opposed to writing high-level languages.
And then about...
Four years ago, I set on a journey to just start from scratch, start building a company.
And here we are today, building a program language.
As far as I know, you're also YC-backed, right?
And as many YC companies, you also pivoted like 12 times, right?
I hope most companies don't pivot 12 times.
We sadly did, is the way I'd put it.
But yeah, we actually, I would say we got into YC despite our idea, is probably the best way to put it.
YC gave us 500k to not build a Slack competitor.
We got in, we're building a Slack competitor, and they told us in the interview, please pivot.
Okay.
But a Slack competitor wouldn't be a bad idea these days, right?
I'd say.
I mean, there are many, but...
I think there are many, many ideas.
If you win.
There are many, many good ideas that people can do.
Like I said, I wrote Assembly for nine years of my life, 10 years of my life.
My co-founder worked on core systems at AWS, a core distributed EC2 type systems at watch parties.
We should not be building a UI-based product.
Like, let's be real.
Yeah, I think it would also be a bit bad if you wouldn't be building compilers then yourself, right?
Like looking at your journey.
We're better suited for a different kind of business.
I guess so.
So, funny enough, I've been a Rubyist for 20 years.
And you told me in the pre-call that modern software shouldn't be written in Ruby.
So this is going to be fun today, right?
Well, I think so, yeah.
Thousands and thousands of euros for AWS every month.
You know that feeling.
You're building fast.
New services, new instances, new databases.
Everything grows.
And so does your AWS cloud bill.
That is where Blox comes in.
Blox guarantees at least 20% less on AWS.
No long-term contract, no infrastructure changes.
How do they do that?
Big group buying discounts and AI optimization.
I have known Blox co-founder Andreas for more than 20 years.
I trust these guys.
They will help you getting cloud costs under control.
So if you use AWS and want to know how much you can save, run the free cloud check at blocks.cloud.alphalist.
That's B-L-O-C-K-S dot cloud slash alphalist.
Maybe let's zoom back a little.
So why did you actually start falling in love with computers initially?
So originally, I actually wanted to go through neuroscience.
I was in middle school.
And why did I want to be a neurosurgeon?
Because it was hard.
It was like the hardest doctor you could be.
And I just wanted to go do that.
And then later, I realized I freaking suck at biology.
It's not where my brain works.
It's not very, at least for me, it's not very creative.
And at some point, I learned how to code.
I had an idea one day.
My friend was like, we can build that.
I have no idea what he meant by that.
So I went back.
I watched him actually build it.
We convinced our school to use that software.
They paid us $500.
And I just fell in love.
The concept of an idea to being a reality that you can just manifest and then other people can use it is just...
I don't know how...
That's just beautiful to me.
I don't know how else to describe that concept and that feeling.
And once that happened, that was it.
From that point onward, I just built and built and built and I never stopped building.
If I could think of it, I wanted to make it happen.
I tried making a quadcopter once.
I lost $600 in college because I had a bug in my flight control I was riding and the machine just went up and had no way to do anything else.
It was a very expensive machine.
Oh, no.
I've bricked many Linux machines trying to understand weird things about them because I didn't know any better.
And in those early days, when I first was coding, I was just doing things.
And the fact that I could just do things, and yes, I would break things all the time.
It was like a puzzle that never stopped being done and just got harder and harder and harder all the time.
Until at a certain point, it just got much easier because you were equipped with code, etc.
How does that feel?
I mean, how was your first?
AI moment?
I was actually...
Yeah?
Yeah, I was actually not a believer in AI in the very beginning.
Like, yes, I worked on machine learning systems.
Like, I get what machine...
Like, we built these systems.
But like, I don't know if I trusted them to that degree.
Like, they're limited systems, at least the ones I worked on in the past.
But then when we were working in the startup, my co-founder, Aaron, my co-founder was a fabulous engineer.
But he's not a C++ systems engineer in that sense.
And definitely not back at that time.
there was a time when he came through and we were building our Slack competitor at that time.
And he was like, hey, I built this driver, Mac OS driver level thing that you thought was too hard.
I was like, how did you do that?
He's like, oh, I use GPT-3.5.
And I was like, and this was November of 2022 around that timeframe.
So it had just come out.
And that was it for me.
At that point, I was like, well, I fought it a little bit.
I was like, it won't be that big.
It won't be that, it's good, but not like phenomenal.
That was the first time I recognized it.
And then about nine months ago, 10 months ago, I don't think I've written code by hand since then.
I had to force myself to stop writing code by hand because I write code by hand pretty fast using cursor tab.
All these other systems were pretty good.
But then I actually forced myself for a month or two to stop.
And I was slower for a little bit.
But I've been measuring my statistics over the last...
few months and just every quarter I track it.
I've been looking at it over the last week.
I apparently have been writing 10% more code consistently every quarter.
And there was a jump where I 2x in the middle from a certain degree, but that number just is monotomically going up.
And I'm sure there's a ceiling somewhere based on what's happened right now.
And maybe I'm probably adding more slop.
So maybe I'm adding 10% more slop than I used to add.
there's definitely something happening that has changed the velocity at which I can write code.
And that is beautiful because I can do the part that I truly love, which is solve problems.
In a different way, right?
I don't know if it's that different of a way.
If you take the hardest problems that you worked on in the past, how much of that was actually the code?
Yeah.
Like almost all of it is systems design.
Like very, very little parts are like...
like, oh yes, this thing is the right code to write, even in high-performance assembly code.
90% of the system that we designed was actually like, what's a really good hot loop I can build so I can try five algorithms really quickly?
And it's not about the code.
The code is a means to an end.
Yeah, the code is often a very interesting little puzzle that ultimately also often doesn't solve problems, right?
I would say, I mean, you're...
looking at the kind of problems you solved, you're different from many other people.
I know so many people, honestly, that earned good freelancer money because they, I don't know, wrote a React front-end on some GraphQL back-end that someone else wrote where they, I don't know, literally built a form for half a year.
and earned a good salary from it.
And I think if I look at that now, and many of those are still, well, I mean, most people kind of converted, but many are like still whine after that somehow, right?
Many people are still said that they are no longer able to do that.
And also if I look at my personal Ruby history.
At a certain point, it just pisses you off to do again and again what you did so many times.
I don't know, another sign-up flow somewhere, another whatever here.
That's what most people do day on and on.
And I think it's a relief to not have to do that anymore.
I completely agree.
90% of software engineering, well, in most jobs, 100% of software engineering is plumbing.
If you're lucky to do any sort of thing beyond that, like systems design or assembly or any of these harder problems, even then, only 10% of your job is that.
90% of your job is still plumbing.
And AI just takes that 90% and just makes it go away.
And I love that part of it.
Yeah, absolutely.
I don't miss a thing, but maybe tell us a bit more about the moment in your career when you decided, okay, the next thing I build is a language.
I mean, that's what you do with BAML and you have to tell us a bit more about that.
Like, what was that moment when you said, okay, this is the thing?
And how do you sell a language to YC then?
Like, how did that happen?
So, like I said, we got into YC before we were working on BAML.
We actually got into YC.
So you had the money and you took the money and ran, basically.
That's one of the most of our money we've raised has actually been on Bamod's company.
But YC, I think YC historically, most very early stage investors bet on team more so than they bet on any one idea.
Because very few companies don't make some sort of directional change at some point in their life cycle.
And like Aaron and I are first time founders, it was unlikely the first idea we had.
was going to be the hit home run that we actually go through with all of through and through.
But really, I think it boils down to first principles thinking.
And before Python came out, there were a lot of hacks on top of C and C++ to make it more appealing.
You could do shared pointers, unique pointers.
I guess that's C++ 11 technically.
But the concepts still exist.
There's hacks on these lower level languages to make concepts become easier.
But there's nothing you can do in C or C++ to make it as convenient as Python.
And if you don't make that transition, well, then the number of people that are called engineers is strictly smaller than the number of people that are down to learn like pointer arithmetic and all this other stuff you have to learn.
Same with Java.
Like why does Java exist?
Well, because we have multiple operating systems.
And we can either write custom C code for all of them and target that and go deploy that, or we can just use a higher level system that solves that problem fundamentally.
Why does JavaScript exist?
Well, browsers came out.
We need a new way to write code that's browser first, an event-driven language.
Because that's what browsers are.
You click, you do other things, everything kind of happens in parallel, it's sequence-driven, it's a different concept.
Well, why does React exist?
Our websites went from being static images to very interactive components.
And suddenly, HTML templating doesn't really work really well.
You want type safety, you want all these other constraints that languages and logic has.
And if you think of it from that way, AI is a new type of compute paradigm.
Assembly was for hardware.
C was for Unix machines.
Java was for operating systems.
Python was for abstracting away compute in general.
JavaScript was for browsers.
BAML is a new thing that exists because we have a new compute primitive in the form of LLMs.
LLMs are basically just compute systems like add or subtract or any of the other things, but they take in data in and produce data out.
And having a language that makes these probabilistic, non-deterministic systems better with custom tooling built around that, I think is, maybe it's overkill, but someone might have said Python is overkill.
Just use shared pointers.
Someone might have said Java is overkill.
Just use custom headers in your C program.
Someone might say the same thing about JavaScript.
Just write a compiled program.
It's not that hard.
But these new systems sometimes, very rarely, but sometimes make dramatic impacts.
for what it means to be able to build on top of that framework for everyone downstream for decades to come.
And that's the bet that we're making.
Yeah, super interesting.
And if you could, do you have one way to kind of convert a CTO who's just wired up LankChain or Instructor or Pidentic AI and is wondering what they are missing?
Yeah, I think the best way to think about it is like...
How hard is it for your engineers to reason all this around this?
You have tons of abstractions, you have tons of code.
The number one win that you get when you use BAML is, one, you can use it from any language.
So unlike most programming languages, you don't write your whole code base in it.
You make it completely integrated into your existing system.
It's an embedded language.
So you can call a BAML function from Python or TypeScript or Go or Rust.
And it works exactly the same in all the scenarios.
But then more interestingly now is you can use that as a shared abstraction for swapping models out, testing different prompts, getting extremely high-quality structured outputs.
And we do all of that for you in a more centralized layer so that you don't have to worry about types and type systems.
And the LLM can now agentically code much faster.
The other thing we've done is we've made testing and evals a first part of the language because these are non-determinant systems.
So because testing and eval is much more simple, you wouldn't believe the number of code bases I've seen that have no tests that call LLM functions.
Well, yeah, of course it's not working.
You barely know what's running.
And then the most useful part is that once people use BAML, we have government agencies that use us, teams at SAP, AMD, Stitch Fix, Grindr, Keeper, Vetcove.
So ranging from major enterprises, governments, mid-sized startups and billion-dollar unicorns.
all use us because it's incredibly reliable.
We have some algorithms in there, not LLM calls, but algorithms that reduce your cost and latency substantially on not just open source models, but closed source models.
So there's just a few things that compilers can do that humans can't do.
Like every single place is just what the language does automatically.
Okay.
And stepping back a little.
what's the business model behind it then?
Like, are you implementing for your clients or are you, yeah, like, how does it work?
Like, how do you make money off this, right?
Because you're right, like, if you're a language, like, how do you trust that you're going to use this system?
And how do you know the system's going to be around for years if your business goes under or something?
We actually are working on a way to help connect.
Think about what TypeScript did and why TypeScript is so good.
TypeScript as a language was a bet that says your front end is written in the same language as your back end.
And that is incredibly powerful because you can ship code, get good guarantees that you're not going to make an API breaking change and your code base will be stable.
And you also don't have the trench between front end and back end, which also often comes in, right?
Exactly.
It's just one code base.
And that's very, very powerful.
And we've seen that be true.
But with non-deterministic systems, it turns out that you have another trench, which is your data trench.
Because you need really high quality observability and data to understand your system.
And today, you have your code base and your data, and they're totally different systems.
What we do with BAML and why we really set out to make a programming language is imagine your front end, your back end, and your data all speak the same thing.
They're all based off the same type system, off the same data.
They're all version off the same type system.
You change your type in your code base, Your database is now segmented and your old data lives in a different partition than your new data.
How do you do that except without a type system?
And that's kind of what our cloud system does.
It helps bridge all three together and brings the type system into the data layer.
So you have similar to Protobuf protocol embedded that kind of translates data.
between different languages, etc.
Or how does that work?
Exactly that.
So we have like a serialization format that allows you to send data across different languages.
We bridge all the types together and we also use that same format to send data across the wire to our cloud system.
Okay, interesting.
Whenever I talk about what scares me in AI, like as someone who owns many SaaS companies, it is the moment when software writes software or AI writes software without letting you know it does, right?
Like without you explicitly asking it to code something, it codes something.
And then like I always say like, hey, there's no, whenever it does that, like there's no team function, right?
Because there's no exchange between stuff that you accidentally coded and I.
Do you see a world or are you kind of an enabler of that?
Yeah.
In my theory, I agree.
We talk about this a lot on the team.
The premise, we can now generate code at machine speed.
That is a solved problem.
There's no human that can write code faster than a machine can today.
It's impossible.
But we still cannot ship code at machine speed.
And the reason is, like you said, I don't feel comfortable letting a machine write code automatically and deploy it without me being at least a little bit in the loop.
So how do you solve this problem traditionally in software?
Well, the way that we got to shipping software very quickly is we added CICD.
What did CICD do?
I hired a really big team.
Well, we'll add tests so that whenever every engineer merges code, we have some guarantee that not everything is breaking.
Things might still break.
But we have some guarantees and we accept that level of risk along the way.
But with an agent loop, CICD does not work.
It is not rich enough because...
In the human world, there's some assumption that humans are communicating ideas with each other and be like, oh yeah, don't change that abstraction because it's going to be useful six months from now.
Change this one because we have a new feature that we're unlocking for these users.
There's communication that's happening.
In the agent world, God knows.
They're just going to change everything.
So what you need is you need a way to lock the code base.
Imagine you could say, this is a public-facing API.
if this API changes, like the signature of that API changes, have this human or this other agent review it.
Don't just automatically merge it.
How do we do that today?
Languages aren't designed for this kind of concept.
Our type system and our versioning system actually kind of gives you that for free.
Whether you want to do that is up to you.
That's like CICD.
How much do you use CICD is up to you as a company?
but where you use it, how much you use it, those controls should still be available.
And that's kind of how we think about it.
We need a time dimension of our code base where we want to say, lock this until a specific person approves this.
Everything else, auto-merge.
And I think that level of granularity isn't really available today in today's code bases.
It's very hard to build that out.
And how does that workflow work in your case then?
You want to see?
Can I show you?
Yeah, sure, sure.
Do that.
I think it's a lot easier.
I think I have something open.
It's like one of the things open.
The first podcast ever where someone shares its screen.
I'll show the code in a second, but this function is a function and we are actually able to understand all the functions in your code base.
We can capture data off of all of them, but every single function gets an automatic version.
As the versions change, you can actually tell what changed.
The first number means that the type signature changed, if it changed.
The second number means that the implementation of that function somehow changed.
So here, the type signature changed.
But here, the type signature is the same, but the implementation is different.
And we can actually give you that information.
Now you can imagine putting a CICD lock on saying, do not let this type signature change.
But the implementation, I don't care about.
You might even lock the implementation.
Don't ever change the implementation of this function.
And these weird kind of controls, that's kind of the idea.
Does that help answer some of this question?
That helps, yeah, that helps.
And the system that you're just showing is basically your own traceability system that you added on top, which you are selling?
Yeah, so this is super beta right now.
This is not open source.
This is still closed source, but our language is fully open source and runs without any dependency on the cloud system.
Okay.
It turns out modeling a type system in a database is incredibly hard.
So it's taken a little bit of work to get this to work, and we're still making it more advanced, like modeling ideas like closures and other programming language concepts in here.
And being able to build that sort of dependency graph, like generics, they're tricky.
And being able to build that out just takes time.
I can imagine.
But it really sounds like a super interesting problem that you're solving there.
Are there any other languages that you compete with that people came up with because they see the same problem as you do?
I don't think so.
And I think it's because it was okay to have human-gated systems before.
It was never a problem.
But if you...
And the companies that really cared about this are like Facebook, Google.
They really care because they have a hot loop.
When they do their machine learning systems, they want to auto-update their code all the time.
They want their models to auto-update.
And they did actually solve this problem for themselves, which is they invented Protobuf and Thrift.
And that was their solution to this, which is we're going to have data that you have to describe the data contract in this one place.
And thou shalt use Protobuf inside all of Google.
all the tools in all of Google will be built on Protobuf.
And then Facebook will be the same.
Exactly.
And what, gRPC is built on top of Protobuf.
Yeah.
Because of that reason.
So once they did, that's how Google saw this problem.
But no one else has the engineering bandwidth to just sit and solve these incredibly hard type system problems with good developer tooling.
And like, why does no one in the world use Protobuf?
Like, very few companies use Protobuf.
Because it's a pain in the ass.
to try using.
If you ever use Portable in Python, it's disgusting.
No one as a developer will look at that and be like, ah, that's beautiful code.
And code should be artistic.
Part of why people use, why do you like Ruby?
It feels artistic to you.
It's a very good way of expressing ideas.
And these systems aren't built for that.
They're built to be good enough to solve the problem at hand that is at Google scale, which is collect really good data, highly versioned data.
And then so we can do analytics on it later.
Okay.
Yeah.
Super, super, super interesting how you, how you ended up there.
Did you, did you see that happening at Google or were you yourself using protobuf and knew the pain or knew the concept of it and then said, okay, this kind of fits in here into this, this, this new kind of problem or.
We kind of had the protobuf idea from the very beginning.
But the problem with Protobuf was that it was ugly.
We focused a lot on making the language, I don't know, at least from ours.
I won't say it's objectively pretty because everyone has their own view on programming languages, but from our perspective, pretty.
And a consequence of that is agents are good at writing it.
So that principle when we thought about this was these core problems like version data structures do exist.
And if you don't have version data structures, you have polluted data.
Because imagine you're doing a classification problem and you're running it for like a million people and you have 50 categories.
Then your engineering team adds three more categories.
Well, all your previous data samples are not useful for this new categorization system because picking category one out of 50 is different than category one out of 53.
They're just different problems because the categories might overlap, they might be disjoint.
And you have to be able to get that from data.
And building that system is like, most engineers mess up and therefore end up with bad data.
And a half-broken system.
Yeah, absolutely.
And like you said, at Google, it's everywhere.
Did it really, or like Protobuf is everywhere, did it really distribute to that extent that like now, I don't know, Gmail is also using it and like almost every tool is using that?
Yeah.
Okay.
It's also phenomenal in a way that an organization of that size can actually have shared libraries, right?
Or shared...
I mean, it's not a library, per se.
Google has one of the best...
Google and Facebook have some of the best engineering cultures in the world.
They devote tons of...
They have entire orgs whose only job it is to make every other engineer at Google 1% more effective.
So they invent all sorts of tools.
Google's tooling is the best in the world.
Every single thing that Google built internally as an internal tool, I think could be a billion-dollar SaaS company.
If the world adopted the rest of the tools, but they won't.
The problem is it only works in that closed ecosystem where set up and everything is done for you.
We tried to set up things like Google has a build system called Bazel or Blaze.
You can't set it up.
It's so hard.
to use outside of the Google ecosystem.
And how easy is it to get started with BAML?
What's the easiest example?
How does a Hello World look like?
It's probably...
You literally just go here.
You copy the agents.md that we have.
You don't even need that.
All the models are trained on BAML at this point.
So there's no actual work to do.
But you just got to...
Let's go to...
What am I doing?
Ghosty.
Ghosty, actually.
I'm a big fan of Ghosty.
So for the ones that can't see that, he's creating a directory?
Yeah, I made a directory.
I'm initializing a basic Python project.
But again, Bama works in any language, so you can use any of them.
Claude.
paste, make a program that, I don't know, like, takes in a user message and classifies its sentiment.
That's all you need.
Why did you call Claude and not YOLO?
I have thought about using, like, Codex.
Oh, you mean, oh, I do run Claude in YOLO mode.
Auto-accept everything.
Yeah.
I just YOLO everything.
And then it'll set it up for you.
It'll install everything, set up virtual environments, and it'll set up Python and just do the whole integration loop.
And if you have any questions about it, you can just ask Claude to explain to you how stuff works, and it'll just work.
We obviously have docs.
We have our YouTube channel where we describe concepts.
And every Tuesday, we run a podcast with Dexter where we talk about interesting things about...
agent engineering.
So one of the things that we did a while ago was we had Jeff Huntley on, who was the creator of the Ralph loop three months before Ralph got popular when he first made Ralph.
And you can see it just works.
And now the system is just working along the hood.
So it's very, very easy to get started.
You can see the code if you want.
Because code should be pretty.
All right, boom.
Okay, just created a tree.
Yeah, it generates something really simple.
Like this is a function that generates, it just generated a BAML file.
Everything in BAML is actually, this is actually probably been the most insightful thing that we've done.
A lot of people are used to using Claude and OpenAI through interesting mechanisms like chat, you have to use OpenAI SDK.
So you end up doing like OpenAI.chat.completion.responses or something, or like anthropic.messages.responses.
We said something else.
What if you just model everything as a function?
Functions have inputs, functions have outputs, and then you can write tests that help you understand this really well.
So I can just test this.
Oh, Cloud3 Haiku, why is it doing that?
Let's use Haiku model.
Haiku latest?
Okay.
Haiku is missed out.
Haiku is misspelled.
Thank you.
We're doing live coding here in the podcast.
I don't actually know what the Haiku model is called.
Anthropic models have the worst names in the world.
We actually ship some of them for you so you don't have to guess anymore.
There you go.
Let's use this one.
Claude Sonnet.
Yeah, that always pisses me off.
And right over here, the model messed up.
It put back to JSON.
We corrected it for you.
And we just fixed the mistake.
So the value prop is as a model runs everything, this function is guaranteed no matter what to always return a sentiment result object no matter what the model returns.
And the sentiment result object is defined above?
Yep, it's like here.
So you could say answer with some reasoning as well.
So now if the model includes some reasoning, like it added some extra tokens down here.
all of those just got dropped.
You don't have to think about it.
You only got the chunk of data that you cared about.
So there's no cleanup work for you to do as an individual.
No matter what the model sends back, no matter what noise it sends, no matter what mistakes it makes, we'll always give you the right data back.
And in the background, this all translates into Python?
Nope, it actually all runs in Rust.
It all runs in Rust.
Okay, to make life a bit more fun.
To make life a little bit faster.
is the way I'd put it.
Sure.
And all it's doing is calling a web request.
So we actually call this from Rust and we have a compiler and a runtime and then it goes through, calls a Rust function.
And what you get in Python is a beautiful example where the classify sentiment function actually gives you a sentiment type in Python.
Ah, okay.
That makes sense.
That makes sense.
So you really have that type in Python you can use and it's safe to use?
Exactly.
So if I change this, for example, to a sentiment array, well, this thing becomes a sentiment array too in Python.
So the idea is the type system across BAML and Python is one and the same.
And you can do this in any language, like I said, not just Python.
So what a lot of people end up using BAML for is actually you can write your backend in the language of your choice.
and have BAML generate types for your backend and functions for your backend.
And also at the same time, have BAML generate React code that you can call on the frontend.
So now you have your type safety, and you're not limited to just using TypeScript for your backend, for example.
If you care about performance, use Go, use Rust, and share types for free.
Cool.
That's really phenomenal.
I mean, you have the same with Protobuf, in a way, if you use Protobuf, right?
Yeah.
And you're the same with OpenAPI.
All these things offer that, but we have that with logic, with AI as a first-class citizen, and we don't have a disgusting developer interface.
Understood.
In the pre-call, you suggested that we talk about how to ship code at agent speed.
Yeah.
So let's go there.
What does that actually mean from your perspective?
What's changing right now?
I mean, we see things no longer really working, like pull requests kind of are too slow, etc.
How do you get there?
How do you ship at agent speed?
And why does it change that?
Yeah, this is my two cents.
I think shipping code is merely a matter of trust.
When do we merge code?
When we trust it.
If you have highly sensitive code, well...
Even code reviews are not enough.
You code review with a specific human being.
You're like, this person has to approve this code review for me to merge this in.
When you have code that's less sensitive, it has to pass the ICD, and that's good enough.
And depending on what level of trust we have for different subsystems, we merge.
And today we've gone to the point of, hey, if the PR looks simple enough in my brain, I'll merge it without reading any of the code.
And sometimes I just read the title.
And the title is good enough, I'll merge it without reading any of the code.
But all we're really doing is we're shifting what trust is and what the meaning of trust is.
And as we have more trust in the underlying infrastructure and the units of work that are happening, we ship code faster and faster and faster because we do less and less verification.
So to ship code truly at agent speed, you have to ask, what does it take to remove a human out of the loop and not even require them to go look at the code?
And I think to some degree, I have to feel, at least for myself, that the decision that the agent made is bounded within some part of my code base, maybe not all of it.
I know it for sure has not changed certain things.
And if it has, I will review them, but everything else is fair game.
And what things I allow and pass that boundary changes how fast I can ship effectively.
And instead of requiring human attention on every piece of code, you want to selectively choose where human intention is being applied.
And I think that's what it means to ship at agent speed, which is reducing the amount of your volume of code that requires human attention.
I think we will soon see very good visualizations for code reviews, etc.
Oh, you want to see that?
I can run that.
If you want to see that visualization, I can show you.
So one of the things that we've been working on is exactly that.
It's like, how do you visualize code?
instead of visualizing code at a very high level.
So check out this pipeline.
This pipeline is going to be two folks on a podcast.
Sorry, I still see the white screen.
Oh, let me try sharing the whole screen.
All right, can you see this now?
Yes.
Check out this pipeline.
It's actually just running code.
You don't even have to know what the code is to understand that it's running code.
And this visualization is just as rich as the code base, but it's kind of like Python.
Yes, everything touches memory, but Python is easier to read than C.
We think this is easier to read.
And you can click and this jumps you to an exact line of code.
So you might say, hey, this thing is a little shaky.
Let me go inspect this part of the system really fast.
And you can imagine seeing a slightly more complicated pipeline.
where you can just quickly go through and see what the PyBind does.
And the point is, you may not even care about certain parts of the code, but you could imagine seeing a diff of this code base where it shows you two graph diffs.
I wish I had a local diff running.
A red box, and you click that red box, and there it really changed, right?
Exactly.
And you can see how that would be much faster and much more efficient than literally looking at this arbitrary code.
And since this is a thing that can be this is immune to refactors because you can move this pipeline to a different file and it's still the same thing.
And yes, if you rename it, we lose some information.
But renaming is done much less rarely than actually changing control flow.
And we made it more easy to see things being control flow changing rather than names changing per se.
Does that kind of make sense?
Absolutely makes sense, yeah.
I mean, that is...
Obviously, a big game changer if you compare that to how people right now review pull requests, right?
Yeah, you can imagine going to GitHub, having a Chrome extension that just visualizes this for you right away instead of the actual files.
Yeah.
I still ask myself, or I still see many things, many people not necessarily swapping languages, but just having better visualizations with kind of...
aimed for the same thing as you do, right?
How do you see...
What's your path to world domination then with this?
I think that sort of stuff is not really how I think about it.
Our goal is to build the best tools for agents.
I want agents to have a beautiful time writing this language.
I don't think React tried to have world domination.
React just builds really solid engineering.
And because it's good, you just use the thing that's good.
Our goal is not to try and be like, shove this down people's throat.
There's no amount of money I could pay a CTO to use BAML because it's extremely high risk.
What I can do is I can show them, here are the other people that use it.
Here's how much money they saved by some of the stuff that we have built.
Here's how much infrastructure is more stable by using BAML.
Do you want to try using BAML for one function in your code base?
And because it's incrementally adoptable, you can write it in BAML and use it from any language of your choice.
You can just write one function and you can see how good that part of your code base is.
You can see if agents struggled with it.
You can see if it's stable.
You can see performance.
And if all those meet your requirements, I hope that you choose to write more BAML.
I hope Claude chooses to write more BAML.
Okay.
Yeah.
Well, convinced.
I have to try it somewhere in my next project at least.
And what's the biggest application of BAML you know?
Is there any you can talk about?
Or I guess a lot of NDA then?
Yeah, we work with some things that I can't share.
But people process, let's say, I know there are some businesses that do close to high seven figures, eight figures of revenue built purely on Campbell.
I can't say how much data the megacorps that use this process, sadly.
But by their names, you probably can estimate how much data they might be processing through Campbell functions.
SAP is not known for having a small chunk of data.
So the best use cases are really long lines in building rag systems, agents of any kind, all the way from like browser agents to like CLI agents.
Streaming is the number one use case for BAML.
Or like if you want to do really nice streaming, BAML does beautiful streaming with extremely good type safety.
If you want to build type systems where you want to have your users define, code.
BAML has a type system that can be defined at runtime and compile time.
So people use this often to say that here's our pipeline and this part of it will let our users control as long as they match our type system.
And that's a very useful tool in the agentic world.
It allows you to increase your customer base without increasing your engineering burden on your team.
So there's quite a few use cases.
They're all built in.
The CloudMD will can help you.
If you just tell it, I want to go do this kind of use case, it'll just build it for you.
It's like one shot for most things.
So, okay.
So for people that want to try it, like they just use your agents MD as you described, right?
Where can they find it?
If you go to our doc site, docs.bamil.com, there's a tab that says agents MD.
Just copy and paste that file or go to Claude and just say, can you get the BAML agents MD file?
It'll just get it for you.
Okay.
Yeah, cool.
Cool.
Then try that out, folks.
Then, As you're someone who's dealing quite a lot with the future of software and programming, I'd be curious, and also you mentioned something in the pre-call which really fascinated me.
So I'd be curious on your view on software.
What fascinated me in the pre-call was that you said that the world has mathematically infinite appetite for software.
Can you maybe dig a bit deeper there?
Because I think many folks right now are scared.
What will happen to software?
Will it survive in a way?
How will it look tomorrow?
What's going to be my job then?
How do you see that?
To me, software is very artistic.
It's a beautiful form of expressing ideas.
So I might be very biased in my views.
I don't think we've yet found a company that hasn't found that I can make more money if I write more code.
And it seems to be asymptotically, like it's not even asymptotic.
It just seems to be true.
And every single company in the world writes more code, makes more money.
And it doesn't mean all the code you write makes money.
Sometimes to make your next percentage, you have to double your code base.
And it's not like a linear curve of like lines of code to revenue made out.
But it seems to be...
effectively true that you can never stop writing code.
So I just don't see a world where software dies.
We will write code forever.
And whether or not humans are necessarily writing code and if the job is actually writing code, I don't know.
But I don't think the best part of the job was ever writing code.
The best part of the job was solving problems with this tool that we have, which is code.
And that doesn't go away.
That will always be true.
Solving problems and the fact that machines, you can manipulate these bits to make value appear for other individuals.
That isn't going to change.
It's potentially dramatically exploding in adoption and the amount of builders will potentially change.
I don't know how you see that.
I think it was Jason Fried who recently wrote a LinkedIn post that from his perspective, they're either the There are two types of people, the ones that like computers and the ones that don't.
I don't know if it's that simple.
So he basically said that he doesn't see this really dramatically changing.
How do you see that?
Will we have more builders?
Oh, yeah, 100%.
The number of engineers that happened after we had Python compared to C is like order of magnitude.
The number of builders after C, after we had C instead of assembly, in order of magnitude more.
The number of builders that we have after cloud code.
is an order of magnitude more.
That's definitively true.
Anyone that doesn't believe that, I think, is like, not everyone has a time to learn memory models and pointer arithmetic and all this other crap.
Like, some people just want to build stuff, and they can be fabulous engineers without knowing syntax.
I think we will have engineers who have no idea how to read lines of code.
Just like today, we have engineers who have no idea how to read assembly.
That doesn't make them not engineers.
And the definition of an engineer will definitively change.
I don't think we'll look at like, oh, do you know what an if statement is?
Well, maybe an if.
Well, maybe I'm wrong.
But I don't think we'll say that like, you probably need to understand branching as a concept.
But maybe we'll all look at that visualization I showed and be like, that's code.
And performance optimizers click on it and look at the lines of code and actually make the lines of code correct.
But 90% of us just look at the visuals.
And that's good enough for us.
Yeah, I guess most people also don't know how to read or write assembly, right?
So in a way, it's an abstraction layer, which is like an interesting abstraction layer because it's not really one because it's non-deterministic, right?
And that changes things dramatically, which you also change or which you saw, right?
And are now changing.
I think it's just, we just need to find the right abstraction layer that gives us that same feeling.
of not having to read lines of code, but still lets us go all the way down to assembly when we have to.
Like Python is successful, not because it's a high-level language.
Python is successful because it's a high-level language where a very small percentage of people can write custom C and assembly code so the rest of the Python world can have NumPy.
If NumPy doesn't exist, TensorFlow doesn't exist or PyTorch doesn't exist.
If those systems don't exist, we don't have widespread machine learning systems.
We need all of that to make it happen.
And everyone in the world is like, English is the next programming language.
My point is that's completely false.
It's impossible.
And the reason it's impossible is because English can't go down to assembly.
And it's not that English needs to go to assembly.
It's that we still need that 1% of developers to write something like NumPy or PyTorch.
So 99% of us can build the incredible things that we're going to build on top of it.
And the minute you add that to English, what have you done?
You've built a new programming language.
And for our hope, it's that spam.
And I guess you're then also the first, you're building the first language which is fully written with AI, right?
Yeah, we strongly recommend people not handwrite it.
Just use an agent.
Stop handwriting code.
Yeah, I agree.
This shouldn't be happening anymore.
So what I also wanted to touch, as I told you, I run a portfolio company of bootstrap B2B SaaS companies.
So we have roughly 30 of them.
And your thesis says I should be more bullish on each of them than ever.
Convince me or push back on me?
No, I 100% agree.
I think...
Especially in today's...
I think there's short-term bullish and long-term bullish, and they're two separate things.
I think short-term bullish is that very few people can leverage AI.
You're a very, very experimental human being who's going to try new things.
That means that each of your SaaS businesses has higher alpha relative to each of your other competitors in the same space because you might be able to leverage AI and run more experiments than your other competitors will.
I think that that is a case for short-term bullish.
Long-term bullish, I think SaaS is going to change.
I don't think SaaS in the traditional form will work long-term.
I think what we need is like PaaS will work more likely.
People want data as a service or platform as a service and nothing else.
Because every SaaS app can be built.
What I really want is I want a platform where I can...
Remember what I said earlier, we have a way for people to bring in their customer control floor or something into their logic.
That's what everyone will want.
I want 90% of your system and 10% of it built exactly for my use case.
And I want to plug it into your system.
I think if you can do that with each of your 30 businesses, I'm super long-term bullish as well.
So literally a system of record where you can store whatever rules you have.
for your business to run.
Not even that specific idea.
I think take any custom SaaS, like take Slack.
What do I want to do in Slack?
Slack built a stupid workflow engine.
I really just want to write arbitrary code and eval it on Slack servers.
So then I can write my own workflow engine with Cloud code.
What is Cloud going to write better?
A custom data structure that Slack ships or arbitrary code?
it's obviously going to write code way better than the data structure Slack ships.
So just let me write code.
But that comes with security concerns, that comes with infrastructure problems, that comes with homogeneity.
And all these systems are really hard to build up.
And eval is a known security...
Remote code execution is like, we all know how dangerous that is.
So how do you do that safely?
How do all these things?
That's kind of how...
That's what I think the long-term business is.
The companies that are most successful using BAML...
all do this.
They inject and cut even the largest companies.
They inject into shapes and the choices by customer defined data models and they plug that into their orchestration loop.
Everyone is basically a harness.
The customers define the data models.
You're the harness that actually stitches everything together, composes all the data, pulls all the context, does all that stuff.
That's what I think.
If I wanted to be super bullish on you, that's the direction I want, especially long-term.
that's the direction I want to see each of your SaaS businesses move in.
Yeah.
I also see that this is automatically happening as demand is changing, right?
And the other supply as well.
And you kind of have to orientate, like reorientate and restructure.
Pricing models are going to change most likely, right?
So seed-based is potentially no longer sustainable long-term.
Yeah, usage-based everything.
Yeah.
But that doesn't necessarily make it cheaper, right?
I think that's...
Everyone's going to charge more for everything.
Yeah, I think potentially that more and more of the whole onboarding and time to first...
success moment will be way shorter, right?
And that this is something you really have to optimize for as someone who is a founder of whatever company, right?
Do you remember the fake door test that people used to do?
Yeah.
It's like that, right?
You don't have to build the product.
You don't see people are willing to click on it.
Yeah, yeah.
But now you can build a prototype.
That's the only difference.
You can have a real door or like, I'd say it's like a very...
a breakable door test.
Now you can have a door that will work, but definitely break.
Yeah, yeah, yeah.
Well, it breaks later then at some stage, right?
Because it's not compatible with what you built before, or in many cases.
In the BAML case, it is, right?
Because it uses the same types.
But yeah, I think you're absolutely right.
And I think that, yeah, many people...
don't yet really see that future, clearly.
And like one recent example, or I think partly the front is going away as well, right?
Like people, I mean, I'm super lazy.
Like I love doing things through Claude now.
And I don't see, like there was, I think it was Greg Orchick recently ranting that design is going to become more important.
I am not sure if that's going to happen, right?
Yeah, I mean, Airbnb for...
I've thought about this a lot, actually, the design side.
Yeah.
As much as we as engineers love terminal, remember, the definition of engineer is going to change.
So more people will use software to build software.
I actually agree with everyone else.
I think design is going to be more important.
Yeah.
But I don't think in the traditional sense.
Because like, look, if my mom...
Let's say my mom has an example.
Imagine my mom wants to be an engineer by our definition of a builder.
Cloud code will enable that.
But do you really think my mom is going to open ghosty, type in cloud and press stuff into it?
No chance.
Most likely not.
Yeah.
Exactly.
Right.
So something will have to be there to replace that.
And then do you really think my mom wants to read a markdown preview?
Or do you think she wants to see a website that's interactive as the output?
it's almost definitively she wants an interactive website.
So like, if we assume that the number of people that are engineers is going to expand by 10x, well, we have to think about the needs of those 10x people more than the 1x people that we have today.
And those people are not terminal people.
Those people are like, just like, you go back to like the early days.
I remember when people used to make fun of me that I didn't type in Vim and I used like an IDE.
Like, does that make me a worse engineer?
Like maybe, but I'm still an engineer.
And it's the same thing.
And I think design will matter more because the volume of people that use it is going to be much higher than the volume of people that use pure terminal.
Interesting then that there's not so much focus on those people yet, right?
I mean, if you look at Claude and...
Yeah, we're not there yet.
Yeah, it's a bit clumsy.
Like I just tried getting like a set of MCP servers running on a...
on a CEO's computer on Friday and it was awful.
It was awful.
You could use it in your terminal and then whenever you touch the desktop, it wasn't working anymore.
You need to edit config files to make it work.
It doesn't really work.
Yeah, these systems are not...
FFmpeg, good luck trying to teach a non-engineer how to use FFmpeg.
It's not built for that audience.
That's why people pay all this tool for converting one image type to another image type because the CLI tools are too expensive to learn how to go do for this skill set of individual.
I think long-term, it's going to be different.
I think long-term, people will invest in that.
Now, the magic moment in the market for people trying to build stuff is, can you time the market and build it at the right time so that you're ready when that market is there?
Let's see.
It's not going to take long, I guess.
So slowly coming to the end, I still have a little surprise for you.
I love surprises.
It is the at time travel decorator in BAML, which you potentially don't know.
But Aaron, your co-founder, told me about a hidden decorator that only your staff engineers know about.
Time travel, and you give it a year.
wraps any function in it and the runtime emits a typed advice return value back to your younger version of yourself.
So schema aligned parsed, of course.
So even your parsed self can't malform the JSON.
And we are now going to send it to you in 2017.
When you were on the HoloLamps team at Microsoft.
And yeah, deciding whether to stay on computer vision or go somewhere else.
And you now can whisper something into your younger self's ears.
What would it be?
Like stop chasing HoloLens, I guess.
But what else?
What's funny is I actually got the advice that I wanted to back then.
Well, probably what I'd say is buy Bitcoin.
It's going to do really well.
Way better than you thought.
That's just a joke.
What I really got was actually really good advice from a really good friend, Yesen, back then.
Funny enough, around the 2017 time period.
An advice that he gave me that I really liked was I very much wanted to aim for retirement.
Back then, I was like, I've been working for two or three years.
I was like, how do I retire?
How do I retire really early?
And I was well on that path.
But he asked me a really foundational question that shifted my whole worldview.
which was what would you do if you were to retire?
And firstly, I realized I don't freaking know.
I just love coding.
So I guess I'd code more.
And what he said was like, okay, well, like, then why the heck do you want to retire?
Just do the thing that you do when you retire now, even if you make way less money doing it.
Because what's the point?
And like, I think that fundamentally shifted my view.
Like I never chased a job that has the most money.
solve the thing that you want to solve for in life, whatever it is, whether it's travel, whether it's food, whether it's whatever, go do that.
But probably the real tangible advice I would give myself on top of that was like, spend way more money than you think on things that you want, especially things that give you a lot of happiness.
Much later in life, I read a book that, or I listened to a talk about someone that came up to Google, which is like, for things that give you the most dopamine in life, spend four times as much money as you would normally on it.
And for things that give you no dopamine, spend nothing.
So I sit in economy seats in flights and I don't care.
It's like, no problem.
I love the middle seat.
Give it to me.
I don't care at all.
I'm either sleeping or typing on my computer anyway.
Exactly.
Even if I want business, it doesn't give me dopamine.
But I love eating nice food.
I love taking my friends out to eat good food.
That's a fantastic thing to do.
How do I spend four X more?
I take three of my friends out to meals.
and I'll buy their dinner for them at a wonderful place that I'm excited to share with them.
And I wish I did stuff like that more when I was younger.
And I think it would have foundationally shifted a lot of my worldview a lot earlier.
But the other thing I'd say is like, learn this machine learning stuff faster than you think you need to.
I sadly learned it too late.
I was a non-believer for a long time.
But I wish I had...
started not just from the classical computer vision mathematics, but actually more on the ML side a little bit earlier.
Okay, yeah, that absolutely makes sense.
Like both advices.
Thanks a lot.
Thanks a lot for the podcast, Vibev.
This was tons of fun.
Really great having you.
And the first podcast where someone shared the screen at CFA for listeners.
If we're going to talk about code.
how do I describe code?
Imagine someone describing Python to you and you've never seen it or heard it.
Good freaking luck.
No chance.
So hopefully if people are interested, they'll check it out.
They'll get to go see what it is and maybe try BAML for themselves.
Yeah.
If you didn't see the screen share, don't worry.
Go to the BAML website.
Check out the AgentsMD, I guess.
Yeah.
Get to know it there.
Fun story if you search BAML on Google.
It used to be rank two behind Bank of America Merrill Lynch.
We're now rank one.
Very good.
Very good.
So yeah, and SEO, you landed in the SEO world as well.
Accidentally, I guess.
So, Weibov, thanks a lot for being here and looking forward to see you in real life at a certain point.
I think you're actually coming to Hamburg to the CodeTalks conference.
I am.
I will be seeing you there.
We are seeing each other there.
Looking forward to that.
And thanks a lot for the great stuff.
This was tons of fun.
Thank you for having me.
Thank you for listening to the Arthelist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.