What it takes to set intelligence free

7:26:09good to go here. Um, all right. Welcome

7:26:11everyone. Glad to be here. I'm Fabian,

7:26:14co-founder and CTO of of Lovable. And um

7:26:18we spent the last three years or so

7:26:20building a platform to let anyone create

7:26:22software and then operate that and

7:26:24deploy that software. Um and um the the

7:26:28topic of today is what it takes to set

7:26:32intelligence free. Um really um for us

7:26:37this takes us back to when we when we

7:26:40started three years ago. And um I have

7:26:42to say I have a bit of a complicated

7:26:45relationship with with agents. Um and I

7:26:48I'll tell you why. Um we almost failed

7:26:51as a company because we thought um back

7:26:55in 2023 that hey we these agents are the

7:26:58future. So let's build for them now. Um

7:27:00I think the we kind of turned out to be

7:27:02true that they were the future but we

7:27:04were definitely wrong on the the now

7:27:06piece in in 23. So this was back in kind

7:27:08of GPT4 days. Um and um at the at that

7:27:13time the intelligence was simply not

7:27:15there to have more of these kind of

7:27:17complex agentic systems. Um but now it

7:27:20is right now uh now the intelligence is

7:27:23actually at a place where where you can

7:27:25really build out more complicated

7:27:27systems around them. Um, and so I I'll

7:27:29give you kind of a a quick um background

7:27:32story here of of our journey um in in

7:27:36working with intelligence or or these

7:27:39LMS. And so

7:27:42um back in 2023, we built the first

7:27:45version of our product. We called it GP

7:27:46Engineer back then. Um and really the UI

7:27:50was very similar to what it is today

7:27:51where you can kind of have a chat and

7:27:53this preview. Um but the AI at that

7:27:55point was quite simple. We just had a

7:27:58prompt and a response, one LM call per

7:28:01user message. Uh, very simple. It it

7:28:03worked fine. Um, but you could kind of

7:28:05build one page apps and and simpler

7:28:08applications with this. Um, and then we

7:28:12thought, okay, this intelligence is

7:28:14going to keep on evolving. So, we have

7:28:16to be ready for uh for it as it evolves.

7:28:19And so, we thought, let's go out and

7:28:20build this agentic framework. And so we

7:28:23we went and we built this very

7:28:25sophisticated there is a beautiful

7:28:27framework for for agents to work. And um

7:28:30we had kind of this one main agent that

7:28:33would talk to the user and that agent

7:28:34would spawn other agents like an

7:28:37implementation agent here in the example

7:28:39and each agent could have a specialtity.

7:28:41This agent would kind of specialize in

7:28:43the first generation of an app and then

7:28:45you would have like a front-end agent

7:28:46and a backend agent and they would all

7:28:48talk to each other, send messages back

7:28:50and forth. and we thought, "Oh, this is

7:28:52beautiful." And there was papers around

7:28:54this and how well this could work. And

7:28:56in the end, it didn't work at all. We

7:28:58just made the product worse. Um, we um

7:29:02we definitely failed on this one. Um,

7:29:06but luckily before we ran out of money,

7:29:08we figured out like, hey, let's go back

7:29:10to a simpler system again. So uh in late

7:29:1224 we went back to a much simpler um

7:29:15system where it was a bit of a shame

7:29:17where we had like some some smaller LMS

7:29:19doing some knowledge retrieval and then

7:29:22really just one main LM kind of writing

7:29:24to the user and and writing the code in

7:29:26the same message. And this worked great.

7:29:28It was very responsive for for users in

7:29:30the UI and it was reliable and users

7:29:33were kind of in it and and iterating

7:29:34with uh with the model. Um, and so, um,

7:29:39let's close that down. Um, but now it's

7:29:43time again. We're back. We're so back.

7:29:45Agents this time, uh, they work. Um,

7:29:48and, uh, we're running them in

7:29:50production over a billion tokens per

7:29:51minute on on on these systems that I'm

7:29:53going to talk about. Um, but, um, first

7:29:57just looking at okay, what is actually

7:29:59loveable? So uh if you simplify the UI

7:30:03and this was same back in 2023 as it is

7:30:06today. Uh to the left we have a chat

7:30:08where humans come in and they kind of

7:30:10describe their their intent to to build

7:30:12or whatever they want to do. And to the

7:30:14right you have a preview uh which is the

7:30:16output or or the outcomes of of what

7:30:19you're building. Um and this back in 23

7:30:23you could do simpler things with right

7:30:25but now we've really seen working at

7:30:28this layer of abstraction you're able to

7:30:30build very complex things right and I

7:30:32think we've even seen uh a lot of

7:30:34tooling meant for for developers for

7:30:37example moving to this type of interface

7:30:39where you're not really looking at the

7:30:40code every day and so on and you're

7:30:42getting kind of abstracted and working

7:30:44on on be architecture uh or looking at

7:30:47some kind of output of of what you're

7:30:49doing. And um this is something that

7:30:52we've always believed in and it's been

7:30:54kind of a core thesis behind lovable

7:30:56that you won't have to care about the

7:30:58code in in the same way that you had had

7:31:01to do before. And I think today we're

7:31:03kind of in this almost a bit in between

7:31:05I think in the industry where you know

7:31:06some people might say you don't have to

7:31:08care about code at all and some people

7:31:09might have different opinions. Um um I

7:31:13of course like growing up coding and

7:31:15these things you get a bit attached u

7:31:17but in the end what matters is u is

7:31:20actually not the code um sorry if we

7:31:23remove that last part but uh what what

7:31:25matters is uh is the outcomes right um

7:31:29and so um the outcomes what is that well

7:31:33for for our users the outcomes is um uh

7:31:36creating a business and monetizing and

7:31:39creating value for for others in in in

7:31:41some type of way. And I'll kind of

7:31:44quickly go over um what we build as a

7:31:47platform to to enable this before I go

7:31:48in kind of on the uh on the technical

7:31:50side of this talk. So if you if you look

7:31:53at lovable the first thing that that you

7:31:56can say about the platform is that we

7:31:58have this agent and like any other agent

7:32:00it can do quite arbitrary things and

7:32:02it's quite specialized at at building

7:32:05software uh and it has access to a

7:32:08browser so it can verify what it's

7:32:10building and um it connects to to GitHub

7:32:13and you know it writes code that and you

7:32:15can do whatever you want with that code

7:32:17so on. So that's um kind of your basic

7:32:19uh coding coding agent. Um and the the

7:32:22other pieces of the platform is this

7:32:23kind of cloud and and business piece of

7:32:25the platform. And so um the cloud part

7:32:28of the platform is is about just giving

7:32:31kind of these u hosting primitives just

7:32:33seamlessly to to this agent. And so we

7:32:36we built out databases, authentication,

7:32:38storage, all the types of backend

7:32:40compute and security scanners and like

7:32:42backups and logs for all of these

7:32:44things. And all of it can be

7:32:45introspected by by the agent. Um, and

7:32:48this just makes it seamless to to build

7:32:50things. You don't have to kind of go to

7:32:52different services to set this together.

7:32:54We just kind of provide you uh these

7:32:55primitives. Um, so that's still around

7:32:58building software and hosting this,

7:32:59right? Um, but then the last piece is

7:33:02around these business capabilities where

7:33:05again the output of what our users are

7:33:07doing on lovable, we don't see that

7:33:08output as code. the output is is a

7:33:11product or or a business. Um, and if you

7:33:15want to succeed as a business, you need

7:33:17to do more things than just write code,

7:33:19right? And so we we we help our users

7:33:22with uh receiving payments, sending

7:33:24emails, optimizing SEO, um, doing ads on

7:33:27on Google and meta um, and kind of

7:33:29analyzing what is happening with the

7:33:31product through analytics and you can

7:33:34look at kind of conversions and and

7:33:36optimize these sort of things. and the

7:33:37agent is in the loop in all of this,

7:33:40right? So, that's kind of our uh

7:33:43capability offering, you could say. Um,

7:33:46and again, the core part of this is an

7:33:48agent that all of these capabilities are

7:33:49built for. Um, and at some point in

7:33:53level history, we used to limit our

7:33:55agents to work for only 30 minutes

7:33:57because we thought they weren't reliable

7:33:59to to work for a longer amount of time.

7:34:01Um but uh now we've changed this to

7:34:04really be uh without any any sort of

7:34:07bound in terms of the length an agent

7:34:09can work. And so you can imagine agents

7:34:11working for for 10 hours plus. Um and so

7:34:14I'll I'll go into some of the things

7:34:16that we've done um in our architecture

7:34:18to to enable this. And so the first

7:34:20piece is really around the agent runtime

7:34:23itself and how how we enable that to to

7:34:26run for a longer amount of time. And the

7:34:27second piece is the computer where each

7:34:31of these agents are actually doing their

7:34:32work running a dev server um and um

7:34:36actually verifying what it's doing. And

7:34:38so so the last piece then is the

7:34:40verification itself where if you want an

7:34:42agent to to work for a long amount of

7:34:44time, you need to make sure that you

7:34:45have these feedback loops in place so

7:34:47that it's not kind of going off uh in in

7:34:49in the wrong direction. Um and so if we

7:34:53start by looking at the agent runtime

7:34:56itself um you can imagine that um um you

7:35:00have um really three different sources

7:35:02that can um interact with an agent. So

7:35:06it can be yourself kind of prompting

7:35:07this or a human. It could be other

7:35:09agents and it could also be just a

7:35:11system on on a schedule waking up. And

7:35:14the way we chose to architect this is

7:35:16that for for each agent we have a

7:35:18separate inbox uh where any of these

7:35:21sources would kind of send in messages.

7:35:23And so you might have a message here

7:35:25like what's the status? Um and you can

7:35:28imagine you have this agent and this

7:35:29agent is kind of an always on agent that

7:35:31that might be working right and so um

7:35:33you can imagine it has done like three

7:35:35actions here a request a tool call and

7:35:37it got some some result and then at this

7:35:39point the agent is ready to actually

7:35:41receive uh messages. So um since anyone

7:35:45can drop a message into this inbox, the

7:35:47agent then can copy that itself into its

7:35:50own uh what we call a trajectory

7:35:51basically it's a task history. Um and

7:35:54this is the type of interaction that I

7:35:56think you're familiar with if if you're

7:35:57using agents overall. Um so that's kind

7:36:01of the the first design principle uh

7:36:03behind this agent runtime. I'll go

7:36:05through a few more here. And so um the

7:36:09the trajectory in which the the agent is

7:36:12working in which is kind of the history

7:36:13of what has happened so far um and

7:36:16really the basis for any sort of of

7:36:18memory for for for the agent right um

7:36:21and we designed this trajectory with uh

7:36:24really git as inspiration and so the

7:36:27trajectory what is it it's an append

7:36:29only log where each event uh points

7:36:33towards a parent the previous event Um

7:36:37and because of this you get um a nice um

7:36:41capability just like in git where you

7:36:43can fork things right. So you can have

7:36:45two events pointing to the same parent

7:36:46which essentially creates a fork. Um and

7:36:49because of that you can kind of spin up

7:36:51parallel agents at um um at any point of

7:36:55time in the history without having to

7:36:57duplicate all of the kind of the shared

7:36:59history. Um and um semantically it's a

7:37:02bit unclear what would happen if you

7:37:03merge this. So unlike it, we cannot

7:37:05merge agent trajectories, but we can

7:37:07kind of um spawn them out, right? And

7:37:09these agents can can talk to each other.

7:37:12Um the other thing that uh we made sure

7:37:14to design for is that this uh agent

7:37:17trajectory, it includes kind of the full

7:37:20history and everything that happens uh

7:37:22with the agent. And so every tool call

7:37:24um a bunch of other things happening on

7:37:26the platform if a tool call like failed

7:37:28or succeeded and a bunch of and what

7:37:30we've done is make sure that we have

7:37:32this appendon log and and from that we

7:37:35can actually build a prompt that we

7:37:36would feed into into the actual LM and

7:37:39um you might ask why why why would you

7:37:41want to do this? Well um one one reason

7:37:44is that um when you build a prompt you

7:37:46if you have a long history you probably

7:37:48want to do some sort of compaction. you

7:37:49want to summarize part of that history

7:37:52um in in the earlier steps for example.

7:37:54Um but this summarization would differ

7:37:57um for example if you use different

7:37:59models with different context lens you

7:38:00would probably think differently about

7:38:02when you should summarize and not. And

7:38:05so by separating the the prompt from the

7:38:07actual task history, we're able to

7:38:09render prompts for for any type of model

7:38:11or or any type of task um that that we

7:38:15can kind of find the best and optimal

7:38:16prompt for. Um, so to show this event

7:38:21history in in progress, we have this

7:38:23debug tool here. So here it's just

7:38:24recording of me dragging this uh slider

7:38:27in our UI. And you can see on the right

7:38:29that uh um the UI is kind of updating as

7:38:32I'm as I'm dragging this along and you

7:38:34have 156 events here and one each of

7:38:36those is an event in this event history.

7:38:39Uh and you can see how how the UI can

7:38:41render kind of any point in history. And

7:38:43this is just showcasing that at any

7:38:46point in time we have full control of um

7:38:49of say the UI or or anything else

7:38:51happening on the this platform thanks to

7:38:53um this history kind of detailing

7:38:55everything that has happened.

7:38:57Um the the last piece I'll go over here

7:39:00on the on the runtime itself is that um

7:39:03the process that is running these agents

7:39:06they're separate from from the actual

7:39:08task history. And so the process is uh

7:39:11almost entirely stateless in that

7:39:13between each each call each call each

7:39:15turn um it will actually just persist

7:39:18into the task history and so you can

7:39:20have a process come and go. Um and then

7:39:24the question is why why do we care about

7:39:25this? Um well

7:39:28uh at Lovable this system um we deploy

7:39:31to it um 700 times per day. So that's

7:39:34about once every two minutes. And you

7:39:36can imagine if you have um a agent

7:39:39working for for 10 hours um you want to

7:39:43not disrupt that agent when it's

7:39:44working, right? This this agent is doing

7:39:46something for for a customer. Um but at

7:39:48the same time we want to make sure that

7:39:49this agent is running on the latest

7:39:51deploy. and it might be a new feature or

7:39:53something like that, but it might also

7:39:55be like a security vulnerability in in

7:39:58the Linux kernel and it's like, okay, we

7:39:59need to update this ASAP. Um, and and so

7:40:02to do that, thanks to this separation

7:40:04between the actual history and and the

7:40:06processes, we can actually make sure

7:40:09that we have one one agent that is

7:40:11working on one task, but we can have

7:40:13different processes taking up and

7:40:15actually doing the compute behind that

7:40:17work. Um so so this task can keep on

7:40:20working while we have um different

7:40:22deploys um working on it be it for 10

7:40:26hours or or even longer right um so

7:40:29that's the agent runtime. The second

7:40:32piece of um of this platform right is

7:40:34the is the computer. So this is where

7:40:36the work is actually happening. Um and

7:40:39we've been through a lot of iterations

7:40:41and uh a lot of vendors kind of working

7:40:43with um um providing these sandboxes for

7:40:46for the computer for for the agent to

7:40:48work in. And we've landed in in this

7:40:50system that we've worked really hard now

7:40:52to develop which is um um checkpointing

7:40:56um a computer. And so you can imagine

7:40:59you come to level you start a new

7:41:00project. Uh we have this common what we

7:41:03call a golden checkpoint which contains

7:41:06the OS and the system services. It has

7:41:08common tools installed and a dev server

7:41:10that is ready to start. And this

7:41:12checkpoint, it it includes everything on

7:41:14disk uh memory and also running

7:41:16processes. And and so when you start a

7:41:19new project, you get all of that for

7:41:20free. And uh all of that is copied over

7:41:22in about 230 milliseconds. Um and so

7:41:26once you start a project, you you might

7:41:28have some specific code and and some

7:41:30dependencies within that project. Um and

7:41:33um that is also checkpointed as you go.

7:41:37And and so each time the the agent is

7:41:40running and it finishes a turn, we will

7:41:43actually save a checkpoint o of that

7:41:45computer and and from that we're able to

7:41:47again like very quickly subsecond uh uh

7:41:50spin that computer up whenever you need

7:41:52it. That means we can save on on

7:41:53resources by kind of spinning this down.

7:41:55If you leave for say 10 minutes or or so

7:41:58and come back, we can just spin it up

7:42:00extremely quickly. So you don't even

7:42:01notice this and even uh kind of requests

7:42:04um in transit will will not even be

7:42:07dropped in in in this setup. Um the

7:42:10other thing we can do thanks to uh this

7:42:12checkpointing is that just like the

7:42:15trajectory itself uh in the agent

7:42:17runtime we can also fork um the computer

7:42:20and when we do this um we have for

7:42:23example we have um a feature in in level

7:42:26that is called draft where you kind of

7:42:28work in different environments of what

7:42:29you're doing and and to support that we

7:42:31need to fork the computer that you're

7:42:32working in. Um and um here we have um um

7:42:38kind of the example of doing two at the

7:42:40same time. And um you can imagine doing

7:42:42hundreds of these, right? Um and so um

7:42:46we've we've had to do uh some

7:42:48optimizations to make this feasible to

7:42:50to actually run. So one of these

7:42:52optimizations is copy on write on the

7:42:54RAM itself. And so creating one of these

7:42:57forks of a computer is uh is basically

7:42:59free in terms of of the RAM that it's

7:43:01using. But um as soon as you start

7:43:04writing um um in in a process to to RAM,

7:43:07we will kind of copy that page over and

7:43:09only then will you start having to

7:43:11allocate new memory. Um and there's

7:43:15another optimization here also which is

7:43:17that um each of these sandboxes require

7:43:20a few hundreds of megabytes of memory.

7:43:22Um but and that would take a few seconds

7:43:25to stream in if you have it in like cold

7:43:27object storage and then it has to go to

7:43:28disk and then then into memory of this

7:43:30uh um this VM. But um thanks to uh um

7:43:36being able to stream the memory, we can

7:43:37actually boot up the the machine before

7:43:41all of the memory is is actually um

7:43:44ready on it. So the the memory the OS

7:43:47uses comes first and then like some

7:43:48processes and so on will will start to

7:43:50work as soon as the memory gets there.

7:43:52And this also shaves off some some extra

7:43:55startup time. Um, and then we started

7:43:57asking ourselves, how can we make this

7:43:58even more efficient and even more faster

7:44:00for our users? And so you might be

7:44:02familiar with V. It's this great dev

7:44:04server that most of the meta frameworks

7:44:06out there in the JavaScript ecosystem is

7:44:08using. Uh, and so we we took that and we

7:44:10forked it and we rewrote it in in Rust.

7:44:13And uh, that made our code starts two

7:44:15times faster and we went from getting

7:44:17this preview from 14 seconds to to 3

7:44:19seconds. And the main um kind of thing

7:44:21that we made faster here is that vit

7:44:23uses noode.js and we're able to like

7:44:25drop that dependency off itself and just

7:44:28have this rust binary. So um that made

7:44:30the memory footprint be 6.5 times less

7:44:34uh in these machines. Um and by taking

7:44:36control of the applications that we're

7:44:38running in these computers, we're also

7:44:39able to control kind of how we write to

7:44:42memory. And so when we control how we

7:44:44write to memory, we're even more

7:44:46optimizing. If you remember back to the

7:44:48kind of the copy and write solution when

7:44:49we're drafting different um um different

7:44:52computers and so we're able to uh run

7:44:55this extremely efficiently so that we

7:44:57can run um lots and lots of agents in in

7:44:59parallel and kind of have agents explore

7:45:02different solutions to solving a bug or

7:45:04improving the performance of of your

7:45:06applications and and so on. Um and so

7:45:10this has been fun. Um uh but the last

7:45:13piece now is is about verification. And

7:45:15of course this kind of computer and this

7:45:17dev server is a big piece of being able

7:45:19to verify what an agent is doing. Um and

7:45:23if you look at verification, you can

7:45:25think of these feedback loops, right?

7:45:27That the agent needs to get information.

7:45:29It took an action. Was this a good

7:45:30action or was it a bad action? And um

7:45:33you can think of it as this inner loop

7:45:35and this outer loop. So this inner loop

7:45:36is um during the turn of the agent. And

7:45:38you have kind of obvious things such as

7:45:40like the um is the build working? Do we

7:45:42have lint errors or type errors in the

7:45:44code that we're running? And then you

7:45:46can check for runtime errors in in the

7:45:48preview that you're running. You can

7:45:49also have within this computer a

7:45:51headless browser where the agent can go

7:45:53in and kind of explore um the the web

7:45:56app it's it's building or whatever it's

7:45:58building, right? Um and and a bunch of

7:46:00other things that we're using to help

7:46:02verify within the turn of an agent. But

7:46:04then you also have this outer loop which

7:46:06is kind of between each turn and the

7:46:08turn you can think of like when the

7:46:10agent is yielding to you as a user. Um

7:46:12and um between each turn you might get

7:46:15some info on on the product itself uh

7:46:17from from production from your users,

7:46:19right? And so you can look at how your

7:46:21visitors are behavior are behaving. Um

7:46:24what users are are telling you online.

7:46:26Uh you can do automatic AB tests and

7:46:28actually see change some copy and see is

7:46:31this improving conversion and so on. And

7:46:33then you can also take these business

7:46:34metrics and and remember this goes back

7:46:36to kind of the capabilities I showed

7:46:37you. By having control over these

7:46:39things, we can make sure that we can

7:46:41optimize how the agent is is getting

7:46:43this out of feedback loop. So, we can

7:46:45make sure that if you're running

7:46:46payments, we can actually track those

7:46:49transactions and conversions and make

7:46:51sure that um the agent can actually help

7:46:53you optimize uh not only the the code,

7:46:56right, but the the business strategy um

7:46:59around around your product. Um and so

7:47:03those are really the the three things

7:47:05that that we've been working for. And uh

7:47:08we'll continue to kind of build out um

7:47:11these uh these capabilities and this

7:47:14architecture around really orchestrating

7:47:17these LMS into into agents. And so um

7:47:20this agentic system that we're building,

7:47:21it's running billions of tokens per

7:47:23minute. Um and um these computers,

7:47:26right, we can spawn up with each agent

7:47:28and we can have multiple agents use one

7:47:30computer. And now we're kind of back to

7:47:32this uh quite beautiful setup where we

7:47:34have agents talking to agents and

7:47:36they're orchestrating and and this time

7:47:38it's it's actually working and it's

7:47:41working at scale thanks to some of these

7:47:43optimizations. Um and so if you're

7:47:45curious to try this out, you can head

7:47:47to.dev and you'll you'll see our our

7:47:49preview spinning up and and so on, but

7:47:51you'll get a very simple and um a nice

7:47:54interface and you won't have to care

7:47:55about all of this stuff. Thank you so

7:47:57much. It's been pleasure. Um, and uh,

7:48:00yeah, hope you hope you learned

7:48:01something. Thanks so much. [applause]