IA: incompetência acelerada

• Na engenharia de software, a dependência excessiva de LLMs acelera rapidamente a incompetência
• LLMs têm limitações que os impedem de substituir o pensamento crítico e a capacidade de resolver problemas
• O uso de LLMs traz vários riscos, como saídas incorretas, erros de entrada, queda na qualidade do código, deterioração da capacidade dos desenvolvedores e perda do prazer de criar
• LLMs não conseguem fornecer competências essenciais de desenvolvimento, como teoria do programa e entropia do programa
• No longo prazo, capacidade técnica e profundidade de pensamento são mais importantes do que nunca

---

Introdução

Desde o surgimento da IA e dos LLMs, que ganharam atenção popular no fim de 2022, muitas discussões vêm acontecendo.
Como engenheiro de software experiente, o autor apresenta dois grandes problemas observados nos LLMs.

A visão de que "LLM é meu amigo"

Engenheiros que veem LLMs como a melhor ferramenta acabam colocando a velocidade como valor máximo.
É possível gerar muito código rapidamente com LLMs, mas isso embute riscos de longo prazo.

Riscos do uso de LLMs

• Risco de saídas incorretas: LLMs geram tanto código claramente errado (que nem compila) quanto código com erros sutis (bugs de lógica etc.).
  • Quando pessoas sem capacidade de avaliação pedem código-fonte, a chance de receber respostas inadequadas é alta
• Risco de entradas incorretas: LLMs não criticam prompts baseados em premissas erradas ou com contexto insuficiente.
  • Não conseguem distinguir perguntas corretas nem empatizar com o problema XY (falha em identificar a causa raiz)
• Queda na velocidade futura de desenvolvimento: a adoção de LLMs aumenta rapidamente a dívida técnica, transformando internamente a base de código em algo confuso e difícil de manter
• Risco de imaturidade do usuário: com o desaparecimento das oportunidades de resolver problemas e desenvolver o raciocínio, a deterioração da capacidade dos talentos de desenvolvimento se acelera.
  • Desenvolvedores sêniores deixam de ganhar experiência em resolução de problemas mais profundos, e desenvolvedores juniores acabam nem conseguindo desenvolver suas habilidades
• Perda da alegria de criar: escrever código com base em LLMs tira o estado de flow e o prazer da criação, e ler e modificar código feito por IA costuma ser doloroso

A preocupação: "Vou perder meu emprego por causa da IA?"

A probabilidade disso é muito baixa.
Existem duas competências de desenvolvimento que LLMs não conseguem substituir: teoria do programa e entropia do programa.

Teoria do programa

• Como argumentou Peter Naur, “programar é uma atividade de construir uma teoria do design”.
  • O código-fonte não é o produto real; a compreensão coletiva (teoria) é mais importante
  • Se duas equipes com a mesma capacidade receberem o mesmo problema e apenas entregarem o código, a equipe que o construiu diretamente conseguirá adicionar funcionalidades com muito mais eficácia
  • Em uma base de código não familiar, a produtividade é baixa, mas aumenta gradualmente à medida que se compreende a teoria interna de design

LLMs e a teoria do programa

• LLMs têm apenas memória dentro do contexto, então não conseguem internalizar uma verdadeira teoria do programa nem um design profundo.
  • Na prática, a verdadeira essência da programação (design e construção de teoria) é algo que apenas humanos adquirem

Entropia do programa

• Fred Brooks chamou a complexidade (entropia) de dificuldade fundamental da programação.
  • A manutenção de programas aumenta a complexidade, e até as melhores execuções empurram os sistemas para um envelhecimento irreversível

LLMs e a entropia do programa

• LLMs fazem apenas previsão de tokens no nível do texto, sendo incapazes de realizar raciocínio semântico no nível de ideias, projetos ou requisitos.
  • Quanto mais lidam com conversas longas ou grandes blocos de código, mais repetem mudanças desnecessárias ou estranhas, aumentando ainda mais a complexidade
  • O trabalho de reduzir a complexidade ou resistir a ela só pode ser feito por humanos

Conclusão

Com base nas percepções de dois pioneiros, o texto reafirma a natureza do design de software e da complexidade.
Se você espera que a IA melhore sua carreira em desenvolvimento, é preciso cuidado: ela pode, na verdade, acelerar a incompetência.
Como desenvolvedor com ampla experiência e habilidade refinada, é preciso reconhecer que LLMs não podem substituir engenheiros humanos.
O apelo empresarial da adoção de IA está na redução de custos, mas, na prática, ela cria novos riscos, e o uso excessivo acumula custos adicionais de longo prazo e riscos organizacionais.
A importância da capacidade técnica e do pensamento profundo não muda no longo prazo, e a IA deve ser usada como ferramenta, enquanto se continua investindo nas competências essenciais que já eram importantes em 2019.

Próximo texto

Em um post posterior, serão abordadas soluções concretas para cada um dos riscos.

Referências

• Leading Question: https://en.wikipedia.org/wiki/Leading_question
• The XY Problem: https://en.wikipedia.org/wiki/XY_problem
• ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
• Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
• Thoughts on Thinking: https://dcurt.is/thinking
• The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
• "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
• Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
• Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
• Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle

[GN⁺]

Comentários do Hacker News

• Compartilhamento de uma experiência em que, às vezes, sente que a discussão sobre programação com IA reflete a diferença entre engenheiros de software e cientistas de dados/engenheiros de machine learning
  Espera-se sempre que engenheiros de software criem software previsível e que passe nos testes, e o ferramental também é muito mais avançado
  Já para engenheiros de machine learning, trabalhar com modelos probabilísticos é algo natural do dia a dia, e os testes normalmente também são mais focados em métricas do que em saídas específicas
  Por isso, estão mais acostumados com o fato de que a IA nem sempre é confiável
  Também abordam assistentes de código com a mentalidade de que, mesmo que acertem só 80%, os 20% restantes podem ser detectados por eles
• Na minha experiência, cerca de metade disso também parece familiar
  Quando trabalhei na Amazon, soluções baseadas em ML foram muito úteis para problemas sem abordagem clássica
  Mas, em uma startup, insistiam apenas em abordagens baseadas em aprendizado, sem entender filtragem ou mapeamento básicos, e continuavam produzindo resultados absurdos na estimativa de atitude de uma aeronave parada
  Essa lacuna entre ML e engenharia de software é clara, e seria bom haver uma forma melhor de expô-la no processo de contratação
• No clima atual, parece que a mentalidade de MLE está sendo forçada sobre outros grupos também
  Em uma empresa que vende produtos nos quais precisão e correção são essenciais, o time de ML dizia que 80~90% já era suficiente, e houve insatisfação de arquitetos com isso
  Como no exemplo das discussões sobre taxa de letalidade de 1% na pandemia, vale lembrar que pequenos percentuais também podem ter grande impacto
• Menção à diferença entre comportamento determinístico e comportamento probabilístico
  Este texto trata da preocupação metanível sobre IA e engenharia de software, isto é, do gerenciamento da entropia do programa
  Gerenciar entropia é uma parte enorme da construção de produtos de software, e a IA talvez um dia torne isso fácil, mas por enquanto muitas vezes piora ainda mais a entropia
• Atualmente fazendo mestrado em IA (especialmente ML), desenvolvendo como SWE novos músculos
  Enxerga MLE a partir de uma perspectiva mais ampla de SWE, com necessidade de entender o todo: construção de pipelines robustos, integração de modelos, deploy etc.
  Mas a maioria dos especialistas puros em MLE carece de visão de SWE, e muitas vezes entende ML sem ter intuição computacional
  Para ser realmente full-stack, é essencial entender sistemas de baixo nível, arquitetura, deploy e também MLE
  Mas o mercado geralmente procura apenas SWE ou doutores em MLE; fica a vontade de pedirem para fazer tudo isso e também oferecerem recompensa por isso
• Engenheiros de software também aplicam bastante raciocínio probabilístico na prática
  Por exemplo, ao reprojetar race conditions, prever p99 de chamadas a banco de dados, fazer testes A/B etc.
• Concordo em geral com a tese do artigo, mas também percebi mudanças positivas ao usar LLMs
  Como desenvolvedor sênior com 30 anos de experiência, ter de ler código gerado por IA significa que o desenvolvimento está migrando para um fluxo centrado em code review
  Isso ajuda até desenvolvedores individuais a aprender responsabilidade em nível de equipe e experiência de leitura de código
  Além disso, para usar LLMs direito, é essencial entender a estrutura hierárquica do problema
  Projetar detalhadamente por seção antes de implementar ajuda naturalmente a definir interfaces e fronteiras
  LLMs são um catalisador que acelera o crescimento de juniores para seniores e ajuda a experimentar o aprendizado de desenvolvedores experientes
  A IA não vai substituir desenvolvedores e, no fim, vai se integrar como ferramenta
  • Acho que a quantidade de código que você lê deve ser sempre maior que a quantidade que você escreve
    Código gerado por LLM pode ser monótono, mas ainda assim é uma oportunidade de aprendizado
    Descobri muitos novos idioms/chamadas de biblioteca em código gerado por LLM
    Quanto mais sênior, melhor o prompt que se consegue dar, então o LLM age como um catalisador ainda mais poderoso
  • A IA é muito boa para gerar código em nível de protótipo, como ferramenta de copiar e colar, mas não para revisar e commitar
  • Do ponto de vista das empresas, em vez de ajudar juniores, a IA vira um pretexto para acabar com contratações júnior e exigir produtividade 10x dos seniores com IA
    Big tech, mid tech e small tech seguem reduzindo equipes
• A controvérsia sobre IA foi comparada ao pensamento antigo de que impressão 3D substituiria toda a manufatura
  A tese é que a IA está mais próxima desse tipo de mudança realista do que da singularidade
  • Impressão 3D é uma tecnologia realmente incrível e inovadora, mas injection molding ainda continua existindo
  • Impressão 3D não trouxe singularidade, mas em ambientes de trabalho do conhecimento, como o ensino universitário, a IA já está tendo grande impacto
    Compartilhamento da realidade de que formas de aula, tarefas e ensino antes consideradas óbvias estão mudando rapidamente no mundo todo com a chegada dos LLMs
  • Impressão 3D é um exemplo de enorme mudança e inovação em vários setores, como aeroespacial e espacial
    Sem a SpaceX, muitas coisas teriam sido de fato impossíveis
  • Também é parecido com a expectativa de que o Bitcoin substituiria os bancos
    No fim, o resultado foi os bancos venderem produtos financeiros baseados em Bitcoin
  • Impressão 3D e IA têm curvas de crescimento completamente diferentes
    Impressão 3D não é vista como substituta da manufatura existente, e ficou limitada a usos como protótipos/mockups/PoC
• LLMs são excelentes para escrever código, mas não podem ser o sujeito da “responsabilidade”
  Código aceito sem compreensão cobra depois um preço alto na manutenção, na forma de dívida técnica
  É como a ilusão de velocidade grátis; na prática, é como acumular dívida técnica a uma taxa de juros anual de 40%
  A IA pode automatizar a digitação, mas o pensamento ainda precisa ser humano
  • Como o LLM não “entende” de verdade, a compreensão real só existe quando o humano entende o contexto da base de código e do sistema
  • Sugestão de reduzir os juros (dívida técnica) com testes e estruturação de subsistemas isolados (tdd, microsserviços etc.)
    Alguns dizem que tdd e microsserviços, antes desnecessários no desenvolvimento tradicional, ganham mais valor na era dos LLMs
  • Dependendo da tarefa, a IA pode ser até muito ruim para escrever código
• Compartilhamento de que o maior ponto de dor foi o risco de entrada (Input Risk)
  Uma pequena ambiguidade no prompt pode desviar completamente o resultado, e quando isso é percebido, já é difícil consertar depois
  Foi por causa da ambiguidade da linguagem humana que surgiram linguagens formais claras
  Pessoalmente, ao usar ferramentas de IA, sente que sua habilidade está piorando rapidamente, e houve casos em que gastou ainda mais tempo e energia
  A IA é útil, mas parece haver um grupo em que pequenos erros se acumulam em problemas complexos, e outro grupo de gestores/não técnicos que olham apenas o resultado e dizem “substitui a função”
  [Experiência detalhada: comentário anterior]
  • Recomenda usar a IA como assistente, mantendo uma estrutura em que a própria pessoa assume diretamente a responsabilidade por qualidade e manutenção
    Assim como a calculadora reduziu a capacidade de cálculo mental das pessoas, a IA também pode reduzir habilidades de escrita, comunicação e resolução de problemas
  • Compartilhamento da experiência de que inserir palavras ambíguas leva o LLM a resultados ilógicos
    Por isso, usa LLMs apenas para tarefas pequenas e claras, ou problemas que buscaria no StackOverflow
    As respostas são tratadas não como verdade absoluta, mas como guia
  • A IA ajuda a resolver alguns problemas mais rápido, mas não consegue resolver problemas que ela mesma torna desnecessariamente mais complexos
    A capacidade humana de entender o blueprint completo é a chave para resistir à entropia
  • Método usado com frequência: primeiro pedir ao LLM “faça 5 perguntas claras por 3 rodadas”
    Isso ajuda a refinar melhor o tema e o contexto
    Espera que essa dica útil também ajude outras pessoas
  • Pressentimento de que, depois desta era de hype, a importância do controle de qualidade será redescoberta
    Exemplo: a antiga guerra Coke vs Pepsi
• Há quem discorde da afirmação de que LLMs não lidam conceitualmente com ideias, diagramas e especificações
  Se você perguntar ao LLM sobre a intenção do design, algo como “quero um código simplificado”, é possível obter uma segunda opinião bastante boa
  Se não perguntar, não haverá resposta alguma, e as configurações padrão também são uma escolha nossa, então isso é visto como algo sem relação com a essência da tecnologia subjacente
  • Já existem casos mostrando empiricamente, de várias formas, o trabalho conceitual dos LLMs
    Na realidade, ninguém consegue compreender um programa enorme inteiro na cabeça; ferramentas e linguagens evoluíram quase sempre com base em compreensão parcial
    LLMs compartilham esse mesmo limite, então nesse enquadramento humanos e LLMs têm limitações parecidas
  • Ao revisar código de juniores, sente que há mais problemas de direção do que de qualidade do código em si
    É uma pena que LLMs tenham dificuldade em perguntar “por que você está fazendo assim?” nessa direção
  • Pergunta se usam ferramentas automáticas para converter código em diagramas ou se fazem isso manualmente
• Menção à semelhança com a ideia de que softwares de mapa, como Google/Apple Maps, deterioram a capacidade humana de orientação
  Há algo de verdade nisso, mas acredita que a maioria já não tinha grande habilidade de se orientar e, pelo contrário, a tecnologia de mapas elevou em média a capacidade de ir de A até B
  Mesmo para a minoria mais habilidosa, a tecnologia funciona mais como apoio do que como substituição da capacidade
  A IA também deve trazer uma mudança semelhante em escala maior, com pontos em que habilidades diminuem e se perdem, mas também muitos ganhos
  • Mapas não são comparáveis a LLMs em termos de confiabilidade
    Mapas quase sempre dão o valor esperado, mas LLMs mudam o resultado até com o mesmo prompt, então parecem difíceis de confiar
    Assim como há pessoas que acabam num lago por causa do mapa, confiar cegamente em LLMs pode causar problemas ainda maiores
  • Pessoalmente, usar software de mapas ajuda até na memória espacial
    Dá para se perder à vontade e pegar a rota quando necessário, o que amplifica a experiência
  • O Google Maps é mais de 90% mais preciso que um taxista
    Há casos em que a IA é pior do que alguém comum com apenas alguns dias de experiência naquela área
  • Fica a dúvida se há evidência para a tese de “melhora da habilidade média”
• Há quem não concorde com a afirmação do autor de que “[IA] não pode trabalhar em nível conceitual”
  LLMs recentes claramente conseguem trabalhar em nível conceitual (ex.: tradução/aplicação de conceitos)
  Afirmam até que entendem conceitos que humanos não vivenciaram pessoalmente
  • LLMs modelam conceitos por meio de clusters de tokens
    Ex.: perto de dog, agrupam-se palavras relacionadas
    Mas não conseguem modelar combinação, intenção ou lógica contrafactual
    Mostram força em perguntas semelhantes aos dados de treinamento
    Em áreas em que a conceituação é bem definida, como engenharia de software, podem ser úteis
  • Exemplo adicional de que humanos também conseguem entender conceitos sem experiência direta
• Na prática, 70% dos funcionários fazem o trabalho de qualquer jeito, e às vezes a IA é até melhor
  No fim, quem não se esforça continua igual mesmo usando IA, e só quem realmente aprende cresce junto com ela
  • Aponta o limite da narrativa autocentrada de presumir que a si mesmo pertence aos 30%
  • Quem tenta empurrar trabalho de qualquer jeito com IA acaba até aumentando o risco de demissão
    Se a IA fizer melhor o trabalho, isso só cria justificativa para substituir o agente
  • Concorda que, no padrão de grandes empresas, essa é a visão mais realista
    Até o FSD é muito melhor do que um motorista comum que não seja especialista
• Compartilhamento de que recentemente sentiu necessidade de reconfigurar o 90s.dev como uma comunidade sem IA, um espaço para o artesanato do software
  Está pensando em formatos como fórum, mailing list, multiblog etc.
  Lista de discussão temporária
  • Acredita que, em vez de uma estrutura aberta a qualquer pessoa, um modelo baseado em convite e em uma árvore de confiança por indicação é mais adequado para uma comunidade duradoura
    Já houve casos bem-sucedidos assim em certas comunidades
  • Também seria uma boa ideia usar um software clássico de fórum da época com design retrô