Chapter 3… Looots of iteration, more complex flows implemented and integration with n8n. Speed is not the differentiator, but autonomy is.

It feels more like an endurance test and, as we’ve already seen with no-code, a lot of people stop there.

By now I must have spent about 50 hours with Lovable. I had to keep looking at the browser inspector, partly looking at the logs and partly at the code, to ask more “precisely” for the tag/component to change.

I’m forcing myself to use Lovable as my product development “IDE”. It hurts, but it’s coming along. Does it make mistakes? Plenty, but again, like a junior dev. Knowing how to ask is by far the most important thing for this to work well. Good thing the discipline of product management exists.

Now I’m investigating how the development discipline is shifting toward more of an architecture role. It’s been interesting. Just as Lovable itself doesn’t have the PM role — as far as I know it only has product engineers — you can imagine the same without the development role, as a discipline. We’ll see.

It’s the old 80/20… most cases are nothing “mega sophisticated”. I needed to draw a flow to explain the service, I sent example screens, I opened the HTML and grabbed the component to explain exactly what I wanted it to change. It works. And well.

New lesson: you STILL need to understand code to make it work well. Nothing much beyond what a product person would understand, but you need to know how to read code.

So, the updated list:

To be continued….

Originally written in Portuguese and published on LinkedIn on April 1, 2025. I translated it into English with the help of AI (Claude): it let me bring my LinkedIn posts to people who don’t read Portuguese without rewriting each one from scratch. I reviewed the translation to keep my original meaning and tone.