Todo mundo virou dev?

Todo mundo virou dev ?
Assistido por IA ou vibe coding?

Esses dias, parei e fiz uma pergunta para mim e para alguns desenvolvedores:

“Vocês estão programando com IA ou estão vibe codando?”

Alguns sequer entenderam a pergunta.

E tudo bem. O termo ainda é novo e já está sendo usado para descrever coisas bem diferentes.

Andrej Karpathy cunhou “vibe coding” no início de 2025. Na descrição original, ele falava sobre se entregar completamente às sugestões da IA, aceitar as mudanças e praticamente esquecer que o código existe.

Era quase uma confissão sobre uma forma diferente de prototipar: você descreve o que quer, observa o resultado, pede ajustes e segue em frente.

Desde então, o termo cresceu. Hoje, qualquer pessoa usando IA para escrever código corre o risco de ser chamada de vibe coder.

Mas acredito que existe uma diferença importante.

Um desenvolvedor assistido por IA usa o agente para escrever código, explorar soluções e ganhar velocidade. Mesmo assim, continua responsável pelo que será executado.

O vibe coding começa quando o entendimento sai do processo.

Mais gente está construindo

Tem uma parte desse movimento que eu acho muito legal.

Pessoas que até pouco tempo não sabiam o que era VS Code agora estão instalando um editor, escrevendo alguns prompts e vendo uma ideia aparecer na tela.

Gente excelente em produto, marketing e outras áreas de negócio finalmente consegue experimentar sem precisar montar um time inteiro antes de validar uma hipótese.

Isso é poderoso.

Também me deu mais assunto para conversar com essa galera, o que já considero uma vantagem. Hahaha.

Meu receio começa quando uma aplicação funcionando na tela passa a ser tratada como um sistema pronto.

Escrever linhas de código quase nunca foi a parte mais difícil de construir um produto.

O desafio sempre esteve em manter essas linhas sustentáveis durante anos. Manter o software seguro. Criar uma esteira de CI/CD. Entender requisitos. Observar o comportamento do usuário e tomar decisões com base nisso.

A IA facilitou a escrita.

Ela não eliminou o restante do trabalho.

O código funciona. E depois?

Conheço pessoas excelentes em suas áreas tentando construir produtos com IA e sem conseguir sair do lugar.

Elas produzem telas, endpoints e novas versões rapidamente. Mesmo assim, o projeto não avança de verdade.

Recentemente, acompanhei um projeto feito dessa forma passar pelas mãos de várias pessoas e pela pauta de várias reuniões. Em diferentes momentos, cogitaram começar tudo novamente do zero.

Quatro vezes.

O problema não era falta de código. Havia bastante código.

Faltava uma estrutura que permitisse entender o que já existia, reaproveitar regras de negócio e tomar decisões sem quebrar outra parte do sistema.

Uma IA consegue gerar um laço de repetição. O engenheiro precisa perceber quando um for aninhado esconde um problema sério de desempenho.

Uma IA consegue montar autenticação e autorização. O engenheiro precisa verificar se o usuário A consegue acessar o dado do usuário B.

Uma IA consegue entregar uma funcionalidade. Alguém ainda precisa responder se aquilo atende ao requisito certo, continua seguro e poderá ser mantido depois.

Essa é a diferença que me interessa.

“É só pedir para o Claude revisar”

Quando levanto esse ponto, surge uma resposta previsível:

“Mas é só pedir para o Claude revisar segurança, arquitetura e qualidade.”

Quase.

O agente pode revisar o próprio trabalho, executar testes e encontrar problemas. Eu uso isso todos os dias.

Mas, se você não consegue avaliar a resposta, apenas trocou um pedido por outro.

Você pediu para gerar o código. Depois pediu para verificar o código. Em ambos os casos, continua dependendo do modelo para dizer se ele próprio fez um bom trabalho.

O modelo produz uma resposta provável com base no contexto que recebeu. Ele não assume a responsabilidade pelo que acontece em produção.

Se você não entende um laço de repetição, uma estrutura condicional ou o mecanismo de autenticação criado pelo agente, não consegue distinguir uma boa explicação de uma explicação que apenas parece convincente.

Foi justamente para reduzir esse problema que comecei a trabalhar com Harness Engineering.

Um bom harness entrega contexto ao agente, registra decisões, executa testes e cria barreiras para impedir violações conhecidas. Ele melhora o ambiente no qual humanos e agentes escrevem software.

Mas nem mesmo um bom harness elimina a necessidade de alguém entender o sistema.

Escrevi mais sobre isso em:

https://entredobras.com.br/artigos/harness-engineering-a-engenharia

Ainda vamos aprender?

Outra pergunta tem aparecido entre desenvolvedores:

“Se a IA escrever o código, continuaremos aprendendo como aprendemos durante nossas carreiras?”

Minha opinião é que sim, desde que não terceirizemos também o entendimento.

Antes, escrevíamos algumas linhas, executávamos, encontrávamos um erro e precisávamos descobrir o que havia acontecido.

Agora, parte desse aprendizado migra para a revisão.

Precisamos ler o que foi gerado, confrontar com o requisito, procurar falhas de segurança, avaliar as decisões e entender por que aquela solução funciona.

Quem aceita tudo sem revisar aprende a pedir.

Quem investiga o resultado continua aprendendo engenharia.

Por isso vejo desenvolvedores em início de carreira divididos. Alguns estão assustados. Outros estão animados com a possibilidade de produzir muito mais cedo.

A oportunidade é enorme, mas ela aumenta a importância dos fundamentos.

Durante o período em que dei aula, eu repetia que a base era a parte mais importante.

Continuo acreditando nisso.

Você pode usar uma biblioteca sem conhecer sua implementação inteira. Pode trabalhar com um framework sem dominar cada detalhe interno. Pode pedir para um agente escrever uma funcionalidade completa.

Mas precisa entender fluxo de execução, estruturas de dados, estado, autenticação, autorização e testes o suficiente para questionar o resultado.

Quanto mais alta fica a abstração, mais perigoso é não conhecer o que existe abaixo dela.

O foguete

Minha analogia é esta:

Um engenheiro assistido por IA está montado em um foguete.

O foguete entrega uma velocidade que não tínhamos antes. Podemos experimentar, construir e gerar valor muito mais rápido.

Mas alguém precisa saber para onde ele está indo, perceber quando saiu da rota e assumir o controle quando algo dá errado.

O diferencial não será apertar o botão que faz o foguete subir.

Será saber pilotá-lo.

Não sou contra vibe coding. Pelo contrário: use para experimentar, construir protótipos e colocar ideias no mundo.

Só precisamos reconhecer o momento em que a vibe termina e a engenharia começa.

Porque uma aplicação pode nascer de um prompt.

Um sistema precisa sobreviver ao que acontece depois dele.

E essa foi mais uma dobra de: usar IA sem terceirizar o entendimento.

Nos vemos na próxima quinta, às 10:10.