← todos os posts
Manutenção 5 min de leitura

"Fazer certo do início ou fazer o lixo e arrumar depois: a pergunta de quem foi contratado pra arrumar"

"A dívida de código só cobra juros quando alguém depende do app. O que pode ser rascunho, as 4 coisas que não podem, e o caderno de dívida pra hoje."

"Agora o dificil é decidir se teria sido mais barato e melhor fazer certo do inicio ou se é mais barato e melhor fazer o lixo e dps arrumar."

Quem escreveu foi um dev brasileiro, no TabNews, contratado pra arrumar um sistema feito com IA. Eu já respondi essa pergunta uma vez aqui, no post do segundo mês: começar rápido não é o que encarece, o que encarece é não anotar nada. Continuo achando. Mas faltou dizer a parte que decide de verdade, e é ela que este post entrega.

A pergunta vem do lugar errado

Repara em quem pergunta e quando. É alguém olhando de trás pra frente, já com o sistema caindo, decidindo se o dono "devia ter feito certo". É a pergunta de quem chegou no fim.

E ela tem uma armadilha: pro dono, no começo, "fazer certo" quase sempre queria dizer "contratar dev" ou "aprender a programar antes". As duas são o conselho que manda ele embora. Quem não programa e testou a ideia com IA não fez lixo por preguiça. Fez o que dava, e na hora era a escolha certa.

A culpa, se existe, não está no rascunho. Está em ninguém ter dito quando o rascunho deixa de poder ser rascunho.

A dívida só cobra juros quando alguém depende

Programador chama isso de dívida técnica, e o nome tem dono. Ward Cunningham cunhou a ideia em 1992, num relato apresentado na OOPSLA, uma conferência de software: "entregar código de primeira viagem é como entrar em dívida." E completou que um pouco de dívida acelera o trabalho, desde que seja paga logo, e que cada minuto gasto com código não-tão-certo conta como juros.

Leia de novo pensando no seu app. Dívida não é crime. Ela vira problema por dois motivos: juros e prazo.

Antes do primeiro cliente, os juros são quase zero. Código feio que só você usa custa o seu tempo e mais nada. Se quebrar, apaga. Se ninguém usar, joga fora, e jogou fora pouco. Nessa fase, rascunho é a escolha certa, e às vezes o rascunho certo nem é app, é planilha.

Depois do primeiro cliente, os juros são de outra pessoa. O cadastro que some, o pagamento que não libera, o dado que aparece pra conta errada: quem paga é o cliente, e você paga depois, em confiança. Foi isso que o dev do fórum encontrou. Não era código feio. Era código feio com gente dentro.

Então a resposta pra pergunta é: depende de ter cliente ou não. E dá pra transformar isso numa regra que você aplica hoje.

O que mede o tamanho da dívida, e o que não mede

Um estudo publicado em 2026 por pesquisadores de universidade (Liu e colegas, no arXiv) analisou cerca de 300 mil commits, as "gravações" de mudança no código, feitos por assistentes de IA em mais de 6 mil projetos do GitHub. Dos problemas que esses commits introduziram, 89,3% eram code smells, o nome que programador dá a código que funciona mas é difícil de mexer. E 22,7% dos problemas rastreados continuavam lá na versão mais recente do projeto.

O que esse número não prova: são projetos de código aberto, a maioria tocada por programadores, avaliados por ferramenta automática. Não é o seu app, e code smell não é defeito que o cliente vê. Mas mostra uma coisa que serve pra você: "arrumar depois" não acontece sozinho nem com dev. Quase um quarto da bagunça fica. A dívida que ninguém anotou não é paga.

Faça hoje: a linha e o caderno

1. Divida o app em duas colunas. Numa folha:

Pode ser rascunho, mesmo com cliente Não pode, a partir do primeiro cliente
visual remendado ponto de retorno pra voltar a ontem
arquivo gigante login que protege, não só que aparece
código "feio" chave secreta fora do código
lentidão leve backup que você já restaurou uma vez

A coluna da esquerda pode esperar. A da direita é onde moram os juros que caem no cliente.

2. Teste a coluna da direita, item por item. Cada um tem um post com o teste: o ponto de retorno, o teste das duas contas, a busca pela chave exposta e o backup restaurado. Item que der "não" fecha a porta: ninguém de fora entra até virar "sim". Se você vai cobrar, a lista cresce, e ela está aqui.

3. Abra o caderno de dívida. É a parte do Cunningham que todo mundo esquece: pagar logo. Toda vez que você aceitar um rascunho da coluna da esquerda, uma linha:

DÍVIDA                         | POR QUE ACEITEI        | PAGAR ATÉ
tela de orçamento num arquivo  | testar a ideia rápido  | antes do 10º cliente
3 jeitos de mostrar data       | ninguém reclamou ainda | 30/11/2026

A data é o que transforma lixo em dívida. Lixo é o que ninguém sabe que está lá. Dívida tem nome, motivo e vencimento.

A pergunta certa

"Fazer certo ou fazer o lixo" é a pergunta de quem chegou no fim. A de quem está no começo é outra: o que pode ficar torto, e até quando? Ela tem resposta, e a resposta muda no dia em que entra a primeira pessoa que não é você.

Essa linha é uma parede. As outras são o que vem depois dela: pagar a dívida na ordem certa, sem quebrar o que o cliente já usa, e saber qual item da direita testar primeiro no seu caso. A ordem existe, e é o que faz o dev contratado pra arrumar nunca ser chamado.

Fontes

  • Relato do dev contratado pra arrumar um sistema feito no vibe coding, TabNews (registrado na pesquisa do blog, pesquisa/03-swipe-file-verbatim.md; é relato, não estatística)
  • Ward Cunningham, "The WyCash Portfolio Management System", relato na OOPSLA '92 (origem da metáfora da dívida técnica): https://c2.com/doc/oopsla92.html
  • Liu et al., "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild", arXiv, 2026 (v3 de 13/10/2026: 302,6 mil commits de IA em 6.299 repositórios; 89,3% dos problemas são code smells; 22,7% persistem): https://arxiv.org/abs/2603.28592