O que é dívida técnica
É a diferença entre o que existe e o que seria preciso para manter aquilo. Copiar e colar em vez de fazer uma função, não escrever o teste, deixar a versão velha de uma dependência, o nome que já não diz o que faz. Cada atalho se paga depois, em horas de quem vem atrás.
Nem toda dívida é ruim. A que se assume de propósito e se anota se devolve; a que ninguém anotou se descobre no dia em que algo quebra e ninguém sabe por quê.
Tipos de dívida técnica
A classificação mais citada é a de Martin Fowler, que cruza duas perguntas: se a dívida foi assumida de propósito ou sem perceber, e se foi prudente ou imprudente. A deliberada e prudente é um atalho anotado para ser pago; a inadvertida e imprudente é a que aparece quando ninguém sabia que havia outro jeito de fazer.
Pelo lugar onde vive, aparece no código (duplicação, funções enormes), na arquitetura (partes que dependem demais umas das outras), nos testes que faltam, nas dependências antigas, na documentação e na infraestrutura, como o servidor que ninguém sabe montar de novo.
Exemplos de dívida técnica
A mesma regra de negócio copiada em três lugares, alterada em dois e esquecida no terceiro. Uma biblioteca com uma vulnerabilidade conhecida que não é atualizada porque quebra algo. Uma consulta que vai bem com mil linhas e demora segundos com um milhão. Uma senha escrita no código porque era só um teste.
E a mais cara, a que não se vê: um processo que falha sem avisar e deixa dados pela metade. Ela se reduz como qualquer dívida: primeiro se mede, depois se paga o que gera mais juros, e se para de assumir dívida nova sem anotá-la.
Por que cresce mais rápido com IA
A IA escreve muito código em pouco tempo, e esse código chega sem o contexto de por que está assim. Duplica-se o que já existia, repetem-se padrões diferentes para a mesma coisa e entram dependências que ninguém escolheu. Em laboratório, 45% do código gerado por IA trazia vulnerabilidades conhecidas quando não recebia instruções de segurança.
O efeito não aparece na primeira semana: aparece quando é preciso mudar algo e cada mudança toca cinco lugares.
Como se mede e por onde começar
Mede-se com o código na frente: duplicação, dependências desatualizadas e com vulnerabilidades conhecidas, testes que não existem, rotas sem proteção, consultas que não aguentam o volume real e pontos onde o sistema falha sem avisar. Cada um com a sua evidência, não com uma opinião.
E se ordena pelo que custa se quebrar, não pelo que incomoda na leitura. Entregamos essa lista e a ordem; a reparação é um segundo nível: sua equipe a aplica, ou nós a fazemos se você nos contratar para isso.