- Usar ferramentas de programação com IA aumenta a dívida de código
- Entre duas empresas com o mesmo produto e a mesma receita, uma empresa com 1 milhão de linhas de código é muito mais difícil e lenta de entender e modificar do que uma operando com 100 mil linhas de código
- Em outras palavras, quanto mais código, maior a dívida; a geração de código por IA aumenta a produtividade, mas ao mesmo tempo pode ser interpretada como uma ação que aumenta a dívida
- A dívida tem lados positivos e negativos
- Positivo: possibilita crescimento rápido no curto prazo
- Negativo: no longo prazo, se for mal gerida, pode levar ao risco de colapso do projeto
- Ou seja, a dívida pode ser boa ou ruim, pode ter ou não juros, pode permitir crescimento rápido, mas também pode derrubar um projeto
- O importante não é usar ou não a ferramenta, mas ter uma postura de gestão responsável
- É preciso garantir acesso fácil às ferramentas, ao mesmo tempo em que se considera a qualidade do código gerado e seu custo de longo prazo
5 comentários
Se o código for muito longo, mas ainda for fácil explicar "o que ele faz", então isso não é dívida.
A questão é que o uso indiscriminado de IA torna isso mais difícil, e por isso se diz que ele gera dívida.
https://github.com/kelseyhightower/nocode
Isso não está explicitamente declarado no texto principal, mas talvez possa significar que, quando o código é escrito por IA, ele acaba se tornando uma dívida porque é menos familiar do que aquele escrito diretamente por uma pessoa?
Opiniões do Hacker News
À primeira vista, medir tudo pela quantidade de linhas de código (LOC) parece reducionista. Se a Empresa A tiver 1 milhão de linhas de código muito mais limpas, bem organizadas e documentadas, ela pode estar em situação melhor do que a Empresa B com 100 mil linhas mal escritas. O ponto central não é o código em si, mas a complexidade; a quantidade de linhas é só um indicador aproximado dela. Código é um ativo. É o produto e também um ativo de uma empresa de software. Claro que, quanto mais ativos, maior a complexidade, mas isso é óbvio demais. É como não dar para enxergar a malha rodoviária dos EUA de forma totalmente negativa só porque é complexa e difícil de manter. Mesmo deixando de lado a questão da IA, no fim a tese do autor se resume a uma conclusão básica e conhecida por todos: “quanto menos complexidade, melhor”. Então, o ponto mais importante deste texto pode ser condensado em algo como: “verifique se as ferramentas de codificação com IA não estão adicionando complexidade desnecessária ao código final”
Eu até acho que a complexidade não é a questão principal aqui. Se partirmos do contrário e assumirmos que já existe um negócio de software que sobreviveu, então todo custo (compras, salários etc.) deve, em princípio, ser reduzido ao máximo. Dizem que complexidade é pior que simplicidade, mas isso só acontece porque, quando ela é real, custa mais caro. No fim, o que importa mesmo é o custo em si, seja de curto ou longo prazo, seja de capital ou operacional. A verdadeira questão é se o código gerado por LLM reduz custos ou os aumenta. Tamanho do código, complexidade e inúmeras outras variáveis que nem o OP nem você mencionaram são todas importantes
Eu costumo olhar a complexidade das minhas funções com cyclomatic complexity. Meço a complexidade com SwiftLint e marco quando passa do limite. Às vezes eu só quebro o código de qualquer jeito, mas normalmente tento encontrar uma forma de deixá-lo mais simples. Meus arquivos costumam ser bem longos, mas procuro manter uma proporção de 50:50 entre comentários e código. Se você der ao LLM um prompt para reduzir a complexidade e aumentar os comentários, acho que ele consegue fazer isso bem o suficiente
Código é como um produto químico volátil: ao mesmo tempo ativo e passivo. Se for usado corretamente e com rapidez, pode gerar dinheiro; se for deixado de lado ou derramado, vira passivo. O código-fonte não se deteriora sozinho, mas sua “adequação ao propósito” muda continuamente à medida que os objetivos e processos da organização mudam
Achei interessante o tema “por que não conseguimos fazer software simples?”. Sobre complexidade, me marcou a ideia de que “a complexidade surge quando sistemas interagem. Sistemas complexos podem caminhar para a irracionalidade e também produzir criatividade inesperada”
Eu acho que o ativo é o software em si, não o código. Assim como, numa rodovia, o ativo não é o concreto, mas a infraestrutura pronta. A qualidade do concreto afeta a depreciação do valor do ativo e o custo de manutenção, o que por sua vez afeta o valor do ativo. Também é essencial considerar a perspectiva de gestão de risco aqui
No começo da minha carreira, eu achava importante escrever muito código. Depois de 20 anos, hoje tenho mais orgulho de apagar mais código. Do ponto de vista de um engenheiro de segurança, código não é apenas passivo, também é risco. Dependências de bibliotecas externas são um risco especialmente grande. Recentemente, junto com um colega, escrevi um pequeno init system para Linux com menos de 600 linhas usando apenas a biblioteca padrão de Rust, e ele está em produção em várias organizações. Sem dependências, com boot concluído em menos de 1 segundo. Isso me fez perceber que dá para criar servidores Linux do tipo appliance sem systemd e sem milhões de linhas de código em C. Fazendo você mesmo, a quantidade de código é muito menor e dá para entender completamente o sistema inteiro
Acho que o pior cenário do código gerado por IA aparece com mais clareza em projetos mais pessoais, e não tanto do ponto de vista da empresa. Eu posso escrever pessoalmente 10.000 linhas de ótimo código que conheço bem, ou posso produzir às pressas, várias vezes mais rápido, 20.000 linhas de código problemático. Eu mesmo tento encontrar um equilíbrio no meio disso. Se eu continuar expandindo o desenvolvimento, acho que o tempo “economizado” no primeiro caso acaba virando prejuízo
Eu diria que sempre existe um meio-termo. No meu caso, só deleguei geração real de código para IA em códigos autocontidos, como scripts Bash e Python. Como esses scripts interagem só com a linha de comando, os limites são claros e são fáceis de gerenciar. São códigos que escrevi uma vez e nunca mais revi. Mas gerar com IA o código do domínio principal do negócio não faz muito sentido, então não faço isso. De qualquer forma, preciso revisar o código, e o que realmente me importa é quando consigo validar a manutenibilidade dele. Se não for um caso em que dá para simplesmente descartar o código depois, ou só fazer uma revisão simples, não há necessidade de usar ferramenta de geração de código. Se a IA pudesse fazer o papel de product owner, entendendo perdas reais de negócio e até melhorando isso, aí a conversa seria outra — mas nesse ponto eu começaria a me preocupar até com o risco de não haver mais usuários
Eu também, sempre que confiei código demais à IA, em algum momento paguei caro em produtividade perdida. Se for um app todo feito em vibe coding, a habilidade mais importante talvez seja julgar “essa funcionalidade realmente precisava existir?”. Deve ser um sofrimento enorme depurar código espaguete sem fazer a menor ideia do que cada linha faz
Você disse que no primeiro caso perdeu tempo, mas o segundo caso (código pior, mais rápido) também acaba sendo perda de tempo. Acho que a essência está em encontrar o ponto intermediário
Código curto, com nomes de variáveis ruins ou “inteligente” demais, é muito pior do que código mais verboso, bem documentado e com nomes de variáveis ricos. No fim, o passivo é proporcional ao tempo necessário para entender, modificar e expandir o código. Número de linhas também não é um indicador que consiga medir perfeitamente esse passivo. Se todas as outras condições fossem iguais, reduzir a quantidade de código poderia sacrificar a legibilidade e, na verdade, aumentar o passivo. Por isso, acho mais correto dizer que “a ausência de teoria é o passivo”. Aliás, código curto em si pode até ser um passivo do ponto de vista dos LLMs. Isso porque o uso de LLM reduz a construção de teoria, especialmente no estado atual, em que a IA ainda não consegue formar por conta própria uma teoria sobre o projeto inteiro e transmiti-la corretamente ao engenheiro
Eu gosto de ver programação como um processo de construção de teoria. Especialmente em programas de negócio, essa teoria precisa ser centrada no negócio. Por exemplo, acho que necessariamente devem entrar perspectivas como “é fácil contratar desenvolvedores para esta base de código?”, “quão estável é o modelo de negócio?” e “qual é a importância de negócio de cada funcionalidade?”
Tive uma ideia agora. Será que dá para perguntar à IA sobre os nomes de variáveis / explicações das funções dentro do código? Até agora eu só usei IA para geração de código
Em algumas empresas em que trabalhei por muito tempo, não existiam ativos próprios de código, mas o negócio principal dependia de serviços corporativos externos de terceiros. A minha dúvida aqui é: nesse caso, como medir de fato quanto código existe? Por exemplo, se dependemos de um provedor SaaS legado, deveríamos considerar as linhas de código deles como parte do nosso passivo?
Na minha visão, o maior risco ao depender de serviços de terceiros é eles quebrarem ou terem os termos de serviço alterados por uma aquisição ou fusão. Na maioria das vezes, acabamos usando serviços de startups supercapitalizadas que ainda não conseguiram se sustentar de verdade
Concordo totalmente com isso. Numa empresa anterior, usamos um SaaS de email marketing; apesar de o código de integração que escrevemos ter só umas 500 linhas, sofremos demais apagando incêndio por causa dos problemas do serviço. No fim, reimplementamos internamente só as funcionalidades de que precisávamos, economizamos muito custo e dor de cabeça, e o número de linhas de código aumentou em cerca de 3 mil
Não entendi muito bem.
Código é claramente um ativo, sem dúvida, mas assim como hardware, seu valor se deprecia por vários motivos (defeitos, mudanças na indústria de software/hardware etc.). Quanto mais código de software você tem, maior é o custo anual de depreciação. Se não houver manutenção suficiente (por exemplo, código demais para o número de desenvolvedores), o custo para corrigir problemas depois cresce de forma exponencial. É como se o conceito de depreciação viesse com “juros”. Então, entendo por que usar o termo “passivo”, mas não é um conceito perfeitamente equivalente
Claro, o repositório mais perfeito é este aqui
Antigamente, meu orgulho era apagar 20 mil linhas de código por mês. Alguns anos atrás, tentei repetir isso com uma equipe remota de 20 desenvolvedores, mas havia pull requests demais entrando e eu simplesmente não conseguia acompanhar. Hoje faço pair programming com Claude Code e GPT, e a sensação é totalmente a segunda. Acho que existe aqui uma oportunidade para refatorações inteligentes. Só que provavelmente falta mais contexto. Tentei algo assim em código legado com Cursor e Claude opus 4.1, mas nem 1 milhão de tokens bastou. Talvez funcionasse melhor traduzindo entre um LLM pessoal e um LLM compartilhado; queria saber se alguém já teve experiência com isso
Quase ninguém parece fazer a pergunta importantíssima: “qual é a quantidade mínima absoluta de código necessária para implementar completamente a funcionalidade X?”. Claro que é impossível responder com precisão, mas pensar assim já cria uma mentalidade eficiente. Em contrapartida, as pessoas se interessam muito por coisas que na prática não são tão importantes, como verificação formal. Sem considerar a quantidade mínima viável de código, verificação formal pode acabar sendo desperdiçada e sem sentido. E normalmente se assume que código escrito por engenheiros é bom por natureza, quando na realidade a maior parte só adiciona abstração desnecessária e complexidade, criando mais trabalho. Uma parcela considerável da engenharia de software, na verdade, tem valor negativo. Claro, existem partes positivas e negativas misturadas, e isso torna o julgamento ainda mais difícil