You're working on iPhone Pago, which is the fintech arm of I
Food. Exactly.
So a lot of people know I food, especially in Brazil, most of
Brazilians know I food, it's a food delivery app in the
marketplace, the the market leader in Brazil.
But a few people know that we have all these other business.
One of those is our fintech business.
So our fintech business is how can we help and enable our
restaurants to grow and have more support to grow inside our
platform. So it's, it's not a bank that
lives alone in his space, but it's a bank that serves ifood in
the ifood ecosystem. So success for our bank, our
fintech is seeing our customers, our restaurants grow inside the
platform. And I'm assuming you know a lot
about the restaurants, so you can help them in different ways
by giving them loans, but also understanding their credit and
how risky the loans are. We know how the restaurants
operate. So we can we can give loans to
restaurants that probably wouldn't get a loan outside our
fintech, but we can give this loan because we know that he's a
good restaurant, that he's serving the clients, that he's
actually delivering the food and so on.
But. Why wouldn't they be able to get
it outside? Because around 80% of our
restaurants are actually small restaurants in Brazil.
So sometimes you see a single person that takes care of the
restaurant, the packaging, preparing the meal and then
taking care of the finance of the business as well.
So it's a very small business and sometimes they don't have
access to credit in in regular banks.
So what we do is since we know this is a good restaurant that
is really operating inside eye food, we can give a loan to that
person. And you can know what their
order volume is, and you can understand like, yeah, this is
sustainable. Exactly, because having working
capital is very important for a restaurant.
So they cannot grow if they don't have access to some
capital to start growing the business.
So this is very important for them.
And since we know how it operates and how it's actually
working in the platform, we can choose the right amount, the the
right size of loan for this restaurant.
Yeah. And how are you bringing the
agentic experience into that whole life cycle?
Yeah, we have a lot of different agents inside Pago in that life
cycle. Specifically, we have chat bank,
which, which is like the bank manager for the, for those
restaurants. And it's a a different kind of
bank manager because it's not only saying things about like
your, your balance or general information about your account,
but it actually helps the entrepreneur to run the
restaurant. So it says, OK, you need to pay
your employees. The, the, the entrepreneur can
say, I want to play my employees.
I have these five employees and those are the accounts.
And then the, the bank manager can do the, the bank transfers.
It also can and. The bank.
So me as a restaurant owner, I keep all my money in the bank
and I'm using ifood as my bank as opposed to whatever like ING
or N 26 type of thing. Different people choose
different ways of working, but a lot of our restaurants use our
account because of all these different features that we have
for. Them it makes it a lot easier I
can imagine. Yes, exactly.
So this chat bank assistant the the bank manager, it helps the
the the restaurant owner with the day-to-day life of the
restaurant. So making payments, knowing that
he has an outstanding invoice that he needs to pay.
And this also is an opportunity for helping him with the working
capital as well. So for example, we can say we
see that you have an outstanding payment, but you don't have the
money in your account right now. But I, I see that you have
access to credit like you have this three different sources of
credit you can use. But I'm seeing that the cheapest
1 is this one. So you can access the cheapest
possible credit just to solve your problem right now in the in
the quickest and cheapest way possible.
And this is all done through a chat interface.
Yes, exactly. WhatsApp is very popular in
Brazil and the restaurant owners are usually operating in
WhatsApp as well. So he's talking to suppliers,
he's talking to customers in WhatsApp.
So helping him in WhatsApp works really well because it's it's
very comfortable for him. So they, I imagine a world where
they can just forward invoices to chat, Bing, WhatsApp, and
then it's automatically uploaded, Yeah.
Exactly. He actually does that.
Yeah. Yeah.
He can even take a picture of something and say I want to make
a pix for this number. Pix is the Brazilian Trans Money
Transfer Protocol, one of the the protocols.
So I can say I just want to transfer money for this account
and take a picture and then the Chet Bank takes care of the
rest. Yeah.
It's like pay this shit, I don't want to deal with it Exactly and
it will transfer the funds. It's just I send a WhatsApp
message. Yes, and then you make the
transfer. It's, of course, it's a secure
procedure, so the the restaurant owner has to tap his password,
but everything is very well integrated, like the user
experience is very seamless for him.
So he just types the password and then the transfer is made.
Wow, yeah. Behind the scenes, what's it
look like? Behind the scenes we have an
agent there that for every message the user sends it reacts
to it. So it it receives the message
creates an execution plan. So what should I do for the this
message? So for example, I need to start
a money transfer operation. So he calls this function and
then this function becomes UI element inside WhatsApp for the
user to confirm the password. And then the after the
password's confirmed, then the transfer is created in the back
end. So it's the agent works like a
front end, like a web front end. And you have all these tools in
the back end that interface with the different APIs we have
inside the the fintech. So we have APIs for the money
transfer, we have APIs for getting the account balance for
authentication. We need to know if a WhatsApp
number is attached to a fintech account, what account is that
account. So these are all the different
back end functions that we need and and we have other agents and
other business as well. So inside our Fintech we have
beneficious which is a corporate meal voucher that is very common
in Brazil. It's like a credit card but only
for meals. And we have an agent that helps
small companies hire this the service and also operate the
service in a day-to-day basis. And hire the service?
You mean like go and get you a credit card?
Not for the person, but the company's HR.
So I'm from a company HR and I go there and I want to hire this
beneficious for all my employees and have this credit card for
all my employees. And the thing with the agents
here is that we can scale a very custom experience for this
person. So we can say, OK, what's the
size of your company? What are your needs for
beneficious for the the meal voucher?
What are you worried about? And sometimes people ask what's
the difference between this product here and this other
product? And then we can help the user
guide his decision and and make the best decision.
So this is one of the ways we use these agents.
Yeah, talk to me more about this idea of scaling personalization.
Yeah, because I think that's something fascinating that you
all are doing and it is mainly happening right now through
chat, right? Yeah.
But what are your thoughts around it?
Yeah. So for me, when I started using
AI, when I started working with AI, the the interesting thing
for me is that you can bring a very customized experience to a
whole new level. You can like scale that to a
huge population. So for example, when you look at
ifood, not only the fintech part, but but the whole ifood
company, you have a lot of opportunities that you want to
be more tailored to the customers.
So when you're ordering food, I want to offer you what's good
for you. When I'm trying to help you find
and hire beneficials, I want to clarify for you and make easier
for you to understand how beneficious can help you in your
company, not someone else's company.
And with agents, we can bring that to everyone so you can talk
to the person in their own context.
So it's way easier to do that. And today this is, this mostly
happens by chat because it's a very open-ended interface.
It's, it's kind of easy to put everywhere, but what I'm seeing
right now is more and more we're starting to creating like custom
UIS that are more tailored to the specific cases.
So for example, we, we have a case in ILO, which is our food
recommendation agent that having the the right UI for the user
not only saves time because he can just tap the dish that he
wants, but it also saves a lot of processing in the background
because reduce like LLM calls. Yeah.
So it's not only about having the right experience, which is
easier and and and nicer to use, but it's also about efficiency
as well. Dude that is so true.
The tightrope that you have to walk to make sure that you're
not just sending everything to the LLM, It's that fine line and
you get to be almost an artist about where you throw in the LLM
and where you don't. Yes, as the models improves,
it's getting easier because it's not that sensitive to your,
your, the, the way you write your prompt and everything.
But there's still some magic to it, like maybe it's one word
that you put that changes how the agent works.
So how you evaluate that and and how you choose what you put
inside the context is it's very important.
Yeah. And just thinking about where
the human plays the role, where do you actually have the human
be part of the process versus not, is also fascinating in my
mind. Because I imagine you're
thinking a lot about how to get the merchant the least friction
way possible to do something. So for you, anywhere that the
human has to do something is it's like it better be a must
that they have to actually do it, because otherwise you're not
saving them as much time. But but at the same time, you
have to build trust as well. So when you use an agent and it
starts doing everything for you, maybe you can get uncomfortable
like I don't want you to do that or just wait.
You need my approval to do that. So it's it's a fine line you
have to walk between giving the automation and making the person
comfortable with the decisions that are being taken.
Well, especially with money. Yeah, exactly.
So it's it's a very sensitive topic, Yeah.
Yeah, you're, I, I mean, if the wrong pizza shows up at my door,
that's one thing, But if you send my employees an extra 2
grand, I'm gonna. That's a totally different
problem to have. And if it's the agent's mistake
on both of those parts, like 1 is a little excusable.
The other is like, hey, I want that 2 grand back, but I'm not
going to not give it back to my like it's just a messy situation
that you're in. Yeah, exactly.
The the harness we build for different types of products and
applications is completely different.
Like I, I, I like to put agents and AI in a spectrum, like in in
one end, you have a lot of control and in on the other end,
you have a lot of magic. So you have to choose where
you're going to put your product in this spectrum because
sometimes it will feel a bit more stiff, but you want that
because you need more control. And sometimes the the risks are
low. So you want to see more magic.
You want things to happen and and people to feel that wow
moment when using your product. Are there moments where you've
just let it go completely to the magic side of that spectrum?
Yeah. I don't think that in fintech
business we have that, but in I food in ILO, for example, for
recommending food, yes, it we want it to be a magical
experience. So instead of saying I just want
something that I like or I, I just want the pizza here, we
want people to ask what should I get for a romantic dinner with
my wife? So this is a different level of
openness that we want from our users.
You talked a little bit about how the chat interface is
changing and how we're starting to create these new components.
I'm also fascinated by that. I've seen there's a, there's a
project that I saw on Figma that was, I can't, I think it's
called Language GUI and it's a bunch of Figma components that
you can use inside the chat to help render different things
that you wouldn't necessarily get in a chat.
Maybe that's an embedded tweet or it's a voice note or it's a
snippet of a podcast, so that instead of always getting back
text, I get different, more enriched data points.
And now we're seeing that a ton with the MCPUI, which is that
taking to the extreme. And I'm excited to see what
people build with it. I know that some people in the
MO OPS community, Slack, we're talking about how hard it was to
work with MCPUI right now, just because it's so nascent and you
kind of expect that. But are you thinking through
different components that you're now rendering?
You talked about how you tap for authorization, so that's one.
What else is there that you're like trying to bring into the
chat that you don't have to have the user leave for any reason?
Those are usually very specific and tailor made for each case.
Of course you have like a generic, a genetic UI toolkit
that can be used. But I think the the real
experience it, it becomes really good when you tailor the
components exactly for the use case that we have and what the
user needs. So it's, it's not about the only
about the agentic part, the AI, but it's you, it's the how the
the customer is using your product in a day-to-day basis in
the experience that he has. So those special components are
very important. I think we have this for
passwords, for confirming information with the user to
make sure that he's aware of what the agent is doing and
what's happening. So this is something we are
experimenting about. But when I think of agentic UI
components and so on, I also see that spectrum from control to
magic. Like on one side you have all
these agentic UI toolkits popping up right now with
different CSSHTML or React components already packed that
the agent can choose. And on the other side of the
spectrum you have like free HTML with JavaScript and CSS with
which also is working really well nowadays.
So for for some internal tools we are actually doing that a
lot. So generate on the fly the HTML
with this visualization for this specific case.
Yeah, that's kind of like the playgrounds that I was showing
you. Yeah.
Exactly, Yeah, like the playgrounds you were showing,
for example, we had one one problem in a in a, in a data set
that we had and we wanted to investigate in the book what was
happening. And we created a simple tool
like called code created this tool.
I want to investigate this, this and that.
I want to see the lineage of the data set and why this happened.
And it just generates the HTML with the visualization, the
graph with the data sets being built.
And it was very easy to see why the problem happened.
Yeah, I, I've, that's one of my primary use cases for this
playground skill is debugging, Yeah.
And getting visual representations and then being
able to hone in on what the problem is and where it's
happening. And then you can just copy over
the prompt and be like alright fix that for me please.
Yeah, exactly. It's a really cool application.
When you're talking about these different components that you're
serving up to customers, do you feel like that is also
personalization at scales? So now I'm going to get on the
app and it knows the top four things that I normally do when I
talk to it on WhatsApp or whatever.
So it instantly says, hey, welcome back.
Here's do you want to do any of these, like quick buttons, you
know, so I don't even have to think.
I'm talking more about context in general.
That affects everything. So for example, I know that you
have two employees. I know that you're not opening
your restaurant tomorrow. Those are the things in context
that start summing up to give a nice experience for the user.
So today I'm not going to say for I'm not going to send you a
message for you to pay your employees because I know you're
not opening today or something like that.
So this context enriches every experience.
And and one being the the buttons I'm going to show in
what order and what's the user going to use first?
Like what's the most frequently used?
Yeah. Right now, behind the scenes to
create that context. I know that isn't the easiest
problem. How are you going about making
sure that you have all of the right context at the right time?
Yeah. I think it's something that is
more of a emergent behavior because you have different
systems. Some are pretty simple but bring
this feeling and some are pretty complex.
In in one end of the spectrum, the complex part, we have LCM,
which is our own custom LLM tailored for e-commerce data
that has the profiles that can build profiles for the user and
say Thiago really likes Japanese food and during the weekends he
likes to eat pizza as well and so on.
So this is LCM that brings a whole new level of
personalization for our customers in I food.
But on the other end of the spectrum, maybe just counting
how frequently you you use every feature and use that to sort the
the menu is enough. So I think this is more of a
emergent behavior that when we start assembling all the pieces
and putting everything together, it seems like it's pretty
complex, but some components are complex, some are very simple
and they when they are all aligned, they bring this this
feeling. Is there stuff with like your
context engineering that is the low hanging fruit?
Usually it's the the basic profile that you have on the
restaurant or the person and so on.
So for example, I'll give an example with the the customer
facing part because I think it's easier to visualize.
But if I have my last 10 orders inside my context, it's pretty
easy to see what I like eating. So for the restaurants, this can
be the, the, the way it operates.
So where it is located, what's the opening hours and what's the
cuisine, all these things can help creating this experience
for the restaurant. So for example, we have a
product which is I food shop that sells supplies for
restaurants. And knowing the cuisine is and
the dishes that the restaurant serves is the information we use
to recommend what products he can buy.
So for example, if it's a pizza restaurant, I'm going to sell,
for example, cheese because I know it's something that he uses
a lot. Yeah, you're not going to
recommend chopsticks. Yes, exactly.
Yeah, it feels like there is a law of diminishing returns with
the context that you give it versus what actually is the most
valuable in that output and what your your end user is
experiencing. Depends a lot on the task you're
actually trying to solve. So when when I'm building
agents, I see that if the technology was perfect and the
models were, were perfect, we would we would have only one
single agent agentic prompt that says everything the agent has to
do with all the guides and all the information and all the
tools. And it would have access to like
100 tools and everything would be perfect.
But the reality is not like that.
As you increase the prompt size, as you increase the number of
different instructions the agents has to follow, as you add
more tools, it gets harder and harder for the agent to to have
a high accuracy to do the right thing at the right time.
So what we see is that as the complexity grows, you start
breaking this agent in sub graphs of agents that that
solves a specific problem. So for example, this agent
starts really complex. I see that when I'm talking
about payments for the employees, I, I should have a
special care when dealing with this part.
So I've created a different prompt of a different context
with different tools for the agent to handle that specific
case. So when we look at the context,
for me this is very important, what we're trying to solve.
And this context is going to change given the task we're
trying to solve. Do you feel like there is ever a
point where you're just going to have sub agent bloat because
you've created so many sub agents now that the at some
point there's got to be that bottleneck, right?
And so if Or is it just layers of abstraction?
I see more as layers of abstraction.
It's like breaking a complex problem in smaller problems.
So it's usually easier to handle that way.
So I haven't reached a point of a sub agent bloat or something
like that. And I don't even like to think a
lot as sub agents because when we're building an agent, I see
more like a graph like I have these nodes and this node
execute a specific operation and it can go to other nodes and so
on. So a sub agent can be a sub
graph can be a set of different nodes that solve a task.
And it's a very seamless thing is it's not something like you,
you say, oh, I'm going to have those 3 sub agents.
It's more something like grows into 3 sub agents.
So when I'm building a single product, I think more of an
agent that starts to be assembled by different pieces
and start to being created by different pieces.
When I think of sub agents, I I think in something more similar
to like micro services. Like I have two different teams.
One team builds one specific agent to solve a task.
I have another team building an agent that handles another part
of the business and sometimes one will need to call the other
and then I have this extra change of information.
Tell me more about how it grows. If we start with this single
node, that solves everything. This is the way I think all
agents should start. You always start with the
simplest approach possible, which is a single node.
We have access to tools, and then it can choose what to do.
And you have this set of evaluations that for every case
that you have, we evaluate what's the accuracy of your
agent. As you progress and as you get
more data and you start expanding that evaluation set
and you start having real users with your agent, then things
start not working so well. And you start to detect which
points are not working really well.
So when the user tries to do action A, it's usually the, the,
the agent usually messes up what he's trying to do.
So here's something that we should break.
So you go to your evals, you're going to see that in your eval,
this specific case is not performing really well.
And then you break that node in two nodes.
And now I have one node that takes care of only this specific
case. And then you go back to your
evals and see how it's working. Now everything's fine.
We, we keep working with this agent.
As you progress, as you get more data, people use it more than
you're going to identify another use case that's not working
well. And then you do the same thing.
Now I have to break this specific node in two nodes and
so on. So it's more of a iterative
process. It's not something that you, I,
well, I believe it's not something you can plan in
advance. So I'm going to have this agent,
I'm going to have all this 10 nodes and it's going to be the
best architecture possible. I think the architecture is
being discovered as you gain knowledge of the problem.
Yeah, you don't try and boil the ocean with that first agent.
Exactly. You see what it's doing right,
what it's doing wrong, and then you try and create those edge
cases and continue to have that feedback loop.
I I like that vision. Now I understand why you say it
grows because it's that iterative loop and you water
your little plant by giving it more evals and looking at it
again, seeing where we can break it up.
OK, now there's a new branch. Now it's sprouted and and this
side of the tree is flowering. Cool, let's go there.
Let's water that a little bit more and give it more eval sets.
Yeah, in in my opinion, complexity should never be
planned. It it should be a result of of
time. It's not something that you
prepare. You're going to start complex.
You have to reach that point after a lot of time of work.
And and for me, what makes a very effective team at building
agents is actually running this feedback loop really quick.
So if you can get new instance for your evals, run your evals,
detect what's what's wrong, grow in your agent and doing that
loop really quick, those are the teams that are winners and those
are the agents that are winners as well.
I've never met an engineer that told me I wish this system was
more complex. If anything you try and go the
other way and like you said, you want to try and keep it as
simple as possible. But that feedback loop, you
allow it to enrich the experience and complexity comes
from that. But that's only when you're
faced with the reality of the world.
Exactly. It guides you when to add
complexity and where. So I know you had hot takes
yesterday on Claudebot, which is Moldbot, which is open Claude
now. I really like open claw.
It's something that it's, it's a game changer.
It, it doesn't bring a lot of new techniques or anything like
that, but it's a very good interface.
Like you, you have it 24/7 by your side, answering your
questions using the tools. And the, the, the thing that is
different from open Claw is that it actually develops itself.
So for me, this is the the biggest thing for open Claw
because I can say I wanted to create a new SKU to search the
Internet for me and do this. So for I'll give you an example
for my open claw, I asked it to create a new SKU that researches
the Internet and Twitter and see what are the trending topics for
the day. And then it reflects in the art
image to create and it has its consistent style.
So it has like a book of styles that it can use.
And then he chooses for this reflection he's creating for
this specific day, what is the style he's going to use.
And then he generates the description for an image and
then generates an image with this reflection that represents
this reflection. So this is something I created
there. And, and this is not trivial to
do because he had to create a specific script to use the X API
to fetch training data. He had to get data from the
Internet as well, then summarize this, and then he had to create
a script to call the image generation API and so on.
And it's all nicely packaged and I only had to talk to him to
create that. So this self development process
is what makes open class so interesting in my opinion.
But at the same time, all this complexity and all this freedom
for it to create also brings a lot of security risks as well.
So Open Claw expands a lot on the attack surface that we have
not only by installing software and downloading software and and
doing getting skills from somewhere on the Internet and so
on, which is 1 attack surface. But also when you look at prompt
injection and other problems that can arise from processing
the the textual information as well.
And for the prompt injection, it's not enough to control the
entry point. Like for example, if you don't
talk to my open cloud, then I'm safe.
This is not true because maybe you can get a calendar invite
that has a prompt injection, or maybe someone sends you a
message in WhatsApp with a prompt injection, or you receive
an e-mail with a prompt injection.
Yeah, because it's monitoring all of it, Yes, so.
The the amount of excess you give, it's also the amount of
risk you're taking. You had mentioned too before the
idea of how much your job has changed.
As you were talking about what you've created with Open Cloud,
I was like, oh, so basically what you were doing in 2009, you
basically can put together in 20 minutes now with Open Cloud and
probably more. Can you talk me through now like
how you think about working through the all those changes
that you've had over the years? Yeah, I think that the the cost
of software of writing code, it's already a fraction of what
it was a few years ago. We're still in the adaption
period in in which people are actually understand how to use
and how to make it work. But one example for my personal
experience as well, it's been easier sometimes to write a tool
to solve a problem than to find a suitable candidate in in
Google. So for example, I have one
website that I put all the tools, small tools that I code.
One example, I sometimes will create a presentation deck, some
slides and I want to put a video converted as a GIF.
So I want to get a video convert to GIF and put in my
presentation and I always used to search for a website and I
always was thinking if this website is storing my video
there or not and everything which it is.
Yeah. And what I did was I opened 1A
genetic programming tool and I prompted to create.
I want this small tool only using HTML and JavaScript.
So it runs on the browser and you're going to use FFM peg in
web assembly to convert this video to GIF and then it created
like one shot the the application.
So I have this ripple that I put all those tools and I have it
online and for the specific case, it's easier to do that
than to find a suitable candidate.
So right now this is getting very common and as the models
progress and get better, it's going to be more and more common
to see that happen. Actually, you are bringing up
such a good point. Yesterday I saw a tweet from
Andre Caparti. Then he said that he trained a G
PT2 model. It was capable the same stuff
for under 100 bucks. Yeah, that is so crazy because
you think about how much it cost to train back in whatever 2019
when they first did 2017 when they were doing it till now.
And so not only is software going trending towards being 0
price, but the models themselves are trending towards 0.
It is 7 years later, but still man, if you can train it for
under 100 bucks, in seven years from now, you're telling me that
we're going to be able to train Kodak's 5.2 for under 100 bucks?
You have access to a huge amount of intelligence for a very small
price. And when you look at code in
this scenario, it's it's so cheap that you're going to get
software for free. And what happens when we live in
the world that software is free. So my, my personal take is that
it's going to increase a lot of demand for software because it,
it's now easier to build. So we want to build more stuff.
So for example, you said, I'm going to create a small tool
here just to debug a problem that I have or just to
experiment with a different character I want to put in my
game. And and this is not something
that you used to do. Even the game itself.
I'm making a game for my daughter, and I would have never
thought I'm going to code a game so that my daughter can play.
I would have gone to Google and I would have found a game and it
probably would fit a little bit. But it goes back to that
personalization at scale, and now I can have our own game that
I choose the character names, I choose how they look and what
they're doing and what it's related to.
This one specifically around geometry.
And it has horses because my daughter loves that, right?
That's the personalization for me and of one, well, and my
daughter. So I guess I have two.
Yeah. And, and I believe that everyone
will have his or hers 2 belt of programs that you're going to
build and sometimes those will be disposable.
So I create a, a program just to solve this specific case.
And it's so cheap and fast that OK, I can create, I solve my
problem and I'll never touch the software again.
Yeah. Yeah, and you'll want the
novelty, like if I had this horsey game for my daughter, if
it was faster and easier to create.
Because right now I'm spending whatever a weekend on it or a
week. If it was easier to create, then
I would probably make more games I like.
Today I'm playing the horsey game that's revolving around
geometry. Tomorrow I'm going to play the
dog game that revolves around whatever vocabulary expansion or
something like that to try and help my daughter's learning
journey in that regard. And then you augment all of the
different disposable things you're you're creating because
it is so fast and easy to build. Yeah, I, I saw one case recently
that one guy had his MRI scan and there's only one software or
a few software that can do that and it, and it runs on Windows.
And he said, I want to, to see my files and I want to see in my
Mac or Linux or whatever. So he went there to code code
and Vibe coded his MRI file visualizer that runs on the
browser. So this is something crazy.
Yeah, wouldn't happen like a few years ago.
Wow, you at ifood. I'm sure in your current
position you're using a lot of software still that is like
you're and you're probably paying for a lot of software.
Are you going to just stop paying for it?
No, I, I I don't think so. I think when you build a company
around software is not only the code, like you have a lot of
things happening around the code that are very important.
You have the operation, we have support, you have a lot of other
things happening there. And so I, I think this is not
going to happen. It's not going to stop, but
maybe we'll want to build more stuff that previously we
wouldn't like to build. So for example, I have this back
office thing, maybe I'm using external provider today.
But now the cost to build a similar software is so small.
And and if we had a customized, a custom made one would be so
much better for us that now it makes sense to actually put the
the team, the time and the effort to build that because the
cost has decreased. So I think that that could
happen, yeah. Yeah, with the envelopes
community, we were able to save a ton of money because we vibe
coded a newsletter platform. We were spending like, because
once you get to a certain amount of subscribers, you're paying
per subscriber every time you send a newsletter.
And well, each platform has different cost structures, but
the platform we were using, we're paying up the ass for it.
And it was like, well, you know what, maybe we can try and vibe
code something so that we don't have to pay 1000 bucks a month.
And it totally worked. And so now we saved 12 grand.
Yeah. Yeah, the the, the word already
changed like in in, In my opinion, what we're seeing is
that we completely moved the abstraction level that we work
with code. So right now we're not thinking.
It's the same thing that happened when we moved from
assembly to Fortran. For example, this is imagine
John Bacchus arriving and saying, hey, I created this new
programming language. It's really cool.
It's called Fortran and it's easier to program a computer in
that I imagine that people would say, oh, this is, this is not
that good because if I call in assembly, I can choose every
register, I can make every decision, I can choose every
instruction the computer is using.
And and he say, yes, but this is a higher level of abstraction
and so on. And this is something that
completely took the word like right now, most of programming
happens in the high level programming language.
And with those AI tools, what I see is that we're giving another
hop in this abstraction level ladder.
So we're working in a new higher level of abstraction.
It's the it's the kind of the same shift that we had before.