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 become 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 and say, “Okay, this is a better model.”

We don’t use just 1 LLM. We do smart routing and use models from Google Gemini, OpenAI, and Anthropic, and soon, I imagine, potentially DeepSeek.

When you’re connecting to external APIs, as you said, there are often more things that can go wrong. That’s where you need 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 works in an intuitive way. Making an agent work intuitively and nicely takes a lot of iteration. If you’re currently working without AI, then I think you’re really disappointing your employer or your customers.

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 Anton Osika and Isaak 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 its first 2 months on the market, thus becoming 1 of, if not the single, fastest-growing European startups ever.

In this hands-on episode, we weave a discussion about Lovable’s vision for the future of software, its product philosophy, and some of the opinionated choices it has made to maximize user success rates—including its Supabase integration for database functionality and authentication, its approach to error-message handling and debugging, and its extremely novice-friendly user experience for handling API keys—together with a live demo in which we actually use Lovable to build a large-language-model-powered product-comparison application.

As you’ll hear, while we do encounter some friction along the way, in the end we’re 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. 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.

I should note that we recorded 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 a willingness to retry when needed can create basic full-stack applications on their own without writing any code. New models will only continue to expand the scope of what’s possible.

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, cognitive revolution. We always welcome your feedback and suggestions. For now, I hope you enjoy this unique look at AI-powered software development.

My guests in this episode are Anton Osika and Isaak Sundeman, founder and AI engineer at Lovable, online at lovable.dev. Welcome to The Cognitive Revolution. It’s great to have you here.

It’s great to be here. Thank you.

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

Well, thank you. That’s very flattering. That is definitely the goal: to learn as much as we can and hopefully be a little smarter about what’s going on in AI.

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 1 of these so-called AI full-stack engineers.

AI full-stack engineer, yeah.

It’s 1 of these things where you can show up and say, “Hey, I want a piece of software created for me,” describe what you want in natural language, and then have the AI run off and try to build it for you.

Today, what I thought we would do is a little bit harder than our usual format. We’ll have the normal conversation, try to understand what you’re building and your vision for the future, and discuss how soon you think human coding becomes irrelevant, if that ever is going to happen. At the same time, we’ll actually go in the background—partially in the background—and try to build an app as we go. I think that’ll be a very informative, 2-track experience.

Anton, you and I will be primarily talking, and Isaak, I think you’ll be primarily coding in the background. Let’s start with a little bit of programming. This will be on the video feed, so we can follow along with you. We can stop and interject at any time and share developments, while Anton and I continue with the big-picture discussion.

A simple app that I had an idea for, and that I think we’re going to try today, is a product-comparison app. Basically, say you’ve got a couple of links to a couple of products online and you want to get a good comparison of those 2 products. You feed them both into an app, and the app comes back and tells you what matters about this kind of product and how these products compare on that dimension.

I’m thinking of this as an AI-driven comparison. It’s not something that would be fully programmatic or formulaic, but there would be a little bit of dynamism in using the AI to determine what sort of comparison even makes sense for a given product.

How does that sound?

That sounds good. I think—I hope so. What types of products do you want to use this for?

What’s so interesting about AI products in general is how open-ended and flexible they can be. My initial idea was 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. My wife has been going onto review sites, Wirecutter, Consumer Reports, and trying to figure out which one we should get. Obviously, capitalism has provided us with a huge number of different options, but we don’t even really know what matters. We’ve never bought one before, and we’ve never thought about it.

If you think about what you do today—or if I think about what I do today—I first feel like I have to go out and educate myself generally about a product category. What are the dimensions that matter? That process of identifying those dimensions is where the bulk of the cognitive work seems to be going.

For example, do I want a front-loader or a top-loader in my washing machine? That was not a question I had considered at all before. I first had to educate myself to even get to the point where I realized that was an important dimension of the comparison.

If the AI was really serving me well, I feel like it would flag for me, “Here are the main things that people find important about these products that you may not even be aware of yet, and here’s how they compare.” Creating the comparison framework and then populating it is what I imagine we would have loved to have had these last couple of days.

Let’s see if we can ship an MVP and iterate. I think that’s always the best start: keep it super simple.

The first part is to get some core data input into the system, fill that into an AI, and see if we can hook all that up and how long it would take.

One workflow could be that you say, “I want to buy a washing machine. Which ones should I compare?” But let’s be more helpful and say, “I want to put in a few URLs of different washing machines and compare them.” Does that sound reasonable?

I don’t have a super-prescriptive idea in mind of exactly what the user experience should be. That’s probably the cheaper first version.

There are also some of the things you can think about when you create a project within Lovable. You can think more broadly about what tools and APIs we should use. For example, there’s the Firecrawl API, I believe, which will automatically search things up for us. That could perhaps be super useful.

Let’s start with as many constraints as possible, see if that works out, and just get the UI up.

First, we type out a prompt where we say, “I want the UI to let me put in URLs of products, and then some information about those products should be shown. The AI should help guide us through what’s important to consider, maybe generating a product-comparison table.”

Let’s go with this prompt.

Nathan, do you think this is good? What do you want it to do once you put in the fields? Should we have a button called “Analyze” or “Compare”?

Have an “Analyze” button.

That sounds good. Then we have an “Analyze” button that, when pressed, will scrape the website and get the data, and then call GPT-4o. Let’s take that later. Let’s start with a really nice UI.

I’m typing out the prompt here, which has a few typos and things.

The typos don’t matter. It understands them perfectly. But the formatting and the sequencing of what you ask, and in what order, matter quite a lot. Being very specific about what you want to change in an application is very important.

What we’re seeing now is that the AI creates a plan for what to do. First, it plans out the design, and then it generates what we think are the best practices in terms of a web application. Most software today is actually a web application, so that’s what it’s doing. It’s React code, and now it’s spinning up the first UI version of this.

Here, you can add a few product URLs and click “Compare Products.”

Then we’re getting a Swedish version of washing machines because Google is adapting to where we are right now. Let’s pick that one.

I guess the idea is the same one, right?

Yes. Let’s take something else, this different one.

This should work for Amazon or any URL, right? Let’s see. Then we press “Compare.”

Nothing should happen right now because we haven’t actually connected the backend or anything.

I love how it gives you that little heads-up notification. We need to hook up the data input, and then we need a backend. The backend is necessary when you have something that requires external data, AI features, and so on.

The way we set up a backend is that we rely on our wonderful friends over at Supabase, which has a backend-as-a-service that covers all your needs. Usually, I guess you would be logged in here, but now we can connect it with 1 click and get the backend set up.

Let me log in real quick.

Do you want us to clarify anything about what’s happening there, Nathan?

Let’s start with the big vision, and then we can meet in the middle. We’ve got the very low-level process: we did our first prompt and we’re connecting to Supabase. What do you think is the big-picture future of software? Where is all this headed?

I feel like we have competing narratives right now around the future of software. My crystal ball gets very foggy more than a few months out, but what do you think is the medium-term future of software? You could take that from a user standpoint or a developer standpoint. Are there still developers? Does anybody just speak software into existence?

My biggest prediction here is that when I was very young, I started coding and creating computer games. That was a superpower: understanding the world, communicating about technology, and making things come into existence. But much less than 1% of the world’s population has that superpower.

With AI, the other 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 software that they prefer, customized or improved for them.

The change, and how fast it’s going to happen, is that AI is much faster than humans at writing code. That’s going to result in some kind of Cambrian explosion of really high-quality software. Human creativity is going to be unleashed at a much larger pace.

That’s going to be the biggest change. 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.

One big question I still have about that is: with this example we have, if I imagine a future where AI continues to advance and achieves the promises that everybody seems to believe it’s about to achieve, it seems like we have lots of reasons to think capabilities aren’t done improving.

Will there be any UI in the comparison process for products in the future? I could imagine a much different thing entirely where I just ask the question directly. Maybe that’s a fault of the example app 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 a lot about generative UI. There’s a lot of discussion along the lines of, “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’s not going to be the whole answer, and there’s a very simple reason for that: as humans, we prefer when things are predictable and consistent. We also prefer that the products we’re interfacing with have a UX that has been tested by many other humans—something that humans understand easily.

If you have an AI that always generates a new type of interface, with context dependent on where you are, then it’s going to be different every time, potentially. It’s also going to be different for your grandmother and yourself, so you can’t explain, “This is how this software works.”

I’m pretty sure we’re going to have standardized software. People are going to use the same software with the same UX most of the time because that’s easier for us humans. We get used to it and build up muscle memory: How do I use Slack? How do I use my email client?

The exact UX is something that’s super hard to nail. It takes so many iterations to make 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 what the right UI is for what this software is supposed to do.

That’s why I don’t think generative UI is going to come in and wipe out everything else. There are definitely going to be many more generated components and parts of software powered by AI that pull in the right context depending on what you’re trying to solve right now.

I agree with that to an extent. Part of what we’re doing here will have a generative UI component because, even in this product-comparison idea, the dimensions on which a product will be compared are not hard-coded. Even the table—what the fields of comparison are—is a sort of generative UI in miniature.

When it comes to powerful software that people spend a lot of time with, like Gmail, I would not want a Gmail experience where I log in and the UI is regenerated every day on the fly. I know where things are in today’s world, and I want consistency. There’s probably just no reason to recreate that all the time.

Hey, we'll continue our interview in a moment after a word from our sponsors. Even if you think it's a bit overhyped, AI is suddenly everywhere—from self-driving cars to molecular medicine to business efficiency. If it's not in your industry yet, it's coming, and fast. But AI needs a lot of speed and computing power, so how do you compete without costs spiraling out of control? Time to upgrade to the next generation of the cloud: Oracle Cloud Infrastructure, or OCI. OCI is a blazing-fast and secure platform for your infrastructure, database, application development, plus all of your AI and machine-learning workloads. OCI costs 50% less for compute and 80% less for networking, so you're saving a pile of money. Thousands of businesses have already upgraded to OCI, including Vodafone, Thomson Reuters, and Sunno AI. Right now Oracle is offering to cut your current cloud bill in half if you move to OCI for new US customers with minimum financial commitment. Offer ends March 31st. See if your company qualifies for this special offer at oracle.com/cognitive. That's oracle.com/cognitive.

What does the future hold for business? Ask 9 experts and you'll get 10 answers. Bull market, bear market, rates will rise or fall, inflation's up or down—can someone please invent a crystal ball? Until then, over 41,000 businesses have future-proofed their business with NetSuite by Oracle, the number-one cloud ERP, bringing accounting, financial management, inventory, and HR into one fluid platform. With one unified business-management suite, there's one source of truth, giving you the visibility and control you need to make quick decisions with real-time insights and forecasting. You're peering into the future with actionable data. When you're closing books in days, not weeks, you're spending less time looking backward and more time on what's next. Download the CFO's Guide to AI and Machine Learning at netsuite.com/cognitive. That's netsuite.com/cognitive.

People do want that. I hear you on all of that. At the same time, I have a different vision that competes with this, too. If we’re imagining a world of abundance in the future, and we say, “What do the people who have the most abundance today do?” would people in that future state of abundance try to do the same thing, or would they do something different?

How does Elon Musk buy a washing machine today? I think the answer is that 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. If it did, he would just say, “Find the best one, buy it, install it, and let me know when it’s done.”

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 he’d say, “Tell me what I should do, and then I’ll review it and approve it.”

I 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. Then go online and buy it.”

I can riff on this. The AI would know what he wants—or, in his case, his colleagues would know what he wants. That transfer is the only important thing in the future: somehow transferring what the human wants and desires in this very moment to a different system, and transferring the information back to the user.

Over time, AIs are going to read our minds, basically, or become extremely good at predicting what we want in a given situation. Those UI elements where you need to say, “I care about front-loading,” won’t be necessary because the system will already know what you want.

Displaying information to the user might also be less important in the future. We’re going to have, at least at some level, standardized UI components, but I’m not saying this isn’t going to happen. I’m just saying there are going to be some parts that are going to be this way.

One question I’ve had, as I’ve tried all sorts of things—I’ve made it my business to try a wide range of products—is that I’ve been a longtime fan of Replit, and I’ve used Cursor pretty heavily in recent months while 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’s exposed to the internet—seems very hard relative to that initial code. So many experiences I’ve had are like this: you say, “Give me this UI,” and you get something pretty decent that looks more or less like what you had in mind. Then you ask, “Why is this dependency missing? What’s going on? This thing isn’t building,” or you’re not sure what’s happening with port forwarding.

All of that seems very hard for the AI. Do you have a theory for why 1 is so much more difficult than the other?

Totally. Software engineering gets very hard when you have different things that have to connect. The more components that have to be wired up and connected to each other in the right way, the more exponentially error-prone it becomes.

The way we approach it is to limit those choices as much as possible. We say, “If you’re going to deploy something, you can only use Supabase for your backend functions and database. If you’re going to add payments, there’s a very clear happy path for that.”

We generate a button for you to go to Stripe and get your account set up, or simply grab your API key and come back. Then the payment is almost guaranteed to work if you follow that path.

If you let an LLM—large language model—work in a tool like Cursor, which is much less opinionated but still an amazing tool, it will sometimes generate different pieces of software that haven’t been fine-tuned to work together or aren’t guaranteed to work well together. At some point, you’re going to run into a problem, and the AI is going to have a hard time recovering from it.

Do you think this is a technology wave that creates consolidation across different technology stacks and potentially across core providers?

It seems like everyone is noticing, for example, that in the original generation it was Tailwind CSS. That’s become a community favorite, if not a standard, and it seems like it’s a standard in most code-generation experiences. For payments, I don’t know what you’re using, but I would expect Stripe to be a leading candidate because it has lots of great documentation and so on.

Is there a Schelling-point effect where everybody ends up using the same core components?

I think so. There’s already a Schelling point among human developers where Tailwind is the Schelling point, at least according to most people.

Large language models accelerate that because, first, it’s much easier for a human to learn new best practices. If I don’t know Tailwind, it takes me a long time as a human to learn it. With an LLM, it can instantly produce it and it works.

Secondly, the LLMs are much better at the very popular choices because they have much more training data on them. There’s some convergence, for sure, but I’m also excited that there are going to be technological innovations. Tailwind might not be the end-all. There might be better ways to style components.

Facebook came out with something a few months ago—I think if that gets adoption, all the AI tools might switch over to this new Schelling point overnight.

That’s a really interesting possibility. I’ve been interested in that idea at the level of the AI providers, too. Are we entering a race dynamic either between countries or between leading companies? What are the incentives there?

Is there any way for people to coordinate and proceed with responsible caution, or are they going to constantly face this incentive to go faster to beat the other guy?

One question I’ve been wondering about is how easy it is for everybody to switch when a new model comes online. One thing I noticed in Lovable, which is distinct from Cursor, is that in Cursor I can choose which model I’m using in the background from a dropdown. All the developers get to choose.

With Lovable, I don’t know which background model I’m using, so you’re choosing. I wonder how easy it is for you to switch and which dynamic is better or worse from the developers’ standpoint. You’d have more of a process, but you’d be switching on behalf of all your users. I’m interested in how you think about model choice and switching.

Historically, we have switched overnight after a new model comes out. We try it and say, “Okay, this is a better model.”

We don’t use just 1 LLM. We do smart routing and use models from Google Gemini, OpenAI, and Anthropic, and soon, I imagine, potentially DeepSeek and maybe Kimi.

We do have a model selector for ourselves as an admin feature, so we can make selections. But I don’t think that’s the right user interface for users because if you have a selection and don’t have all the context, you’re more likely to make the wrong decision.

What we’re planning to roll out is that the default will be the fastest chain of large language models. If that doesn’t work, it will show that in the UI and let the user have some control and a deeper analysis of the problem with larger and slower large language models.

I think that’s the right approach, rather than being specific about which chain of models is running. That’s too much information for the user.

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 a winner-take-all contest. You’re already subdividing the queries and figuring out where they should go, so a new model would at most take a bite out of other providers’ usage. It seems very unlikely, based on what you’re saying, that there would be a new model that would dominate everything and take all of the activity from 1 day to the next.

We’ll see, of course. Everything is about having a team that can execute super, super, super fast and move the fastest. It might turn out that 1 model just dominates everyone else in terms of price and performance.

DeepSeek does seem to have become a strong contender all of a sudden.

Do you have a cached rundown of how OpenAI, Anthropic, and Gemini compare to each other today? Is there a shared understanding on the team of what’s best for what?

Sure. To your point, DeepSeek is open source, and that makes it much easier to have low-level control and train your own model. For maybe the majority of fast use cases, you could just train your own model and use that as the default. I see that happening for us quite soon.

Right now, Claude 3.5 is still the best one. It’s very fast, very good at coding, good at reasoning, and it works the best most of the time.

If you want speed and low cost, Claude is actually quite expensive compared to GPT-4o mini. The best model we’ve switched to for the smallest calls is Google’s fast model, which is also really performant and fast.

For OpenAI, the final advantage is that its reasoning models are good when the AI gets stuck and you want to get out of that. They take a lot of information about an uncommon situation and reason from first principles. OpenAI’s reasoning models are still the best ones for that.

The Cognitive Revolution is brought to you by Shopify. I've known Shopify as the world's leading e-commerce platform for years, but it was only recently, when I started a project with my friends at Quickly, that I realized just how dominant Shopify really is. Quickly is an urgency-marketing platform that's been running innovative, time-limited marketing activations for major brands for years. Now we're working together to build an AI layer that will use generative AI to scale their service to long-tail e-commerce businesses. Since Shopify has the largest market share, the most robust APIs, and the most thriving application ecosystem, we are building exclusively for the Shopify platform. If you're building an e-commerce business, upgrade to Shopify and you'll enjoy not only their market-leading checkout system but also an increasingly robust library of cutting-edge AI apps like Quickly, many of which will be exclusive to Shopify on launch. Cognitive Revolution listeners can sign up for a $1-per-month trial period at shopify.com/cognitive. Nobody does selling better than Shopify, so visit shopify.com/cognitive to upgrade your selling today.

I feel like that echoes what I’ve experienced when doing this sort of model choice manually. It always varies a bit, but if I want to add a new feature to an app, I’m working on an app that’s designed to help people create, even more so than curate, because oftentimes it’s synthetic data that’s being used—really high-quality examples for use in few-shot prompting or potentially even fine-tuning.

I found that not many LLM-ops apps really help with that. There are many things that help with monitoring performance, logging everything, and running standard evals, but I haven’t seen too many things that help you get to a half-dozen or 10 really high-quality examples for your particular task.

So I decided I was going to make 1 as an exercise. Why do you use those examples? Is it to compare the vibe-check output on different LLMs, or is it something else?

Did you build this app with Lovable?

I didn’t. No, I’ve been working on it; it’s been a slow burn. That’s part of it. I find that great examples are the heart of any automation project. You first have to understand what you want. Usually, there’s a team involved, so can everyone look at these examples and agree that this is what we want as a team?

Getting clear on that is more of a social challenge than a technical challenge, but it’s an important challenge in practice for many automation purposes. Then, yes, once we have those examples, which model can imitate that on a few-shot basis?

Does it also try to help fill in the reasoning process that converts the inputs to outputs?

Obviously, reasoning and chain-of-thought-type approaches are all the rage now, but even a few months ago—and still, I think—people slept on how important that is.

Often, what they have in their business is the input and the output. If they want to automate responses to customer-service tickets, for example, they have the message received from the customer and then maybe the message sent back to the customer by the agent. But what they generally fail to capture—and maybe they have documentation and policies in some format—is any sort of chain of thought that connects the two.

They very rarely have anything that says, “The user sent this, and now I’m thinking about it this way. The user is asking about this,” and then works through everything until it arrives at an output. That typically doesn’t exist.

Part of what my app does is try to fill that in. It says, “Here’s the output, and it came from this input. What is the likely chain of thought?” It helps people iterate on that so they can see something, react to it, and say, “That is what I do,” or, “That’s not what I do.” They can iterate toward a chain of thought that represents the way they really think about the task.

From there, they can test different models and maybe graduate to fine-tuning. I’m not planning to commercialize this app because I don’t think it’s very monetizable. It’s the sort of thing you don’t necessarily use all the time, and it stops at the point where you have enough examples to take them somewhere else.

We’re not going to run fine-tunings for you or be your middleware. You just get to the examples, and you can export them to a prompt format, JSONL, or whatever format you need.

We launched on November 21. Since then, the product has changed a lot. We launched Lovable with the backend functionality, which is a huge part of the unlock.

Since then, we’ve just been scaling absolutely crazily and spending most of our time keeping up with that. But I’d be happy to show you some of those parts and get back to the product comparison. What do you think?

I just had to log in to Supabase again. I had too many Supabase projects that I’d created, so I had to deal with that.

I pressed the Supabase button and connected a Supabase project to our Lovable project. We can see that we also get a message that’s automatically sent to the Lovable AI when we do that.

Where we are now is that we have the UI, and we’re supposed to try comparing 2 products. We need to fetch the data from the websites of the products we’re comparing somehow. I think the right thing is to ask the AI, “How do I connect a script to an external URL and create data from an external URL?”

We don’t have chat mode enabled here, but we could enable that.

You can decide.

We have a chat-mode feature that allows you to chat with the AI, as opposed to having it code. If you only want to chat with the AI and plan things out before writing any code, you can enable this feature in Labs, where we try out new features.

If you go back into the project, you’ll see this little toggle. Now we can turn on chat-only mode and ask this question. The AI will give us some guidance.

A couple of interesting things here, while it’s thinking: one of the questions I had written down, before I realized this feature was there, was how you get the AI to ask more questions and coax more of what you want out of you.

In my general use of AI, I think this is starting to change a little bit with reasoning models, but certainly before reasoning models I developed a practice of trying to be very neutral with my language. Especially in an area where I don’t know the right answer, I’ll often find that I can unintentionally bias the AI in a particular direction.

For example, “scrape” seems to send almost all the models, at least until the o1 series, down a path where they say, “Okay, we’re scraping.” In many tools I’ve seen, I really like the idea of defaulting to a best-in-class tool like Firecrawl rather than recreating scrapers from scratch.

I’ve had many experiences where the AI says, “We’re going to write a Python scraper,” and then makes a bare-bones plan: “We’ll use the requests library to get the HTML, and then we’ll use Beautiful Soup,” and so on. The next thing you know, you’re lost in scraping hell.

There are much better things out there to do this. I like the idea that you’re curating these production-grade tools that you trust and can tap into immediately, rather than recreating things from scratch. Do you have a list of tools that are at that Firecrawl level—tools that you know and trust and try to route common needs to?

There are a lot of things you learn by using a system like this. When you become a superuser of our tool or other AI tools, you get 10 times the value, so getting there as quickly as possible is a big part of building a product like this.

We haven’t gone that far yet. What you’re seeing here is that it suggests clicking a button to go to the Supabase API key or the Edge Function logs, for example. It gives you that information contextually.

The next step is to interject into some of these conversations: “Before we do that, let’s go through a few things to clarify.” Then it says, “I’m ready to build it now. Does this look good? Does this plan look good?” After that, it goes back to execution.

It’s not the most critical thing for the product. If you’re really good at using it and have used it a lot, you can still get all the value without that. I would say that now this is an AI full-stack engineer, but in the future you’re going to be talking more to something like a CPTO—a chief product and technology officer—or a chief design officer or head of design.

That system should be doing even more of those things: suggesting technology choices, suggesting product decisions, and so on. I’m super excited to see how all of this evolves for us and for others building in the space.

What you’re seeing now on the prompting side is that the AI says, “Let’s use Firecrawl.” Firecrawl is a very popular way of fetching data from the internet. Then it says, “I’m going to need your Firecrawl API key.” You go to this URL, and it opens an input box where you paste your API key.

You have to do that because we don’t manage your Firecrawl account. Firecrawl is free in the beginning, but then it costs money later on. You’re fully in control as a builder with Lovable that way.

Now it’s trying to do a scrape request, and when you’re building yourself—or building with AI, for that matter—you often run into errors. That’s what we’re seeing here. There are some errors, and you can click “Try Again.”

We’re seeing some of the error logs here. We’ve got access from Supabase so we can get the error logs from the backend. That’s going to be a game changer for building these backend endpoints, which is what we’re doing here.

Right now, Isaak has to manually open the Edge Function logs in Supabase and paste the errors from there, so there’s still some complexity.

Is this a new feature? This is something I’m also very much on the lookout for: people building for AI users as opposed to building for human users.

If I’m understanding you correctly, this may be an instance of that. In the past, Supabase might have said, “Of course it’s going to be a human developer. They’ll come to our site, look at the logs, understand the logs, and so on.” Now you need more programmatic access because you’re trying to feed the logs directly into a language model.

I think we’ve driven most of Supabase’s new signups, at least in the past. That might still be the case. They’re realizing, “Wait, we have to start building for exactly what you’re saying—for programmatic access to everything.”

I know that others who are building similar products to Supabase are also saying, “We’re going to be agent-first,” in terms of building for a world where software and these things are managed by agents, not by humans.

I’ve definitely had this experience, where I find myself being a glorified copy-and-paster. A lot of what I’m doing is moving things back and forth between systems.

Even when we got sidetracked earlier and were talking about different models and what happens when there’s an error, OpenAI’s o1 series can help reason through things. I’ve often used ChatGPT Pro to make a plan or diagnose how I should think about a feature at a high level, and then have it give me instructions.

Then I’m pasting those instructions one by one into another AI UI and having it implement the plan step by step. It’s funny how much time is spent watching over the shoulder and pasting things back and forth between systems. That definitely seems like the sort of thing that’s going to get smoothed out.

That’s a big part of what you’re seeing with Lovable here. The hardest or most important part in the beginning of building a large-language-model app is context management: knowing whether we need information from this source, from another source, from our knowledge base, or from the history of what the user has done.

If you’re very good at managing that context, it becomes much easier for the coding model—in our case, Claude—to take the right decisions. We’ve spent a lot of time on that, and that’s 1 reason it’s more reliable than other tools, at least according to the people I know who have compared them.

I did enjoy how you had the prompts along the way. This may also get to who you’re targeting in terms of users and the backgrounds and levels of knowledge they have coming in.

I appreciated that instead of telling me to go somewhere else and find the place to do something, you let me provide the API key here and then 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.

Do you want to go to the Edge Function logs and see exactly what the error is?

Here it says “Error.” If you click that one, this is what isn’t yet in production, at least, but it should of course be fed into the AI system.

What does it say exactly?

I think we can copy and paste all of this into the app. Let’s do that and then go back to the app.

This is what you were saying: now we’re doing the copy and pasting, but this is going to be completely automated. We wouldn’t have gotten stuck at this point at all.

Let’s send that. Hopefully, this should work.

When you’re connecting to external APIs, as you said, Nathan, there are often more things that can go wrong. That’s where you need a system that’s good at debugging itself between the different components that are interacting.

Now we’re interacting with the browser. The browser is interacting with Supabase, which in turn is interacting with Firecrawl, which is 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—“What’s the best way to scrape product information?” What’s the best way to scrape data from an external URL?

I’ve found in my general use of AI that, especially before reasoning models, I developed a practice of trying to be extremely neutral with my language. In an area where I don’t know the right answer, I’ll often find that I can unintentionally bias the AI in a particular direction.

“Scrape” seemed to send almost all the models, at least until the o1 series, down a path of, “Okay, we’re scraping.” In many tools I’ve seen, I like the idea of defaulting to a best-in-class tool like Firecrawl, so you’re not recreating scrapers from scratch.

I’ve had many experiences where the AI says, “We’re going to write a Python scraper,” and then makes a bare-bones plan: “We’ll use the requests library to get the HTML, and then we’ll use Beautiful Soup.” The next thing you know, you’re lost in scraping hell.

There are much better tools out there for doing this. I like the idea that you’re curating these production-grade tools that you trust and can tap into immediately, rather than recreating things from scratch.

Do you have a list of tools that are at that Firecrawl level—tools that you know and trust and will try to route common needs to?

For integrations, there are the ones that we default to, and we're adding more. I think maybe not everyone is here, but for email we have Resend; for payments, Stripe; and for AI, it defaults to OpenAI or Anthropic if you ask for that. If you want an app that generates images, that's Runway. I'm not sure we launched it yet, but we're using Replicate for various AI models—lots of other LLM models, for sure.

Many people request that we add their companies. People reach out from AI tech companies because they want us to use them as a default provider for both the backend parts and, for some things like payments, for example.

That's cool. I think that is really smart. Going back to the language and the user potentially mistakenly leading the AI astray, I've started to see that 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.”

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 strategy for questioning the assumptions of the user to make sure they're not going down the wrong path?

That's a good question. We should have that. Now, we rely on people really knowing their stuff, or being fast learners and figuring out errors. In this case, I would definitely be like, “Okay, maybe we hit a problem,” and I would restart from scratch. I would just say, “Okay, let's restart from scratch,” because then you can quickly learn how to make this work reliably.

In the future, we want to be much more Socratic and say, “Okay, this is the situation. I think you're asking for this, but it doesn't really make sense, potentially. What do you mean exactly?” That's going to be a big level-up for most users.

I'm surprised that this didn't work absolutely instantly. What we're seeing is that we're getting an error—a bad request. Most non-developers have a hard time understanding this, but it is possible as a human to go in and say, “Okay, there's something about the connection here that's not working.” It says, “Review the API documentation,” but I don't think we need to do that. It says “unrecognized keys,” so maybe something changed in the API. We're getting 400 errors.

If I ask it to try to fix it, will it pass in these logs? It will not use our Supabase logs, right? You need at least 2 products to compare.

Okay, sure. Let's do it. “Failed to scrape enough products for comparison.” That's clear, at least. While it's running, I'll check the Supabase logs to see if there's any more detail there.

What you can of course do, if you're a developer, is spin up a nice UI. There are a lot of best practices that get spun up for you—Stripe and so on—and then at some point maybe you want to edit the product.

It seems like it was successful. Product 1—

I think the problem here is that I'm not scraping washing machines. Do you have any washing machines?

Yeah, on another tab. Let's take 2 of the same washing machines. Here we go.

I had to click “Try to fix.” I'm so happy I could help you out. Why didn't—okay, let's hear what it's saying.

It just says, “Unknown product. Make sure to show—” It seems like we're making progress now. I think it successfully scraped the links.

One thing that I did was include the documentation on Firecrawl. These LLMs are not up to date. If, for example, Firecrawl updated its documentation or API, Lovable might use the old documentation, and then you might have to include the updated documentation within the context.

In our native integrations, we stay on top of all of that stuff, so that will essentially always work. In the case where we want to pick an arbitrary API and use it, it will not necessarily work if the API has been updated.

I guess Lovable AI doesn't actually know what to display right here, and I think we would have to use AI.

That's true. We have to process the product through an AI model. This is very standard: you get something, and you're like, “Okay, the API works. Now we have to update the UI to handle the API response.” That's what it's doing now and writing a little code.

Let's see. Yeah, there they are. Here we go. We're seeing them. Now let's run an AI analysis of them.

Nathan, do you have any preferences for what you would want to compare, given where the UI is at right now?

I think maybe I want a 2-part analysis. First, what are the most relevant factors to consumer satisfaction with this product type? Then present those in a head-to-head way. They could be key features or common problems.

The front-loader versus top-loader distinction is a good example. I had never really thought about that before. When you start reading Wirecutter on washing machines, the first thing you're going to need to decide is whether you want a front-loader or a top-loader. By the way, if you have a top-loader, you definitely can't stack them on top of each other. Do you have space for 2 side by side, or do they need to stack?

It's this question of, “What should I even be thinking about as the relevant dimensions?” Then show me what those dimensions actually are.

Very sensible. Let's ask that.

I'm going to send all these products to the AI, and it should give you 3 important features to consider in a short format. As a recap, what we have now is that you can enter products, get data, and then send the product data to an AI model to ask what we should consider. After that, we could probably list the differences among those dimensions in a table or something like that.

That's really interesting, because with some products, we don't even know what the relevant dimensions are. You didn't even know that was a relevant thing to look for in washing machines. It would be really cool if the dimensions were suggested by the AI and then used to create the table.

We want to get a structured response from one of these answers, right? That's totally possible using function calling, and Lovable knows how to use that. The next step is probably to read this response.

I also want to clarify that for an application like this, I would say that a pretty technical person can very reliably build the entire application end to end. For people who are less technical, for a simple application like this one, with some patience, you can 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 ton of time. You'll feel like you're getting stuck.

It's also a bit random. In some cases you're lucky, and in some cases you're less lucky. 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.

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

The company has been around for a bit more than a year. We went through a few different iterations. We went down the agent route, which has some advantages, but we came to the realization that the UX of an agent is usually very bad. We made it much more focused on speed—the fastest possible way to get the result back to the user.

I think people have very different ideas of what an agent is, or they mean very different things when they talk about agents. The way I think about agents, as opposed to intelligent workflows, is that an agent has at least a certain amount of delegated decision-making authority.

If I make something in a Zapier-type framework where one step follows another, maybe some of those steps are AI-based, but the prompt is prescribed and everything happens sequentially, I would say that's low agency. It might be intelligent, but it would be low agency if every step is fully planned out.

Here, I think this is actually higher agency for the AI than most product experiences, because there is a decent amount of the AI interpreting what you're saying and making dynamic decisions about exactly how it's going to proceed.

How do you understand agency, and what do you mean by it?

For me, agency is a bit different. It's goal-oriented. But in an LLM setting, an agent does 1 action, looks at the result, does another action, looks at the result, and continues in a very open-ended loop.

In most cases, if you want reasoning steps and so on, you can do that without that kind of open-ended loop. You can design the chain of LLM calls in an intelligent way. The problem with doing it in an agentic way, which has the benefit of being more general, is that it's very unpredictable how long it's going to take.

From a user's standpoint, especially if the system is not 100% reliable, unpredictability combined with unreliability is a very bad experience. You want to get as far away as possible from that. Once you're as fast and reliable as possible, then you can start making it take more than 1 step of LLM calls.

I'll look back at the product now so we can see the 2 products and compare them. The dimensions we should look at are load capacity and steam-cleaning technology.

I don't know if that's a top priority, but apparently that's what the AI says is the top priority. We could do some better prompting to make sure it looks at what's most important. Energy efficiency makes sense.

Let's take 2 other products. What would you consider buying, Nathan? Apart from a washing machine, let's do headphones. We'll do Bose and JBL.

Now we're still just going to see what's good to consider for headphones. The next step would be to list why you should use X over Y. For now, we could just write the pros and cons for both of them.

We should consider sound quality, battery life, and comfort and fit.

For the next prompt, I imagine we could write something like, “Let's prompt the AI system to also list how the 2 products compare along these dimensions,” as a nested bullet list or something like that. Does that make sense?

Yeah. Ask for another step. Under the listed dimensions, compare how the 2 products compare with each other. It isn't limited to 2; it's the products compared with each other based on the features listed.

Let's make this happen in the same edit. Maybe this is going to be a killer application when we're done.

I guess the next step, not too far downstream from this, would be pulling in customer-review highlights as well. My vision for the product is evolving.

The first step is the advisor layer, where it's coaching you on what you should be thinking about. The second step is an objective tale of the tape. To some extent, that's informed by the product pages, which typically have these specifications, but of course they're all formatted differently.

Even with simple things like the size of the washing machine, it's hard to know: how wide was that other one? Was this one wider? The third section could be what past customers have to say about the products, and whether there's anything they're bringing to the fore that the product pages themselves didn't mention.

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.

100%. What I'm also excited about here is that the first step could be that I'm looking for a dishwasher, and then it preselects some of the products to analyze.

Yeah, that's cool too. We got an error now.

What was that? Maybe we're out of quota for our APIs.

If you're impatient, you just click “Try to fix.” But I don't know why we would have a new error here. I would read the logs in this case and try to understand why it suddenly had an error.

It says “Bad gateway,” and that's on Firecrawl's side. If it starts with 500, it's not our fault; it's actually Firecrawl. Now it's trying to fix it on our side. We can't do that, but we can try again and hopefully it will prove transient.

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

That's a very reasonable thing to do, but there are a few reasons we don't unleash it like that enough for now.

Tell me what they are. I feel like, having tried a bunch of these different experiences, another one that's obviously gone through cycles of hype and counter-hype over the course of the year is Devin.

In preparing for this, I did an experiment with a similar little project where I loaded up multiple coding agents or assistants that create products. With Devin, I had a weird experience because it just keeps working in the background.

I was rotating between them. I would look at the state of one of the products, give it a next direction like we're doing here, and then tab over to the next one. When I got to the Devin tab, I realized I had no idea what was going on. This thing had been working continuously in the background.

In some ways, that's very appealing. In other ways, when I get there, it might be on iteration 87, and I have no idea what the current state is. It's very hard in that moment to ask, “What are you even working on? What's working and what's not working right now? Where are we?” I found that weird.

That led me to a certain perspective, but here I also think, as you said, it would certainly be reasonable in some cases to take the next step. Another thing we're looking at here is literally pasting in the URLs and running it again.

To some degree, especially with Claude computer use starting to become a thing, part of me wonders whether I could have limited agency. I don't necessarily want this thing to run forever, run up a bill, or drift off into some state where I have no idea where it is. But I would like it if it took my 1 prompt, tried to do it, tried to use the product, and then stopped.

With Claude computer use, the computer-use parts are there. My point is that many of these things are possible. I think you saw Isaak use the selector to use Chat mode. There is a preview of an Agent mode in that selector. It's not publicly available; it's only available if you have an admin account, like Isaak has.

These are things that people like us experiment with. The most important thing is that you have a product that predictably works in an intuitive way. Making an agent work intuitively and nicely takes a lot of iteration—a lot of iteration. We haven't made it work in a reliable, nice way yet, but I think we'll be there very soon. It's one of the things that's going to be at the top of the roadmap in the coming few weeks.

What you saw here is that the product works now. We have the 2 headphones compared, and it says the key features to consider are sound quality, noise cancellation, battery life, and then it runs a comparison.

We should continue to iterate to make sure that the AI always gives us the comparison in an easily digestible format. Here, it says that one is offering superior sound quality in a long paragraph.

Nathan, what did you do?

Isaak asked the AI what we should do next. It said, “Visual comparison improvements,” and we could pick one of those suggestions, paste it in, and ask it to do it. It kind of knows what to do next.

What would you say? We're the CEO, and then there's the AI product manager. We decide what the software engineer should do from those suggestions.

Some of these are pretty good. Reviews would be really good if we had the table you guys talked about. I'm going to nudge the Lovable AI now to use function calling from OpenAI, just to make sure we get that formatted response for the table.

In this case, we don't want a long chat response. We want the formatted response so we can render it in this beautiful, digestible way.

Yeah, I think that was a good rundown. 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 it to take 5 minutes. I'd be happy to see people do speed runs on something like this tonight. But as you can see, there is a lot of iteration.

Plain English is the hottest programming language. It actually works in this case, but it still takes a human engineer supervisor to use it this way. That's the state of things right now.

Here we go. That's actually really good. One more prompt and you nail it.

Yeah, nice. This is nice.

Unfortunately, the AI is extremely politically correct. It just says everything is good. We should do this with Bolt and Lovable AI and see what it does.

Should I try? Let's try it. See what it says.

Go for it.

Okay, Bolt and Lovable. Let's see if it's going to betray itself. This is also a self-awareness and situational-awareness test.

This isn't our AI answering. This is the—

But it probably knows in a system prompt or something. It should have some clue as to who it is.

Okay, let's see. We got “user interface, deployment options, and ease of use.” No. Bolt 1, 2—but that isn't true, actually. We do build in deployment options. I would say this is what's incorrect.

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, that's really cool.

First of all, we're an hour into trying this. How many iterations have we been through? It looks like 17—edit 17.

One thing you mentioned earlier that caught my ear, because I've also experienced this a lot while trying to develop my own coding-with-AI best practices, is to commit at every working state. Definitely be prepared and willing to roll back to a previous known-good state.

I don't think we ever reverted in this experience. Maybe we can scroll through and look at the 17 steps we took. This isn't a comment on Lovable; this is more about me doing it with Cursor and finding that once I get off track, I've often found it really hard to get back on track.

The models are generally much better at doing a thing and getting it right the first time than they are at iteratively debugging it. A lot of times they end up making a mess. They try things over and over again, get confused, and don't break things down well.

Any thoughts about when to revert or how to know when to revert? One thing I've found somewhat successful is that when I revert, I'll sometimes take the error message it was struggling to fix, go back to the last known-good 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.” That often does seem to help.

I wonder what else you've experienced in terms of the right way to make that tactical retreat. It's way different, because people generally have a lot of attachment to their code. It represents a lot of their work, whereas it should be much easier to throw away whatever a language model has given you over 4 rounds of prompts.

I have some good takes here. I see it as a search tree. You start off in the middle of it, and then you can go in different directions.

When you're trying to implement a particular feature, there are various ways of doing that, and sometimes certain features require certain substeps. Usually, when a nontechnical user gets stuck implementing a feature, it's because they haven't correctly taken all of the steps in the right order. That's why we recommend consulting with Chat mode—not Agent mode, just Chat mode.

If you have taken the steps in the incorrect order, then it's a very good idea to revert. You can include the error you got when you became stuck, and you have that intuition of where things went wrong. You can nudge the AI to go in a different direction.

Even if you don't do any nudging, there's still a probability that the AI will go in a different direction on its own because of randomness, and then it might work. It's hard to say exactly which scenarios are the ones where you should revert, but if it seems like you went down a spiral and it's hard to get up again, then reverting is a good idea.

For instance, I think it could have been a good idea to revert in our case when we were struggling with Firecrawl, and then maybe include some of the documentation instead.

Isaak is now redoing it. I figured, let's see if I can do this in 4 prompts.

Can I get your API key for Firecrawl?

Yeah, absolutely. Do you want to show your screen as you're doing this? You're on a different computer.

Yeah, maybe you can share your screen.

I think this is really interesting too. Humans end up in this spot where we've been coding something for years, we've got all sorts of technical debt and shortcuts, and we use weird strategies that we wish we would clean up.

This is basically the AI equivalent of that, right? We've been through 17 rounds, we're not exactly sure what weird little micro-decisions might have been made, and now you're saying, “I know what I want. Let me go back, take it from the top, and see if I can do a really clean version.” Is that basically the thought process you're going through?

Yes. I think Isaak had the worst luck I've ever seen, so I figured out what was more likely to happen in this case. Sometimes you're unlucky, but this is what I did: I said, “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 them to OpenAI and answer 2 things: 1, what features should be considered when making a purchase decision; and 2, how do the 2 products compare?”

This will just be the second edit.

How did this work, actually?

I think we had those 2 baked into 1 edit.

That's true. Have we connected Supabase on this project?

No. I'm going to say Supabase is not connected in this project. That's why I wanted to do it in the absolutely fastest possible way.

If I had connected Supabase first, it would have put the scraping on the backend, but it's all right because we don't hard-code the keys. Instead, we have this input field where the user would put in their own keys.

So we're skipping a step there.

That's the idea. It seems like Lovable almost never hard-codes keys. Even though we haven't implemented Supabase in this project, it understands that we probably don't want to hard-code API keys within the frontend.

Instead of saying, “Let's just have these input fields,” this will probably also be much less error-prone, because before we had this complex system.

I'm going to enter the OpenAI API key here. I'll make sure I don't leak it. Hopefully it's all right; I can just remove it.

Let's go. Here are the websites. It's going to compare Lovable in this case. I'm going to fetch from it, and here we go.

Oh, nice. So we did it in 3 edits. That's what I would expect, to be honest.

Let's compare something really hard to scrape—headphones. I hope that works. This was a 3-prompt version of it.

Back to your question about how much we can expect this to work: if you're good at using reverts and so on, then for any product—or any internal tool, which is one of our core use cases as well—where there's 1 main feature, like we're creating here, it should take a dozen edits or so.

If you're adding many features, it takes hundreds of edits. Then it also starts becoming much harder, because the AI doesn't handle large codebases as well.

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

I'd be interested to hear more about that, to the degree that you want to share it. What I've been doing on my own is taking literally my whole codebase. The little app I've mentioned a couple of times is roughly 100,000 tokens.

With AI's help, I had it write a little script to put everything into a single file, kind of like your llms.txt, except it's not documentation; it's literally just the source. Then I paste that into ChatGPT and ask o1 Pro to figure out a plan.

Obviously, that's going to run into limits. I've started by modifying the script that creates the single file. We don't really need the CSS classes, for example, so we can skip various things. It adds a bunch of regular expressions to the script that prints the single file, and that saves me about 20% of the tokens.

Now I can do a couple more features before hitting the limit. But obviously, big codebases are much bigger than 100,000 tokens. What have you learned about managing context? Are you doing dependency-tree-type work?

There are some things that give you a lot of bang for the buck. We do RAG, and agentic RAG is one of the key differentiators for why our product is very good, even as the codebase grows.

I can't go into detail, but being smart about agentic RAG gets you very far.

That will be a side quest for me—to figure out exactly what that means. I mean, I can try to reverse-engineer it as well.

We're looking to be more open about this. It's a big part of where we're strong. We're building out many more areas, but yes.

Let me see how the product works now. We got this error from the last session. The OpenAI model couldn't handle Amazon websites because there was too much text on the Amazon website, so the AI set the maximum number of characters to 4,000.

My guess is that this won't have the information. That's what I ran into when I was messing around with this myself. If you just truncate the page, you get a lot of header, script, and other garbage. I was thinking that maybe Firecrawl could solve some of that nonsense for me.

I think it did solve that quite well. Can we get a response here? Is it crawling?

No, I hope not. It picks up the title and the text in a nicer format.

I don't know how we're using this different data. Normally, to use our product to its full potential, you often want to paste in the payloads from the API request. They aren't currently fed into the LLM by default. As you can see, there's a lot of data here, but it would be better at picking these things up.

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

Okay, we got a response. It's still analyzing, so we're waiting for the LLM.

It's not a fast application that has been built here, but it gives us—okay, it's completed.

Oh no, I refreshed, or I think I pressed back. The whole thing is gone.

This has been really good. Smart RAG is definitely a takeaway—something to think about more.

Context management is a superset of smart RAG, and that's really one of the core pieces of this.

Just a couple of wrapping-up questions: where are you guys today? Who are your users? You've scaled remarkably fast. I've seen tweets saying you're one of the fastest-growing, if not the fastest-growing, European startup ever. What's the story over the last couple of months?

Since we launched, we've continued to grow. If you annualize it over a year, it's $1 million in revenue per year. Now we're actually at $9 million, and that's faster than any other company launching from Europe, according to my research.

More importantly, we have hundreds of thousands of users. Whenever we post something online, the comments are full of people who are blown away by what they can do with our product. There's a lot of love.

Our paying users use it every other day, so there are a lot of positive aspects to what we're doing. Going forward, we're making this valuable for teams that collaborate. You can see that on my screen—we're going to make it much easier for people who collaborate to use our product that way.

That's a snapshot. What's much more exciting is making the AI more reliable, enabling it to do more debugging itself, and launching the agentic mode that you saw here as well. It seems to work.

I wanted to ask about “Edit code” and “Publish,” which I see in the upper-right corners. Those are perhaps less interesting from an AI perspective, but they're obviously important for people who want to ship even an internal tool. What does that look like?

We're deploying the applications at the edge with Cloudflare. With 1 click, you build your app and it's all in production. It scales really well too. That's how the publish flow works right now.

“Edit code” is more interesting than it sounds. You can edit it with any browser and any IDE. Here I'm just opening VS Code in the browser. If I change something, it will synchronize, so I'll instantly see that a human edited the code from their favorite IDE.

This is also a way to collaborate with teams. GitHub is synced as well, which is what I'm showing on the screen.

There are some other very valuable features that you learn if you're a superuser. One is that if you have the documentation for a specific API, you can put it in the knowledge for the project we're editing. If you want to make a change experimentally, developers are used to something called branching, and that's built into the product as well.

You've got a dual mode, basically: you can do the full developer experience with your IDE, all your changes are tracked in a Git repository, and you've got branching.

How does your user base break down? It may all be happening so fast that you don't even know, but how many people are developers trying to move faster versus people who don't really know how to code but want to make something?

We asked users how much coding experience they have, and it's split evenly, with 25% in each category, from no coding experience up to a lot of coding experience.

We're all about empowering the 99% of people who don't know how to code. Even more people don't know how to do both frontend and backend, so there are more users in that bucket.

The technical people get much further. They can build much more complicated things because they understand a bit about what they're building. They understand how API calls work and so on.

The common theme among our favorite users is that they have an entrepreneurial spirit. They're high-agency people, which is another way I like to put it. They're often founders and operators who are running their own businesses, perhaps an agency, and they're very quick to understand what's possible with the new technology. Those are our favorite users today.

What do you think will move the needle most over the next couple of months? Is it just better models, or is there anything else you're specifically tracking? If you can see that far into the future, where do you think we get over the course of 2025?

For us, as you mentioned, DevOps and infrastructure are the big bottlenecks. Long term, we're going to package more of the infrastructure in a very nice and quite opinionated way for AI.

The best AI models and more of the smart algorithms that put us ahead of others today are going to matter less because the large language models are going to advance and keep becoming more intelligent. Our tricks on top of that are going to be less important.

What does matter for us in the coming months is adding a few more people. We're trying to assemble a team with the highest talent density here in Europe—absolute geniuses who are creating the product. That's what matters for us.

We need to make the team work really well together and figure out the right abstractions, both in the UI and UX, in the infrastructure, and in the code that's on the projects being generated. We need to be smart with it and get the most out of the large language models.

Figuring that out as a team is really the key to winning in any type of AI product.

Do you want to put out a call for what you're looking for? Are you all in Stockholm, or is there another arrangement?

We're hiring mainly for people who are willing to relocate and build in an office, which is much more fun, want to solve really hard problems, and want to be at the absolute epicenter of what AI is able to do right now. We're paying top of market for top talent.

This has been fascinating. Is there anything else you want to touch on before we break?

If people haven't tried these tools, the best thing they can do for their career and for their friends is get their hands very dirty. You're going to learn so much from using these tools, even if you don't have a business application for them today.

If you're currently working without AI, then I think you're really disappointing your employer or your customers and clients if you're running an agency. You should get on the train. It's a huge time-saver.

Get hands-on. That's always my number-one piece of advice as well.

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

For now, I will say Anton Osika and Isaak Sundeman, 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.

It is both energizing and enlightening to hear why people listen and learn what they value about the show. 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.