Software Supernova: Lovable's "Superhuman Full Stack Engineer" to Transform Idea to App in Seconds

Over time, AIs are going to read our minds basically, or they're going to be extremely good at predicting what we want in a given situation. Historically, we have switched overnight after a new model comes out because we try it out and say, okay, this is a better model. We don't use just one LLM. We do smart routing and we use from Gemini, OpenAI, and Anthropic. And soon I imagine potentially from DeepSeek. When you're connecting to external APIs, it's, as you said, Nathan, it's often more Things that can go wrong. And that's where you need to have a system that's good at debugging itself between the different components that are interacting. The most important thing is that you have a product that predictably works and like works in an intuitive way. And making an agent work intuitively and like in a nice way, it takes a lot of iteration. If you're currently like working without AI, then I think you're Really disappointing your employer or your customer or your clients.

Hello and welcome back to The Cognitive Revolution. Today we're simultaneously releasing the first 2 parts of a series we're calling Software Supernova with the makers of new and stunningly fast-growing full-stack AI developer products, Lovable and Bolt. Each episode explores in its own way how AI's rapidly improving coding capabilities are beginning to tangibly transform the software industry. By expanding the space of what can be built, changing how professional software developers work, and making it possible for people to create software without ever learning to code. My guests in this episode are Antono Sika and Isaac Sundeman, founder and AI engineer at Lovable, online at lovable.dev, which describes itself as your superhuman full-stack engineer and promises to take users from idea to app in seconds. Headquartered in Stockholm, Sweden, Lovable has achieved extraordinary growth since launching in November, reaching $9 million in annual recurring revenue in just their first 2 months in market, thus becoming one of, if not the single fastest growing European startup ever. In this hands-on episode, we weave a discussion about Lovable's vision for the future of software, their product philosophy, and some of the opinionated choices they've made to maximize user success rates, Including their Supabase integration for database functionality and authentication, their approach to error message handling and debugging, and their extremely novice-friendly user experience for handling API keys, all together with a live demo in which we actually use Lovable to build a large language model-powered product comparison application. I think the audio version should be fine for most listeners, but if you want to read all the prompts and see the product in action, you can visit our YouTube channel for a version that includes a screen recording. As you'll hear and perhaps see, while we do encounter some friction along the way, in the end, we are able to create a neat little AI app, not just once, but twice. The first time iteratively over a dozen or so interactions, and then on the second go with a few lessons learned in just 4 prompts. All with Claude 3.5 Sonnet, I should note, as we did record this episode just prior to the recent release of O3 Mini. The upshot is that today, non-coders with a bit of AI savvy and willingness to retry when needed can create basic full-stack applications on their own without writing any code. And of course, new models will only continue to expand the scope of possibility. This represents a massive democratization of software development, and considering that so many of the resulting apps will use AI to do things that traditional software never could, a low-cost path to AI transformation for many millions of businesses. As always, if you're finding value in the show, please take a moment to share it with friends, write a review, or reach out via our website, cognitiverevolution.ai. We always welcome your feedback and suggestions. For now, I hope you enjoy this unique look at AI-powered software development with Anton Osika and Isaac Zundeman of Lovable, online at lovable.dev.

Anton Osika and Isaac Sundeman, founder and AI engineer at lovable.dev. Welcome to The Cognitive Revolution.

It's great to be here.

Thank you.

Thanks, Nathan. I've been listening to your podcast and I love that you cover everything and I get smarter every time I listen.

Well, thank you.

Very flattering.

That is definitely the goal, is to learn as much as we can and hopefully be a little smarter about what's going on in AI. So you guys have been on quite an exciting journey lately. Lovable online at lovable.dev is an AI coding agent. I would classify it as, you can tell me if you have a different high-level label for it, but it's one of these new—

AI full-stack engineer.

AI full-stack engineer.

Yeah.

So it's one of these things where you can show up and say, hey, I want a piece of software created for me and just describe what you want in natural language and then have the AI run off and try to build it for you. And so Today, what I thought we would do is kind of a little bit of a departure from our usual format, but have the normal conversation, try to understand what you're building and your vision for the future and how soon you think human coding becomes irrelevant, if that ever is going to happen. And then at the same time, actually kind of go in the background, partially in the background, and actually try to build an app as we go. And I think that'll be a very informative two-track experience. So I guess Anton, you and I'll be primarily talking and Isaac, you'll be kind of primarily coding in the background. So I guess maybe let's start with just kind of a little, we'll get you running on the programming and this will be on the video feed. You know, we can just be kind of following along with you. You can, you know, we can stop and interject anytime and share developments. And then Anton and I will kind of just, you know, continue with sort of big picture stuff while you're Moving forward, a simple app that I had an idea for that I think we are going to try today is just a product comparison app. Basically, say you've got a couple links to a couple products online and you want to get a good comparison of those 2 products, feed them both into an app and have the app come back and tell you what matters about this kind of product and how these products compare. On that dimension. And I'm sort of thinking of this as an AI-driven comparison, right? So it's not something that would be fully programmatic or formulaic, but where there's a little bit of dynamism in using the AI to determine what sort of comparison even makes sense for a given product. How's that sound?

That sounds good, I think.

I hope so. Like, what type of products do you want to use this for?

Well, I think what's so interesting about AI products in general is how open-ended they can be and how flexible they can be. So I guess my initial idea was like any products, a very live example right now this week in my home is that our washing machine has broken and we need to replace it. And so my wife is going onto review sites and The Wirecutter and Consumer Reports and trying to figure out Which one should we get? Obviously, capitalism has provided us with a huge number of different options, but we don't even really know what matters, right? We've never bought one before. We've never thought about it. If you think about what you do today, if I think about what I do today, I first sort of feel like I have to go out and educate myself generally about a product category. Like, what are the dimensions that matter? But that process of identifying those dimensions, is where the bulk of the cognitive work seems to be going. Do I want, for example, a front loader or a top loader in my washing machine was not a question I had considered at all before. And I had to first educate myself to even get to the point where I realised that, okay, that is an important dimension of this comparison. So I feel like if the AI was really serving me well, it would flag for me like, okay, here are the main things that people find to be important about these products that you may not even be aware of yet. And then here's how they compare. But sort of creating the comparison framework and then populating it is sort of what I imagine we would've loved to have had these last couple of days.

Let's see if we can ship an MVP and then iterate. I think that's always the best, start super simple. So I guess let's go. I'm thinking the first part is to just get up some core data input into the system and then feed that into an AI and see if we can hook all that up and how long time that would take. I would do just like, you want to put— so one workflow is you just say, I want to buy a dishwasher, which ones should I compare? But let's be more— help it out and say, I want to put in a few URLs of these different dishwashers and compare them. Does that sound reasonable? Yeah.

Great question. I don't have a super prescriptive idea in mind of exactly what the user experience should be.

Yeah. That's cheap, a first version. That's it.

There are also like some of the things that you can think about when you create like your product within Lovable is that you can think more overarching, uh, what tools and APIs we should use. Like for example, there is this, uh, Perplexity API, I believe, that will automatically search up, uh, things for us. So that could perhaps—

That could be super useful. But let's start with like, we have a specif— we have it constrained as much as possible, see if that works out. And we just get the UI up. So first type out the— we first type out a prompt where we say, I want the UI to kind of do— let me put in URLs of products. And then some information about those products should be shown and the AI should help guide us through what's important to consider. Maybe generating a product comparison table. So let's go with this prompt. So it says, create a product comparison tool. That uses AI, but we'll create the UI and the flow is something like the user put in product URLs.

Products, products URLs in input fields.

Nathan, do you think this is good? What do you want it to do once you put in the fields?

Should we have like a button called analyze or like compare?

Yeah, let's have a button, analyze button. Yeah, sounds good.

And then we have analyze button that when pressed will scrape the websites and get the data and then call upon— then call GPT-4o.

Let's take that later. Let's call GPT-4o.

Yeah, but let's start with a really nice UI.

So it's like it's typing out a prompt here that is like has a few typos and things.

Yeah.

And I think that the typos, they don't matter. The AI understands perfectly, but the formatting and the sequencing of what you ask in what order, that does matter quite a lot. So like be— and being very specific about what, once you have an application and you want to change it, being very specific about in the prompt, in your prompt is very important. And what we're seeing now, feel free to ask any questions, Nathan. I think that's more fun. But what we're seeing now is that the, like the AI creates a plan for what to do, a bit about the— first it plans out the design and then it generates what we think is the best practices in terms of a web application. Most software today is actually web applications. So that's what it's doing. It's React code. And now it's spinning up the first UI version of this. And yeah, I guess here you can add a few product URLs. and click compare products in the— Yeah. And then now, now you're getting a Swedish version of washing machines because the Google is adapted to where, where we are at right now. But let's pick that one.

Okay. So I guess the idea is we, we have the same one. Yeah. Yeah. Okay. Let's, let's take, take something else here. Is this a different one?

Yeah. And this should work for like Amazon or any URL, right? But let's, let's see.

And then we would press—

What happens if we press compare?

Yeah. So nothing should happen right now because we haven't actually connected the backend, right? So yeah, analysis feature is coming.

I love how it gives you the little heads up.

Notification.

Yeah. And so, yeah, so let's hook up the data input and then we need a backend. So the backend is needed when you have something that requires like external data, AI features and so on. So the way we set up a backend is that we rely on our wonderful friends over at Supabase, which has like a backend as a service that covers all your needs. And then usually I guess you would be logged in here, but now—

Yeah. Now I need to log in.

Just one click, one click to get the backend set up.

Yeah. Let me, let me log in real quick.

Do you want us to clarify anything on what's happening there, Nathan?

Well, let's maybe start with a, like, Big vision, and then, you know, we can kind of meet maybe in the middle. We've got the very low level, like we did our first prompt, we're connecting into Supabase. What do you think is the sort of big picture future of software? Like, where is this all headed?

Yeah.

Because I feel like we have this sort of like competing narratives right now around the future of software. And I always say my crystal ball gets real foggy more than a few months out. So what do you think is the medium-term future of software? You can maybe take that from like a user standpoint, you know, a developer standpoint. Are there still developers? Does anybody just sort of speak software into existence?

My biggest kind of prediction here is that when I was super young, I started coding and started creating computer games. And that's been like a superpower to understand the world and communicate about technology and to make things come into existence, but much less than 1% of the world's population has that superpower. And with AI, the 99% are going to be empowered to create, solve problems with software and edit and improve software. Everyone is going to be able to use a version of the software that they prefer, that's customized or is improved to them. And that change and how fast it's going to be, because AI is much faster than humans at writing code, is going to result in some kind of Cambrian explosion of really high-quality software. And just human creativity is going to be unleashed at a much larger pace. I think that's going to be the biggest change. And then you can talk about how that affects the current workforce building software. And that's a bit more complex, but I think that's the biggest obvious change in my eyes.

I guess one big question I still have about that though, is with this example that we have, right? If I imagine a future where AI is sort of continuing to advance and it's achieving the promises that everybody sort of seems to believe that it's about to achieve, it seems like we have lots of reasons to think capabilities are not done improving, then will there be any UI in the comparison process of products in the future? I could imagine a much different thing entirely where I just ask the question directly, right? And maybe this is sort of a fault of the example app that I proposed, but in today's world, we need these dedicated UIs because we don't have a general purpose interface to the world's information, let alone reasoning.

I've been hearing this generative UI thesis a lot on like, oh, we're not going to have software, we're just going to have AI. And then there's some general interface to all of this AI. I'm confident that that's not going to be the whole answer. And there is a very simple reason for that. And it's that us humans, We prefer when things are predictable and the same, and more so that the software that we're in, the products that we're interfacing with, has a UX that has been tested by many other humans. And it's something that humans kind of understand easily. So if you have an AI that always generates a new type of interface, a bit context-dependent on where you're at, then it's going to be different every time, potentially. And it's going to be different for your grandmother and yourself. So you cannot explain, oh, this is how the software works. I'm pretty sure that we're going to have standardized— people are going to use the same software with the same UX always, most of the time, because that's just easier for us humans to get used to, build up the muscle memory of how do I use Slack? How do I use my email client? And so on. And the exact UX is something That is super hard to nail. Like it takes so many iterations of making a product lovable. That's why we call it lovable. It takes so many iterations. And now with AI, you're going to be able to go through those iterations and really nail like what is the right UI for what this software is supposed to do. So that's why I don't think generative UI is going to come in and just wipe out everything else. But there's definitely going to be much more generated components and like Parts of the, parts of software that is powered by AI that pulls in the right context depending on what you're trying to solve for right now.

Hey, we'll continue our interview in a moment after a word from our sponsors. Yeah, I feel like I agree with that to an extent, at least where I'm kind of like, part of what we're doing here will have a little bit of a generative UI component to it because part of it has that because we're going to have, I mean, even, and even in just in this product comparison idea, there's going to be sort of the dimensions on which a product will be compared are not hardcoded, right? So even just like the table, what are the sort of fields of comparison is like that sort of dynamic or generated UI writ small. I agree that when it comes to power software that people spend a lot of time with, your Gmail or whatever, I would not want to have a Gmail experience that I log into and it gets— the UI is regenerated every day on the fly. And it's like, well, where was— I know where things are in today's world and I want consistency, and there's probably just no reason to recreate that all the time. People do want— I hear you on all that stuff. At the same time, though, I do have a sort of different vision that competes with this too, where I'm like, if If we're imagining a world of abundance in the future and we sort of say, okay, well, what do the people that have the most abundance today do? And would people in the future state of abundance try to do the same, or would they do something different? How does Elon Musk buy a washing machine today? I think the answer is he basically says to someone on his team, Or maybe at his level, it doesn't even come to his attention that the washing machine is broken in the first place. But if it did, he would just say, okay, find the best one and buy it and install it and let me know when it's done. Right?

Yeah.

There's a sort of, I don't even want to think about this. I just want to delegate the entire task end to end, come back when it's installed, or maybe somewhat short of that, like, tell me what I should do, and then maybe I'll review it and approve and we'll go from there. So I do sort of wonder if my future is mediated by UI at all in some of these scenarios, or if I just say to a general AI, my washing machine broke, find me a couple of good options, tell me what the pros and cons are, and I'll make a call. And then you go online and buy them.

Yeah.

I mean, can I spin on this, on the topic of the AI would know, or in Elon Musk's case, his colleagues, whatever, they know what he wants. And that, I mean, that transfer, I think, is the only important thing in the future somehow, like transferring what the human wants, desires in this very moment to a different system. Yeah. And transferring the information to the user. And over time, AIs are going to like read our minds basically, or they're going to be extremely good at predicting what we want in a given situation. So then that, those UIs, those elements where you need to say like, oh, I care about the front loading, whatever. You don't need to do them because it already knows what you want. On the displaying information to the user, like, which might be less important as well in the future, that there we are going to have the more, at least some level of standardized UI components. But yeah, I'm, I'm not saying this is not going to happen.

I'm just saying there's going to be some parts that are going to be, uh, One question I've had, I wonder if you have a take on, as I've tried all sorts of things like this and I've definitely made it my business to go and try a wide range of products. I've been a longtime fan of Replit. I've used Cursor pretty heavily in recent months building an app. It always seems like the DevOps portion, the ability to actually deploy to a machine and get things working In a way that is exposed to the internet always seems so hard relative to that initial code. Like so many experiences I've had, you could say, oh, gimme this UI. You get something pretty decent that like looks more or less what you had in mind. And then you're like, why is this? I have a dependency that's missing. What's going on? Or this thing is not building or whatever. I'm not sure what's going on with these port Forwarding situations, all that stuff seems like very hard for the AI. Do you have a theory for why one is so much more difficult than the other?

Yeah, totally. I mean, the software engineering gets very hard when you have like different things that have to connect. The more components that have to kind of be wired up and connected to each other in the right way makes it exponentially more error-prone. And the way to handle that in like how we, how we approach it as well is to limit those choices as much as possible and say like, okay, no, if you're going to deploy something, you can only use Supabase for your backend functions and for your database. And if you're going to add payment, there's a very clear happy path for that. And it goes like this, we generate a button for you to go out to Stripe and get your account setup there or just grab your API key, come back, and then the payment is almost guaranteed to work. If you just let an LLM, like a large language model, if you're using Cursor, that's much less opinionated, but still an amazing tool, then it's going to sometimes generate different pieces of the software that haven't been fine-tuned so that they are guaranteed to work really well together. And then at some point it's going to You're going to run into a problem and the AI is going to have a hard time recovering from that problem.

So do you think this is a technology wave that creates consolidation across different technology stacks and potentially core providers? It seems like everybody I noticed, for example, in the original generation, it was Tailwind CSS. It seems like that's become a community favorite, if not standard. And it seems like it's kind of a standard in most of the codegen experiences. And I would imagine, like, you know, for payments, I don't know what you're using, but I would expect that Stripe is probably a leading candidate that has lots of great documentation and so on. Is there sort of a Schelling point effect where everybody ends up using the same core components?

I think so. I mean, there is already a Schelling point among human developers where Tailwind is like the Schelling point. It seems like now, or at least according to most people, and large language models accelerate that because it's much easier. One is it's much easier to learn these new best practices. As a human, if I don't know Tailwind, it takes a long time for me as a human to learn it. With LLMs, they just instantly spit it out and it works. And secondly, the LLMs are much better at the very popular choices because they have much more training data there. So there's some convergence for sure, but I'm also excited about that. There are going to be technological innovations. Like Tailwind might not be the end-all. There might be better ways to style components. Facebook came out with something like a few months ago, I think. If this gets adoption, then all the AI tools are going to just like overnight maybe switch over to this new shelling point.

Yeah, that's a really interesting possibility. I've been kind of interested in that idea. At the level of the AI providers too, are we entering into a race dynamic either between countries perhaps, or between leading companies? And what are the incentives there? Is there any way for people to sort of coordinate to proceed with responsible caution, or are they going to sort of constantly face this, like, got to go faster to beat the other guy? incentive. And one of the questions I've been wondering about there is, like, how easy is it for everybody to switch when a new model comes online? And one thing I did notice in Lovable, which is distinct from, say, Cursor, is like in Cursor, I just have a dropdown. I can choose what model I'm using in the background.

Yeah.

And so now all the developers get to choose. With Lovable, I don't know what background model I'm using, and so you are choosing.

Mm-hmm.

And I guess I wonder, like, how easy is it for you to switch, and which dynamic, like, is better or worse from the standpoint of the developers and the racing dynamics? Like, if all the developers can switch, not all of them will, but it's like, it can happen, you know, super quickly. You guys would have more of a process. But you'd be switching on behalf of like all your users.

Yeah.

So yeah, we're interested in how you think about model choice and switching.

Yeah. I mean, historically we have switched overnight after a new model comes out because we try it out and say, okay, this is a better model. We don't use just one LLM, like we do smart routing and we use like from Gemini, OpenAI, and Anthropic. And soon I imagine potentially from DeepSeek, from their lab.

And maybe KIMI. Don't sleep on KIMI.

We'll see. Yeah. But. We do have a model selector for us, like an admin feature, so we can do some selections. And what I think, but I don't think that's the right user interface for a user because like if you have a selection and you don't know how to have all the context, then you're more likely to make the wrong decision. What we're planning to roll out is that you can, I mean, it defaults to being the fastest chain of large language models. And then if that doesn't work, it goes into showing that in the UI and letting the user have some type of control and a deeper analysis of the problem with larger and slower large language models. So I think that's the right approach and not be specific about which chain of models are running here. That's too much information for the user. Yeah. I mean, we make sure that we can switch out models super fast and know if that's a Better or worse user experience.

In the future, you expect to be able to incorporate new models really quickly, but it doesn't sound like the activity on Lovable is going to be like a winner-take-all contest because you're already subdividing the queries and figuring out where they should go. And so a new model will at most take a bite out of other providers' usage. It seems very unlikely from what you're saying that there would be a new model that would just dominate everything and take all of the activity from one day to the next.

Yeah, we'll see, of course. It's all about moving. Everything is about having a team that can just execute super, super, super fast and move the fastest here. And it might turn out that one model just dominates everyone else in terms of price and performance.

DeepSeek does seem like they have a strong contender all of a sudden. Do you have a sort of rundown, a cached thought on how the OpenAIs, Anthropics, and Geminis compare to each other today? Is there a shared understanding on the team of what's best for what?

Yeah, sure. And to your point there, DeepSeek is open source, and that makes it much easier to have low-level control and train your own model, at least for maybe the majority of fast use cases, just train your own model. And use that as the default. I see that happening for us quite soon. The difference is now Claude 3.5 is still overall the best one. It's fast, it's very good at coding, it's good at reasoning, and it works the best most of the time. Then if you look at wanting the speed and low costs, then Haiku is actually quite expensive compared to 4o Mini. And the best one that we have switched over to for the smallest calls now is Google's fast model, which is also really performant and fast. And yeah, so for OpenAI, but the final win for OpenAI is that their reasoning models are good when the AI gets stuck and you want to get out of that and do take a lot of information about, like, kind of in uncommon situations, reason from first principles, then OpenAI's reasoning models are still the best ones.

Hey, we'll continue our interview in a moment after a word from our sponsors. Yeah, I feel like that echoes what I've experienced when doing this sort of model choice manually. You know, it always varies a bit, but I would say if I want to do like a new feature on an app, and I'm working on this app that is designed to help people create even more so than curate, because oftentimes it is synthetic data that is being used, just really high quality examples for use in few-shot prompting or potentially even fine tuning, but some sort of AI automation context. You have some task, routine task that you want to automate first. And honestly, the most critical step most of the time is Get together a small number of examples that demonstrate what you want and that you can sort of stand behind and say, yes, this represents a job well done. I found that not too many of the LLM ops apps really help with that. There's many things that help with monitoring your performance and logging everything and running standard evals, but just getting to like half a dozen or 10 really high quality examples for your particular task, I haven't seen too many things that help with that. So I decided I was just going to make one. kind of as an exercise.

To me, like, why do you— what do you use those examples for? To compare this vibe check output on different LLMs or something else?

Yeah, that's part of it. I just find kind of the great examples are kind of the heart of any automation project, right? You first have to understand what is it that we want. Usually there's a team involved. So like, can we all look at these examples and agree that, you know, this is what we want as a team. Just getting clear on that, that's more of a social challenge than a technical challenge, but it's an important challenge in practice for many automation purposes. And then, yeah, once we have those, which model can even just on a few-shot basis imitate that? Part of what the app does is it also tries to help fill in the reasoning process that converts the inputs to outputs. Obviously now reasoning, chain of thought type of stuff is like all the rage. But a few months ago, and even still, I think people kind of sleep on how important that is because often what they have in their business is the inputs and outputs. Whatever they want to automate responses to customer service tickets or whatever, right? They have the message received from the customer, and then maybe they have the message sent back to the customer by the agent. But what they generally fail to capture, and maybe they have documentation in policy format or something like that, but they very rarely have any sort of chain of thought that connects like, okay, this is what the user sent. And now I'm thinking about the deep seek. Okay, the user is asking about this, right? And then working through all that stuff until you finally get to an output. That stuff typically does not exist. So part of what my little app does is tries to help fill that in, saying, okay, well, here's the output and it came from this input. what is the likely chain of thought, help people iterate on that so that they can see something, because people have a hard time writing this stuff down. So show them something, then they can react to it and say, like, that is what I do, or that's not what I do. And they can iterate toward hopefully a chain of thought that represents the way they really think about it.

Makes sense.

And then from there, yeah, test out different models, maybe graduate to fine tuning. I'm not planning to commercialise this app because I don't think it's a very monetizable thing. It's like, it's the sort of thing you don't necessarily use all the time. And it stops actually at the point where you have enough examples that you can take it somewhere else. Like, we're not gonna, I'm not gonna run fine tunings for you or, you know, be your like middleware of any sort. It's just like you get to the examples and you can export 'em to a prompt format or a JSONL format or, you know, whatever.

Did you build this app with Lovable?

I didn't know. I was, I've been, it's been a slow burn. So I'm not even sure if you guys had launched. Maybe you can tell the timeline of launch and how you've scaled. I think I started on it before you were an option.

Yes. Yeah. We launched the 21st of November. We launched like Lovable. And since then the product has like, that's when we also launched, like we have built out everything with the backend functionality, which Is a huge part of the unlock. And yeah, since then we've just been scaling like absolutely crazy and spent most of the time keeping up with that. But I'd be happy to show you some of those, show some of those parts and get back to the product comparison tool.

What do you think?

Yeah.

So I just had to log into Supabase again. I hit rate limits or not rate limits, but I had too many Supabase projects. That I had created. So I had to, yeah, I had to just fill that. Okay. So I've pressed this Supabase button now and connected a Supabase project to our Lovable project. And we can see that we also, we get this message that automatically is sent to the Lovable AI when we do that.

Where are we at now? We have the UI and we, we are supposed to try comparing 2 products and we need to fetch the data from those, from the websites of the products we're comparing somehow. So I think then the right thing is just to ask the AI, how do I connect the scraped data from an external URL?

Scrape data from an external URL.

And you don't have chat mode enabled here, but that's—

But we could enable that.

Yeah, you can decide.

Yeah. So we have this chat mode feature which allows you to chat with the AI opposed to just tell— if you only want to chat with AI and you don't want the AI to code, you want to plan out things before actually writing any code, then you can enable this feature right here in Labs where we try out new features. If you go back into the project, you will see that we have this little toggle right here. So now we can go on chat-only mode.

Mm-hmm.

And now we can ask this question and now the AI will actually give us some guidance. So how do I scrape data from an external URL?

Yeah, sure.

So then we can just send that.

Yeah, a couple interesting things here. While it's thinking, one of the questions I had written down, I hadn't realized this feature was there, was how do you think about getting the AI to sort of coax more of what you want out of you? When I first kind of prompted and when you first prompted, it was like, here's what I want. And then it just kind of immediately hauls off and is like, all right, we're coding, here we go. And I feel like if you were to, again, just sort of compare and contrast this against What would the experience be if I were Elon Musk today? Right. It would be sort of a person answering back to me and being like, hey, okay, so yeah, Elon, I got a couple questions for you about what exactly you want before I go start coding this. This seems like a step in that direction, but I'm interested in your thoughts on the sort of potential for a Socratic interaction with—

Yeah, there's a lot of things you learn by using a system like this. And I, we are like, as when you become a super user of our tool or other AI tools, you get like 10x The value. So getting there the fastest is, is something that's a big part of building a product like this. And we haven't gotten that far. What you're seeing here is that it suggests click on this button to go to the Supabase API key or the edge function logs, for example. It gives you those information contextually, but the next steps are to interject some of these conversations like, okay, before we do that, let's go through a few of the things to clarify. And then it— It says, I'm ready to build it now. Does this look good? Does this plan look good? Then we go back to execute. It's not the most critical thing for the product. If you're really good at using it, if you use it a lot, then you can still get all the value without that, I would say. Now, this is an AI full-stack engineer, but in the future, you're going to be talking more to a CPTO, Chief Product Technology Officer. That's how I see it. Or also, Chief Design, Head of Design.

Yeah.

And then it should be doing even more of those things, right? Like what technology choices, like suggesting things with a product. And I'm super excited about seeing how all of this evolves for us and for others building in the space. What you're seeing now in what Isaac is doing on the prompting side is that it said, okay, let's use Firecrawl. Firecrawl is this super popular way of fetching data from the internet. And then it says, I'm going to need your Firecrawl API key. Go to this URL, and then it opens an input box where you just paste your API key. So you have to like we don't manage your Firecrawl billing. Firecrawl is free in the beginning, but then it costs money later on. But you're fully in control as a builder with Lovable that way. And then now it is trying to do a scrape request, and like when you're building yourself or when you're building with Air for that. You often run into errors. So that, that, that's what we're seeing here. There's some, some kind of errors and you can click try, like we're seeing some of the error part of the logs here. Now we've, we've gotten access from Supabase so that we can get the error logs from the backend. So that's going to be launched. That's going to be a game changer to build this, build backend endpoints, which is what, what we're doing here.

Mm-hmm.

But right now, Isak has to manually open the edge function logs in Supabase and paste the errors from there. So there's a bit of a complexity here.

So is this a new feature that they're— because this is something I'm also very much on the lookout for, is people building for AI users as opposed to building for human users. And if I'm understanding you correctly, this is maybe an instance of this from Supabase where they In the past were kind of like, well, of course it's gonna be a human developer, so they'll just come to our site and look at the logs and understand the logs and whatever. And now you need more programmatic access because you're actually trying to directly feed that into a language model. Yes.

Yeah.

I think we've been driving most of Supabase new signups, at least in the past. I think that might still be the case. And they are like, oh wait, we have to start building for exactly what you're saying, for programmatic access to everything. And I, I know that others who are building similar products to Supabase are also like, we are going to be agent first in terms of building for a world where software and all of these things are managed by agents, not by humans.

I definitely have this experience too, where I find myself being like a glorified copy and paster, you know, is sort of a lot of what I'm doing between things. That's also been the case even in just, we kind of got sidetracked from this earlier, but we were talking about like different models and what happens when there's an error and OpenAI can with the 01 series can kind of help reason through things. I found myself quite often using ChatGPT Pro to make my plan or diagnose how should I think about this feature at a high level, have it give me instructions, and then I'm pasting instructions one by one into another UI, AI UI, and having it implement the plan step by step. So it is funny how much of the actual watch over the human shoulder. They're spending just like pasting, you know, stuff back and forth between systems. And that definitely seems like the sort of thing that's gonna get smoothed out.

Like that, that's a big part of the, the, what you're seeing with Lovable here is, is collecting, like the, the hardest part or the most important part in the beginning of building a large language model app is context management and knowing like, do we need information from this source for this, from this other source? From our knowledge database and from like the history of what the user has done. And if you're very good at managing that context, it becomes much easier for the workhorse of the coding, in our case, Claude, to take the right decisions. And yeah, I think that's— we have spent a lot of time on that and that's why, a reason why it's just more reliable than other tools that, at least according to the people that I know who have, who run comparisons among all of them.

I did enjoy how you had the, and this maybe also kind of gets to who you're targeting in terms of users and what you're seeing in terms of, you know, the kind of background of people that are using the tool and what level of knowledge they have coming in.

Yeah.

But I did appreciate how along the way there are these sort of prompts to say like, I'm not going to tell you go somewhere else and find the place to do this instead. Like, You give me the API key here, I'll put it where it needs to go. I thought that was quite nice and definitely a notable step toward anybody being able to do this sort of thing.

Yeah.

But Isaac, do you want to go to the edge function logs and see what was exactly the error?

Yeah, let's do that.

So, here it says error if you click that one. And this is what's not yet, in production at least, fed into The AI system, but that should of course be fed into the AI system. And what does it say exactly? So I think we can just copy paste all of this into the—

Yeah, let's just do that.

And then go back to the, to the app. So this is what you're saying, like now we're doing the copy pasting. This is going to be completely automated and then we wouldn't have gotten stuck at this point at all.

Sure. Yeah, let's just send that. Hopefully this should—

So when you're connecting to external APIs, it's as you said, Nathan, it's often more things that can go wrong. And that's where you need to have a system that's good at debugging itself between the different components that are interacting. And now we're interacting with the browser is interacting with Supabase that in turn is interacting with the Firecrawl, which is kind of fetching the data for us.

One other question I had going back several rounds in the exchange with the AI was I forget exactly what you typed, but it was like, what's the best way to scrape product information?

Yep.

And yeah, so what's the best— how do I scrape data from an external URL? So I found in my general use of AI that I think this is starting to change a little bit with the reasoning models, but certainly pre-reasoning models, I've developed a practice of trying to be super neutral with my language, because especially in an area where I don't know super well what the right answer is, I'll often find that unintentionally I can bias the AI in a particular direction. So, for example, there scrape, right? Seems like it with almost all the models up, at least until the sort of 01 series, My use of the word scrape would naturally send the AI down a path of like, okay, we're scraping. And then in a lot of tools I've seen, actually, I really like the idea of trying to default to the best-in-class tool, like a Firecrawl, so that you're not kind of recreating scrapers from scratch. But I've had many experiences where it'll be like, okay, we're going to write a Python scraper. And then it'll make a sort of bare bones, like, we'll use the requests library to go get the HTML and then we'll use BeautifulSoup and whatever. And next thing you know, you're sort of lost in scraping hell.

Yeah.

And it's like, man, there's way better things out there to do this. So I like the idea, first of all, that you're sort of seems to be kind of curating in the background, like, these are the production-grade tools that we trust that you can tap into immediately. So you're not kind of recreating stuff from scratch. But I also wonder if you're like, in more general, do you have like a list of sort of, these are the tools that are like on that sort of Firecrawl level that we know and trust, and we're going to kind of try to route common needs to those best-in-class tools?

Yeah.

So we have like a list. We have, if you go to lovable.dev/integrations, there's like the ones that We default to, and we're adding, I think maybe not everyone is here, but we have for emails, we have Resend, for payments, Stripe. For AI, it defaults to OpenAI or Anthropic if you ask for that. If you want an app that generates images, that's Runway. And I'm not sure we launched it yet, but we have using Replicate for various AI and all other plethora of AI APIs. Yeah.

Models galore, for sure.

Yeah. And I think there are many people that request us to add their, like, people that reach out from large tech companies that want us to use them as a default provider for both for the backend parts and for some, like, for payment, for example.

That's cool. I think that is really smart. Going back to just kind of the language and sort of the user potentially Mistakenly leading the AI astray. I've started to see with the reasoning models, occasionally they will come back to me and say, I understand what you're trying to do and why you're trying to do it this way, but I actually recommend a different approach. Like in this case, it might say instead of scraping, you should use a commercial API that can get product information for you or whatever. Do you have any sort of strategy for kind of questioning the assumptions Of the user to make sure they're not like going down sort of the wrong path?

That's a good, that's a good, yeah, we should have that. Like now we rely on people really knowing their shit and like, or being, being fast learners and figuring out errors. Like in this case, I will definitely be like, okay, now maybe we had the problem and I will restart from scratch. I would just like, okay, let's restart from scratch. And because then you can instantly quickly learn like, how do you make this? Work reliably. And in the future, I mean, we want to of course be much more Socratic and be like, okay, this is the situation. We— I think you're asking for this, but it doesn't really make sense potentially. Or like, what do you mean exactly? And that's going to be a big level up for most users. I'm surprised that this didn't work absolutely instantly. So what we're seeing is We're getting an error. We're getting a bad request. And now, I mean, most non-developers have a hard time understanding this, but it is possible that as a human go in and say, okay, there's something about the connection here not working. And it says like, oh, review the API documentation. I don't think we need to do that. It says unrecognized keys. Maybe something changed in their API, but we're getting 400 errors. If I ask try to fix, it will pass the test in— use these logs. It will not use our Supabase logs, right? You need at least 2 products to compare. Okay, sure, let's do it. Uh, it'll scrape enough products for comparison. That's, that's clear at least. And while, while it's running, I'll check the Supabase logs to see if there's any more details there. Cool. And yeah, what you can of course do if you're a developer is like you spin up a nice UI. There's a lot of best practices that are like spun up for you, Stripe and so on. And then at some point maybe you want to do edit the—

Seems like it was successful.

Oh yeah. Unknown product, unknown product. I think the problem here is that I'm not scraping washing machines. Do you have any washing machines? Yeah, I added on another tab, but it's going to Let's take two of the same washing machines. Here we go. So I had to click try to fix. I'm so happy I could help you out.

You were trying to fix it. Why didn't? Okay, let's hear.

Amazing. So then what you what you say is just like it just says unknown product. Make sure.

To show it. It seems like we're making progress now. So I think it successfully scraped the links now. And I think like one thing that I did is that I included the documentation on Firecrawl. And that's one thing, like these LLMs are not up to date. If, for example, Firecrawl updated their docs or API, the Lovable might use the old documentation and then you might have to include that within the context. Now in our native integrations, we actually stay on top. of all of that stuff. So that will essentially always work. But in the case where we want to pick an arbitrary API and use it, then it will not necessarily work if the API has been updated. Now, I guess the LLaMA AI doesn't actually know what to display right here. And I think we will have to use OpenAI.

Yeah, no, that's true. That's true. We have to process the product image through an AI model. But I mean, this is very standard. Okay, so You get something, you'd be like, okay, something, the API works. Now we have to update the UI to handle the API response. And that's what we're do— what it's doing now and writing a little code.

Let's see. Yeah, there we go. There we are.

Yeah, here we go. Yep. So we're seeing that, we're seeing them, but let's now an AI analysis of them. And Nathan, do you have any preferences on what you would, so what you would want to compare given where the UI is at right now?

Yeah, I think maybe I want a 2-part analysis that first is like, what are the most relevant factors to consumer satisfaction with this product type? And then present those in sort of a head-to-head way. And they could be like key features, it could be common problems. But that front loader, top loader thing is a good example where I was just never really thought about that before. And then when you start reading the Wirecutter on washing machines, it's like, okay, well, the first thing you're going to need to decide is, do you want front loader or a top loader? And by the way, if you have a top loader, then you definitely can't stack them on each other. So do you have space for 2 side by side, or do they need to stack? It's sort of this, like, what should I even be thinking about? As the relevant dimensions and then show me what they actually are.

That makes sense.

So let's ask that. I'm saying let's send all these products to the AI and it should be like in a short format, give you 3 important features to consider. And as a recap, now what we have is you can enter products, you can get the data, and now we're going to send the product data to an AI model to say what should we consider? And then as a step after that, probably list the differences among those dimensions as a table or something like that.

Yeah, but that's really interesting that like some of the dimensions of certain products we don't even know, right? Like you didn't even know that that was a relevant thing to look for in dishwashers. So yeah, I think that would be a really cool thing that dimensions will actually be suggested by the AI to us. And to create that table, we'll want to get a structured response from one of these LLMs, right? And that's totally possible using function calling, and Label knows how to use that. So I think that's probably the next step after we have this response.

And I just want to clarify, for an application like this, it's, I would say, for a pretty technical person, you can very reliably build this entire application end-to-end for a technical person. If for people who are less technical, for a simple application like this one, with some patience, you can, you will be able to succeed in building it, but you will run into problems with at least 50% probability. You'll be frustrated if you're not technical. And with maybe 10% probability, it will take a shit ton of time. Like you'll really like get, feel like you're getting stuck. And that's But, and it's a bit random, like for, in some, some cases you're lucky, in some cases you're, you're less lucky. So just like this, this type of application is something you can definitely build with the current version of Lovable. And this is as bad as it's ever going to be. Like this is as bad as it's ever going to be.

Yeah, it's funny. This has just been, how long were you building before you launched 2 months ago? I think we're talking on exactly the 2-month anniversary of your launch.

So the company has been, we, we started the company a bit more than a year ago. And then we went through a few different iterations. We went down like their agent hole or agent route, which has some advantages, but we came to some realization on the UX why agents usually have very bad UX and made it much more focused on speed and like the fastest possible way to get the result back to the user.

I mean, I think people have very different ideas of what an agent is, or they mean very different things when they talk about agents.

Yep.

And the way I think about agents, as opposed to, say, intelligent workflows, is that an agent in my mind is something that has at least a certain amount of delegated decision-making authority. Whereas if I make something in a Zapier-type framework where it's like one step follows the other, maybe some of those steps are AIs, but the prompt is prescribed, everything is kind of happening sequentially one step after another. I would say that might be intelligent, but it would be low agency if every step is sort of fully planned out. Whereas here, I think this is actually higher agency for the AI than most product experiences, because here there is a decent amount of the AI sort of interpreting what you're saying and making sort of dynamic decisions about Exactly how it's going to go about it. So how do you understand agency and what do you mean?

I mean, the agency, I think, is a bit different. It's goal-oriented, but agent in LLM setting is like the agent does one action and then it looks at the result and then it does another action, then it looks at the result and very open with a very open-ended loop. I think in most cases, if you want to do what you're asking for, like a Reasoning steps and so on. You can do that without that kind of open end, that very open-ended loop. You can design the chain of LLM calls in a, in an intelligent way. What the problem is with, if you do it in an agentic way, which has the benefit of being more general, is that it's very unpredictable how long time it's going to take. And that the unpredictability from a user standpoint, especially if the system is not 100% reliable, if it's unpredictable and not 100% reliable, It's a very shitty experience. So you want to get as far away as possible from that. Uh, and then once you're at the, like the far, as, as fast and as reliable, then you can start making it take more than one, just one step of LLM calls. But I'll, I'll just, uh, look back to the product now so we can see the 2 products now and, uh, them compared, like what we should look at, load capacity, steam cleansing technology. Okay. I don't know if that's a top grade priority, but that's apparently what the AI says is the, the priority.

Yeah.

So we could do some. Better prompting at making sure it looks at what's most important and energy efficiency. That makes sense. Let's take 2 other products. What would you consider buying, Nathan, apart from a dishwasher?

Let's do headphones.

Let's do headphones. So we do Bose and JBL here. And now we're still just going to see what's good to consider for for headphones in this case, but the next step would be for it to list like why you should use X over Y. And I guess we could just write the pros and cons list for both of them for now. We should consider sound quality, battery life, comfort, and fit. So for next prompt, I imagine we could write something like, let's just prompt the AI system to also list the, how the 2 different, all the products compare along these dimensions as a Nested bullet list or something like that. Does that make sense for you?

Yeah, yeah, I think so.

That's like another step then?

I would do the same step before, just for safety.

Same step, okay. And then under the listed dimensions, compare how the 2 products compare with each other.

It's not limited to 2 products.

Drop the number.

It's not—

The products with each other based on the features listed.

Yeah.

Make this happen in the same AI call.

Yeah.

Okay, let's send that.

Maybe this is going to be a killer application when we're done. Yeah, I guess so.

Yeah, I mean, next, not too far downstream from this would be then starting to pull in like customer review highlights potentially. as well. I'm just kind of, my vision for the product is evolving. I'm kind of imagining a sort of advice. The first step is like the advisor layer that's kind of, I'm coaching you on what you should be thinking about. Second step is like, now here's an objective tale of the tape. And to some extent, that's kind of informed by the product pages typically have these sort of spec things. But of course, the They're all formatted differently and it's hard to, even just in simple things like the size of the washing machine, wait, how wide was that other one? And is this one wider and whatever? And then a third section that I could imagine would be just like, what do past customers have to say about this? And is there anything that they're bringing to the fore that the product pages themselves didn't mention? When we may or may not get there in this session, but with all 3 of those things, I think you would have a pretty useful little tool.

Yeah, 100%. I think what I'm also excited about here would be the first step is just, I'm looking for dishwasher and then it pre-fills some of the products to analyze.

Yeah, yeah, that's cool too.

And we got an error now. I don't know what was that.

Yeah, me either. It was—

Maybe we're out of quota for our APIs. So I mean, this is, if you're impatient, you just click to fix. But I don't know why we would have a new error here. So, I would read the logs in this case and be like, if you show logs up there, we can try to understand like why did it suddenly have an error? So, it had bad gateway and that's Firecrawl side. So, if the error starts with 500, it's not our fault. It's actually Firecrawl. So, now it's trying to fix it on our side. We can't do that. But we can try again.

Hopefully it'll prove transient.

Yeah.

Going back to the agency thing, while we're debugging this, if I understand your understanding of agency correctly, what would make this more agentic, but you think is not a great experience, is if, for example, encountering this error, then it just took the next step on its own to try to resolve the error.

Yeah. That is a very reasonable thing to do, right? But it, yeah, there's a few reasons we don't do that. We don't unleash it like that for now.

Yeah. So tell me what they are, because I could, I mean, I feel like having tried a bunch of these different experiences, another one that's obviously gone through cycles of hype and counterhype and whatever over the course of the year is Devin.

Yeah.

And in preparing for this, I did an experiment with a similar little project where I loaded up multiple of these sort of coding agents or assistants or whatever, creating products. And with Devin, I did have a weird experience where, because it just keeps working, right, in the background.

Yeah.

I was rotating between them. I would look at the state of one of the products, give a next direction like we're doing here, but then I would just tab over to the next one. And when I would get to the Devin tab, I did realize I have no idea what's going on. This thing has been working continuously in the background. And in some ways that's like very appealing. But in other ways, when I get there, it might be on iteration 87, and I have no idea what the current state is. So it's very hard in that moment to be like, what are you even working on? What's working and what's not working right now? Where are we? And I did find that to be weird. So it kind of led me to a sense. But then here, I also do think, as you said, that certainly be reasonable in some cases to take that next step. Or another thing that we're looking at here a lot is just literally pasting in the URLs and running it again. And so to some degree, I also think, especially with something like Claude computer use starting to be a thing, part of me is like, could I sort of have limited agency? I don't necessarily want this thing to run forever and run up a bill or drift off into some state that I have no idea where it's at. But I kind of would like it if it sort of took my one prompt, tried to do it, tried to use the product, you know, and head claw computer use, like face, face, go.

That is coming up, the computer use part. I mean, my point, this thing, many of these things you can, like, I think you saw Isaac just use the selector. She'll use chat mode. And there is a pre— this is not publicly available, but there is an agent mode there in that selector, which is only available if you have an admin account like Isaac has. So these things are things that people like us experiment with. The most important thing is that you have a product that predictably works, works in an intuitive way. And Making an agent work intuitively and in a nice way, it takes a lot of iteration, a lot, lot, lot of iteration. And we haven't made it work in a reliable, nice way, but I think we're going to be there very soon. It's something— it's one of the things in the coming few weeks that's going to be on the top of the roadmap.

Yeah, gotcha.

And what you saw here, so the product works now. If you look, we have the 2 headphones compared and it says the key feature to consider is Sound quality, noise cancellation, battery life, and then it runs a comparison. And here, we should continue to iterate to make sure that the AI always spits out the comparison in an easily digestible format. Here, I think it says, oh, this one is offering superior sound quality, in a long paragraph. And what you did, Isaac, is you asked the AI, what should we do next? And then it says, oh, yeah, do visual comparison improvements. We could just— Pick one of these, paste it in, and ask the AI to do it. And then it's, you know, what would you say? Like, we're the CEO and then there's, we just ask the AI PM, product manager, and then we decide what the software engineer should do out of those suggestions. Yeah, I think some of these are pretty good, like reviews.

I think it would look really good if we had like a table, like you guys talked about. And I think I'm going to nudge the Lovable AI now to use function calling from OpenAI. Just to make sure that we get that formatted response for the table. Because yeah, in this case we don't just want a long chat response, we want a formatted response so we can render it in this beautiful digestible way. So yeah.

But yeah, I think that was a good rundown. Now we built this simple AI app and it ended up giving us a product that can provide value. If we had done this with everything logged in and set up from scratch, I would expect this to take 5 minutes and we are happy to see people do speedruns of something like this and record it online. But yeah, as you can see, there is a lot of iteration. Now plain English is the hottest programming language. It actually works in this case, but it still takes an engineer, a human supervisor that does the QA at this point. So that's the state of things right now.

Oh, here we go.

Oh wow, this is actually really good. One more prompt and you just nail it. Yeah.

Yeah.

Nice.

This is nice. Nice.

And unfortunately the AI is extremely politically correct. It just says everything. I can't decide yet.

We should do this with the Bolt and Lava Bolt, see what it does. Is it gonna— should I try it? See what it says?

Go for it. Okay.

Bolt and Lovable. Let's see if it's going to betray us. Betray itself.

This is also like a self-awareness. Oh yeah. Situational awareness test. Yeah.

What a good point. So, so this is not our AI answering. This is the, this is the—

But it, it probably knows, right? In like a system prompt or something. Yeah. It, it should have some clue as to who it is.

Yeah. Yeah. Okay. Let's see if we can get the images.

Oh, for this Lovable. Great.

Let's see.

User interface, deployment options, and ease of use.

No.

Vault 1, 2, or 0.

What?

But that is not true, actually. We do built-in deployment options. So I would say this is, this was great. And yeah, the interfaces are also the same, but that's what you get with AI.

I can definitely vouch for the fact that the interfaces are quite similar.

Yeah.

Yeah.

Okay.

Yeah.

That's, That is really— that's cool. I mean, first of all, we're an hour into trying this. How many iterations have we been through?

17, it looks like. Edit 17.

One thing you mentioned earlier that kind of caught my ear, because I've also experienced this a lot, I'm trying to build up my own coding with AI best practices, is commit at every working state. And definitely be prepared and be willing to roll back to a previous good known state. Find that, and I don't think we ever reverted in this experience. Maybe we can just kind of scroll through and look at what were the 17 steps that we took. And this is not like a lovable comment. This is more of a, like, me doing it with cursor finding. But once I get off the track, I have often found it really hard to get back on track. It seems that the models are generally much better at sort of doing the thing, getting it to doing it right the first time versus iteratively debugging. I find a lot of times they kind of end up making a mess. They try things over and over again. They get kind of confused.

That's right.

They don't break frame well. So yeah, any thoughts about kind of when to revert, how to know when to revert? One thing I have found somewhat successful is when I do revert, I'll sometimes take the error message that it was struggling to fix. I'll grab that error message, go back to the last known state, edit my prompt and say, by the way, last time we got here and you couldn't fix it, so make sure you avoid that this time. And that often does seem to help. But anyway, just kind of wonder what else you have experienced in terms of the— and it's way different, right?

Yeah.

Because I think people have in general, when they have done the code, They have a lot of attachment to that code because it represents a lot of their work. Whereas it should be much easier to just throw away whatever a language model has given you over 4 rounds of prompts. But yeah, what else have you learned about when to execute a tactical retreat?

I think I have some good takes here. So I kind of see it as a search tree, right? You kind of have this tree, you start off You know, in the middle of it, and then you can go in different directions. And when you're trying to implement a particular feature, there are various ways of doing that. And sometimes certain features require certain sub-steps. So usually when a non-technical user gets stuck implementing a feature, it's because he has not correctly taken all of the steps in the right order. And that's why we recommend consulting with the chat-only, the chat-only mode. But I think if you have taken the steps in the incorrect order, then it is a very good idea to revert back. Because then you could just kind of, as you mentioned, you can include the error that you got when you actually got stuck. You have that score tissue, kind of that intuition of where things went wrong, and you can nudge the AI to go in a different direction. And then even if you don't do any nudging, there's still a probability that the AI will go in a different direction just on its own because of randomness, and then it might work. So I think it's hard to say exactly in which scenarios where you should revert, but if it seems like you went down a spiral and it's hard to get up again, then it's a very visual way of saying it. But for instance, I think it could have been a good idea to revert in our case when we were struggling with Firecrawler and then maybe include some of the documentation instead. Yeah, Antoine is now redoing it now with—

I figured out, just see if I can do this in 4 prompts. Can I get your API key for Firecrawler?

Yeah, absolutely.

So do you want to, do you want to show your screen as you're doing this? You're on a different computer.

Yeah, let's, uh, let's see. Maybe you can screen share.

Um, yeah, I think this is really interesting too. I mean, this is sort of, humans end up in this spot where it's like we've been coding this thing for years. We've got all sorts of technical debt. We've got like all sorts of, you know, kind of shortcuts or weird strategies that we use that we kind of wish we would clean up. And this is basically the AI equivalent of that, right? Like, we've been 17 rounds, we're not exactly sure what weird little micro decisions might have been made. And now you're basically saying, okay, now I kind of know what I want. Let me go back, take it from the top and see if I can do like a really clean version.

Is it—

that's basically the thought process you're going through?

Yes.

I mean, I think Isaac had like the worst unlock I've ever seen. So, so I figured like, what's the more likely outcome in, in this case? I mean, sometimes you are unlucky, but this is what I did. I said, okay, let's add the 2 URLs and then let's add Firecrawl, scrape them with Firecrawl. And now I'm going to ask it to send it to OpenAI and to answer 2 things. One, what features should be Considered when making a purchase decision? 2, how do the 2 products compare?

So, this will just be the second edit?

That will be the—

yeah.

So, how did this work, actually? I think we had these 2 baked into one edit. That's true.

Have we connected Supabase on this project?

No, Supabase is not connected in this, in this project, but that's why I wanted to do it like absolutely fastest possible way. Yeah, so, uh, if I would have connected the Supabase first, it would have put the scraping on the base.

But it's all right because we don't hardcode the keys now. Instead, we have this input field where the user would put in their own keys.

Yeah, so we're skipping it, we're skipping a step there.

Yeah, so that's the OpenAI key, that's the Filecoin key.

Let's see here.

And that's very nice. So, like, Laravel seems to almost never hardcode keys. So even though right now we haven't implemented Supabase, it still understands that we probably don't want to hardcode the API keys within the frontend, right? So instead, it just lets us add these input fields. And this will probably also be way less error-prone because now we don't have A complex system, right? Before we had this.

Yeah, I don't know. I wish I connected Supabase. I was too quick to ask for Firecrawl, but at least now we're going to show that this works in just a few prompts, I hope. So what it does is that it lets me enter the OpenAI API key here. I'm gonna make sure I don't leak the API key. Hopefully.

It's all right. I can just remove it afterwards.

Okay. And if you're a bit technical, you can always look at the network logs here and see if we're getting a response from them. Okay, so here we have the websites. It's going to compare Lovable in this case. So then when I fetch from— I hope it's fine. Here we go.

Oh, nice.

So now we did it actually in 3 edits. So now that's, that's what I would expect. To be honest. And we compared, let's compare something really helpful. Amazon is notoriously hard to scrape, so I hope that works. But this was a 3-prompt version of it. And back to your question was like how much we can expect this to work. I think if you're good at using reverts and so on, as you were touching on, then for any product. That is, or any internal tool is one of our core use cases as well, where it's like one main feature, like we're creating one main feature here, then it should take a dozen edits or so. If you're adding many features, it takes hundreds of edits. But, and then it also starts becoming much harder because you're noticing that like the AI doesn't handle large codebases as well. We, yeah.

Yeah.

There's a lot of smart things we're doing to handle large codebases, but it doesn't handle large codebases as well.

Yeah, that's, I mean, I'd be interested to hear more about that to the degree that you wanna share it. I mean, what I have been doing on my own is just taking literally my whole codebase, like my little app that I've mentioned a couple times is roughly 100,000 tokens. And with AI's help, of course, I had it, you know, just write a little script to Put that all into a single file, kind of like your llms.txt, except it's not docs, it's literally just the source. And then paste that into ChatGPT and ask O1 Pro, figure out a plan. Here's all my code, figure out a plan for whatever. Now, obviously that's going to run into limits. So I've started to try to first modify my script that creates the single file. And, you know, well, we don't really need like the CSS classes, you know, or we can like skip these various things. So it sort of adds a bunch of regular expressions to the script that prints the single file and that'll save me like 20% of the tokens. So then it's okay, cool. Now I can, you know, do a couple more features till I hit the limit. But I'm like, obviously, you know, big codebases are like way bigger than 100,000 tokens. So what have you learned about managing context? Are you doing like dependency tree type of stuff?

Yeah.

Curious as to what you've found to be successful?

I mean, there's some things that really give you a bang, a lot of bang for the buck. And how we do RAG, like we do agentic RAG, is one of the key differentiators for why our product is very good, even as the codebase grows. So I can't go into detail, but just being smart about agentic RAG gets you very far.

Okay, well, that'll be a little— I'll have to go on a little side quest to figure out exactly what that is.

I mean, you can try to reverse engineer it as well. I'm looking to be more open about this. This is a big part of it, like where it's strong, and we're building out many more areas. But yes, we got this error from where, like in the last session here, just seeing how does the product work that we built, where the error was that OpenAI couldn't handle Amazon websites, there's too much text on the Amazon website. So the AI set the max number of characters to 4,000.

I think my guess is that this is going to not have the information. That's kind of what I ran into when I was messing around with this myself a little bit. If you just like truncate, you get a lot of just like header script kind of cruft garbage. So I was. I was thinking, you know, how, but that does get tough. That's where I was kind of like, man, hopefully Firecrawl can like maybe solve some of that nonsense for me because—

Yeah, but I think it did solve that. Yeah, I think it did solve that quite well. Did we get a response here? Oh, is it doing a crawl in here? No, I hope, I hope not. So it do, it says like that it, it picks up the title, it picks up the text like in a nicer format. And now I don't know if. We're like, how— I don't know how we're using this different data. Normally, like, to use our product to its full potential, you often want to paste in like the payloads from the API request because they are not fed currently, I think, per default, at least not fed into the LLM. As you see, there's a lot of data here, but then it would be better at picking this.

Yeah.

I think we're doing something in the background. Why is that? Can I do like a clipboard history here?

Oh, we got a response.

Okay, we've got the response. So we have a lot of info.

Yeah, I think it's still analyzing, so we're waiting for the LLM to—

So it's not a fast application that has been built here by the AI, but it gives us—

Okay, it says it's completed.

Oh no, I refreshed, or I think I pressed back. Oh, no, I have to start over.

Okay, cool. I think this has been really good. It's really interesting. Smart RAG is a takeaway of something to think about more, for sure.

Yep. Management is a superset of Smart RAG, and that's really one of the core pieces of this.

Just in kind of a couple wrapping up sort of questions, where are you guys at today? Who are your users? You've scaled like remarkably fast. I've seen tweets to the effect of, you know, one of the fastest growing, if not the fastest growing, you know, European startup ever, maybe. So what's that story like over the last couple months?

Yeah, so I mean, since we launched, we've been just continuing to grow. If you analyze it over a year, it's $1 million revenue per year. So now we're actually at $9 million. And that's faster than From like in, so that's in 8 weeks. So that's faster than any other company like launching from Europe that, from my research, it's the fastest. And more importantly, we have hundreds of thousands of users. And when we ever, we post something online, people are, it's full of comments of people who are just like blown away by what they can do with our product now. And there's a lot of love. Yeah. Our users are the people who are paying, they're using it. Every other day. So there's a lot of positive aspects. What we're doing going forward is to make this valuable also to teams that collaborate. And you can actually see that on my screen that I'm sharing here. Like, this is not a launch, but we're going to make it much easier for people who collaborate to use our product for that. That's a bit of a snapshot, but what's much more exciting than that is the AI becoming more reliable, being able to do more debugging itself, and launch agentic mode that you saw here as well. That's in the works.

So I wanted to ask also about edit code and publish that I see in the upper right-hand corners. Like those are, you know, maybe the less interesting things from an AI perspective, but they're obviously important for people that wanna Even ship an internal tool, right? So what does that look like?

We're deploying the applications on the edge with Cloudflare. And then it makes it possible to just like with one click, you have built your app and it's all in production and it's running and it scales really well as well. So that's how our publish flow works right now. Edit code is actually more interesting than it sounds. I mean, you can edit it with any IDE, like Cursor, whatever. Here, I'm just opening VS Code in the browser. And then if I change something, let's see here, then it will synchronize. So, then I will instantly see, oh, a human edited the code from their favorite IDE. And this is also a way to collaborate with the teams. And this is not us. So, GitHub is now slow, is what I'm showing on the screen. But that's what we have mainly to talk about. I mean, there are some more very valuable features that you learn if you're a super user. One is that if you have a specific API, like the documentation for a specific API, you can just put that in the knowledge for this project that we're editing. And if you want to do changes experimentally, like if you're a developer, you're used to something called branching, and that's something that's built into the product as well.

Gotcha. So you've got the basically kind of dual mode of you can do the full developer experience with your IDE. You've got all your obviously changes tracked on in a Git repo here, branching, et cetera. How does your user base break down? I mean, it's probably all happening so fast, you may not even know, but like how many people would you say that are using this are developers trying to move faster versus people who are like, I don't really know how to code, but I want to make something?

I think we ask this question, like, how much coding experience do you have? And it's split evenly with 25% in like no coding to up to a bit and up to like a lot of coding experience. And we are all about empowering like the 99% of people that don't know how to code. And it's even more who don't know how to do both frontend and do backend. So there are more users in that bucket, but the people who are technical, they get much further. They can build much more complicated things because they understand a bit of debugging. They understand what API calls, how that works, and so on. So the theme we have in common about our favorite users are that they have a very entrepreneurial spirit. They are like high agency, another way I like to put that. So it's often founders and operators who are running their own business. So maybe it's an agency and they're like super quick to understand what's possible with the new technology. Like those are our favorite users today.

What do you think is going to move the needle most over the next couple months? Is it just better models or anything else that you're kind of specifically tracking? And where do you think we get? Say over, if you can see this far into the future, where do you think we get over the course of 2025?

Yeah. I mean, for us, like you mentioned DevOps and the infrastructure being the big bottleneck and long-term, we are going to be more of the infrastructure package in a very nice, quite opinionated way for AI, for the best AI models. And more of our, the smart algorithms that are putting us ahead of others today are going to matter less because the large language models. are going to advance and advance and just keep becoming more intelligent. And our tricks on top of that are going to be less important. The things that do matter for us in the coming months is to add a few more. We're trying to assemble a team of the highest talent density here in Europe, like absolute geniuses, the people creating the product mostly. And that's what matters for us, and making the team work really well together, figuring out what is the right abstractions, both on the UI and the UX, on the infrastructure of the code, that's on the projects that are being generated, and being smart with getting the most out of the large language models. So figuring that out as a team is really the key to win in any, building any type of AI product, I think.

Do you want to put out a call for what you're looking for and where? Are you guys all in Stockholm or is there a—

Yeah, so we're hiring. Mainly for people who are up for relocating to building in an office, which is much, much more fun and want to solve really, really hard problems and be at like the absolute epicenter of what AI is able to do right now. And we're paying top of market for the top talent. Cool.

Well, this has been fascinating. Anything else you guys wanna touch on before we break?

I think if people haven't tried these tools, Then the best thing you can do for your career and for your friends and so on is to get your hands very dirty. That's like you're going to learn so much from using these tools, even if you don't have a business application today. You're going to learn so much. If you're currently like working without AI, then I think you're really disappointing your employer or your customer, your clients. If you're running an agency. So you should get on the train. It's a huge time saver.

Yeah, get hands-on. That's always my number one advice as well.

Cool.

This has been really fun. I've enjoyed the peek into the product and I will definitely continue to follow your progress and I don't expect it to slow down. So keep up the great work.

Thanks a lot.

For now, I will say antanasika and aiseksundaman. Founder and AI engineer respectively at Lovable, online at lovable.dev. Thank you both for being part of the Cognitive Revolution.

Thank you for having us. Pleasure.

It is both energizing and enlightening to hear why people listen and learn what they value about the show. So please don't hesitate to reach out via email at tcr@turpentine.co, or you can DM me on the social media platform of your choice.