Parece que você está defendendo criar um produto a todo custo apenas por entr... · user1

Em resposta a O dev sênior pode ser pior em vibe coding do que você

Parece que você está defendendo criar um produto a todo custo apenas por entregar, mesmo que gere valor inicial ele não vai se sustentar no tempo, é um castelo de areia.

Devs com muitos anos de experiência têm sim restrições ao uso de IA em relação aos vibe coders emocionados, não é porque não querem entregar um produto, é porque querem entregar o produto certo e sabem que qualquer software tem seu ciclo de vida que se estende muito mais do que o uso inicial.

Empresas que vendem IA vão fazer o maior lobby possível para dizer que criar software dessa forma é a melhor possível apenas por ser mais rápido. Mas no fundo o que querem é que você construa sua casa em um terreno que não é seu, por enquanto está bem barato fazer isso, mas quando você já estiver bem consolidado nessa nova casa, se tornará um refém.

O lanche de fastfood é mais rápido e mais barato, mas isso não significa que ele é melhor. Pode resolver uma fome pontual e até ser divertido, mas consumir demais vai te cobrar um preço bem alto no futuro (sua saúde), tão alto que talvez você não consiga mais consumir fastfood.

zilvodev

2 meses atrás

Boa parte do que você escreveu eu concordo, especialmente sobre o lock-in. A analogia do terreno é precisa: Lovable gerencia o Supabase por você, o usuário não tem acesso às próprias credenciais. Quando o preço subir, você está preso.

Sobre o castelo de areia: o argumento do artigo não é que software descartável é bom. É que o gargalo mudou de lugar. Antes era "conseguir construir", agora é "saber o que construir". O dev que freia na arquitetura tem razão quando está construindo o sistema certo. O problema aparece quando freia um MVP que precisava de feedback do mercado para saber se merece arquitetura.

Não é que qualidade não importa. É que validar antes de arquitetar costuma economizar mais tempo do que arquitetar antes de validar.

user1

Autor

2 meses atrás

Dá uma lida no seu post original e verá que não menciona sobre MVP, validação de mercado ou software descartável.

Além disso, a cultura do marketing digital tem feito a anos as pessoas acreditarem que o MVP não precisa ser bem construído pois será jogado fora depois e que não vale o esforço, é só para uma validação (vai que não dá certo, né?). Quem está há muito tempo na área sabe que MVP bom não é descartado, ele evolui.

Tem muita gente que vende a ideia de que só porque é MVP não precisa de segurança, escalabilidade e monitoramento, que são pontos de confiança do produto, são o alicerce para o software crescer. Mas a galera que vende essa ideia de criar o MVP "basicão" como solução (com ou sem uso de IA), não fala sobre isso, o argumento é que o sistema não fica pronto porque o dev tá ocupado com CSS 😒 (faz muito tempo que desenhar a interface deixou de ser problemático e demorado).

Imagina alguém apresentando um MVP feito dessa forma para um cliente, sistema lindo, aparentemente funcional, mas deixando claro para o contratante que os dados pessoais dos clientes dele têm risco aumentado de vazamento por conta de ser um MVP, ou que o sistema pode ficar fora do ar durante o processo de faturamento dele por ser um MVP. Será que conseguiriam vender esse MVP?

MVP não é desculpa para fazer um sistema apenas para agradar o usuário em um primeiro momento, e deixar as outras preocupações básicas do desenvolvimento de software de lado. Se quiser economizar em um MVP, que seja nas features e não na construção dele.