**What a Founder’s 1,500-Prompt Failure Taught Me About AI and Vibe Coding**

Recently I had a call with a founder who was looking for advice about building with Bubble.io. He came to me after experimenting with vibecoding, an emerging trend where users vibe their way through prompts to generate an app. I have to confess that I have been suspicious about generative AI app builders, having invested in learning how to code and then how to build apps with no code. However, I don’t want to approach every scenario with a bias that I want AI to fail in generating apps just because I want to keep building them myself. Surely, one can’t do in minutes what has taken years to learn? It seems the answer is a bit murky. It’s yes and no.

Initially the build seemed to be going well for the founder I spoke with. After 200 prompts he had built the tool he wanted and all seemed good. But there were some bugs and he wanted to add a database. 1300 prompts later he was no closer to the finish line, he even spent time learning how to code in order to try to debug himself but after 1500 prompts he had to admit defeat.

When I heard first hand about this experience I was shocked. I have seen on social media the apps that people have been showing off that they built with AI. I know that AI is changing fast and that the tools are getting better. What surprised me the most in this conversation was where I expected to be proven wrong; the challenges I suspected were not only real, but bigger than I imagined.

I really felt for what this founder had gone through. He had started the process feeling hopeful and had invested 3 weeks of effort only to have to admit defeat. We don’t hear many of these stories. What we do hear is the headlines about how AI is revolutionising development. We see the demos where something shiny gets built in a short timeframe. What we don’t often see are the quiet struggles behind the scenes and the weeks spent inside tools trying to fix what was “almost working”, only to give up.

That conversation pushed me to reflect more deeply on my own experiences with generative tools. Over the past few months, I’ve been watching this space unfold. As someone who builds with no-code tools, primarily Bubble, my path into software development has been visual, structured, and collaborative. Testing Bubble’s generative AI app builder has given mixed results. It was impressive how a basic skeleton of an app can be built with a prompt but it was far from complete. In each test I did there were missing workflows, the UI was underwhelming and there were no privacy rules. That experience showed me that while the builder can get something started, finishing it still requires real Bubble skills.

Get Dawn Curran’s stories in your inbox

This led me to ask: what kind of help are we really looking for when we turn to AI? Are we trying to shortcut complexity? Are we hoping to skip the learning curve? Or are we simply trying to build faster? And how do I recognise and work through my own biases along the way?

Over time, the real value has become clearer to me: AI is not here to replace us, but to assist in our development work. There is a difference between vibe-coding and AI assisted coding. There is a difference between using an app generator to just build you an app and using it to get you started while you put in the time to complete it. Just as using AI doesn’t always result in success it also doesn’t always end in failure.

But even when it helps, AI still demands something from us. It feels important to talk more honestly about the emotional and intellectual load of working with tools that promise ease but often demand a lot of invisible labour. Especially when that labour includes learning to debug code you didn’t write, or writing endless prompts to try to solve problems only to end up going round in circles.

I started looking to others for perspective. I found a recent discussion on the Bubble forum fascinating. Devs were sharing their thoughts and experiences of building with AI. It wasn’t just people airing concerns, it was a conversation filled with thoughtful questions about transparency, sustainability, and trust. About how platforms evolve, and what kind of builder experience we invest in.

George Collier’s discussion of his experience building Buildprint with AI assisted coding was particularly compelling. It was successful because he is technical and already understands the logic it takes to create an app. He gave insight that those who are good devs will succeed better with AI because in order to use AI successfully we need to understand what we are asking it to do, we need an understanding of the logic it takes to build an app.

One contributor said something that really stuck with me: that many of us came to no-code not because we wanted to avoid learning, but because we wanted to learn differently. We wanted to understand structure, patterns, and logic, not just syntax. We wanted to build real things, yes, but we also wanted a process that could grow with us, not leave us behind. It has helped me to understand that learning how something works is what will set us up well to ride the AI revolution.

This perspective has shaped how AI is currently integrated into my own workflow. While I am not using AI to generate client apps, I do use AI to help me think through the planning of an app or a feature, asking what else might be missing, exploring user flows, or structuring the database. Do I always agree with them? No, but the process helps me to think through the implications of different ways of building, faster. That’s where AI currently fits into my workflow, as a thinking partner, not a builder.

Upon reflection the most valuable asset a developer has right now is their deep understanding of what it takes to build. I think AI is some way off replacing development skills in full. It takes human creativity to think through an app idea and apply logic. Focusing on becoming better developers is what will place us in good stead for adapting to AI as tools continue to improve.