Essa é uma pergunta incômoda.
E talvez por isso ela esteja aparecendo cada vez mais em conversas sobre engenharia de software.
Ela incomoda porque toca em algo que muita gente sente, mas nem sempre consegue explicar bem: a sensação de que estamos produzindo mais código, mais rápido, com menos esforço aparente, mas talvez entendendo menos o que estamos colocando em produção.
É uma provocação fácil de comprar. Afinal, se antes o desenvolvedor precisava quebrar a cabeça para desenhar uma solução, escrever a implementação, lidar com os erros, ajustar os testes e entender cada consequência do que estava fazendo, agora boa parte desse processo pode ser acelerada por uma IA.
O autocomplete completa blocos inteiros. O agente cria arquivos, altera múltiplas camadas, sugere testes, escreve documentação e às vezes entrega uma feature inteira antes mesmo de o desenvolvedor ter clareza completa sobre o caminho tomado.
Visto de fora, parece simples concluir:
Os devs estão ficando preguiçosos, dependentes e tecnicamente mais fracos.
Mas talvez essa seja uma leitura superficial do problema.
A questão mais interessante não é se a IA está deixando desenvolvedores “mais burros”, como se a ferramenta tivesse um efeito mágico sobre a inteligência das pessoas.
A questão é se estamos criando ambientes onde pensar, entender e questionar passaram a competir com uma pressão cada vez maior por velocidade.
Nesse cenário, o problema não é apenas individual. Não é só o dev que “aceitou a sugestão da IA”. É o processo, a cultura, as métricas e a liderança que começam a tratar volume de entrega como se fosse sinônimo de valor entregue.
Dívida técnica já conhecemos. E a dívida cognitiva?
Na engenharia de software, nós já temos um conceito conhecido para falar sobre custos que são empurrados para o futuro: a dívida técnica.
Ela acontece quando tomamos uma decisão que resolve um problema agora, mas deixa um custo para o futuro. Pode ser um código duplicado, uma abstração ruim, uma falta de teste, um acoplamento indevido ou aquela solução “temporária” que continua viva em produção anos depois.
A dívida técnica nem sempre nasce de incompetência. Muitas vezes ela é uma decisão consciente. O time sabe que está aceitando um custo futuro para conseguir entregar algo no presente.
Com a IA, algo parecido começa a acontecer, mas em outra camada.
Não estamos acumulando apenas dívida no código. Estamos acumulando dívida no entendimento.
A dívida cognitiva aparece quando existe uma distância crescente entre o que foi implementado e o quanto o time realmente entende sobre aquilo.
O sistema cresce, os arquivos aumentam, as features chegam, os PRs são aprovados, mas a compreensão coletiva não acompanha essa velocidade.
E esse é o ponto perigoso:
A dívida cognitiva pode parecer produtividade.
Quando produtividade vira silêncio
É fácil perceber alguns sintomas desse novo momento:
- Pull Requests ficando maiores.
- Code Reviews ficando mais rápidos.
- Mais código indo para produção.
- Mais sugestões sendo aceitas.
- Mais features sendo entregues.
À primeira vista, isso parece ótimo. O time está mais produtivo. A liderança enxerga velocidade. O negócio percebe entregas chegando antes.
Mas, quando alguém pergunta “por que isso foi implementado dessa forma?”, a resposta muitas vezes é silêncio.
Esse silêncio é um sinal de dívida cognitiva.
Não porque todo desenvolvedor precise lembrar cada detalhe de cada linha escrita, mas porque decisões relevantes precisam ser compreendidas e defendidas por alguém.
Software não é apenas um conjunto de arquivos funcionando.
Software é uma coleção de decisões acumuladas.
Cada endpoint, cada abstração, cada regra de negócio, cada dependência e cada exceção carrega uma escolha.
Quando essas escolhas passam a entrar no sistema sem que o time as absorva, a base de código pode até crescer, mas a capacidade de manutenção começa a encolher.
O problema não é “burrice”
É tentador chamar isso de burrice porque a palavra é forte e captura bem a sensação de perda de habilidade.
É claro que existe um risco real de perda de habilidade. Se um desenvolvedor terceiriza constantemente o raciocínio, evita o esforço de entender e aceita respostas prontas sem crítica, ele pode sim enfraquecer tecnicamente com o tempo.
Mas dizer apenas que os devs estão ficando burros joga a discussão para um lugar raso.
O futuro do desenvolvimento provavelmente não é o dev escrevendo cada linha de código manualmente. Mas também não deveria ser o dev virando apenas um operador de prompt.
O nosso papel está mudando, amigos.
Ninguém sabe ao certo o que vai significar “ser DEV” daqui alguns anos, nem mesmo se a profissão continuará existindo. Leiam isso da forma mais otimista possível: não quero propagar profecias apocalípticas.
Para desenvolvedores
O aviso é simples: use IA, mas não abra mão do entendimento.
Não aceite uma solução só porque ela parece funcionar.
Não aprove uma mudança que você não consegue explicar.
Não transforme o autocomplete em piloto automático.
A IA pode escrever o código, mas quem precisa entender as decisões, os riscos e as consequências ainda é você.
Isso não significa voltar a programar como antes ou rejeitar ferramentas modernas. Significa usar IA como apoio ao raciocínio, não como substituta dele.
Pergunte mais. Questione mais. Entenda os trade-offs.
Se a IA gerou algo que você não conseguiria defender em uma conversa técnica, talvez esse código ainda não esteja pronto para entrar no sistema.
Para líderes
O aviso é ainda mais importante: tenham consciência de que a dívida cognitiva existe e tratem isso com seus times.
Não olhem apenas para:
- velocidade de entrega;
- quantidade de PRs;
- volume de código gerado;
- número de features concluídas.
Esses indicadores podem dar a sensação de produtividade enquanto escondem uma perda perigosa de entendimento coletivo.
Criem espaço para revisão de verdade.
Incentivem PRs menores.
Valorizem explicações de decisões técnicas.
Peçam que o time registre trade-offs importantes.
Tratem code review como construção de conhecimento, não como etapa burocrática.
E, principalmente, façam uma pergunta que talvez seja mais importante do que “isso está pronto?”:
O time entendeu o que está sendo colocado em produção?
Talvez a pergunta seja outra
Talvez os devs não estejam ficando mais burros.
Talvez estejamos ficando mais endividados cognitivamente.
E essa dívida é perigosa justamente porque não aparece de imediato.
Ela não quebra o build.
Não falha no lint.
Não aparece no coverage.
Ela aparece depois, quando o sistema precisa mudar, quando uma decisão precisa ser explicada, quando um bug difícil surge em produção ou quando o time percebe que já não entende tão bem aquilo que está mantendo.
O desafio daqui para frente não vai ser apenas produzir mais código.
Vai ser continuar entendendo o suficiente para sustentar o código que estamos colocando no mundo.