Capítulo 3… Muiiiita iteração, fluxos mais complexos implementados e integração com o N8N. Velocidade não é o diferencial, mas a autonomia é.
Parece mais uma prova de resistência e como já vimos no no-code, muita gente para por aí.
Agora devo ter gastado umas 50h com o Lovable. Tive que ficar olhando o inspecionar sendo uma parte olhando os logs e outra código para pedir mais “certinho” a tag/componente para mexer.
Estou me forçando a usar o Lovable como minha “IDE” de desenvolvimento do produto. Está dolorido, mas está saindo. Erra? Bastante, mas de novo, como uma pessoa dev junior. Saber pedir é disparado a coisa mais importante para isso funcionar bem. Ainda bem que existe a disciplina de gestão de produto.
Agora estou investigando como a disciplina de desenvolvimento está mudando para um papel mais de arquitetura. Está sendo interessante. Do mesmo jeito que o próprio Lovable não tem o papel de PM - até onde eu sei só tem product engineers - dá para pensar o mesmo sem o papel de desenvolvimento, como disicplina. Vamos ver.
É o velho 80/20… a maioria dos casos são nada “mega sofisticado”. Precisei desenhar um fluxo para explicar o serviço, mandei telas de exemplo, abri o html e peguei o componente para explicar exatamente o que eu queria que mexesse. Funciona. E bem.
Nova lição: AINDA precisa entender de código para fazer funcionar bem. Nada muito mais do que uma pessoa de produto entederia, mas precisa saber ler um código.
Então a lista atualizada:
- mandar exemplos de telas (UI/UX)
- cabeça de produto ao pedir (PM)
- logs e refatoração sempre que aparece a opção (débitos técnicos)
- Desenhe o fluxo do backend para algum serviço mais complicado e mande como imagem
To be continued….
Publicado originalmente no LinkedIn em 1 de abril de 2025. A versão em inglês foi traduzida com ajuda de IA (Claude) e revisada por mim.