Vibe code é código legado
(blog.val.town)- Vibe coding é uma forma de escrever código rapidamente com a ajuda de IA, seguindo a intuição, e no fim acaba deixando código que ninguém entende, ou seja, código legado
- Código legado é código que ninguém entende, o que traz dívida técnica e problemas de manutenção, além de aumentar a chance de erros ao adicionar novas funcionalidades
- Vibe coding pode ser um meio rápido de desenvolvimento para protótipos ou projetos de curto prazo, mas é inadequado para projetos que precisam ser mantidos no longo prazo
- Quando não especialistas fazem vibe coding em projetos grandes, existe um risco comparável a dar um cartão de crédito a uma criança
- Mesmo em 2025, ao desenvolver com IA, é importante manter cautela e compreensão
O que é vibe coding
- Andrej Karpathy definiu o termo "vibe coding" como um estilo de programação em que a IA escreve o código e o usuário praticamente deixa de se preocupar com a própria existência do código
- Essa abordagem difere do desenvolvimento tradicional de software porque o desenvolvedor consegue um resultado mesmo sem entender nada do funcionamento interno do código gerado
Os problemas do código legado e a dívida técnica
- Código que ninguém entende já é, por si só, código legado
- Esse tipo de código exige muito tempo para manutenção e faz os problemas crescerem bastante quando surgem bugs ou quando se tenta adicionar novas funcionalidades
- O texto enfatiza que a essência da programação não é produzir muito código, e sim construir uma teoria conceitual
Vibe coding e prototipagem
- Vibe coding oferece entrada rápida e desenvolvimento ágil para protótipos e projetos descartáveis
- Se não houver necessidade de manutenção posterior, não conhecer o interior do código pode não ser um grande problema
- Por isso, ele pode aumentar bastante a velocidade de desenvolvimento e é muito adequado para experimentar novas ideias
O espectro de compreensão no vibe coding
- No vibe coding, quanto menor o entendimento do desenvolvedor sobre o código, mais “vibe” existe no processo
- Em essência, quanto mais claramente o engenheiro entende os requisitos, menos vibe coding acontece
- Quando uma pessoa que não programa pede código sem sequer entender a diferença entre web e app nativo, nem como os dados são armazenados, normalmente ocorre ainda mais vibe coding
Vibe coding em larga escala por não especialistas: algo parecido com um cartão de crédito
- Tentar criar e manter um projeto grande com vibe coding sem ser especialista é uma situação parecida com dar um cartão de crédito a uma criança sem noção do conceito
- No começo, tudo pode parecer fácil, mas depois vêm enormes custos de manutenção e problemas
- No fim, quando a “fatura” chega, a falta de capacidade para resolver os problemas pode até piorar a situação
Desenvolvimento sério na era da IA em 2025
- Andrej Karpathy enfatiza que, ao desenvolver com IA, é indispensável manter prudência, cuidado e uma postura contínua de aprendizado sobre o código existente
- É importante se defender da confiança exagerada da IA e manter o julgamento humano para distinguir código bom de código ruim
- Em vez de simplesmente delegar tudo à IA, é preciso ler e entender o código diretamente
Uso das ferramentas de IA da Val Town
- A Val Town automatiza escrita, execução, verificação e melhoria iterativa de código por meio de um assistente de IA chamado Townie
- O Townie é uma ferramenta adequada para vibe coding e pode ser usada com liberdade ou sob controle rigoroso, dependendo do objetivo
- A forma de desenvolver com IA está evoluindo muito rapidamente, e a importância da base teórica no desenvolvimento de software complexo continuará existindo
Alerta contra vibe coding irresponsável por não especialistas
- Não é uma boa ideia que pessoas que não programam gastem milhares de dólares para fazer vibe coding de uma grande ideia de aplicativo
- No fim, sempre será necessário o olhar humano para ler e analisar o interior do código, e muitas vezes é mais eficaz projetar bem desde o início do que tentar consertar código legado incompreensível
Conclusão e conselho
- Ao construir software complexo, a base teórica é essencial
- Embora a forma de programar esteja mudando rapidamente com o avanço da IA, a expertise do desenvolvedor humano continua sendo importante
- Se uma pessoa sem especialização tentar criar um aplicativo de grande escala com IA, no final pode ser melhor ler todo o código e refazê-lo do zero
12 comentários
A analogia de que é como dar um cartão de crédito para uma criança
parece bem apropriada
ou talvez também dê para comparar com dar uma faca para uma criança
Se surgir uma IA de geração de código que também adicione comentários ao código gerado e desenhe fluxogramas do fluxo do código, isso ajudaria até certo ponto.
É uma observação com a qual eu concordo bastante. Na prática, também já estou passando por isso em parte…
Ao mesmo tempo, fico curioso para ver como essa questão vai mudar conforme o desempenho dos modelos evoluir.
É tão verdade que dá vontade de bater no joelho e concordar. Quem não entende de código diz “uau” quando faz vibe coding, mas quem entende de código pensa “por quê? assim?”.
O estado dos comentários é lamentável.
Então isso quer dizer que não dá para dirigir um carro para sempre até entender toda a sua estrutura interna?
Construir um carro sem entender a estrutura interna = vibe coding
Dá pra usar. Mas criar, não dá.
Acho que é uma questão de método e tecnologia. Quem diz que não se deve usar IA e que o certo é fazer programação manual, orgânica, me parece como quem diz que a verdade está em usar ábaco em vez de calculadora científica, ou em escrever tudo à mão em vez de usar funções do Excel.
É uma analogia equivocada. Assim como uma calculadora de engenharia, uma calculadora comum ou o Excel, os resultados são exatos de acordo com os valores de entrada. Se a IA simplesmente produzisse exatamente o resultado previsto pelo usuário, provavelmente não seria uma tecnologia tão diferente das inúmeras novas tecnologias que surgiram até agora. Esse também é o motivo pelo qual, com o passar do tempo, crescem as preocupações com segurança e alucinações. Em outras palavras, a IA generativa não pode ser controlada. É preciso entender os limites atuais dos LLMs e usá-los nos contextos adequados.
Acho que o vibe coding ainda está no início e que, no ano que vem ou no seguinte, se tornará uma metodologia de desenvolvimento madura. Assim como devops está virando aidevops, acredito que teremos aiagile ou vibeagile.
Comentários do Hacker News
É uma história sobre um amigo não desenvolvedor. No ano passado, ele lançou um SaaS que ele mesmo programou e, quase sem marketing, começou a gerar receita só com boca a boca e inbound. Ele usou Replit e Supabase no desenvolvimento e, considerando que o app foi ficando cada vez mais complexo conforme recebia feedback dos clientes, isso pareceu realmente impressionante. Pelo que entendi, já havia dois fornecedores estabelecidos nesse mercado, e como meu amigo apareceu com um produto mais moderno por uma mensalidade muito mais barata, acho que eles não ficaram nada satisfeitos (os produtos antigos eram todos softwares desktop para Windows). Então contrataram hackers para atacar o SaaS do meu amigo, e esses hackers fizeram isso sem nem exigir dinheiro. Infelizmente, como ele codou rápido e sem experiência, havia muitas vulnerabilidades. Primeiro, a lista de usuários ficou exposta no código de frontend, e os hackers mandaram e-mails para todos os clientes. Segundo, eles conseguiram as chaves do Stripe e processaram reembolsos para todos os clientes. Terceiro, ainda tentam ataques de XSS, e às vezes aparecem tags como
<script>alert()</script>em alguns campos. Minha conclusão é que, quando uma pessoa sem experiência faz vibe coding, a dívida técnica se acumula imediatamente. Mas, ao mesmo tempo, é impressionante que esse amigo tenha provado em poucos meses a viabilidade comercial de um produto sem nenhuma experiência em engenharia. Agora ele está contratando desenvolvedores para corrigir isso. Ele conseguiu validar um potencial de negócio razoável investindo só algumas centenas de dólares, mesmo com um código frouxo e inseguro, então no fim acho que o processo valeu a penaAcho que presumir que foi obra dos concorrentes é mais uma forma de fugir da responsabilidade. O mais plausível é que scanners automatizados de vulnerabilidade tenham detectado o site e, como ele era vulnerável demais, algum invasor entrou para brincar. Quem está acostumado a ver tráfego de exploração em serviços conectados à internet sabe bem como isso acontece com frequência
Moralmente isso é equivalente a construir uma casa sem experiência em engenharia e alguém vir e simplesmente dar um chute até ela desabar. O problema não é o vibe coding em si, mas a falta de conhecimento necessário para tomar decisões importantes. Esse tipo de problema pode até evoluir para responsabilidade legal
Se já havia fornecedores estabelecidos no mercado, será que um MVP assim era mesmo necessário para provar a viabilidade? Essencialmente, não há por que testar se as pessoas trocariam de fornecedor se você simplesmente oferecer algo mais barato. A lição que seu amigo aprendeu é que alguns clientes até vão pagar no começo (sem dados de retenção, porém), mas no fim ele vai precisar contratar gente para fazer um produto de verdade, e aí também vai perder competitividade em preço. Quando chegar a hora de investir seriamente em marketing, vai ter muito mais com o que se preocupar. No fim, isso só reforça a velha conclusão de que ideias sozinhas não têm valor nenhum; o que importa é capacidade de execução
O problema fundamental deste setor é que seu amigo pode continuar tocando o negócio praticamente sem responsabilidade alguma. Se software fosse regulado com o mesmo rigor de outras áreas da engenharia, desenvolvedores e empresas inevitavelmente responderiam legalmente por vazamento de dados de clientes
Mesmo que o negócio em si tenha sido validado, para o cliente isso pode ser prejuízo, não benefício. A pessoa está pagando para usar algo enquanto expõe dados importantes a um ambiente inseguro, sem nem ficar claro se o produto realmente funciona direito. Agora ele vai contratar desenvolvedores para corrigir as coisas, mas isso não vai ser tão simples quanto parece. Sou a favor de IA como material de estudo, ferramenta de aprendizado ou de produtividade, mas, sem intervenção humana no meio, o resultado pode ser horrível
No passado, não desenvolvedores e também desenvolvedores júnior já criaram e distribuíram aplicações com facilidade usando Microsoft Access, Excel e afins muitas vezes. Naquela época também havia limites, problemas de escala e pesadelos de manutenção, mas ao mesmo tempo esse movimento acelerou a criação de soluções melhores por parte dos desenvolvedores profissionais. Foi parecido quando o PC se popularizou: desenvolvedores de mainframe ficavam horrorizados com o código “bagunçado” do mundo dos PCs
Trabalho como engenheiro de software há quase trinta anos e li todos os comentários desta discussão. E, ainda assim, acho que quase todos os argumentos usados para criticar vibe coding se aplicam igualmente a praticamente todas as bases de código “escritas por humanos” que vi ao longo da carreira (embora, claro, existam exceções)
Não entendo por que um protótipo feito para ser descartado seria algo ruim. Essa é a etapa mais importante ao começar um negócio. O mesmo vale para código legado. Na prática, a maior parte do código que realmente gera receita provavelmente já é vista como legado pelos desenvolvedores daquela organização
Existe até a piada de que, no instante em que algo é mergeado na trunk, já virou código legado
Concordo em parte, mas o problema do vibe coding é que ele permite uma abordagem totalmente sem critério, sem pesquisa adequada, sem estudo da estrutura da base existente ou de qual solução é realmente necessária. Ontem mesmo, um colega que não domina Rust criou uma funcionalidade nova com vibe coding. Por fora, ela “funciona”, mas na prática é um desastre completo (I/O síncrono dentro de contexto async do tokio, locks, implementação própria de canal etc.). Já existem abstrações assíncronas seguras, mas ele criou abstrações novas e erradas. Se tivesse pesquisado um pouco ou pedido ajuda antes, poderia até ter usado exemplos do código existente
Todo código um dia vira legado. Pela minha experiência desde os tempos de júnior, e revisando incontáveis scripts e serviços em produção escritos por mim e por outros juniores, acho esse absolutismo exagerado demais. Esse problema se repete na maioria das organizações. Também entendo textos criticando a qualidade de código gerado por LLM, mas qualquer desenvolvedor que tenha passado a carreira corrigindo, estendendo ou refatorando sistemas feitos por outros conhece essa realidade ainda melhor. Enquanto o mundo da engenharia de software não adotar padrões rigorosos de consistência, certificação, responsabilidade e consequências reais como na engenharia mecânica, esse debate tem pouco significado. A indústria moderna de TI é baseada justamente na filosofia oposta: ‘agile’, ‘faz rápido e tudo bem se quebrar’. A ideia é lançar rápido, com pouco design, frequentemente; se der errado, reverte; se cair, “faz parte”. Software é tratado como brinquedo. Talvez 1% diga com orgulho que faz direito, mas a maioria não faz
Há algo interessante acontecendo agora. Pessoas que entendem pouco de engenharia, e até algumas que entendem um pouco mas não conseguem explicar direito, estão espalhando narrativas erradas online. Agora dizem que desenvolvedores júnior são 10 vezes mais produtivos e que até PMs já estão fazendo deploy de código por conta própria. Mas basta fechar os olhos por um instante e imaginar o tipo de código que sai desse cenário: é 100% código legado e descartável. O ponto central não é IA, nem PMs gerando código direto do Figma, nem juniores disparando prompts sem parar. A razão real para o descompasso entre expectativa e realidade é a incapacidade de distinguir corretamente termos e conceitos que foram definidos ao longo de anos de discussão.
Protótipo enxuto e protótipo descartável não são a mesma coisa (nem mesmo um MVP). Um MVP só pode ser criado depois da validação bem-sucedida de um protótipo enxuto. E produto também é diferente de MVP.
Ferramentas de vibe coding são excelentes para fazer protótipos descartáveis rapidamente; IDEs com LLM embutido são mais adequadas para construir produtos de verdade. No estágio atual, só engenheiros de verdade conseguem codar protótipos enxutos com prompts para LLM; o resto só produz software simples funcionando sobre código descartável
Quando você diz “produto é diferente de MVP”, eu queria muito repetir isso em quase todas as empresas onde trabalhei. Hoje em dia, conselhos e executivos C-level vivem com a mentalidade de “entrega qualquer coisa até o fim do trimestre”, então os desenvolvedores fazem um MVP e logo passam para o próximo projeto. Independentemente de ser vibe coding ou não, a realidade é que, se parecer rico em funcionalidades, os indicadores de negócio sobem mesmo que a qualidade real seja ruim. Na verdade, ambientes em que engenheiros de verdade (aparentemente agora é assim que chamam “desenvolvedores”) lideram prototipagem são raros. Talvez em games ou em algumas empresas de tecnologia. A maioria está obcecada exclusivamente por produzir MVPs. Vibe coding só acelera a linha de montagem de MVPs, sacrificando a qualidade na mesma proporção
Essa tendência de usar “definições de termos” de forma vaga e intercambiável cresceu visivelmente na indústria nos últimos dez anos. Esses termos eram palavras carregadas de contexto, acumulado em inúmeros livros, debates e anos de discussão. Quando um desenvolvedor experiente usava uma palavra, ela vinha acompanhada de todo esse histórico e dessas disputas conceituais. Mas novos funcionários simplesmente “copiam” as palavras de forma superficial, sem esse contexto e sem sequer definir o significado. No fim, ninguém mais entende o que cada termo queria dizer originalmente nem por que aquela palavra era a adequada para a situação. Exemplos: "'agile', 'technical debt', 'DevOps', e o mais recente ‘vibe coding'" e por aí vai. Também apareceu no HN um texto sobre semantic drift. Isso é algo comum no setor de software.
Um exemplo técnico é no JavaScript, em que usam 'object', 'JSON', 'dictionary' e 'hashmap' tudo misturado. Originalmente cada termo tem um significado diferente, mas para muitos desenvolvedores JS tudo vira só ‘object’. É como se toda a resolução linguística e conceitual fosse achatada em um único “pixel”
Antigamente, desenvolvedores falavam entre si sobre terem diferentes “posturas mentais” em relação ao código. Agora, a fadiga dos desenvolvedores disparou porque ninguém mais entende o código. Antes, nessas situações, engenheiros entravam para consertar o que estava quebrado e torná-lo útil, enquanto arquitetos reduziam a complexidade. Na era dos LLMs, porém, estão despejando 100 vezes mais código, e justamente engenheiros e arquitetos foram totalmente excluídos desse fluxo. Essa é a situação que estamos sentindo na pele agora.
Se alguém inventar uma forma de testar e resolver isso (um servidor MCP de TDD, um servidor MCP de DDD, ou qualquer workflow/arquitetura), há potencial para uma startup trilionária. Precisamos desesperadamente de ferramentas que aumentem muito e escalem a eficiência de code review
Acho que precisamos definir melhor o que significa “software funcionando”. Por exemplo, UIs feitas por LLM parecem todas iguais e costumam estar sutilmente erradas ou esconder bugs. Um único teste com usuários já revela o problema. Além disso, UI generativa já parece obcecada por seguir tendências, sem conseguir criar algo realmente novo
Você já viu como grandes empresas escrevem código interno? Não é muito diferente de vibe coding. Na verdade, se você ajustar um LLM para passar em pentest, pelo menos ele tenta fazer alguma coisa. As grandes empresas simplesmente não ligam
Na verdade, todo código é legado. Então não há nada de tão especial no fato de vibe coding produzir código rápido e em grande volume. No fim, até “o código que eu mesmo escrevi” e que ninguém entende continua sendo a mesma bagunça. Todo código, do ponto de vista de manutenção, é um fardo. Bibliotecas até podem aliviar problemas, mas as que mudam o tempo todo ou têm interfaces ultrapassadas viram um legado ainda pior.
Quanto mais tempo alguém programa, mais tende a chegar à mesma conclusão: a resposta é produzir menos, ou seja, reduzir a necessidade como um todo. Toda complexidade acaba virando “um problema que meu eu do futuro não vai lembrar”. E, na prática, requisitos mudam o tempo todo, e até requisitos dados por especialistas podem estar errados (inclusive quando o “especialista” é você mesmo)
Não concordo com a ideia de que “todo código é legado”. Alguns códigos são pequenos e o desenvolvedor ainda domina tudo mentalmente, então continuam totalmente “ao vivo”. A definição prática de legado é código enorme e sem dono atual dentro da organização. Código feito por vibe coding já satisfaz essas duas condições no momento em que é gerado
Legado é quando não restam mais stakeholders, e manter ou reconstruir o contexto ficou difícil
Quero resolver problemas com a menor quantidade possível de código. A chave é fazer com que código não precise ser meu problema. A questão é o quanto a abstração “vaza”, e as abstrações que os LLMs produzem hoje são muito ruins. Não está claro o quanto isso vai melhorar.
Eu investiria em ferramentas mais divertidas, fáceis e baratas para entender código. Meu amigo Glen tem um projeto que pode servir de referência: https://glench.github.io/fuzzyset.js/ui/
Como Geoffrey Litt disse, os LLMs podem ser muito mais úteis para criar visualizações temporárias, depuradores e coisas do tipo para nos ajudar a entender nosso código
Todo código tem risco, mas nem todo código é legado. Código gerado por vibe coding dá a sensação de nascer legado porque já vem sem contexto e sem dono
Em resposta à ideia de que todo código seria legado, eu diria que, se consigo apontar a causa de um bug de imediato num projeto que conheço profundamente e consigo visualizar na cabeça como implementar uma nova funcionalidade, então aquilo não é legado
Na minha visão, a era de “olhar para código como matemática” acabou. Software grande o suficiente e conectado ao mundo real não pode ter sua verdade garantida como se fosse uma prova matemática. Sistemas reais são artefatos de engenharia que dependem de garantias formais, design baseado em experiência, testes experimentais, know-how, metas de performance e assim por diante.
Essa tendência vai se estender até aos menores scripts. A maior parte do software nem precisa ser comprovada matematicamente. Basta cumprir o objetivo. Eu reconheço plenamente o artesanato da programação, mas acho que chegou a hora de abrir mão disso.
No fim, o futuro oferece duas opções:
um programa de 100 mil linhas, com 50.000 testes garantindo todos os requisitos, mas difícil de ler por qualquer pessoa, custo total de 50 mil dólares (custos de tokens de API)
um sistema projetado por humanos com 30.000 linhas, 3.000 testes, abstrações elegantes, os mesmos requisitos atendidos, custo total de 300 mil dólares (salários de desenvolvedores)
Se eu fosse consumidor de software, sem me importar com os detalhes internos e olhando só para preço, escolheria sem pensar o que custa 6 vezes menos
É preciso pensar no momento em que surgir uma nova exigência externa e for necessário mudar o sistema. Nesses casos, se esse software for central para o negócio, você terá de trocar de fornecedor imediatamente. É por isso que manutenção e suporte são indispensáveis, seja em B2B ou B2C. Software sempre precisa ser capaz de se adaptar a mudanças
Daí vem a piada: “este código foi entendido apenas por mim e pelo Copilot; agora só o Copilot entende”
Sobre a frase “sistemas grandes o suficiente e conectados ao mundo real não podem ser provados matematicamente corretos”, quem trabalha com verificação formal talvez discorde com veemência — ou concorde em silêncio
Entre esses dois cenários, a pergunta é qual deles será mais barato e mais rápido de atualizar. Hoje eu ainda acho que o modelo com desenvolvedores humanos sai mais barato, mas não tenho certeza sobre o futuro
Na verdade, quase nunca vi nenhuma dessas duas opções no mundo real
Talvez o estágio final da evolução seja uma linguagem de programação totalmente voltada para máquinas, que nem precise ser lida por humanos. Por que um LLM precisaria converter algo para uma linguagem compreensível por pessoas como Python ou Swift? Se houver apenas um resultado executável que funcione, o próprio conceito de manutenção deixa de fazer sentido. Ainda não chegamos lá, mas acho que um dia vamos nessa direção
Bom software está sempre em manutenção. Novos requisitos surgem sem parar, então a ideia de que você entrega uma vez e acabou para sempre é piada. É por isso que código, testes e documentação pensados para mudanças futuras são importantes. Se LLMs passarem a produzir em massa código opaco e sem sentido, isso será assustador. A noção de que LLMs chegarão a um nível de codificação humana e então ninguém mais vai se importar com isso pertence ao campo da ficção científica. Codificar é apenas uma parte do processo completo de criar software realmente útil
Na prática, linguagem de máquina já não seria algo assim? LLMs são otimizados para interfaces legíveis por humanos, por isso geram JSON e quase nunca BSON
Fico me perguntando exatamente que problema isso resolveria. Os problemas que criaria, isso sim, são óbvios
Parece uma espécie de “telefone sem fio”: o LLM aprende com código feito para humanos, recebe esse código de volta e então produz o comportamento desejado. Dá até vontade de perguntar se ele não poderia simplesmente gerar a ação diretamente
Se a ideia é uma linguagem difícil para humanos lerem, Malbolge é um ótimo exemplo. O primeiro programa “Hello World” de verdade dela foi gerado por um algoritmo genético
Sou o autor original. Animado para conversar com vocês
O termo ‘vibe coding’ é uma expressão perfeita demais. É como ‘cloud computing’, que acabou se expandindo muito. Originalmente significava subir instâncias EC2 de forma elástica e descartá-las ao terminar o trabalho, mas a metáfora era intuitiva demais e até o Gmail passou a ser chamado de “nuvem”.