Executando verificação de segurança...
-19
zilvodev
2 min de leitura ·

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

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

Parece absurdo. Mas tem lógica.

Tem uma crença que paralisa muita gente que quer criar apps com IA: "Eu não sei programar. Os devs experientes vão sempre fazer isso melhor."

Não necessariamente.

Vibe coding não é uma skill de engenharia. É uma skill de produto.

Por que os devs sêniors ficam travados

Um dev sênior com 10 anos de experiência olha para código gerado por IA e vê mil coisas erradas: "Esse componente está fazendo duas coisas ao mesmo tempo." "Aqui falta tratamento de erro." "Essa lógica vai quebrar em escala."

E aí ele para. Refatora. Questiona a arquitetura.

No vibe coding, isso vira problema. Quem fica consertando cada detalhe antes de entregar nunca entrega nada.

A skill que realmente importa

Quem vai bem no vibe coding: sabe o que quer construir, consegue quebrar uma ideia vaga em pedaços entregáveis, está confortável em entregar 80% certo e corrigir depois.

Isso não é skill técnica. É raciocínio de produto.

O dono de uma padaria que quer um sistema de pedidos não vai travar porque o CSS não está perfeito. Ele quer que o pedido chegue na cozinha. Funciona? Entrega.

O que a IA mudou de verdade

Antes, a execução técnica era um filtro. A IA removeu esse filtro.

O que sobrou como vantagem real não é conhecimento técnico acumulado. É clareza sobre o que construir e disposição de iterar rápido.

Artigo completo: https://blog.zilvo.app/posts/dev-senior-pior-vibe-coder-que-voce/

Fonte: https://blog.zilvo.app/posts/dev-senior-pior-vibe-coder-que-voce/

Carregando publicação patrocinada...
9
user1

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.

0
zilvodev
  • Autor
    Autor

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.

4
user1

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.

5
Programmer404

No vibe coding, isso vira problema. Quem fica consertando cada detalhe antes de entregar nunca entrega nada

Estou abismado com essa afirmação.

E aí ele para. Refatora. Questiona a arquitetura.

É isso que developers profissionais fazem. Isso e mais um pouco. Não é um setor fácil. Exige uma quantidade absurda de pensamento sobre aquilo que foi implementado.

Pessoas que só pegam o código para fazer X funcionar é apenas um implementador, e não desenvolvedor. Desenvolver não é somente fazer funcionar.

Mesmo que se deixe para "depois" resolver, isso só é verdade para problemas bem simples. Problemas a nível arquitetura é crítico e não se resolve na maioria dos casos.

0
zilvodev
  • Autor
    Autor

Você está certo que a afirmação saiu sem contexto suficiente. A distinção real não é entre "dev que refatora" e "dev que só entrega" — é entre refatorar cedo demais vs refatorar no momento certo.

O dev sênior que para para questionar a arquitetura de um sistema que ainda não tem um usuário real está fazendo a coisa certa, tecnicamente. O problema é que a maioria dos produtos morre antes de precisar de escala, e os que sobrevivem geralmente conseguem refatorar quando chegam lá.

O argumento do artigo é mais sobre timing do que sobre qualidade. Refatorar é necessário. Quando é a pergunta.

3
maniero

Um dos grandes problemas que estamos vivendo é o terraplanismo, como eu gosto de chamar qualquer coisa que usam premissas parecidas, na programação.

Cada vez mais pessoas sem qualquer instrução de qualidade vai apresentar produtos de software por aí. Cada vez mais alguns até com alguma instrução, mas sem sensatez, sem entender o que vai além do código vão ser tentados ou quase obrigados, até pelo mercado, a entregar alguma coisa muito rui, mas que funciona, ou quase. Pode ter inúmeros problemas não muito aparentes.

Mas o problema que eu quero focar aqui é que estamos deixando a engenharia de lado, e isso vale até para grande parte do sêniores (apesar que eu não os classificaria assim), em que a entrega é a única importância que existe.

Eu já venho falando há algum tempo que o vibe coding, mesmo bem feito, o que é raro, produz muita dívida técnica, porque ficou tão barato criar código que as pessoas estão criando aos borbotões. As pessoas estão esquecendo uma frase extremamente conhecida no meio:

O melhor código é quele que não existe.

Estamos criando pilhas de código lixo em vez de pensar e gerar o código mais adequado.

Eu até acho que usar a IA fortemente em alguns casos possa ser a solução, mas poucas pessoas estão preparadas para decidir isso. EU não estou, afinal não tenho muita experiência com isso. Pelo menos eu sei disso, muita gente vai achar que tem a experiência necessária sem ter, e é o caminho para o desastre.

Estamos saindo de pessoas que adoravam fazer overengineering, que glorificavam Clean Code, Clean Architecture e coisas do tipo para pessoas que só querem ver o código rodando sem ela sequer ter escrito algo ou revisado.

Isso não é tão novo, já se fazia isso quando a pessoa se preocupava muito com o MVP. A esmagadora maioria dos produtos que eu vi soltar um MVP o mais rápido possível nunca se tornou um bom produto, agora só está reduzindo o prazo e tem menos cuidado ainda.

A sociedade está muito doente. Onde está o equilibro, a sensatez, o pensamento crítico, a contextualização?

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

2
zilvodev
  • Autor
    Autor

"O melhor código é o que não existe" é uma das frases mais ignoradas do setor, e faz cada vez mais sentido num momento em que código virou commodity.

O que você descreveu como terraplanismo é real: substituir um extremo (overengineering, Clean Architecture de todo) pelo outro (entregar sem revisar nada) não é progresso, é pêndulo.

O equilíbrio que você menciona é exatamente o que falta. Usar IA para pensar menos antes de escrever código costuma gerar mais código, não menos. O dev que usa IA para escrever menos código (decompor o problema, eliminar o desnecessário, depois implementar só o essencial) está usando a ferramenta certa. Poucos fazem isso.

2
Oletros

Meus 2 cents,

E aí ele para. Refatora. Questiona a arquitetura.

No vibe coding, isso vira problema. Quem fica consertando cada detalhe antes de entregar nunca entrega nada.

Olha, de boa, este tipo de colocacao faz sentido para MVP de sistema de 10 reais, nao para sistemas que tem de rodar com dados sensiveis em situacoes reais com empresas reais.

E por dados sensivel nao estou falando de NASA - p.ex. um clinica de fisioterapia que tem o cadastro de pacientes e seu historico ja eh algo sensivel.

O DEV que para e analisa o que esta acontecendo eh basicamente porque ele sabe QUE SISTEMAS DAO MERDA PARA CARALHO E DEPENDO DA MERDA A EMPRESA PODE FALIR !

Porra, trabalhei com sistemas de Folha de Pagamento, e um calculo errado ou uma funcao mal projetada poderia afetar o pagamento de milhares de funcionarios, a gente tinha que revisar 3 vezes nao apenas o codigo, mas se as regras de negocio nao estavam sendo impactadas.

Codar eh barato (com IA sao fracoes de centavos), mas fazer merda sai caro.

Saude e Sucesso !

0
zilvodev
  • Autor
    Autor

Folha de pagamento afetando milhares de funcionários é exatamente o tipo de sistema onde o dev que para e revisa 3x está completamente certo. Nenhuma pressão de entrega justifica um bug nesse contexto.

O ponto do artigo é que nem todo sistema é folha de pagamento. Um MVP de um app de agendamento para uma barbearia de bairro pode testar a hipótese do negócio antes de merecer revisão tripla de arquitetura. Se não tiver usuário depois de 3 meses, a arquitetura perfeita não ajudou em nada.

A questão é contextualizar. Sistemas sensíveis com dados reais de empresas reais: o dev que revisa está certo. Hipótese de produto que precisa de validação de mercado: velocidade pode ser a decisão mais responsável.

2
Oletros

Meus 2 cents extendidos,

Ia fazer um textao, mas ai vi a resposta do @user1 tem basicamente o que eu diria.

Resumindo: teu artigo nao fala de MVP, eh generico o bastante para dizer que DEV eh um bosta por nao entregar rapido (na tua cabeca o artigo pode dizer outra coisa, mas o que esta escrito eh isso).

Saude !