Insights · Dívida técnica

Custo da dívida técnica: quanto a empresa paga, e como estimar

Publicado em 13 de outubro de 2026

O custo da dívida técnica não é só o valor de consertar o código. É o que a empresa paga todo mês enquanto convive com atalhos antigos: mais horas para cada mudança, fatia do orçamento de TI que some em manutenção, risco de segurança e de conformidade, inovação que atrasa e dificuldade de contratar quem ainda domina a tecnologia. Este texto mostra onde esse custo aparece, como estimá-lo na própria empresa e quando vale pagar.

A definição completa do termo, com Ward Cunningham (1992) e o Software Engineering Institute, já está em Sistema legado: o que é, sinais de risco e quando modernizar. Aqui o foco é a conta: principal, juros e decisão.

O que é dívida técnica (em uma frase)

Dívida técnica é o trabalho extra futuro embutido em decisões de código ou de arquitetura que resolvem o problema de hoje e deixam a próxima mudança mais cara ou mais arriscada. Ward Cunningham, em 1992, comparou enviar código de primeira versão a contrair uma dívida: um pouco acelera, desde que seja paga rápido; cada minuto em código "quase certo" conta como juro (The WyCash Portfolio Management System).

Não é sinônimo de bug. Um defeito quebra o comportamento agora. A dívida técnica, muitas vezes, deixa o sistema funcionando e só encarece o que vem depois. Também não é sinônimo de idade: um sistema antigo e estável pode ter juros baixos; um monólito recente, com atalhos em cascata, pode ter juros altos.

Principal e juros: duas contas diferentes

O Consortium for Information & Software Quality (CISQ) separa a dívida em duas partes, no relatório Cost of Poor Software Quality in the US: A 2022 Report e no padrão de medida automatizada de dívida técnica:

Principal: o custo de refatorar ou alterar o software até um nível aceitável de manutenibilidade e capacidade de evoluir. É o "quanto custa consertar".
Juros: o esforço extra que o time gasta em cada mudança porque a dívida existe: manutenção maior, mais incidentes, mais recursos de computação, mais tempo para entregar o mesmo pedido. É o "quanto custa conviver".

A metáfora importa na priorização. Um módulo feio que quase ninguém altera pode ter principal alto e juros baixos: pode esperar. Um trecho confuso que aparece em quase toda entrega pode ter principal menor e juros altos: é o candidato a pagar primeiro. O CISQ estima o estoque de dívida técnica acumulada nos Estados Unidos em cerca de US$ 1,52 trilhão em 2022 (principal) e o custo da má qualidade de software no país (CPSQ) em pelo menos US$ 2,41 trilhões. São duas estimativas distintas, não uma decomposta dentro da outra. O relatório diz que ainda não há boa estimativa agregada dos juros. São números dos EUA, não o custo da sua empresa.

Onde o custo aparece na empresa

O orçamento raramente tem uma linha chamada "dívida técnica". O custo se espalha. A tabela abaixo resume onde olhar e o que registrar. É um mapa de observação, não um benchmark.

Onde o custo aparece	O que você vê no dia a dia	Como começar a medir
Tempo de desenvolvimento	Mudanças simples demoram; estimativas estouram nos mesmos módulos; retrabalho e correção de defeitos ocupam a sprint	Horas por semana (ou por sprint) em manutenção, bugs e adaptações forçadas pela estrutura atual; lead time por área do sistema
Orçamento de TI	Fatia grande do orçamento vai para "manter o que existe", e sobra menos para produto novo	Percentual do orçamento de TI e dos recursos dedicado a lidar com dívida / manutenção estrutural (compare com a pesquisa Protiviti abaixo)
Risco e segurança	Tecnologia sem suporte, vulnerabilidades conhecidas, correções que pedem mudança de arquitetura	Inventário de componentes sem suporte; incidentes ligados a partes frágeis; exigência regulatória (no Brasil, LGPD é o exemplo mais próximo)
Inovação travada	Roadmap atrasa porque cada feature nova esbarra no mesmo acoplamento	Iniciativas adiadas ou cortadas por causa do custo de mudança; tempo até a primeira entrega útil em área crítica
Contratação e conhecimento	Pouca gente no mercado para a stack; uma ou duas pessoas concentram o saber	Tempo para preencher vaga; número de pessoas que conseguem alterar com segurança cada subsistema

Essas linhas se reforçam: mais tempo em manutenção aperta o orçamento, atrasa o novo e concentra conhecimento em poucas pessoas.

O que as pesquisas mostram (ordem de grandeza)

Três fontes primárias dão escala. Parte já aparece em sistema legado: o que é; aqui entram porque esta página precisa da ordem de grandeza. Nenhuma substitui a medição na sua empresa.

Do lado dos executivos. A consultoria Protiviti, que também vende serviços de modernização, ouviu 1.050 executivos de tecnologia, a maioria em empresas com receita de US$ 1 bilhão ou mais, na Global Technology Executive Survey de 2023. Quase 70% das organizações disseram que a dívida técnica tem alto impacto na capacidade de inovar. Em média, destinavam 30% do orçamento de TI e 20% dos recursos a lidar com essa dívida. Os setores com índice mais alto foram biotecnologia e dispositivos médicos (82%), telecomunicações (81%) e serviços financeiros (78%). São respostas declaradas, de empresas grandes, e não medição.

Do lado dos desenvolvedores. O relatório The Developer Coefficient (setembro de 2018), pesquisa que a Stripe fez em parceria com a Harris Poll e que ouviu mais de mil desenvolvedores e mais de mil executivos nos Estados Unidos, Reino Unido, França, Alemanha e Singapura, traz duas perguntas separadas. Os desenvolvedores estimaram, na empresa deles, 17,3 horas de uma semana média de 41,1 com manutenção (código ruim, erros, depuração, refatoração e ajustes). Na pergunta explícita sobre dívida técnica, a média foi 13,5 horas. O 17,3 h mede manutenção, não a pergunta de dívida técnica. É estimativa declarada, não medição. A Stripe também estimou em cerca de US$ 85 bilhões por ano o custo de oportunidade global associado ao tempo em "bad code". Rótulo certo: 17,3 h é manutenção; 13,5 h é a pergunta de dívida técnica.

Do lado do estoque. Os números do CISQ acima (pelo menos US$ 2,41 tri de CPSQ nos EUA; ~US$ 1,52 tri de principal) servem para escala de mercado, não para o seu plano.

O guia de modernização de código publicado pela Anthropic, The Code Modernization Playbook, trata a dívida técnica, na visão da empresa, como uma das tendências que travam a transformação digital. É material de quem vende modelos de IA para esse trabalho: leia como diagnóstico de fornecedor, não como pesquisa. O guia usa, como regra prática, uma fatia acima de 40% do tempo em manutenção como sinal de que vale modernizar. É critério do fornecedor, não dado de pesquisa.

Como estimar na sua empresa

Você não precisa de um modelo financeiro completo para começar. Precisa de três números honestos e de uma comparação.

Escolha o escopo. Um sistema ou um conjunto de módulos que o negócio ainda usa e que muda com frequência. Deixe de fora o que quase não toca ninguém.
Estime os juros (custo de conviver). Por algumas semanas ou por um sprint, registre horas em: correção de bugs ligados à estrutura atual; tempo extra para entregar features nos módulos frágeis; incidentes e hotfixes. Some.
Estime o principal (custo de consertar) nos hotspots. Para os dois ou três trechos que mais geram juros, peça ao time uma faixa de esforço para deixar o trecho alterável com segurança (refatorar, cobrir com testes, cortar acoplamento). Faixa basta: "de X a Y pessoa-dias".
Compare juros acumulados com principal. Se os juros de alguns meses já se aproximam do principal do hotspot, a conta favorece pagar. Se o módulo quase não muda, os juros são baixos e o principal pode esperar.

Fórmula de exemplo (ilustração, não dado)

A fórmula abaixo é um exemplo didático para transformar horas em dinheiro. Os valores H, S e C são placeholders: você preenche com os números da sua empresa. Nenhum valor abaixo é medição da Ithaca nem média de mercado.

Juros estimados no período ≈ H × S × C

em que:

H = horas por semana (ou por sprint) que o time atribui à dívida no escopo escolhido;
S = número de semanas (ou de sprints) no período que você quer enxergar (por exemplo, um trimestre);
C = custo médio por hora do time envolvido (salário + encargos + overhead que a empresa já usa em outras contas de engenharia).

Exemplo numérico só para leitura da fórmula (números inventados de propósito, marcados como fictícios): se um time registrar H = 40 horas por semana atribuíveis à dívida num módulo, olhar S = 12 semanas e usar C = R$ 150 por hora, os juros ilustrativos do trimestre seriam 40 × 12 × 150 = R$ 72.000. Se, ainda no mesmo exemplo fictício, o principal daquele hotspot estiver entre R$ 80 mil e R$ 100 mil, a comparação só ilustra como juntar as duas contas; não é prognóstico nem média. Troque todos os números pelos seus. Sem o registro de horas e sem o custo-hora real, a fórmula não prova nada.

Três cuidados:

Não misture manutenção rotineira saudável com juros da dívida. Separe o que existiria mesmo num código saudável.
Prefira tendência a foto única: a mesma medição no próximo trimestre mostra se a dívida cresce ou cai.
Análise estática (índice de remediação em ferramentas de qualidade de código) ajuda no principal, mas não substitui a percepção do time nem as métricas de entrega. O CISQ formaliza a medida automatizada do esforço de correção; os juros ainda dependem do que acontece no calendário do time.

Quando vale pagar a dívida

Pagar faz sentido quando os juros são altos e recorrentes, o risco já tem data (fim de suporte, vulnerabilidade sem remendo local, dependência de uma pessoa só) ou o roadmap do negócio depende de mudar justamente a área frágil. Quando a dependência de uma pessoa só vem de uma linguagem com pouca gente no mercado, as opções estão em falta de desenvolvedor COBOL, Delphi e VB6. O que fazer quando a vulnerabilidade chega e a versão já não tem suporte está em PHP2Shell e PHP legado. Adiar faz sentido quando o módulo é estável, o principal é desproporcional ao retorno e existe um plano escrito para não deixar a dívida crescer sem dono.

Sinais práticos de que a conversa com a diretoria já deveria estar aberta:

A fatia da semana em manutenção passa de um limiar que o próprio time considera sustentável (a regra prática de 40% do guia da Anthropic é um exemplo de limiar de fornecedor, não uma norma).
O mesmo hotspot aparece em várias sprints seguidas.
Novas contratações travam porque a stack saiu do mercado.
Requisitos de segurança ou de conformidade não cabem sem mudar a arquitetura.

Trocar de servidor sem pagar o principal nos pontos de maior juro não corta os juros. A diferença entre migrar e modernizar está em lift and shift vs modernização.

Quando a decisão for modernizar de verdade, e não só apagar o incêndio do mês, o caminho é trocar por partes, com o novo ao lado do antigo. O passo a passo está em Como modernizar um sistema legado: guia passo a passo. O método da plataforma, para sistemas que não podem parar, está em Modernização de sistemas legados com IA, sem parar a operação.

A conta de juros e principal conversa com o nível de maturidade: o mapa em quatro níveis está em maturidade em modernização de legado.

O que a Ithaca faz com essa conta

A Ithaca opera uma plataforma de desenvolvimento agentic: agentes de código leem o sistema em produção, ajudam a caracterizar o comportamento atual e constroem a parte nova ao lado. Pessoas do time do cliente definem os limites, leem o que vai para produção e ficam com o registro de cada sessão (pedido, passos, modelo, custo, resultado e autoria). Isso não apaga a dívida sozinho: torna mais barato mapear o principal nos hotspots e pagar em fatias conferíveis.

Se o seu time já sente os juros e quer um primeiro corte seguro, escolha o módulo com juros altos e implante a plataforma lado a lado com o seu time: agentes de código supervisionados por engenheiros, com trilha de cada mudança.

Agendar demonstração

Perguntas frequentes

O que é o custo da dívida técnica?

É a soma do principal (quanto custa consertar) e dos juros (quanto custa conviver: tempo extra, orçamento de manutenção, risco, inovação adiada e dificuldade de contratar). O custo que mais pesa no dia a dia costuma ser o dos juros, porque se repete a cada ciclo.

Dívida técnica e manutenção são a mesma coisa?

Não. Manutenção inclui trabalho saudável de operar e evoluir o sistema. Dívida técnica é a parcela embutida em atalhos e desenhos que encarecem a próxima mudança. Na pesquisa Stripe de 2018, a pergunta de manutenção (17,3 h) e a de dívida técnica (13,5 h) são distintas. Quem cita 17,3 h como "dívida técnica" está usando o rótulo errado da pesquisa.

Como medir a dívida técnica na minha empresa?

Comece pelo escopo que mais muda, registre horas de juros por algumas semanas, estime o principal dos hotspots em faixa de esforço e compare. Ferramentas de análise estática ajudam no principal; a percepção do time e o lead time por módulo mostram os juros.

Quando vale a pena pagar a dívida técnica?

Quando os juros são altos e recorrentes, o risco tem prazo (suporte, segurança, conformidade) ou o roadmap depende daquela área. Módulo estável com pouco uso pode esperar, desde que a dívida esteja registrada e com dono.

Modernizar o legado é a única forma de pagar a dívida?

Não. Refatorar um hotspot, cobrir com testes e cortar um acoplamento já paga principal local. Modernizar por partes entra quando a dívida está espalhada na arquitetura, na stack ou na forma de entregar, e o custo de conviver já compete com o de construir o novo ao lado.

Fontes

Ward Cunningham, "The WyCash Portfolio Management System", OOPSLA 1992. http://c2.com/doc/oopsla92.html (lido em 13/10/2026).
Consortium for Information & Software Quality (CISQ), Herb Krasner, "Cost of Poor Software Quality in the US: A 2022 Report", 2022. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/ · PDF: https://www.it-cisq.org/wp-content/uploads/sites/6/2022/11/CPSQ-Report-Nov-22-2.pdf · press release 06/12/2022: https://www.it-cisq.org/press-releases/12-06-22/ (pelo menos US$ 2,41 tri de CPSQ; ~US$ 1,52 tri de principal de dívida técnica; duas estimativas distintas; principal vs juros).
CISQ, "Technical Debt Standard" (Automated Technical Debt Measure). https://www.it-cisq.org/standards/technical-debt/ (lido em 13/10/2026).
Protiviti, Global Technology Executive Survey 2023. https://www.protiviti.com/us-en/global-technology-executive-survey-tech-debt-major-burden · press release 29/03/2023: https://www.protiviti.com/gl-en/press-release-global-technology-executive-survey-results (quase 70%; 30% orçamento / 20% recursos; 82% / 81% / 78%; n = 1.050).
Stripe e Harris Poll, "The Developer Coefficient", setembro de 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf (17,3 h manutenção / 41,1 h; 13,5 h dívida técnica; ~US$ 85 bi oportunidade de "bad code").
Anthropic, "The Code Modernization Playbook" (material de fornecedor, sem data no documento; acessado em 13/10/2026). https://resources.anthropic.com/code-modernization-download (regra prática dos 40%).