Bauplan
Getting Started with Bauplan
Today I have the pleasure to host Yakopo and Chiro. Both of them are the founders of B plan. Hi. Hi Akopo. Hi Chiro.
>> Hi.
>> Hi there. Thank you very much for having us.
>> I'm super happy to have you. And can you start first by introducing yourself then let us know more about your company?
>> I mean sure >> I can start.
>> Go ahead.
>> I am I'm Yakopo. So 10 out of 10 for pronunciation. Congratulation on that.
It's not very easy. Everybody calls me Apple. So that you know like you know we can we can we can usually don't go through all the process. I'm the CTO and founder of BPA. I used to be the CTO
founder of Tuzo which was our previous company. The previous company was doing mostly NLP for information retrieval.
Then after the company got acquired um and we led AI uh and data at the acquirer we decided to build a second company which is which is BLAN as it's not our first uh it's our first company
as I always say you know fool me once shame on you but fool me twice so it's not exactly we didn't know what we were going to get into so thanks so much for having us and of course you know big
proponents of the open lake layouts approach so I'm sure we're going to talk a lot about that today off to you I am Chiro I'm the the co-founder and CEO at Boplan I'm also from the team that built
Patuso. We co-ounded a company together and then we stuck through the acquisition, the IPO and all that. Yeah, I spend most of my days like doing you know machine learning NLP specifically
and then kind of like built incidentally a lot of data infrastructure to support those use cases and when the time came we kind of like wanted to build a platform that we think is to a certain
extent is a platform we wanted to have when we had to build a lot of those in of those um platforms to support machine learning and especially like the data management the data transformation thing
and Boblin effectively is is a lakehouse is a is a kind of like a very simple uh and pythonic lakehouse house. There are a number of assumptions in what we're doing um around that but but I guess
like the the gist here is that we focus a lot on data transformation and data management. We definitely buy into the open lakehouse design and Bablan is in one word is the simplest data stack that
we could think of because we think that data platforms are honestly too complicated.
>> Yeah. And uh I I can get your I can get your point and I so like Yakopo shared with me the uh let's call it a blue blueprint or a paper you wrote about the lakehouse. Can you maybe both of you
walk us through this paper and then we can talk a bit about the lake house?
>> I the the one at the uh yeah I think so.
Yeah. Yeah. The general phil you know why philosophy like so when we set up papers it's hard.
>> Yes. Yes. Is yes it's hard to remember which one which one which one we did which one we did when how with who but the general feeling you can find the same idea in many of our uh of our
writing so far. It's kind of twofold.
One like I was it's a fantastic idea. We did our first company stack on the data lake. You know it worked for us but it was kind of like meh. Uh then we went we went to leave the warehouse word it
worked for certain reason and you know again May again and and when we find out you know the original vision of the lakehouse but you know Renald may much people's like oh my god this is awesome
this is obviously when the next you know data stack where you know when the enterprise data stack of the future is going to be and we like the object storage layer so point like we really
like the unified you know data stuff and we like a lot the optionality in the compute Which gets me to the second point. So if you get this lakehouse idea when there's a unified data layer, you manage data
together um and data is object storage light and compute is all ephemeral then you can go and pick and choose different compute model for a certain things which get to our second let's say unique
insight that we have which is there's an entire class of data workloads that are better served by a fast runtime like functions of service. You can think of like AWS that are not well as well
served by other you know uh typical compute model on the lake layout like you know the one job per cluster model or the SQL engine model fast in between and I'm sure we can go into that more
but like we highlighted that as kind of like a missing niche in the market like we love the lakehouse of the openness there's a bunch of stuff that we can run without asking clients to move out of
their object storage or unity catalog whatever and the price performance of this certain specific set of market is better served by functions of service.
So the only thing left to do was to build is to build the freaking thing which of course is a lot of work but we wouldn't have started if we didn't have at least this generalized view of how we
fit into this broader ecosystem that has been pioneered by the the cost paper by ver data bricks. Yeah, that was I think back in 2020 if I'm not wrong.
>> I think I believe maybe a bit later but was the cider one was the cider the cider paper uh which are like Berkeley Ali Mate and Brainald from of course data bricks and a bunch of people from
Berkeley. Yeah. And I think it's very important to let people know that for the lake house we're we're bringing the best of the two words like the best of the data links and the best of the data
warehouse in in one word and this is this is super important because in the data warehouse you had to for example if you are scaling the compute then you're automatically scaling the the capacity
which was which was big like pretty expensive. So now the goal is maybe like bring the cheapest storage you can have as you mentioned blob storage and then you can bring the compute on on the top
of it like you can be storing one terabyte of data and using maybe just a small like the smallest I don't know VM you can have on Azure AWS or whatever cloud provider and you're good to go and
I think this was was a very very big change and also the fact that you no longer had like this vendor locking like this storage like installed I don't know specific format.
>> Yeah, we were we were very good customers of Snowflake which is an incredible product by the way but but the migration took a long time like you get in and then it takes like a long
time to get out if you ever going to get out.
>> Yeah. Now you keep the data whether like you're storing on I don't know delta iceberg hoodie and you have a bunch of frameworks like Apache Xable data bricks release the uh uniform like before the
acquisition of tabular where you can do this conversion from delta to iceberg and hoodie now it's supported natively which is super cool but >> yeah I want to go back to your um to the
product you did build how can we get started with maybe framework work or language you're supporting. You talked about functions as a service. So this is something also I I believe you're built
on the top of your platform. Yeah, I think the absolutely so is essentially built well on top of object storage and for now our table support is like is is we support iceberg that is not a
terribly important choice for us like I think like depending on what you want to do you can support different tabular formats but the important thing is that the developer who's writing the code and
in our case is Python like we're very pythonentric these days we support SQL as well as is an important language for both transformation and especially for interactive queries. But really the the
bulk of the of the the beauty of the experience shines when when you do Python and what I was saying is that take like the case for instance of of different tabular formats. Uh you can
have different tabular formats and you can have very good reason to have them and it's kind of really up to you.
Should the developer care and the short answer is no. So everything that happens in your code and in a way in which you organize your business logic should be abstract to the point that your code is
essentially declarative and nothing else matters. So if you swap you know an iceberg table for a delta table your code should not change. Um you should have a way to declare that that that
table using the most abstract common denominators that you have across all this which in the case of a table is very abstract. is literally whatever has rows and columns and I can apply
filters. So when you start thinking in this perspective, a pandas data frame, an arrow table, park, an iceberg table built on par, a delta table, those are all the same for your code. M is built
on this concept that is really is a simplicity of development that matters.
We chose Python for a number of reasons.
One I think is very simple. It's just like the experience in Python is particularly broken. It's not easy to to run Python in the cloud and there's not really one way of doing that. So
companies typically have a hodgepodge of kind of like stuff that they did and this it becomes kind of like unmanageable and annoying quickly. But also the point is that I think that
Python is a very important language for data and oddly enough there isn't a pythonic data pipeline not a real one like not a one that was built for first principle for those developers and it's
a language that is growing massively because of AI and it is a language that also to this day the first AI agents are most proficient in. So I think it's a language that will become like even more
important for data. I would expect the future of data pipelines and transformation to be mostly Pythonic with some SQL with a subset of the code written in SQL. So that's why we focused
on on that specific segment.
>> But as you said like you're you're supporting both Python and SQL.
>> Yeah, absolutely. Because like you know like you can think of a lakehouse our thinking around that is this like you can think of your data platform as a as an object that will support three main
use cases, right? One is you interact with your data in real time. So you you run a query and you want to say how many rows are there in this in this table, how many nulls, you want to do a join or
something like that. And that is done obviously in SQL because there's so many advantages. It's such a simple language.
Plus your you know your query engines are all SQL based. So it totally makes sense. There's absolutely no reason to move the developer from this point. Then the second use case that you support is
that there's somebody who is iterating on something that is a little bit more complicated than just a query. It can be a pipeline. It can be training a model, but we're still in that moment where the
developer is iterating. And so we're still kind of like maybe we're in a notebook. And then there's, you know, whatever we did typically is going to look like a pipeline. We want to run it
in the cloud at scale on a schedule with all the retries with all the tests the CI/CD like we want to make sure that this is now a production ready application. The problem that we see
with the data stack and I have to say that the lakehouse offers the possibility to change this but to this date doesn't really solve the problem is that for these three use cases you have
three different infrastructures. In one case is you have a query engine. Second case you might have a single node Spark cluster in the second one you're going to have like a cluster you have
different abstractions and different interfaces you run you know in a SQL editor or you run in a notebook or you run now in your IDE so there's this idea that your platform is has to be three
things to support these three use cases and I I think the the largest bet that we're taking with pipeline is basically saying for the vast majority of your use cases when it comes to data
transformation you don't have to have three infrastruure structure, three interfaces and three type of abstractions. Things can be radically simpler than what they are. The way they
are is just an historical byproduct and then people adapted to it. But you can actually do everything as a function.
Everything's going to look like it's going to look always the same in the back end in the infrastructure and you're in your interface. You write your code in your ID always. You just iterate
on that.
>> And if I'm like I am I don't know a data engineer and I want to get started with bot plan. uh is it a framework? Is it a CLI that I should install? Do you have any library that I can start leveraging
and get connected to your uh to your platform? And also what about the the compute because I've seen that you're saying that like zero uh zero infrastructure management. It's like is
it like those like serverless actions?
>> It's it's a it's a it's a let's say it's like a lambda for data if you will in that in the in the sense of like the the compute is is managed by us. You start with blan by doing pp start bpl plan and
that's literally the only thing you need on the client side and then you will need an API key that connects your client like you know like yours config it's called bplan config you know
imagine the creativity there so the banan config will just with the key connects to your you know remote compute the trial version that you have online now you can log in it's public data set
so it just you know share with you know with adopters you can just try it out to see how it feels you can run all the example But in a real setting, so our customer have their own of course
organization when they can generate their own IP and then every time they run this will points to the compute capacity that they have reserved but the compute capacity is managed either in
their cloud or in our cloud but is managed by us. So the developer never see anything else that is not a function or an API call and then everything that happens between then and the actual
infra that needs to happen is on us to make it happen in a pure you know like you know fast kind of like you know mentality. Uh so it's very similar to other serverless offerings that of
course you know you're you're familiar with but very different than I don't know Yamar or or or this type of experience that you have for example with AWS building blocks for similar
cases. I don't know if you see them very popular in your day-to-day life as well or >> so I will make sure like this something this is something important you mentioned that you have the trial
version so I will put the link so people can try can try boplin >> and also like I I was curious to know your compute is it like are you cloud agnostic like you will run on every single cloud provider or you have like I
don't know preferred one or one where we are like more mature than the others >> we're definitely more mature on AWS like these days like we're focusing more on AWS one simple reason is market share.
The other is actually the fact that I think like AWS in particular is the cloud that historically has been more faithful to uh remaining a toolbox more than a platform. So you can do a lot of
stuff in AWS but is is usually kind of like spare parts. Data platforms built on AWS can become gnarly, can become like very hard to maintain very quickly.
I think we have like a particularly compelling value proposition there because you know we focus particularly on those companies that today have um essentially want to scale their operations without having to scale their
data engineering team. Bobland effectively does a lot of the job that a data engineering team does. And so if your company is in that situation where you have, you know, like one, five, 10
people at most and you think you're going to do way more with the data, but what you see is like, well, if I have to scale the platform now, I have to hire more people. This is going to become
more complicated. I have to really think about how to organize my team. My pitch to you is like, maybe you don't like maybe you can keep your team as it is.
We abstract away all the infrastructure and we give you back abstractions that really a general developer understands as opposed to oh I have to hire now a person who really understands spark
which is like is a is a great advantage especially if you want to hire new folks because essentially like anybody can it's just Python anybody can work with with botlin and generally speaking I
think like spark is a yeah the role of spark is an important piece in what we're trying to do as in like spark is a very foundational technology for data and it's very widespread and it's very
sticky and it's very reliable. But it's also now it seems that there's a fair amount of workloads that are that are not on Spark for a good reason except for you know like we built it on Spark a
few years ago and now that's what we have. But it's just like machines became like so large now in the cloud and I guess like Spark came out in a moment in history when the largest machine you
could have in the cloud was smaller than Lambda today. So of course you needed everything to be distributed. But there's an argument to be made today.
It's like well most enterprises actually I don't know if you ever looked at the red shift paper that reported how like you know the size of queries in workloads. Most workloads actually tend
to be like the order of magnitum a few gigabytes 100 few hundreds gigabytes like rarely go over a terabyte. And all those workloads can be drastically simplified by using a much more
intuitive way of doing things like hey here's a function it's just a Python function running in the cloud. is is a special runtime built specifically for this purpose. But to you is going to
sound is going to look like just running a script and submitting to an API. And then of course for the super large stuff, please keep using Spark. But there's a lot of overhead in my
experience in my past experience especially that teams have to go through in just like maintaining a lot of distributed data frames APIs and distributed systems for workloads that are honestly not that big. I'm curious
to know you mentioned that your data remains in the blob storage then you just need to connect BLAN with the blob storage.
>> Mhm.
>> Which means like you just and you mentioned that you for now you only support uh Apache iceberg. So I I believe you get connect to the the iceberg rest interfere rest catalog cat
catalog to list to list the tables. But like what about for what about the governance part? For example, if you are using I don't know you've seen like many vendors have now their own catalog. So
can you interface their catalog or you can say bypass them and access the data straight to by reading the parket files or whatever files you have there.
>> So the problem comes with a catalog. So Baban comes with a with with a catalog that that allows to do a number of things that are very important in the way in which the developer workflow that
we designed works. In particular, it comes with a catalog that has gitlike abstractions over tables. So, typically the developers that use BLAN today use the platform to create branches where
they zero copy their data into a branch.
Then they they built these pipelines using the serverless functions and then they can deploy as in like merging back into the main branch. We typically have integrations with other catalog because
I don't think I don't think it's a very good idea to have a million cataloges but also I think like people spend way too much mental energy on this like you choose one and then you kind of you know
you can write into your single source of truth and it's fine. I think like that battle is probably going to be won by Unity because it seems to be like very you know omniencing and a lot we have
like a bunch of customers and users who you know come to us and they go okay whatever you guys you want to do this is this looks great for certain use cases it's very simple it's very quick it's
much much cheaper but I don't want to move this stuff from Unity it's like totally understand I also don't want you to move from unity I definitely don't want to go there so you write back into
the final catalog and you inherit the governance from from that single source of truth.
I'm not in the catalog business. My runtime comes with a catalog just because it provides a beautiful ergonomics for for the developer.
>> Yeah. And I I saw in your new website how you push for this less complexity, more robustness with this branching branching of data and like simplifying the uh CI/CD uh component part which is
essential for every single project.
There's a lot of like there's a lot of stuff that the data world kind of like it reinvents and calls it in a different name, right? Like it's a strange thing that happens. It's like I have a
medallion architecture like you mean you have branches in a CI/CD like or she's like no no this is a different thing that we do. was like okay I guess but like ultimately I think there's a lot
there that can be simplified and push you know the data engineering world to become like more uniform with software engineering first because like if we all speak the same abstractions I think like
it becomes like much easier to organize teams and be productive in organizations and secondly because honestly software engineering is a I mean it works you know like we know what we're doing there
like we built very impressive machines at scale using those best practices so I think there's there's an advantage in in pursuing those >> and if someone is interested to whom he or she can reach out in case they have
questions you have any specific email or just reach out to you directly.
>> I I I think the best way we're very easy to reach you can >> you can just you can just you can just you know either either go through the through the website and you know and and
sign up for an account you can reach out on link very easy to reach you can write us an email our address is our first name.lastameblabs.com last name at paplabs.com. So probably you should
write to Chiro because it's a much shorter name and a much shorter last name compared to mine. But yeah, but you know where you can you can reach out anytime.
Bye.
>> Hey folks, welcome back. This is part two. We have as us and Chiro. In the second part we will in the second part you got to show us the platform and how it works.
>> Okay. Well, thank you very much for having us second time. It's it's good to be here. We were discussing before like we change everything location, haircut, shirts like if like so I'm going to do
something very simple. So I think like last time we discussed how we thought about like an execution model and a certain way of exposing the abstraction of of a platform. What we want to do
today is showcase one particular use case of bplan working along with an AI system. So basically if I have to tell you kind of like the story end to end this is the assumption is that a lot of
the work of data engineers and a lot of the work of our early customers we're already seeing is starting to become work that they aim at automating using AI. So like a data engineer does a fair
amount of repetitive and kind of you know dull tasks especially when it comes like to debugging and looking into into several things that went wrong. I think like I can actually share my screen. Um
but effectively like you know like you can think of of of a system in in that is you know you can think of a world where your data engineer will start working with a bunch of automated
systems that can help with the kind of things that are not terribly distinctive. you don't want um your data engineer your data engineering team to spend a whole lot of time on that like
you know ETL or data cleaning like generating quality tests and most importantly fixing pipelines which for anybody who worked in data um it's uh it's a fairly hard and and complicated
thing to do and I don't think anybody um thoroughly enjoys this um so um we're going to show you today like how you can use like our platform form which is designed as a code first platform to
basically use an in an an agentic system. Um agents are very good at code.
Um they're not so good at UIs and GUIs.
Um so anything that is like API first works very well for you to bring this kind of automation. The kind of problem that that we can think of is well there's a pipeline that breaks um
there's a number of things at that point that you need to do. Um you can do like a root cause analysis. You can start thinking about what went wrong. But ultimately one important thing is that
you you want this automation to be uh end to end and so you want also AI system to use your data platform to fix stuff. Okay. Um and that implies that your agent now will have to actually not
only read the data from your data lake or your lakehouse but actually do something and write potentially a new table, write a new pipeline, change a columns, do something else. And so when
you allow a a system like an automatic system, like an AI system to do something in your data, um it's okay to be nervous because the agent can do a number of things that are not necessarily the things that we want to
want them to do. So for instance, like what if it installs a malicious package or what if it just like changes a table or an artifact that other systems will depend on downstream and that will be uh
pretty problematic in um in a production environment. Now the good thing of that is that uh last time we discussed the function as a service uh model for execution that is a part of the of the
of of the design of our platform that allows to have full um isolation when it comes to the runtime. So the agent is essentially now operating with with separated functions are completely
containerized and isolated one from another and isolated from the host. So there's there's a limited amount of things that they can do um to to um um you know like the malicious and and
potentially catastrophic problems like the agent now is is send the second part is the data and last time we discussed like um this abstraction of git for data over um open formats specific case is
iceberg and so at the end of the day what I'm going to show you is if you have a platform that is built for full auditability that has the system of git for data and is built for kind of like
rewards isolation and being pedantic.
Um, you actually can use an AI system to automate a good deal of the work that your data engineering team, not only your data analyst, your data engineering team is doing today. Um, without further
ado, um, for this demo, we're going to just like use cloud code. Um I'm sure that most of the folks will be familiar with that at this time. Um but the real like the um the situation that we find
ourselves should be something like this.
You have a um you know you might I'm sorry this is the initial situation would be something like this where you actually have a bunch of things in your um data platform um that didn't go well.
So imagine that one of these is a pipeline, a transformation pipeline that takes some raw data, transforms the data into a table that is consumed by a downstream uh users or application and
that this um um pipeline failed. It failed during the night maybe failed while um a certain job was running uh on a schedule. The job of a data engineer today would be to go here and fix it and
understand what went wrong. If it is a problem of the data, if it is a problem of the code, it is a problem of the infrastructure. What we aim at doing is automating a part of this. So for
instance, I can do I can go in a place like a cloud code and say, "Hey man, can you tell me um what uh jobs failed in the last I don't know 5 hours." What the system then will do is that we have an AI agent
in this case claude that interfaces with the data platform with the data stack using an MCP server and because everything is exposed as code it's particularly simple to do that. Um so
you have something like this she's like well in the last 5 hours this is what happened. It's like, okay, so um can you tell me what went wrong there?
And do a quick root cause analysis.
Make sure to include your uh sorry your um suggestion um about what to do with the same logic. Now all the APIs of the platform can be explored with the MCP. Now the agent can do and just like
get all the metadata of the files of the tables. Um run queries potentially inside of the of the of the tables to see what went wrong. Scan through the logs of the system that are also exposed
as a Python API. Um and understand like in in in the scenario that I was mentioning before what exactly should be done because it can be in principle a problem of data or the code or the
environment or all of them like it's it's an undetermined problem when we see just a pipeline failing. you don't necessarily know what happens. Okay. Um so in this case um probably what went
wrong here um is going to be a mix of data and um and um and infrastructure um knowing these jobs. Um as you can see we have already our first um report that says like well there's a problem with
the environment. So it appears that we have some um Python and pandas and numpy compatibility problem. So there's a function somewhere um that is not running correctly because of this. Um
and um there's another case where there's actually a problem with our data modeling. There's there's a column that is missing. So the recommendation is to fix this in a certain way. Um now the
question is as I was mentioning before can I have the agent actually fix this like this is very nice and it's already you know you can think of this like in a this is a demo pipeline that is like
fairly simple but you can think of this like on a most gnarly and complicated pipeline. This is already saving you hours of your time that otherwise you would invest in digging into the logs
and do all this by yourself. But the real deal is, okay, can you fix it for me? Because, you know, it's great to know what went wrong, but I actually would like to have, you know, this thing
fixed. Um, so that's what we're going to do. Let's take like the um let's take one of them. Okay. So, for instance, you have first one here. Um, and say, can you help me fix this job right here?
Um, I want you and this is where the ergonomics of the platform comes in because we're going to ask the system to open a branch, open a data branch and change the pipeline, run it and when you
think you have figured it out, um, write a report and tell and give me back the branch.
So I can take a look at it and merge it. This is only possible because there is the git for data abstraction in the in the background. It's the only possible because otherwise I would be very
nervous about an agent changing um some code in a pipeline and running a pipeline in my production environment as that would change effectively the status of a table or will change um um you know
the behavior of downstream applications and if I don't have a quick and simple way to uh isolate the the um the agent while it it does this or a way to roll back both cases I would be extremely
nervous like if you think about it one of the reasons why code generation is so popular um okay it's already fixed those um identified the trouble um the one of the reasons why code agents are so popular
when you do code generation is that you can roll back you have git um so even you know besides the horror stories that you read on Twitter um of people having you know cursor doing something terrible
to their application. Uh but generally speaking is is it like is a reasonably safe environment where you can guard rail the agent um enough when he just like writes code when he writes
something like a data table in your application is completely different ball game um and so I think it's an interesting point that the combination of this data um branching system which
creates like this new branch here is like fixed n by compatibility okay and then just like changes the code and he's actually able to run a project from scratch and create new tables now and
finally give me a report with my new uh new pipeline. This is what happens.
Seems that it run correctly. But now I do have fundamentally a branch that I can check out to. If I switch to my terminal, what I will do is just I'm going to check out this branch. And now
I can explore the branch and see what are the tables that were created by the agent and see potentially explore the data myself to understand what's right, what's wrong. And if I'm okay, I'm going
to merge this table now back into main.
Sorry, this is uh No, this is my >> No, it's not the right branch.
>> I think >> it's not even a branch. This is different.
>> You put the table instead. Yeah, it's the table name instead of the branch name.
>> Table name. There you go. Okay. So now we should have our fantastic uh new table which is called top pickup location at there you go. So we have it in main. So all the work that would have been done
by a person. The bulk of it has been automated by a system. U and for the purpose of this demo like we like to show this as an interactive flow using like cod uh like cloud code where you
can like chat with it. But this is ultimately an AI system. Like the important thing here is that you have an AI system that can access fully a data platform that is designed to be kind of
like AI ready because it's API first and code first. It's very easy to to think of this system as a system that now just like runs asynchronously. So instead of having like my terminal and do this like
myself, I have a bunch of prompts and I just have an agent that wakes up whenever there's a problem. And so instead of waking up in the morning with a bunch of uh failed uh uh jobs and you know little
indication of what happens um what you will have is a bunch of failed jobs and a bunch of attempts to fixing this uh these jobs um by an agent. And so my job now is to review the work that the agent
did while I was sleeping instead of um of of of doing something else. Like the example here would be like if we take like another job for instance, right?
You have uh it will look like this, right? you will have um uh automated systems coming me coming to me with a um uh with a job that is completed and I can then like inspect the job and say
it's like okay so this is what the agent did um this is like the logs this is the code and you know these are the branches in this case this like this job ran on main for instance like this is the
branch where I should check it but you like your work changes pretty radically in that sense like you you become like more able to like you we you can do much more just like managing the swarm of
little agents helping out rather than doing this yourself. Does that make sense?
>> Yeah. Yeah. I think now I can I can fit the presentation you did and the demo.
>> Okay. Fantastic.
>> Do do you need do you need the slides from our side? Do you need any do anything else to be part of the montage like of the final cut or or the video is enough? Like do you need any material
that you want to inter inter?
>> You can you can just give me a few maybe some documentation that I can add uh to the description of the video like beside the website like if you have any any code or stuff that I can add so people
maybe if they want to try it.
>> Oh okay. Fantastic. We can leave a link.
Uh >> yeah.
>> Okay. Let me just do the the the the closing first. Thank you so much Chiro and yeah Koko. It was very interesting to get the plan also having a look at this interactive demo and as you can see
it was really live coding. You've seen like Chiro messing up with the wrong table.
>> I know you mess up like but I think like it gives I don't know. I'm so tired of like those like canned demos like at this point like this is this is an actual system like our our customers
actually using this is real. This is real.
>> Also also it's very hard to mock demo with cloud code in general. Like the other thing is that even if we wanted to mock a demo code is actually possible because the system fight against you
mocking things. So this is real even because even just because we can't pick and >> an extra layer of real because like not only your demo can fail but but the agent >> everything can fail you know it's
nondeterministic so whatever.
>> Yeah. Exactly. You can ask the same question twice you won't have the same answer. And the beauty of the LM yeah so yeah. Yeah. Okay.
All the material will be added to the description of the video and if you have any questions feel free to reach out to Chiro and Yak. We're gonna have their contacts in the description. Thank you
so much guys.
>> Thank you very much for having us and a lot of fun. My