Vibe Coding Cleanup: o que quebra depois da demo

A demo funcionou

Alguém construiu um CRM no Lovable em dois fins de semana. Outra pessoa ligou catorze workflows do n8n ao longo de um ano, um por semana. Um diretor de vendas abriu o Claude Code num domingo à noite e na segunda havia um app que a equipe inteira usa para agendar entregas. Cada um deles funcionou no dia em que foi mostrado, e cada um é agora algo do qual o negócio depende.

O código que as ferramentas escrevem é, na maior parte, bom, e onde não é, é bom do jeito que o código de um desenvolvedor júnior é bom: faz o que pediram e não sabe o que acontece em volta. As falhas que chegam seis semanas depois quase nunca estão na função que foi demonstrada. Estão no que ninguém pediu para escrever.

O que quebra de verdade

Seis coisas, na ordem em que uma leitura as encontra.

Os segredos estão no código. A chave de serviço do Supabase está no bundle do cliente porque foi ali que o prompt a colocou. A chave da OpenAI está num arquivo que entrou no repositório no primeiro dia e nunca mais foi mexido. Qualquer pessoa que abra as ferramentas de desenvolvedor do navegador tem o banco de dados; qualquer pessoa que leia o repositório tem a conta.

O deploy só funciona num único notebook. Roda onde foi construído, com as variáveis de ambiente que foram definidas ali uma vez e nunca anotadas. Na primeira vez em que outra pessoa precisa fazer o deploy, geralmente na semana em que o autor está de férias, ninguém consegue.

O banco de dados não tem caminho de volta. Os backups ou não existem ou nunca foram restaurados, e não há migrações, então o esquema é o que a última edição no painel deixou. A primeira restauração acontece no dia em que importa, que é o pior dia para descobrir que não funciona.

Ninguém está olhando. Os logs ou não existem ou vão para um console que ninguém abre, e a autenticação falhando, a fila acumulando ou o webhook devolvendo um formato novo não alertam ninguém. O sistema falha do jeito que uma integração muda por baixo de você: em silêncio, com dados errados, por semanas.

O chão se move. Cada chave de API, cada formato de webhook e cada versão de modelo de que o sistema depende vai mudar sem avisar. O modelo para o qual ele foi ajustado ganha data de desativação, um provedor adiciona uma camada ao formato da resposta, e a ferramenta que o autor usava é comprada junto com o plano gratuito. Cada uma dessas coisas é uma mudança que algum provedor lançou sem avisar você, porque você nunca esteve na lista dele, e nenhuma delas vai aparecer como uma queda.

O runbook é uma pessoa. A única documentação é a memória de quem construiu, e construiu num fim de semana, o que significa que também não lembra. Pergunte como faz deploy e a resposta honesta é que tentaria coisas até funcionar.

Por que "cleanup" é a unidade errada

O mercado já deu nome a esse trabalho. Busque por vibe coding cleanup e a primeira página é de empresas de outsourcing oferecendo exatamente isso, uma refatoração de qualquer repositório que você mandar, com orçamento anexo. Uma discussão no Hacker News chamou de cleanup as a service. As empresas acertam o trabalho e erram a compra.

Uma limpeza é um projeto. Tem começo, escopo e fatura, e depois termina, e o sistema volta a ser seu. Na sexta-feira seguinte ele quebra, quem limpou está em outro contrato, e você está exatamente onde estava, com um repositório mais arrumado. O negócio precisava de alguém cujo trabalho fosse o sistema, e um repositório mais arrumado não é isso.

Isso muda a compra de "quanto custa consertar isto" para "o que seria preciso para alguém ser responsável por isto", que é uma pergunta sobre a infraestrutura em volta e não sobre o código. É a mesma pergunta que uma empresa respondia com um administrador de sistemas, quando as coisas de que dependia eram servidores e um pacote de contabilidade. As coisas de que depende agora são um CRM no Lovable, uma dúzia de workflows e um agente, e a pergunta não mudou.

A leitura vem antes do reparo

Um vendedor de limpeza incentiva a começar a consertar. A ordem que funciona é ler primeiro, e ler com uma lista fixa.

• Onde ficam os segredos?
• O deploy funciona em algum lugar além do notebook?
• Existe backup, e alguém já restaurou a partir dele?
• Alguma coisa gera log, e alguém é alertado?
• De quais APIs e versões de modelo o sistema depende, e quando mudam?
• Existe um caminho de volta que não passe por quem construiu?

Essa leitura leva cerca de uma semana para um parque típico, e termina em uma de três frases. O sistema pode ser operado como está, e alguém o assume. O sistema pode ser operado depois de um reparo definido, com o escopo escrito e orçado, e nada fora desse escopo. Ou os reparos reconstruiriam a arquitetura em vez de completar o que falta em volta dela, substituir sai mais barato do que reparar, e o relatório diz isso antes que alguém gaste um mês descobrindo.

A terceira resposta é a que uma limpeza nunca dá, porque uma limpeza é paga para limpar. Um agente que decide sozinho sobre reembolsos, sem um limite claro a partir do qual uma pessoa decide, precisa de um projeto diferente, não de um repositório mais arrumado, pelas razões pelas quais o último chatbot falhou, e saber isso na primeira semana é a coisa mais barata desta página.

Quanto custa torná-lo o trabalho de alguém

São três coisas, em sequência, e só a primeira é certa.

A primeira é uma semana de leitura, com preço a partir de um mínimo porque um único app no Vercel leva um dia e um CRM com oito workflows e dois bancos de dados leva a semana inteira. A segunda é o reparo, e só onde a leitura pediu um: deploy, migrações, backups, segredos, logs, as brechas óbvias, o que precisa se sustentar antes de alguém entrar de plantão. Esse sprint não acrescenta funcionalidades, porque um reparo que ganha funcionalidades deixa de ser reparo. A terceira é um mês que continua sendo um mês: monitoramento, verificação de backups, uma janela de resposta, atualizações quando o chão se move e um relatório que dá para ler. Funcionalidade nova é escopada e orçada à parte, para que o mês continue previsível.

A comparação que vale a pena fazer é com o custo daquela sexta à noite, multiplicado pelo número de sextas que um negócio tem antes de quem construiu ir embora, e não com o orçamento da limpeza; a mesma aritmética já está embutida em a linha de manutenção de qualquer orçamento de automação. Na comparação de fornecedores deste site essa linha está na coluna "inteiramente seu, incluindo a manutenção que ninguém agendou", escrita sobre Zapier e Make antes de alguém ter feito um CRM com vibe coding. Continua verdade.

O parque vai crescer

Há um ano a expressão não registrava volume de busca. Em setembro de 2026 são cento e dez mil buscas por mês nos Estados Unidos e trinta e três mil no Brasil, e uma empresa que tinha três sistemas de TI está a caminho de ter um CRM, oito ferramentas internas, catorze workflows, três agentes, dois bancos de dados e um projeto no Vercel que o diretor de vendas escreveu num domingo à noite. Não há como discutir com isso: é software mais barato, construído pelas pessoas que conhecem o processo, e vai continuar chegando.

O que ele precisa é de um jeito de as coisas que eles constroem virarem o trabalho de alguém, e é para isso que serve assumir um sistema: a leitura, o reparo onde um é pedido, e depois o mês em que alguém entende como foi construído, vê quando quebra e sabe levantá-lo de novo.