When I volunteered at Coderdojo, we taught kids to code. In 80% of the cases, that meant building video games with Scratch. While that is cool, the coaches got really excited when a child wanted to do something more exotic. Unity, robotics, or even just JavaScript. Finally, something they could also sink their tech teeth into!
I remember a girl who wanted to build a robot. The volunteers got fired up. We brought Arduino kits and soldering material. We wanted children to short-circuit and burn LED lights to teach them how electronics worked. Quite a few of them did.
But this girl was different. She didn’t care about robotics. She wanted to build a magical friend. The robot she had in mind was called Anne, and she would take her outside to pick flowers together. There were plenty of drawings of what Anne would look like, but never a schematic. While most kids got excited when they burned through their first LED light, this girl was frustrated by anything that wasn’t a fully fleshed-out flower-picking companion. She never got around to burning the LED and, as a result, Anne never got to pick a flower.
I believe there are two archetypes when it comes to building things. There are dreamers and analysts. The dreamers see a problem and imagine what the world would look like if it were solved. The analysts see that problem and break it down into sub-problems that are more manageable. The dreamer sees a flower friend, the analyst a shitload of circuits to build. Idea person vs developer. Product vs Engineering.
It’s an overly simplistic view. We are all part dreamer and part analyst. But if there are these two wolves inside us, one is clearly more dominant than the other.
It explains why half of us are so terrible at vibe-coding and coding agents. Dreamers describe outcomes, hoping to speak them into being. It doesn’t work that way.
Vibe-coding, like all coding, requires the analyst trait. You need to break down a problem into the next small chunk and be thrilled when you’ve made a tiny bit of progress. That doesn’t come naturally to most people, but it’s how software engineers think.
The Lovable subreddit is a litany of people complaining about the tool not building what they want. People dive into building without describing the problem and breaking it up into smaller chunks. Not only is that expensive (Lovable credits burn fast if you don’t know what you’re building), but it also creates sloppy code that breaks down quickly.
So, how do you vibe code if you’re a dreamer?
Start with a conversation
Rather than diving headfirst into Bolt or Claude Code, open up ChatGPT and start talking about your app. What problem are you trying to solve? Who is it for? What is enough for the first version? ChatGPT will ask questions and help you flesh out the solution. After a while, ask it to generate a Product Requirement Document.
“Create a PRD for the first version of the app so I can give it to Lovable.”
“Create a PRD for building this app in Laravel so I can give it to Codex.”
Copy-paste this analysis into Lovable and see your dreams come to life. A 1000-word prompt is better than “I want to build a mobile app for recipes”.
Build one step at a time
This first version will be good, but you will have remarks, feature ideas, and new insights. That doesn’t mean your AI built the wrong thing — It means you are now an agile software developer! You capture the feedback, pick the next improvement to build, and iterate over the solution. Again, don’t discuss this feedback in the Lovable terminal. That’s wasteful and expensive. Revisit your ChatGPT sparring partner and duke it out. Continue the conversation where you left off. Once you feel you have a well-designed new feature, ask it to “Create a PRD so Lovable can build this new feature”. Copy-paste-repeat.
In agile software development, that is called a Plan, Do, Check, Act cycle. ChatGPT plans, Lovable does, you check, and you use ChatGPT to figure out what the next action is together.
Rinse and repeat
Export the analysis from time to time
You can also ask your AI agent to reverse engineer the app into a PRD.
“Write a PRD for this application that contains all the functional scenarios, edge cases, technical architecture, and assumptions. Write it to the repository as PRD.MD”
This document can be used to rewrite the application from scratch. It can tell you why certain behaviour is off. You can also feed this into ChatGPT and ask questions to improve and debug behaviour. Finally, you can hand this off to a developer once your Lovable MVP has some traction and you need to scale.
I don’t believe non-technical people can build a production-grade system through vibe coding. That requires deep-technical insights and hard work. But I do think coding agents can tremendously speed up prototyping and validation. Rather than a requirements document, dreamers can now give their analysts a working app as inspiration. It’s not the production-grade solution, but the best kind of specification we can hope for.
Using ChatGPT to create a PDCA cycle and documenting PRDs along the way is a great, cost-effective method to take the dreamer’s vibe coding to the next level.
And to be clear: we need that more than ever. Analysts know how to build, but they have no clue what to build. Dreamers know what the world needs, but lack the language to describe it.
Lovable and ChatGPT can bridge that gap.
