- A manutenção determina a produtividade de longo prazo mais do que a velocidade de escrever código novo
- No modelo de exemplo, depois de dois anos e meio a manutenção passa de metade do tempo total
- Se agentes de IA aumentarem ao mesmo tempo a produção e o custo de manutenção, o efeito desaparece rapidamente
- Mesmo que o agente seja descontinuado, o custo adicional de manutenção do código já criado continua existindo
- Se a produção dobrar, o custo de manutenção por código também precisa cair para metade
O custo de manutenção determina a produtividade
- Todo tempo gasto escrevendo código continua gerando tempo de manutenção depois, como correção de bugs, limpeza e upgrades de dependências
- O foco não é em novos recursos ou melhorias, mas apenas na manutenção recorrente anual enquanto o código existir
- A estimativa de exemplo assume que, para cada 1 mês escrevendo código, são necessários 10 dias de manutenção no primeiro ano e depois 5 dias por ano
- A ideia é que, perguntando a cerca de 50 desenvolvedores sobre custos de manutenção no estilo Wisdom of the Crowd, seria possível obter uma resposta razoavelmente precisa
- Segundo a planilha do modelo criada com essa hipótese, no início de um novo projeto a maior parte do tempo vai para desenvolver funcionalidades, mas com o passar do tempo a manutenção do código antigo ocupa uma fatia cada vez maior
- Nessa estimativa, depois de dois anos e meio o tempo gasto com manutenção passa de metade do total, e depois de 10 anos chega perto de um ponto em que fica difícil fazer quase qualquer outra coisa
- Se a estimativa de manutenção cair pela metade, dá para ganhar mais 3 anos até o ponto de 50%; se dobrar, a produtividade cai abaixo de 50% em menos de 1 ano
- Se o objetivo é ter uma equipe produtiva, o foco deve estar mais no custo de manutenção do que na velocidade de escrever código novo
O modelo pode estar errado, mas a direção faz sentido
- Em startups em estágio mais avançado, apareceu o problema de times que, após 5 a 9 anos, já não conseguiam mais concluir o trabalho direito, algo parecido com o padrão mostrado no gráfico
- O motivo de equipes reais não parecerem tão ruins quanto o gráfico pode ser um custo de manutenção menor, ou o fato de o problema ter sido mascarado de outras formas
- Possíveis respostas incluem não corrigir todos os bugs, não atualizar todas as dependências, adicionar pessoas quando o time desacelera e continuar adicionando mais, ou abandonar tudo e reescrever
- Os números exatos podem ser discutidos, mas a tendência geral de perda de produtividade ao longo do tempo parece bater com a experiência prática
O efeito multiplicador criado por agentes de IA para programação
- Como exemplo, assume-se que o framework moderno de coding agent Rock Lobster dobra a produção de código
- Ao mesmo tempo, assume-se que o código fica um pouco mais difícil de entender, que o time fica soterrado por pull requests e que ninguém lê o código com o devido cuidado antes da aprovação
- Se em um mês forem produzidos dois meses de código, e o custo de manutenção desse resultado também dobrar, o custo de manutenção do mês seguinte fica 4 vezes maior
- Nesse exemplo extremo, após usar o Rock Lobster por cerca de 5 meses, a produtividade volta ao nível original, e alguns meses depois fica pior do que se ele nunca tivesse sido usado
- Isso não significa que a IA realmente dobre a produtividade ou o custo de manutenção; o ponto é destacar que, mesmo que a manutenção do código seja igual à de código escrito por humanos, o ganho de produtividade não dura muito
Mesmo interrompendo o agente, o custo de manutenção permanece
- Agentes de programação custam dinheiro e, se sua utilidade ficar menor do que seu custo, pode surgir a tentação de voltar ao método anterior
- Ao parar de usar o agente, o ganho de produtividade desaparece, mas o custo adicional de manutenção do código criado por ele continua existindo enquanto esse código permanecer
- Nesse caso, é possível ficar preso a uma produtividade menor do que se o agente nunca tivesse sido usado
A matemática só fecha com redução do custo de manutenção
- O custo de manutenção precisa cair exatamente na razão inversa do quanto o LLM aumenta a produção de código para que a conta geral de produtividade funcione
- Se a produção dobrar e o custo de manutenção desse resultado também dobrar, o custo total de manutenção fica 4 vezes maior
- Se a produção dobrar, mas o custo de manutenção por unidade produzida continuar igual, o custo total de manutenção ainda assim fica 2 vezes maior
- Se a produção dobrar, o custo de manutenção precisa cair pela metade; se a produção triplicar, o custo de manutenção precisa cair para um terço
- Só cumprindo essa condição é possível obter ganho de velocidade sem criar dependência prejudicial no longo prazo
Preocupações atuais com coding agents e outras possíveis alavancas
- Em fontes como o Hacker News, parecem existir muitos sinais de que agentes de programação aumentam os custos de manutenção
- Alguns dizem que eles ajudam a entender sistemas grandes, mas não parece haver a redução substancial de custo de manutenção necessária; na visão apresentada, o efeito parece ser mais o contrário
- O modelo não representa perfeitamente a realidade, mas a mensagem de que a IA precisa reduzir os custos de manutenção na mesma proporção em que acelera a escrita de código continua válida
- Mesmo buscando melhorar a velocidade de programação, é preciso dedicar a mesma atenção à melhoria dos custos de manutenção
- Não se trata de uma posição anti-IA: também existem outras alavancas possíveis, como IA que torne o próprio trabalho de manutenção mais produtivo, mesmo sem melhorar a manutenibilidade do código em si
- Para adaptar as hipóteses à sua situação real, é possível copiar a planilha e ajustar as várias variáveis do modelo
1 comentários
Comentários do Hacker News
Na apresentação da Dconf'24 Software as investment, foi proposto um framework básico baseado em funções de valor combináveis para cada parte do software
Esse framework em si não precisa mudar especificamente por causa da IA, e, separadamente, basta atualizar o modelo de custos conforme o quanto a IA for boa em manutenção
Dizem que a IA introduz 1,7x mais bugs, mas talvez também consiga corrigi-los mais rápido, então não sei ao certo
Se enxergarmos software como investimento, passamos a falar de “valor” em vez de “dívida técnica”, e dívida é apenas um ativo com valor menor que 0
Se o software sair do antigo mundo de margens altas, será preciso definir com precisão o que é um software que vale economicamente a pena existir
Em software sempre há partes que poderiam ter sido escritas melhor, e isso é a dívida
É uma perspectiva perspicaz, e concordo
Infelizmente, manutenibilidade costuma cair na cesta dos “requisitos não funcionais”
Mas requisitos não funcionais como manutenibilidade deveriam ser vistos como algo que preserva e viabiliza a entrega de requisitos funcionais futuros
Não deveriam ser enquadrados apenas como o “como fazer” em contraste com o que o software deve fazer
Se for um projeto em que adicionar e melhorar funcionalidades continuamente é importante, então, exceto por períodos muito curtos, manutenibilidade é praticamente um requisito funcional
No momento em que você cria um nome separado, dá justificativa para alguém que não entende bem isolar aquilo e reduzir sua prioridade
Qualidade importa e, se não for mantida, atinge o demonstrativo de resultados de forma muito rápida e forte
Por isso é tão importante quanto qualquer outro fator
Dá para usar as expressões de Kevlin Henney: características operacionais e características de desenvolvimento
Manutenibilidade é uma característica de desenvolvimento fundamental
Até pode haver um roadmap de produto de 1 a 2 anos, mas, falando francamente, esses roadmaps muitas vezes servem mais para vendas do que para planejamento de engenharia
Quando a receita cai, produto e engenharia mudam de direção, e isso acontece com mais frequência quanto mais cedo a empresa estiver em sua trajetória
Ao sair do modo startup, isso deveria se estabilizar, mas muitas empresas não fazem isso e continuam repetindo o padrão de planejamento de curto prazo
Como resultado, a estabilidade do produto continua sendo uma prioridade baixa
No fim, parece que muitas empresas não têm recursos para construir bom software, ou simplesmente não se importam de verdade
Pelo que vimos ao construir nosso projeto, a IA é rápida, mas os bugs que ela introduz são estranhamente difíceis de encontrar
Não são bugs óbvios; é aquela lógica em que algo quebra em produção três semanas depois e, ao investigar, você descobre que a IA entendeu errado uma nuance
Sinceramente, a IA não reduz tanto o custo de manutenção quanto muda o custo de lugar
O tempo de escrita diminui e o tempo de revisão aumenta
Código de IA, mesmo quando está errado, é fluente e confiante, então é mais difícil de revisar do que código humano
Se isso gera ganho líquido depende inteiramente de quão boa a equipe é em ler código, mais do que em escrevê-lo
Pela minha experiência, a IA reduz o custo de manutenção
Mas o contexto pode ser importante. Eu lido com vários projetos com décadas de existência, e, além de muito desenvolvimento de novas funcionalidades, código e projetos antigos de repente ficaram muito mais fáceis de lidar, modernizar e, em vários casos, até remover
Dependências de bibliotecas antigas e ferramentas de build, em alguns casos, foram atualizadas; em outros, simplesmente removidas, e os builds ficaram mais rápidos e mais fáceis para os desenvolvedores
Configurar e automatizar testes end-to-end também ficou muito mais fácil, DevOps melhorou bastante, e o diagnóstico de problemas operacionais avançou muito
Há muitos logs e informações, além de dashboards integrados e monitoramento para captar o que importa, mas agora consigo fazer muito mais análises em cerca de 50 projetos de sistemas implantados
O argumento central do texto é sobre quantas horas de manutenção são necessárias para cada hora de desenvolvimento de funcionalidades que “agregam valor”
Então, primeiro, não dá para medir só o custo de manutenção, tem que olhar a proporção; e, segundo, esse código antigo nem foi escrito por IA para começo de conversa
Mas acho que o ponto do autor é que, se você perder acesso às ferramentas de IA, tudo volta a parecer muito mais difícil
É como mover montanhas com maquinário pesado e depois ter que voltar às ferramentas manuais
As falhas aumentaram junto com a quantidade de linhas de código implantadas, e os incidentes estão ficando cada vez mais graves
Claro, melhoramos muito código antigo, apagamos ainda mais código, conseguimos automatizar modernização de código, diagnosticar problemas melhor e temos mais opções de mitigação
Mas nada disso compensou a escala esmagadora de código sendo colocado em produção sem que ninguém o entendesse direito
Nossa equipe usa IA para adicionar código, mas também para remover agressivamente código velho e obsoleto
Perguntas como “alguém ainda usa isso?” e “como isso é chamado?” ficam fáceis de responder quando você joga frontend, backend e o codebase inteiro em um agente para ele montar um mapa do projeto de software
IDEs conseguem ajudar até certo ponto dentro de uma única linguagem e geralmente de um único projeto, mas fronteiras como RPC ou REST quebram muitas ferramentas de IDE
Gosto muito desta pergunta: que codebase você gostaria de ter, se pudesse escolher?
Pensando por um instante, provavelmente você não desejaria um codebase com um monte de funcionalidades
Você acabaria querendo uma base de código bem parecida com a atual, mas fácil de entender e de manter e expandir de acordo com os desafios futuros do negócio
Um codebase “em funcionamento”, isto é, um codebase mantido, está resolvendo problemas do mundo real, e resolver esses problemas sempre deve vir antes de limpeza
Um codebase limpo muitas vezes é só um exemplo de vitrine para deixar na prateleira e admirar
Quero acrescentar duas coisas
Primeiro, software não tem apenas manutenção técnica, mas também suporte ao usuário, e isso também cresce conforme o software cresce
Segundo, não tenho certeza de que o custo de manutenção aumente de forma linear
Mesmo que aumente linearmente, chega uma hora em que você acaba gastando todo o seu tempo só com manutenção
Pode ser, se você tiver que manter não apenas cada parte, mas também a forma como as partes interagem entre si
O sinal mais forte que já vi sobre se a IA realmente reduz custos de manutenção é se o desenvolvedor trata a saída da IA como rascunho ou como artefato final
Quando uso ferramentas de IA em um codebase existente — por exemplo, para entender um módulo desconhecido, gerar refatorações pontuais ou escrever scripts de migração — a carga de manutenção realmente diminui
Isso porque a IA está trabalhando sobre código cuja arquitetura eu já entendo, então consigo avaliar a saída rapidamente
O problema aparece quando a IA gera código novo que ninguém entende em profundidade
Esse código acaba sendo mantido por alguém que nem o escreveu nem o projetou
Se fosse código escrito por outra pessoa, pelo menos ainda daria para inferir a intenção a partir dos nomes, da estrutura e do histórico de commits
Código gerado por IA muitas vezes carece dessa intenção legível, porque o “autor” não mantém uma intenção contínua ao longo do arquivo
O texto acerta ao dizer que devemos medir não só velocidade, mas também custo de manutenção
Na prática, isso significa acompanhar, ao longo de meses e não de dias, o tempo necessário para entender código assistido por IA versus código escrito por humanos, além da taxa de falhas em mudanças
O mesmo vale para code review
Fico curioso se a IA poderia tornar code reviews mais agradáveis de ver
Em code reviews humanos, os desenvolvedores aprendem rápido a evitar mudanças visuais desnecessárias, como reformatar código ou comentários, mexer em indentação que a ferramenta não consegue ocultar, mover funções ou apagar linhas
Também não deveriam fazer refatorações desnecessárias
Talvez desse para separar a revisão em duas partes: mudanças funcionais e mudanças visuais
Isso torna a revisão muito mais fácil
A revisão começa do princípio de que “nada deve ter mudado”, e o revisor pode fazer correspondência de padrões
Caso contrário, o revisor precisa reavaliar cada linha de código para verificar se nada mudou, e isso é realmente difícil de fazer direito
Os sistemas de controle de versão que usei permitiam filas de mudanças revisadas de forma independente
Se fosse preciso refatorar durante o desenvolvimento, você subia um commit para a refatoração, enviava para revisão e depois fazia rebase do trabalho em andamento para continuar
Se você continuar soltando mudanças como “CLEANUP:” e “REFACTOR_ONLY:”, a mudança final fica muito menor do que uma alteração monstruosa
Os revisores vão agradecer esse esforço
Em uma organização assim, dá até para fazer jogos de métricas sem que isso se torne perverso
O autor parece partir da premissa de que humanos devem revisar todo código de IA em detalhe e ser capazes de entendê-lo e mantê-lo sem ajuda da IA
Pela minha experiência, não é assim que as pessoas usam IA
No começo, até é. Antes de confiarem nela e antes de aprenderem a escrever prompts para obter o que querem, as pessoas a usam para automatizar partes tediosas, enquanto a implementação inicial ou os padrões vêm do humano e a IA preenche as lacunas
Isso é menos uma grande mudança na forma de escrever código e mais um autocomplete turbinado
Quanto mais as pessoas trabalham com IA, menos se preocupam com o código que ela realmente gera
Isso não quer dizer que seja bom. Ela pode criar bugs, problemas de performance e brechas de segurança
Mas essa é a realidade. O código da IA criou um bug? Peça para a IA corrigir
O código da IA está inchado e difícil de ler? Se isso incomodar, peça para a IA corrigir. Muita gente nem se incomoda
Se humanos saírem completamente da manutenção de código, então a necessidade de código manutenível também desaparece
Ainda não chegamos 100% lá, mas estamos indo nessa direção
Em muitas empresas, já é bom o suficiente para que valha a pena correr o risco e seguir no YOLO
Pessoalmente, eu não confio na IA a ponto de não ler o código que ela gera, mas também não leio cada linha
Eu observo os testes com mais cuidado do que o código testado, presto mais atenção às partes sensíveis a performance e guio a estrutura geral
E, se ainda assim não atingir o padrão, em vez de eu mesmo manter, peço para a IA corrigir
Se manutenção ficou tão barata assim, então custo de manutenção deixa de entrar no meu radar
Este texto destaca bem a necessidade de agentes ou assistentes de IA ajudarem não apenas na parte inicial de “crie um novo widget”, mas em várias etapas do desenvolvimento de software
O autor vê que, se alguém usar agentes ou assistentes de IA só na fase de criar novos widgets, vai acabar produzindo muito mais código com IA e, portanto, terá muito mais código para manter
Mesmo que a qualidade do código seja alta, com o tempo surgem custos de manutenção
Ainda assim, o problema descrito pelo autor parece, em boa medida, menos algo que todos inevitavelmente enfrentarão e mais um problema criado por ele mesmo
A situação de startup que ele aponta — “vamos fazer isso funcionar de qualquer jeito primeiro para validar o product-market fit e conquistar clientes” — sempre veio acompanhada de custos de manutenção mais altos no futuro
Isso porque existe certa justificativa em reduzir a qualidade em nome da velocidade para verificar se há um negócio e, se houver, crescer rápido
Também tive a impressão de que o autor evita falar sobre como a IA pode de fato ajudar na parte de manutenção
Com orientação humana, a IA pode ser muito útil para corrigir dependências antigas ou resolver bugs chatos
Esse tipo de tarefa pode parecer trabalho braçal para engenheiros de software, e é justamente o tipo de coisa em que dá vontade de ter ajuda da IA