Vibe coding e agentic engineering estão ficando mais próximos do que eu gostaria
(simonwillison.net)- vibe coding e agentic engineering eram originalmente diferenciados pelos padrões de revisão de código e de responsabilização, mas, à medida que a confiabilidade dos agentes de programação aumenta, essa fronteira está ficando borrada no trabalho real de produção
- vibe coding é uma abordagem em que quase não se olha o código e, se o resultado desejado aparece, ele é aceito; isso pode ser útil para ferramentas pessoais, mas parece irresponsável em softwares que envolvem dados e experiência de uso de outras pessoas
- agentes como Claude Code lidam repetidamente bem com endpoints de API JSON, consultas SQL, testes e documentação, o que leva a situações em que nem toda linha de código gerada é revisada, criando o risco de confiar em algo sem reputação nem responsabilidade, ao contrário de uma equipe humana
- agora já é possível criar em 30 minutos um repositório com 100 commits, um bom README e testes completos, o que torna mais difícil julgar a qualidade apenas pela aparência; o verdadeiro critério passa a ser se alguém usou aquele software de forma contínua
- ferramentas de IA não substituem a experiência de engenheiros de software; elas a amplificam, e quando a velocidade de produção de código sobe de 200 para 2.000 linhas por dia, o gargalo se desloca para design, validação, operação e uso real
A fronteira entre vibe coding e agentic engineering
- No podcast Heavybit High Leverage Ep. #9, ao falar sobre ferramentas de codificação com IA, surge a percepção de que vibe coding e agentic engineering estão ficando mais próximos entre si no trabalho real
- Antes, em Not all AI-assisted programming is vibe coding (but vibe coding rocks), havia uma distinção clara entre vibe coding e programação assistida por IA feita com responsabilidade; depois, esta última passou a ser chamada de agentic engineering
- vibe coding se caracteriza por quase não olhar o código; alguém que pode nem saber programar pede o resultado desejado, aceita se funcionar e, se não funcionar, pede de novo
- Em casos como ferramentas pessoais, em que bugs só prejudicam o próprio usuário, vibe coding pode ser útil; mas, ao criar software que envolve os dados e a experiência de outras pessoas, isso parece uma abordagem irresponsável
- agentic engineering é a forma de um engenheiro de software profissional usar ferramentas de IA no limite máximo das próprias capacidades, entendendo restrições como segurança, manutenibilidade, operação e performance
- O objetivo não é produzir resultados de qualidade inferior mais rápido, e sim construir sistemas de produção de qualidade superior mais rapidamente
- O problema é que, à medida que os agentes de programação se tornam mais confiáveis, deixa-se de revisar toda linha de código gerada mesmo em tarefas de nível de produção
A confiança que leva a pular a revisão de código
- Ao pedir ao Claude Code que crie um endpoint de API JSON e execute uma consulta SQL para retornar o resultado em JSON, surge a confiança de que ele vai fazer isso direito
- Mesmo ao pedir que adicione testes automatizados e documentação, passa a existir a expectativa de que o resultado será aceitável, e nesse processo às vezes o código em si deixa de ser revisado
- Se o código não foi revisado, fica um sentimento de culpa sobre se é realmente responsável usá-lo em produção
- Isso pode ser visto de forma parecida com como se usa software de outras equipes quando se trabalha como gerente de engenharia em uma grande organização
- Se outra equipe oferece um serviço de redimensionamento de imagens, normalmente não se lê toda linha de código escrita por ela
- Lê-se a documentação, testa-se o redimensionamento de imagens e então se lança a própria funcionalidade
- Só quando aparecem bugs ou problemas de performance é que se pode olhar o repositório Git
- Na maior parte do tempo, esse serviço é tratado como uma caixa-preta parcial
- Os agentes estão passando a ser tratados da mesma forma, mas, ao contrário de uma equipe humana, Claude Code não tem reputação profissional nem responsabilidade(accountability)
- Equipes humanas podem construir reputação ao entregar bom software no passado e sofrem a pressão de que resultados ruins afetam sua reputação profissional
- Claude Code não pode ter esse tipo de reputação, mas vem acumulando confiança ao acertar repetidamente tarefas simples de um jeito alinhado ao estilo que prefere esse tipo de trabalho
- Há aqui um elemento de normalização do desvio
- Cada vez que o modelo escreve código correto sem supervisão próxima, a confiança aumenta
- Junto com isso, cresce também o risco de excesso de confiança no momento errado e do prejuízo que isso pode causar
Fica mais difícil avaliar software
- Antes, se um repositório no GitHub tinha 100 commits, um bom README e testes automatizados, era fácil concluir que o projeto tinha recebido bastante cuidado e atenção
- Agora é possível criar em 30 minutos um repositório Git com 100 commits, um README bonito e testes cobrindo todas as linhas de código
- Um repositório assim pode parecer, por fora, idêntico a um projeto construído com muito cuidado e atenção ao longo do tempo
- Talvez ele seja realmente tão bom quanto, mas é difícil saber só pela aparência, e o mesmo problema também vale para os próprios projetos
- Um critério considerado mais importante do que a qualidade dos testes e da documentação é se alguém realmente usou aquele software
- Mesmo que o resultado tenha sido feito com vibe coding, se a pessoa que o criou o usou todos os dias nas últimas duas semanas, isso é muito mais valioso do que algo gerado e quase nunca executado
O gargalo sai da escrita de código e vai para outras etapas
- Quando se passa de uma situação em que se produziam 200 linhas de código por dia para outra em que se podem produzir 2.000, outras partes do ciclo de vida do desenvolvimento de software começam a quebrar
- O ciclo de vida tradicional do desenvolvimento de software foi projetado assumindo uma velocidade de algumas centenas de linhas de código por dia
- A mudança de gargalo afeta não só as etapas posteriores, mas também as anteriores
- Na apresentação de Jenny Wen, aparece a visão de que o processo tradicional de design parte da premissa de que “é preciso acertar o design”
- Porque, se algo errado for construído por 3 meses depois de ser passado para a engenharia, isso vira um desastre
- Como o design leva a trabalho caro de implementação, cria-se um processo de design extenso
- Mas, se construir algo não leva 3 meses, o custo de errar cai muito, então o processo de design pode assumir bem mais risco
Por que isso ainda não significa o fim da carreira de engenheiro de software
- Conversar com agentes parece, para a maioria das pessoas, uma espécie de “moon language” difícil de entender
- Uma das razões para não ver a carreira de engenheiro de software como acabada só porque computadores agora conseguem escrever código sozinhos é que essas ferramentas amplificam a experiência existente
- Quem sabe o que está fazendo consegue se mover muito mais rápido com ferramentas de IA
- Quanto mais se usam ferramentas de IA, mais se confirma repetidamente como fazer software em si é algo muito difícil
- Mesmo com todas as ferramentas de IA disponíveis, o que se quer alcançar continua sendo difícil
- Matthew Yglesias escreveu em um tweet: “Depois de cinco meses, percebi que não quero fazer vibecode. Quero que empresas de software geridas profissionalmente usem assistência de programação por IA para criar produtos de software mais numerosos, melhores e mais baratos e me vendam isso”, e há concordância com essa visão
- Isso se resume à analogia de que, mesmo vendo vídeos suficientes no YouTube sobre encanamento para talvez consertar a tubulação da própria casa, ainda assim se prefere contratar um encanador
O risco de SaaS versus desenvolvimento interno
- Em relação à ameaça de empresas deixarem de usar SaaS para criar soluções próprias, continua valendo o mesmo critério de preferir software validado pelo uso real
- Em projetos pessoais, há preferência por ferramentas que o próprio criador tenha usado por pelo menos algumas semanas
- Na versão enterprise, o critério vira não querer adotar um CRM a menos que pelo menos duas outras grandes empresas o tenham usado com sucesso por seis meses
- Antes de assumir o risco, quer-se uma solução comprovadamente funcional
1 comentários
Comentários do Hacker News
Vibe coding e LLMs não criaram organizações ou engenheiros sem disciplina; apenas expuseram e aceleraram problemas que já existiam
Muitos engenheiros têm padrões e práticas de escrita de código frouxos ou inexistentes, e muitas equipes também têm critérios fracos para colocar código em produção
Isso não é um fenômeno novo; só significa que ficou muito mais fácil para indivíduos e equipes que nunca seguiram padrões ao longo do ciclo de vida de desenvolvimento de software produzir muito mais código e concretizar ideias
Nunca vi alguém virar um bom engenheiro só por escrever código mais rápido
Os melhores engenheiros que conheço foram pessoas que, com base em experiência e julgamento cuidadoso, compartilharam insights importantes com a equipe e ajudaram a direcionar melhor o sistema
“Claude, faz um sistema aí. Mas faz bem feito. Valeu!”
Antes, quando a base de código começava a resistir ao desenvolvimento de funcionalidades, corrigia-se o gargalo imediato e empurrava-se o resto até o próximo ponto de resistência
Era um estilo de refatorar até certo ponto enquanto se entregavam funcionalidades, mas os modelos de fronteira empurram ainda mais para frente o momento em que “vira problema”
Como conseguem lidar, até certo ponto, com o monte de código dado, isso acaba aparecendo como LLMs criando mais regressões ou deixando passar mais requisitos, mas dá menos a sensação de que o trabalho ficou mais difícil para a pessoa
Até que, em algum momento, quebra coisa demais e precisa consertar, mas a base inteira virou uma camada fractal de decisões que eu não tomei, difícil de desembaraçar
Como você não edita o código diretamente, também desaparece aquela reação visceral de “adicionar isso desse jeito vai gerar tensão”, então fica mais difícil encontrar a oportunidade de uma boa refatoração
Sempre dá para refatorar código depois, e dá para forçar o agente a escrever partes e arquivos pequenos e modularizados
Boa engenharia continua sendo boa engenharia, tenha sido escrita por agente ou por humano
Por enquanto, pelo menos uma pessoa ainda precisa entender e conduzir a arquitetura, e os agentes podem ajudar muito bem com reconhecimento e sugestões
A menos que eu tenha perdido algum avanço nas últimas semanas, parece menos que a IA ficou mais confiável e mais que os erros ficaram mais sutis
Se o código nem compila, é fácil de achar, e se compila mas não funciona, também é relativamente fácil de perceber
Mas quando compila e funciona, só que erra em alguns casos de borda, ou tem vulnerabilidades de segurança, ou traz dívida técnica e decisões arquiteturais duvidosas, fica muito mais difícil de detectar, e a carga de revisão não diminui nada
Na verdade, código plausível pesa mais mentalmente na revisão do que código obviamente ruim
Basta fazê-lo escrever vários testes primeiro, verificar se o código atende a eles e orientá-lo a organizar o código corretamente
Mas agora a pressão vinda de cima está tão forte que o clima é de aplicar isso amplamente em qualquer lugar, e se você se opõe, é desanimador demais e ainda limita sua carreira, o que vai desgastando a cabeça
Quando você aponta um problema óbvio, surgem muitos contornos; logo aparecem outros problemas nesses contornos, e isso gera soluções novas sem fim
Em algum momento, tudo isso começa a parecer trabalho em função da própria máquina
Em muitas empresas, parece que o objetivo real se perdeu e só sobrou o próprio LLM
Não sei se as pessoas que estão apostando o futuro da empresa nessa visão têm garantida uma saída suave para escapar das consequências, ou se a racionalidade foi simplesmente jogada fora por completo
Dá para mitigar os problemas com princípios sólidos de engenharia, mas ainda questiono qual eficiência real isso gera em termos de carga cognitiva, tempo de desenvolvedor, dinheiro e recursos finitos
Na frase “o que quebra quando você passa de 200 linhas por dia para 2.000”, usar linhas de código como métrica de produção de engenharia é algo constrangedor
Revisar 200 linhas e revisar 2.000 linhas são cargas de trabalho completamente diferentes
Quando refiz o mesmo programa com a minha própria cabeça e usei o ChatGPT só como busca e autocompletar, cheguei ao mesmo resultado com 1.500 linhas
Honestamente, a diferença de esforço também não foi tão grande, embora a abordagem manual talvez tenha tido a vantagem de eu já ter pensado no que queria construir graças à primeira versão feita com vibe coding
Faz sentido usar linhas de código como entrada para revisão de software
Afinal, é preciso literalmente ler cada linha
Só são péssimas como medida única de produtividade do desenvolvedor, e é aí que começam os problemas
Ainda assim, são úteis por serem talvez a única métrica imediatamente intuitiva e comparável entre empresas, equipes, linguagens e contextos de aplicação
Mesmo a mesma equipe, trabalhando no mesmo produto, pode resolver uma mudança de 1.000 linhas muito rápido, enquanto uma correção de bug de 1 linha pode exigir dias de depuração
Por isso é difícil comparar PR, feature ou story points fora de contexto; se existisse uma métrica padrão de produtividade de desenvolvedor realmente viável, todo mundo já a usaria, mas isso parece intrinsecamente difícil
Nessas comparações, ajuda assumir que o contexto é o mesmo
Por exemplo, se uma equipe que constrói um produto específico numa empresa específica, com uma stack específica e um processo de qualidade específico, ontem produzia N1 linhas e hoje, com IA, produz N2 linhas, então ao longo do tempo a diferença entre N1 e N2 aproxima o impacto real
Até estudos mais rigorosos sobre produtividade com desenvolvimento assistido por IA geralmente medem isso em estilo de teste A/B, comparando PRs antes e depois do uso de IA no mesmo grupo
Para mim, a diferença está na qualidade e no rigor do pipeline
Vibe coding é tentar uma vez ou algumas vezes, conferir superficialmente o resultado e usar até quebrar
Serve para provas de conceito leves ou apps de baixo risco para uso pessoal, familiar ou de equipes pequenas
Engenharia agentic se preocupa com um conjunto mais amplo de questões, como correção funcional, desempenho, infraestrutura, resiliência/disponibilidade, escalabilidade e manutenibilidade
Há um pipeline em múltiplas etapas gerenciando o fluxo de trabalho, com possíveis fases como intake do projeto, triagem, especificação, decomposição em épicos, decomposição em stories, codificação, documentação e deploy
Cada etapa mistura gates determinísticos de qualidade, como passar em testes ou atingir metas de performance, com revisões adversariais sobre valor de negócio, completude da especificação, elegância do código e rigor e simplicidade da linguagem ubíqua
Isso também é um slider
Às vezes você não quer fazer entrevista, gastar tokens, passar por três revisões adversariais, estimativa de valor e especificação detalhada só para lançar uma funcionalidade; quer só jogar o ticket no sistema
Eu uso Opus, GPT-5.5 e modelos menores todos os dias, mas não entrego o trabalho inteiro a eles
Mesmo colocando bastante esforço em definir e refinar especificações, eles ainda fazem muita bobagem que eu não aprovaria numa revisão humana de PR
Se eu confiasse no resultado, ou criasse um grande pipeline agentic para ganhar uma falsa sensação de estabilidade, seria fácil deixar isso simplesmente escorrer para dentro da base de código
Talvez daqui a 10 anos melhore, mas hoje tanto vibe coding quanto pipelines de engenharia agentic parecem variações do mesmo tema de delegar tudo ao LLM
Hoje de manhã mesmo, achei que poderia deixar o Opus on Max fazer alterações num arquivo único, mas quase todo turno tinha erros ou omissões que precisei corrigir
O código sugerido provavelmente funcionaria na maior parte, mas estava complexo demais e até regrediu partes que eu já tinha simplificado manualmente
Se isso se multiplicar por milhares de commits de agentes, a base de código piora rapidamente
Equipes de desenvolvimento se complicam quando tentam construir sem o processo correto de design, testes e revisão
Isso já era verdade antes da codificação com agentes, mas agora é ainda mais, e as equipes que melhor entenderem como usar agentes dentro desse processo serão as mais bem-sucedidas
Você não sente que agentes de código chegam muito perto da solução já na primeira tentativa, mas exigem um trabalho enorme para acertar os últimos 10% ou 5%?
Se você mudar a forma de abordar o problema, o agente consegue fechar essa lacuna
Dez anos atrás, eu parava de programar a cada 10 ou 15 minutos para refatorar, testar e analisar se estava tudo certo
Porque um bug pode contaminar todo o código escrito depois
Agentes de código não conseguem fazer isso e seguem em frente carregando bugs ou arquitetura errada
O instinto é querer interromper o agente no meio do caminho, mas isso é impossível por vários motivos
Em vez disso, como o custo é muito baixo, você precisa encontrar o ponto em que o agente errou pela primeira vez, ajustar o prompt e, em vez de corrigir o código, apagar tudo e rodar de novo do zero
É só repetir isso até o prompt gerar código perfeito
Vão dizer que isso ainda exige muito trabalho humano, mas esse é exatamente o ponto
Humanos continuam sendo necessários, e usar a ferramenta assim faz a velocidade de escrita de código aumentar 10x
Você consegue fazer “algo que funciona” relativamente rápido, mas leva tempo para avaliar alternativas, refinar, testar e ganhar confiança
A ideia central está certa, mas ninguém sabe onde está o limite
O próximo ano mais ou menos vai ser um período em que todo mundo estará tentando descobrir isso, e por isso se ouve tanto que “precisamos reinventar o GitHub”
Em muitos casos, investir para mecanizar também essa parte final simplesmente não faz sentido econômico
Acho que os provedores de LLM seguiram a abordagem errada desde o começo
Em vez de focar em substituir trabalho, deveriam ter focado em complementar o trabalho, e parece que aprenderam isso do jeito caro
Talvez tivesse sido melhor recomeçar do zero, mas no início eu ainda não sabia como deveria ser a arquitetura desejada
Só porque o LLM sofre para encaixar funcionalidades na arquitetura existente não significa que se possa apagar uma base de código inteira em produção e começar de novo
É um ótimo texto escrito por alguém inteligente, humilde e disposto a continuar aprendendo
Gostei da frase: “Há muitos motivos pelos quais não tenho medo de que a carreira de engenheiro de software tenha acabado só porque computadores agora conseguem escrever seu próprio código. Em parte, é porque essas coisas são amplificadores da experiência prévia. Se você sabe o que está fazendo, consegue correr muito mais rápido”
E também desta: “Usar essas ferramentas continua me lembrando do quão difícil é o que fazemos. Construir software é brutalmente difícil. Mesmo com todas as ferramentas de IA do mundo, o que estamos tentando realizar aqui continua sendo realmente difícil”
Está certo ao apontar que o trabalho a montante também muda junto
As ferramentas de design estão evoluindo especialmente rápido, então já não parece valer a pena arcar com o custo de tradução de permanecer no Figma
A parte assustadora é que camadas de complexidade de IA vão se acumulando na base de código, e os humanos deixam de entender o código, de modo que passa a custar caro para os modelos mais recentes decifrarem e alterarem aquilo
Em pouco tempo, pode desaparecer o reuso de código, e vamos acabar queimando dinheiro reinventando a roda sem parar
Quando eu fazia apps Android no começo, era obrigatório usar IDE, e dava uma sensação de esgotamento da alma ter de escrever uma quantidade absurda de boilerplate só para, ao clicar num botão, aparecer um alerta “Hello World”
Repitam comigo: a maior parte do software passa a maior parte da vida na fase de manutenção
Portanto, a maior parte do dinheiro que o software gera também vem da fase de manutenção
A indústria, depois de quase 100 anos, ainda não entendeu isso
Alan Kay estava 100% certo ao dizer que a revolução dos computadores ainda não aconteceu
Apesar de todos os avanços atuais, as ferramentas ainda são em grande parte nível idade da pedra
Minha grande esperança é que a IA nos acelere até um ponto em que destrua completamente o paradigma atual de forma irreversível, para que finalmente possamos fazer algo novo, diferente e melhor
Então, por enquanto, vamos colocar um jetpack de IA no ciclo de vida de desenvolvimento de software e ver no que dá
Vamos nos mover rápido e quebrar as coisas de verdade
É uma observação oportuna e parece verdadeira para mim também
Eu precisava montar algo relativamente simples de download em lote → conversão → endpoint de API, e usei um prompt bem detalhado, mas deixei em aberto muitos detalhes de implementação, como a fonte dos dados
O Opus 4.7 fez algo cerca de 90% igual ao que eu teria feito, e ainda colocou muito mais métodos utilitários e validação por etapa
Ficou muito bom e me deu espaço mental para pensar em problemas mais difíceis
Sou principalmente desenvolvedor Python, mas uso com frequência outras linguagens de backend como Rust e Go, com as quais tenho familiaridade, embora não no mesmo nível
Com cerca de 13 anos de experiência fortemente concentrada numa linguagem e estudo formal de outras, fica muito mais fácil direcionar o LLM
A carga de aprender sintaxe, componentes básicos, gerenciador de pacotes, testes etc. não é grande comparada ao jeito antigo de programar
Há pouco tempo, ajudei um colega não desenvolvedor que estava automatizando relatórios com Claude cowork/code
Esse colega entendia bem a parte de business intelligence, mas tinha dificuldade com o vocabulário básico para fazer vibe coding de um wrapper em pyautogui que abrisse uma sessão RDP e preenchesse valores numa abstração em MS Access sobre o banco de dados de um fornecedor
Acho que desenvolvedores como profissão ainda estarão bem pelos próximos 5 a 10 anos