- Recentemente, surgiu no setor de TI uma nova categoria de serviço chamada "limpeza de vibe coding":
Vibe Coding Cleanup as a Service
- À medida que fica evidente a realidade de que a maior parte do código gerado por IA não é adequada para produção, surgiu um novo mercado de serviços para organizar e corrigir esse código
- Desde que Andrej Karpathy definiu "Vibe Coding" no início de 2025, 92% dos desenvolvedores usam ferramentas de IA, mas os problemas de queda na qualidade do código e vulnerabilidades de segurança ficaram claros de forma grave
- Na prática, desenvolvedores já trabalham de forma especializada para resolver inconsistências, duplicações e lógica irracional criadas pela IA, e marketplaces dedicados e serviços de consultoria estão se espalhando
- A IA é excelente em tarefas pequenas, mas por não considerar o contexto do sistema acaba produzindo dívida estrutural e problemas de segurança, o que por sua vez cria uma nova oportunidade industrial chamada de "economia da limpeza"
- Para que empresas usem IA para programação com sucesso, é preciso deixar os protótipos com a IA, mas investir em profissionais especializados nos processos de arquitetura, segurança e organização dos testes
O surgimento e a expansão do vibe coding
- No início de 2025, Andrej Karpathy usou o termo "vibe coding", e o conceito se consolidou
- Uma abordagem que gera funções inteiras por meio de conversas em linguagem natural
- Espalhou-se rapidamente com a expectativa de aumentar a produtividade em 10 vezes
- Segundo o GitHub, 92% dos desenvolvedores usam ferramentas de codificação com IA
- O Copilot gera bilhões de linhas de código por mês
- Porém, segundo análise da GitClear, o uso de código de IA apresenta uma taxa de alteração de código 41% maior
- Houve forte aumento no volume de código revertido ou reescrito em até 2 semanas
- Em um estudo de Stanford, desenvolvedores que usam assistência de IA escrevem mais código inseguro, ao mesmo tempo em que tendem a acreditar que ele é mais seguro
- Ferramentas de IA amplificam vários antipadrões, por causa de ausência de validação de entrada, uso de dependências desatualizadas e decisões de design ambíguas
A realidade da economia da limpeza
- Recentemente, surgiu discretamente no setor de TI uma nova área de serviço chamada limpeza de vibe coding
- No início parecia apenas uma piada sobre "consertar o código bagunçado feito por IA", mas agora está se consolidando como uma oportunidade real de negócio
- Segundo investigação da 404 Media, alguns desenvolvedores estão construindo carreira apenas limpando código de IA
- Trabalho de desmontar inconsistências, duplicações e lógica absurda, apelidado de "espaguete de IA"
- A Ulam Labs anuncia o Vibe Coding Cleanup como serviço principal
- Também surgiu um marketplace dedicado chamado VibeCodeFixers.com
- Em poucas semanas, mais de 300 especialistas se cadastraram e dezenas de projetos foram conectados
- Cliente típico: "startup com um protótipo que funciona pela metade depois de gastar milhares de dólares em créditos da OpenAI"
Por que o código de IA falha
- O problema não é que a IA escreva código ruim por si só, mas que ela não entende o contexto do sistema e escreve código otimizado localmente
- Como resultado, acumulam-se padrões inconsistentes, lógica duplicada e brechas de segurança, gerando dívida técnica
- Segundo pesquisa da Georgetown University, ao menos 48% do código gerado por IA contém vulnerabilidades de segurança
- Exposição de segredos, uso de bibliotecas antigas e condições de corrida sob carga, entre outros
- Mais grave ainda é o fato de que o próprio desenvolvedor muitas vezes não entende suficientemente o código gerado pela IA para identificar corretamente os problemas
- A Thoughtworks chama isso de "dívida de capacidade"
- Fenômeno em que a equipe perde a capacidade de manter o código e cai em dependência da IA
Oportunidade de mercado
- O mercado de limpeza está crescendo rapidamente, embora seja difícil medir números concretos
- A Gartner prevê que até 2028, 75% dos desenvolvedores corporativos usarão assistência de IA para código
- Espera-se que a maioria dos projetos gere necessidade de limpeza
- Mesmo que apenas parte deles precise disso, pela escala já se trata de um mercado novo bastante grande
- Também é atraente do ponto de vista econômico
- Startups criam MVPs rapidamente com IA, mas depois investem tempo e dinheiro equivalentes na organização posterior
- Ainda assim, continua sendo mais rápido que o desenvolvimento tradicional
- Especialistas em limpeza cobram US$ 200 a US$ 400 por hora
- Também estão se espalhando serviços empacotados, auditoria de código de IA e pipelines como "Vibe-to-Production"
- Segundo a Thoughtworks, em projetos com uso de IA, a taxa de refatoração caiu, as mudanças de código aumentaram ainda mais, e um processo amplo de limpeza tornou-se indispensável antes da entrada real em produção
- Muitas consultorias já começaram a contratar profissionais dedicados à limpeza ou remediação de código de IA
- Em resumo, o mercado de limpeza existe, cresce rapidamente e ainda tem muitas áreas inexploradas
Impacto na engenharia
- Está em andamento uma mudança fundamental na metodologia de desenvolvimento de software
- O processo de desenvolvimento está sendo reorganizado em um sistema de divisão de trabalho no qual a IA implementa e os humanos cuidam de arquitetura, testes e limpeza
- Gergely Orosz compara as ferramentas de IA a "um desenvolvedor júnior extremamente motivado", enfatizando que elas escrevem código rapidamente, mas sempre precisam de supervisão
- Porém, como a IA sempre permanece no nível de um desenvolvedor júnior e não evolui para sênior, o papel dos especialistas em limpeza continua sempre necessário
- Novos caminhos de carreira também estão se abrindo
- Desenvolvedores júnior que aprendem técnicas de limpeza podem alcançar salário de nível sênior em 2 anos
- Sêniores que entendem os pontos fortes e limites da IA geram alto valor
- As empresas bem-sucedidas não são as que mais usam IA, mas as que constroem processos de limpeza de forma sistemática
- Organizações que estruturam um processo sólido de limpeza podem obter vantagem competitiva no mercado
A posição da Donado Labs
- Com base em muitas experiências de limpeza de código vibe, a Donado Labs enfatiza que a IA é útil para acelerar o trabalho, mas exige obrigatoriamente um processo de limpeza conduzido por especialistas
- A IA fica com prototipagem e tarefas repetitivas; arquitetura central, segurança e testes ficam com pessoas
- Com o serviço "Vibe to Production", a empresa prepara protótipos de IA para nível corporativo
- Incluindo testes, reforço de segurança e documentação
- As empresas que usam IA para código com sucesso não são as que mais usam IA, mas as que a usam com inteligência e investem em limpeza
- O ponto-chave é fazer a limpeza em paralelo antes que a dívida técnica se acumule
- Diante da afirmação de que a IA substituirá programadores, a pergunta "quem vai limpar esse código?" é a verdadeira oportunidade de negócio
4 comentários
No começo do GPT, tinha gente que chegava para quem fazia terceirização de programação dizendo que tinha feito um protótipo com IA e que só faltava terminar um pouquinho, e aí tentava jogar o preço lá para baixo.
> Especialistas em organização cobram de 200 a 400 dólares por hora
Mas, sinceramente, será que existe alguém fazendo isso?
Antes mesmo do surgimento do vibe coding, eu já tinha pensado que seria bom se existisse um serviço que organizasse código todo bagunçado, e alguém acabou fazendo isso. Mas acho que não vai ser algo que a nossa empresa adote, aff
Terceirizar a correção dos dedos em imagens de IA estava na moda... mas agora nem isso as pessoas fazem mais.
Acho que a limpeza com IA também vai seguir esse mesmo caminho.
Comentários do Hacker News
Há bastante tempo eu pego projetos de “reestruturação” por meio do meu negócio.
Antes eu geralmente recebia código quase não funcional vindo de agências terceirizadas, mas hoje em dia parece que a origem disso está migrando para LLMs.
No fim, os mesmos problemas se repetem.
Só mudou a forma de cortar custos.
Existem razões óbvias para escolher atalhos, mas o problema de verdade aparece quando não se tem plena consciência de que isso pode sair caro.
Seja vindo de gerente, funcionário ou terceirizado, o resultado é parecido.
Ainda não anunciei separadamente um serviço de melhoria estrutural para plataformas feitas com vibe coding, mas talvez tenha chegado a hora de testar isso.
O mercado de software da Austrália é pequeno, então quase não se ouve falar dos resultados desse tipo de experimento.
Acho que a diferença entre vibe coding e desenvolvimento terceirizado está no volume de código produzido.
Uma vez usei vibe coding para fazer um script auxiliar simples, e se eu mesmo tivesse escrito teria dado algo como 1/3 do tamanho atual, e a maioria dos edge cases eu nem teria tratado (havia tratamento de exceções inútil, mas também algumas coisas realmente úteis).
O que eu fiz foi basicamente escanear o código e remover uma linha de exclusão de arquivo temporário porque ela poderia apagar meu diretório home por engano.
Mas depois, quando fui fazer um trabalho mais profundo com os dados, percebi que alguns arquivos temporários tinham sumido e que havia mais dois pontos com código de exclusão.
Na prática, é código demais para um humano ler e revisar tudo.
Ainda assim, em termos de velocidade, a eficiência é realmente enorme.
Daqui para frente, em vez de ler o código com atenção, pretendo rodar testes com IA em um sandbox.
Há uma diferença grande, especialmente em ferramentas como o Claude Code, que têm “modo de plano”.
Hoje em dia eu uso bastante o Claude Code na empresa, e sempre começo no modo de plano, perguntando em formato de conversa “como implementar isso”, e depois de algumas interações vou refinando um bom desenho com um plano detalhado.
Depois disso, a IA me diz exatamente que código pretende gerar (junto com o diff do código), e só depois da minha aprovação final ela gera o código de fato.
Em contraste, quando revisei no passado código feito por equipes terceirizadas, era um espaguete caótico impossível de entender.
Acho uma boa ideia colocar no site pelo menos termos ligados a vibe-coding, nem que seja por SEO.
Eu pensei algo parecido.
Mas quando um projeto foi vibe-coded e virou um monte de código cheio de bugs, basta eu entrar, corrigir os bugs e organizar a estrutura, e pronto?
Fico me perguntando como uma empresa que nem tinha o conhecimento especializado para configurar isso no início consegue dar continuidade à manutenção.
Acho que tanto terceirização quanto desenvolvimento baseado em LLM acabam exigindo capacidades muito parecidas.
Ou seja, continuam sendo fundamentais boas bases de engenharia, como levantar requisitos, comunicar, gerir stakeholders, definir especificações, testar e documentar.
Acho meio estranho como o conceito de "vibe coding" do Karpathy pegou desse jeito.
Imagino que isso aconteça mais entre pessoas com pouca experiência real de desenvolvimento.
Pelo que eu me lembro, vibe coding era uma espécie de estado de fluxo em que você simplesmente conversa com a IA, confia no embalo e nem confere de verdade o resultado da geração de código, quase sem olhar para o código.
É uma abordagem horrível se a qualidade do software que você está criando tiver qualquer importância.
Até dá para usar em meme de Twitter, experimento de autoindulgência ou script pequeno para uso doméstico, mas para desenvolver um produto de verdade me parece absurdo.
Isso virou assunto porque alguém famoso como o Karpathy deu um nome estiloso; se outra pessoa tivesse falado disso, teria passado batido.
Mesmo antes da IA, júniores e devs pouco experientes já codavam assim.
Copiavam e colavam coisas de algum lugar, verificavam só se rodava, e quando aparecia um bug bizarro ou um core dump, mexiam na ordem do código até o problema sumir por sorte.
Esse estilo, numa empresa, no mínimo renderia advertência, plano de melhoria de performance ou, pior, desligamento.
Muitas vezes pessoas não técnicas não conseguiam obter bons resultados na comunicação com engenheiros de software.
Vejo o surgimento do vibe coding como um reflexo do que nós vínhamos entregando em software até aqui.
Na prática, o software das startups vibe-coded que eu conheço é péssimo, mas se fizer o que elas querem, a qualidade não importa nesta fase.
Até que a qualidade de software cause um “impacto real” no negócio, elas não vão querer correr o risco de contratar desenvolvedores e ver suas ideias distorcidas.
No fim, mesmo sendo algo lixo, conseguir usar agora o que elas querem é uma opção melhor do que um software perfeito que não corresponde ao que elas queriam.
Gostando ou não, vibe coding não vai desaparecer.
Eu também não concordo muito com o conceito, mas às vezes digo a colegas dentro da organização: “fiz isso em vibe coded”.
Para nós, significa algo como “a maior parte do código foi gerada automaticamente por IA”.
Mas eu jamais colocaria em produção um código desses sem revisão.
É mais no sentido de “montei um app legal rapidinho com vibe coding”, usado de forma leve e experimental.
Acho que o Karpathy quis dizer que vibe coding era um “experimento possível” que valia a pena tentar, para ver até onde dava para chegar e se divertir com isso.
Não acho que ele estivesse recomendando que empresas construíssem produtos reais só com vibe coding.
As pessoas interpretaram a expressão fora de contexto, do jeito que quiseram.
Na verdade, o próprio Karpathy explicou em vídeo no YouTube o que ele quis dizer.
Artigo relacionado
YouTube do Karpathy: Software Is Changing (Again)
Acho que o mal-entendido cresceu porque as pessoas querem acreditar que agora conseguirão fazer coisas difíceis com facilidade.
Eu ainda acho que o tweet original era só uma brincadeira, uma forma de expressar a liberdade de um “YOLO coding”, e não uma recomendação real de processo para uso profissional.
Foi só uma maneira bem-humorada de descrever a sensação de libertação que ele sentiu naquele momento.
Neste momento, vibe coding está sendo usado praticamente como um termo para menosprezar ou zombar de qualquer tipo de assistência de IA para programar.
Qualquer ferramenta pode ser bem ou mal usada, mas hoje em dia o meme de “como vibe coding é idiota” ganha adesão rapidinho online.
Já está ficando cansativo.
O ponto central do artigo é a tese de que “se uma startup consegue encurtar em várias semanas a criação de um MVP graças ao vibe coding e, mesmo que depois acabe gastando tempo e dinheiro parecidos para limpar tudo, ainda assim continua mais rápida do que no desenvolvimento tradicional”.
Queria saber se isso é mesmo verdade.
Pelo que vi, se um desenvolvedor fizer ele mesmo com ajuda de IA, a diferença de velocidade talvez nem seja tão grande.
Especialmente se você já souber que esse MVP ou protótipo vai acabar indo para produção, parece melhor definir direito a arquitetura desde o começo no longo prazo.
Mas a maior parte do pessoal de produto e da gestão vê esse tempo como desperdício.
A verdadeira vantagem do vibe coding é que o time de produto pode construir diretamente o que quer, sem ter que explicar para desenvolvedores.
Talvez haja mercado para ferramentas de produto baseadas em vibe coding que sirvam mais para esclarecer especificações e protótipos do que para criar o código em si.
Essas ferramentas poderiam dar especificações melhores aos desenvolvedores e, ao mesmo tempo, mais contribuição e protagonismo para o lado do negócio.
Em startups, time-to-market é tão importante que, mesmo que no total o tempo e o custo sejam maiores, assumir dívida técnica pode ser uma decisão perfeitamente racional só porque o lançamento acontece mais rápido.
É por isso que as pessoas acumulam dívida técnica.
O Twitter também começou como um web app em Ruby on Rails, e sempre que o Justin Bieber tuitava os servidores caíam e aparecia a fail whale.
Mas, conforme cresceu, acabou contratando especialistas e refez tudo direito em uma estrutura mais robusta e escalável.
Talvez sirva mais para algo no nível de protótipo do que de MVP,
mas se a organização não tiver disciplina institucional e individual para não colocar protótipo em prod, acho melhor evitar vibe coding.
Todo mundo sabe como é difícil convencer a diretoria de que “esse código bonito que estamos usando agora por dentro é um desastre e precisa ser refeito do zero”.
Nesses casos, ferramentas no-code são bem mais seguras.
A realidade é que a maioria dos MVPs e protótipos acaba indo para produção muito rápido.
Lembro de alguém dizer que “se o código do MVP não estiver dolorosamente sujo, você provavelmente está gastando tempo demais com qualidade de código”.
No fim, esses códigos paliativos viram a espinha dorsal da empresa.
Até daria para chamar um serviço focado só nessa reestruturação de "C-Suite cleanup as a Service", mas se anunciasse assim acho que ninguém contrataria.
Assim que li o texto, senti claramente que ele tinha sido escrito pelo Claude, mesmo sem travessões longos.
É claro que o autor original deve ter fornecido os próprios pensamentos e materiais no prompt, mas havia expressões e nuances de frase muito típicas de LLM, então a leitura pareceu meio forçada.
Fico pensando se esse estilo vai acabar ficando datado no futuro como uma “prosa de LLM”.
Acho que agora a próxima onda vai ser vibe-writing cleanup as a service.
Eu já uso em-dash há muito tempo, mas acho que chegou a época em que vou ter que me policiar para reduzir isso.
O Microsoft Word troca hífen por em-dash automaticamente.
Acho que vibe coding é parecido com fazer encanamento DIY.
Você tenta sozinho e, quando o banheiro estoura, acaba chamando um encanador de emergência e pagando caro.
Nesse processo, da próxima vez você aprende um pouco mais.
Dá para ver por esse lado, mas encanadores profissionais também usam bem ferramentas que ajudam no DIY.
A diferença é que os especialistas sabem bem quando usar e até onde ir.
Na verdade, me parece ainda pior.
No trabalho de encanador, você vê com os próprios olhos o que está fazendo, mas no vibe code um dia de repente algo para de funcionar e você nem sabe por quê.
No YouTube também dá para ver muito encanador DIY sendo até mais caprichoso que profissional.
Acho que depende se o vibe coder realmente vai aprender com esse tipo de experiência.
Só o tempo dirá.
Sinto que essa analogia é realmente apropriada.
Assim como um corretor de imóveis pressionado faz um trabalho de encanador às pressas para vender uma casa, um fundador de startup também corre para demonstrar qualquer coisa, atrair atenção de investidor e cliente, e depois chama especialistas de verdade para limpar tudo.
Com sorte, dá até para evitar um desastre grande antes disso.
Fiquei surpreso por já existir na indústria o termo Janitor Engineer.
Além disso, os links do artigo depois de "Why AI code fails at scale" estavam todos quebrados, o que é ainda mais estranho por ser um texto recente.
Espero que ninguém leve isso a mal.
Desde que vibe coding virou moda, eu mesmo venho mantendo como um plano de aposentadoria meio de brincadeira virar um consultor de “all-organic-code” e sair desembolando e organizando blocos de código gerados por IA.
O raro de verdade é projeto greenfield.
Vibe coding está corroendo rapidamente a documentação e a clareza arquitetural.
As empresas tratam apenas a quantidade de tokens de código gerados e a velocidade do protótipo como métricas importantes, ignorando os custos ocultos de manutenção e limpeza.
Agora a habilidade real não é gerar, e sim limpar.
Habilidade de verdade é orientar bem desde o começo para extrair software correto.
Tem gente que olha para Claude Code e pensa “isso é o estado da arte”, mas para fazer direito é preciso um envolvimento muito maior.
Na prática, não é tão diferente da engenharia tradicional.
O essencial é minimizar custo e atender aos requisitos.
Se você não exigir explicitamente manutenibilidade, então o resultado obtido é exatamente o que foi pedido.
Fico me perguntando por que isso significaria a morte da documentação.
Também existe a abordagem de escrever primeiro só a documentação e depois desenvolver verificando se o código está de acordo com ela.
Ou então gerar documentação a partir do código e revisar manualmente se ela está adequada.
Nossa empresa faz recuperação emergencial para sistemas críticos de clientes há décadas (pane etc. causando perdas financeiras severas → impossível resolver internamente).
Nos últimos anos, esse tipo de caso vem aumentando de forma bem rápida.
Vibe code se parece com código legado em vários aspectos.
As pessoas evitam mexer porque não confiam no código, e tanto a qualidade interna quanto a externa são baixas.
Mas também há diferenças.
Há pouco código em relação à idade, muita pressão de prazo e expectativas infladas.
O mais custo-efetivo é empurrar o máximo possível dos erros para antes do runtime, ou seja, para a fase de design ou de compilação.
O problema é que, com a IA, todo mundo está correndo rápido demais até o runtime.
A propósito, vale a leitura de “Vibe code is legacy code (val.town)”.
Post relacionado no HN
Código legado nem sempre é ruim.
Em geral, ele só é complexo, pouco documentado, e acumulou muitos patches operacionais grandes e pequenos ao longo do tempo.
Muitos problemas de operação (como novas exigências) já foram incorporados e ele pode até funcionar muito bem em serviço real.
O problema é quando desaparecem as pessoas que conhecem a base de código, ou até mesmo quem domina a linguagem ou as ferramentas usadas na época.
Fico curioso se vibe coding também funciona em linguagens fortemente tipadas.
Concordo com a ideia de tratar código feito no vibe como código legado.
Mas queria saber se as pessoas realmente também relutam tanto em mudar vibe code.
Tenho pensado que talvez a geração de código por LLM possa desaparecer no futuro.
O artigo sempre parte do pressuposto de que código de LLM será gerado e sempre precisará de limpeza, mas se o custo do LLM + o custo da limpeza for sempre maior que o salário de um desenvolvedor, talvez no fim a gente tenha de voltar ao código escrito diretamente por humanos.
Gerar código com LLM, revisar e então usar não é a mesma coisa que vibe coding.
Vibe coding é quando o código pronto é usado sem checagem.
Os dois modelos provavelmente não vão desaparecer.
Hoje, o vibe coding baseado em IA está aos poucos saindo de moda.
Porque em breve virá uma IA ainda melhor.
Se a pessoa passar o dia inteiro só fazendo vibe coding, isso pode acabar se tornando um modelo economicamente insustentável.
Talvez toda a empolgação tenha vindo de uma ilusão criada por suporte e assistência em excesso, e depois venha o choque de realidade e a dor.
A tendência de usar todos os exemplos de código para criar ferramentas de assistência com autocomplete preditivo e geração automática certamente não vai desaparecer.
Do mesmo jeito que antigamente se programava sem syntax highlighting, mas hoje ninguém faz isso de propósito.
Digitar DFS do zero pela 80ª vez não aumenta minha autoestima como programador.