I spent 3 months vibe coding with AI. Here's what actually happened.
Spoiler: It's like managing the world's most talented intern who also happens to be completely insane.
Product people beware: short of drugs, this is the most addictive thing you can try. And I can only recommend it! -- not the drugs part, in case it's unclear.
If you wonder why I haven’t written in a while, it’s because I sacrificed all my free time to the gods of prompting, more specifically, vibe coding.
It’s both magical and infuriating.
This is an account of what I learned, so you can skip some of the infuriating bits of vibe coding to go straight into the magical parts.
My vibe coding stack
Lovable, the coding agent
I chose Lovable because my reference for low/no-code tools, Éfrem Filho, recommended it to me. It's a very PM-friendly tool, including an amazing one-click deploy. This means it’s instantly accessible everywhere on the internet, without you having to deal with deployment pipelines, AWS, and whatnot. What this means is that you click a button, and it’s live. You can even get your custom domain with a couple of clicks.
It’s magical for non-technical people. Given the AWS infrastructure's productized and accessible nature, engineers might not fully grasp why non-engineers struggle to deploy something. But for non-techies who had at most coded on localhost, it’s empowering.
Supabase, the backend
Supabase provides your project with a real database, the ability to execute backend code (as opposed to running it in the browser, which is crucial for security), S3 buckets for file storage, a secrets vault, and a straightforward way to implement authentication.
Behind the curtains, Supabase uses AWS, and the database is Postgres. So if your app takes off, a real engineer could theoretically port it out of Supabase for AWS to reduce costs.
PS: As of today, Lovable has backend capabilities in beta, so you may not need Supabase as much when you read this.
Claude, the UI designer
Whenever I needed UI designs, I would brief Claude. It can write and render code on the chat interface. Lovable-designed screens were often ultra-generic. To bypass that blandness, a PM friend of mine gave me the hint to send a screenshot of something that has a similar vibe to what you want, so Lovable can get inspiration from.
What is possible to build?
If it runs on the browser, you can likely build it.
Lovable excels particularly with CRUD.
Things that depend on a lot of fine UX are tricky, but can be built too. For example, I've built a simple roadmap management tool without all the bloat of pricey tools:
There are many real examples on the Lovable's Launched website.
Can non-technical people build with AI?
It depends on what you call “build”.
If by “build”, you mean simple prototypes and internal tools, then yes. But production grade? Probably not yet.
Emphasis on the “yet”, as these things are moving at an insane pace.
Think of the current vibe coding tools as a very junior developer who has an outstanding knowledge of code syntax and can do so at breakneck speed, but has terrible judgment and taste. Lovable, and any other coding agent, gets easily confused, enters weird rabbit holes, undoes what it just did to fix a bug, duplicates functions that already exist elsewhere, etc. As a non-technical PM who can barely write a for loop without Stack Overflow ChatGPT, if I can notice this, I only wonder the chill a real engineer feels when exploring a 100% vibe-coded repository.
All of this means that you have to guide the tool to make sensible choices. If you are 100% non-technical, it will be challenging to guide the AI in making the necessary software architecture choices.
That said, the first frontier is already within reach: replace quirky internal things that feel like they should be software, but are currently a spreadsheet.
Lesson #1: Treat it like a software development intern
Write PRDs, user stories with acceptance criteria, show screens, flash out interactions… just like you would with a real software engineer. You can’t just say “build a to-do list app”. That’s not how it works with engineers, that’s not how it works with AI.
I often used Claude or ChatGPT to help me write the PRDs and prompts. I also liked it to be structured like this:
# Goal
What you want to achieve with the change.# Context
Describe all the stuff that the AI should know, like interactions, decisions it should make, etc.# Constraints
Instructions it should comply with — more on that later.
Lesson #2: Images are really helpful
Images with the UI and interactions and diagrams are super helpful. Lovable seems to thrive on it.
For UI design, I use Claude a lot.
Lesson #3: Small iterations will get you faster to the goal
Big changes confuse the AI. Instead of asking for a complete feature, I learned to work in tiny increments: get the UI structure right, then add record creation, then editing, then deletion. One piece at a time. Again, just like you would with human developers.
Lesson #4: Use Clean Architecture
If I leave Lovable to its own devices, this is the software architecture it will create:
It might technically work, but every time you make a change, all hell breaks loose, and everything, including unrelated things, breaks.
But as a non-engineer, how can you help it create something more sensible?
The hack I found was to use Uncle Bob as a persona. I usually add something like this to my prompt constraints:
You are Uncle Bob, always plan and implement clean architecture, SOLID, DRY, and other best system design practices.
Do not hack your way into changes. Analyze the change and the current code, refactor/start from scratch if that would make the system design more robust, maintainable, and easy to change in the future.
Don’t make unnecessary or unrelated changes to achieve the goal, unless they would improve the system design to achieve the goal.
Don’t make unrelated changes to UI, UX, functionality, or behaviors.
Remember to delete unused or deprecated code.
Avoid making things “backward compatible" because this is often a cop-out mechanism for a system that is not behaving 100% of the time as it should.
PS: Uncle Bob wrote one of the most influential software development books, “Clean Code: A Handbook of Agile Software Craftsmanship" (2008)”, and was the one who formalized the SOLID principles in software engineering.
This will not ensure anything, as LLMs tend to lie (“sure sure, of course I used the SOLID principles”). But at least it is more likely they will create a better foundation than a house of cards imagined by Salvador Dali with dementia.
Lesson #5: Refactor when asked to
As files get larger, Lovable will prompt to refactor (usually just breaking down a large file into smaller files). This is crucial. Always do it.
But… always test the before and after, because Lovable can destroy functionality by doing that, including changing completely unrelated things, like how the UI looks.
Lesson #6: Start with chat mode for most changes
Lovable has a builder mode and a chat mode. In builder mode, you prompt, and it writes code, one-shotting it. This often will go wrong. The best approach I found was to use chat mode. In chat mode, it doesn’t change the code, so you can use it to discuss changes. Yes, you pay for it, but believe me, you will use fewer credits this way than trying to fix the errors it causes by one-shotting the wrong thing.
In chat mode, I ask for it to make a plan and to ask clarification questions.
I also highly recommend using chat mode to identify the root causes of bugs. If you don’t do this, it will just pick a random vector and keep doubling down on it every time you give feedback that the bug is still there.
Lesson #7: Clear the cache to test
Sometimes you make a change, then you try to test it, and… nothing changed. More often than not I found that the browser had cached the old version of the system.
Go to the browser’s dev tools and clear the cache:
PS: Spengler educated me that there is a much simpler way of doing this. Go to the “Network” tab and click to “disable cache”.
Lesson #8: Use verbose logging for debugging
Lovable will do a very poor job at debugging if you just give the bug effects you are seeing. Ask it to add logs on the buggy feature and then paste it back to it for debugging.
Sometimes I did this with ChatGPT too, but I found the current version of Lovable is performing better and I need to do this less and less with another LLM. A recommendation I got, which I haven't tested yet, was to use ChatGPT o3 with deep research since it can access the same GitHub repo. Then take the instructions from ChatGPT and paste them to Lovable in Chat mode.
Lesson #9: Use Given/When/Then for debugging
A useful format to describe problems and desired states:
# Problem: impossible to select a team with the keyboard in the empty team select field
## Current behavior
GIVEN the team select modal is open and no team is currently selected on the input,
WHEN a team is selected through keyboard arrow navigation + enter,
THEN the team is not selected in the team input, and the team input remains empty.
# Desired behavior
GIVEN the team select modal is open and no team is currently selected on the input,
WHEN a team is selected through keyboard arrow navigation + enter,
THEN the team is selected in the team input.
Lesson #10: Revert to a previous working version
Contrary to human software engineering, writing code is the cheapest part of the process. Don’t be afraid to throw code away, restore the latest working version, and start again. It’s much cheaper than staying in the bug death spiral:
One pattern I use is this:
Code changes are made.
I test the changes. If I am happy with how it went (e.g. it’s working exactly as intended), I save that commit to history (the little flag by the side of the change).
If I keep changing things and struggle to get it right, I go back to the latest saved commit in my history and restore it. Then I start again, this time with more knowledge about potential issues, which leads me to change my prompt accordingly.
The impact of vibe-coding on product development
When writing code becomes the cheap part, with AI writing it without the need for technical expertise, some might think that software engineers will vanish. There are even some accounts of teams asking for a higher ratio of PMs vs engineers, and not only one person.
But my take is quite the opposite: engineers will likely take on some product management responsibilities, and product managers and UX Designers will need to learn some engineering to be able to ship independently. In a way, we are transitioning from a process where many things required discovery to one where they can be more easily tested and iterated in production. In a sense, many experiments that were discarded could be released simply because the coding part becomes much faster. So vibe coding will compete a lot with "not doing", from a jobs-to-be-done point of view.
If you are a product person, what are you waiting for? Start building. If you don’t get used to these, you might find yourself in a tough spot in the future.
Leave in the comments what you always wanted to build, but didn’t have the resources until now.
If you found this useful, smash the like button and share it with other product people who are curious about AI tools. It's a huge help to me (and might save them from making the same mistakes I did).