IA: incompetência acelerada
(slater.dev)- A dependência excessiva de LLMs na engenharia de software pode aumentar a velocidade no curto prazo, mas enfraquecer o pensamento crítico e a capacidade de resolver problemas
- Um risco maior do que saídas incorretas está em aceitar prompts defeituosos como estão e, como resultado, acumular rapidamente dívida técnica e degradar a competência dos usuários
- Como os LLMs não conseguem lembrar nem internalizar a teoria do programa além da janela de contexto atual, o modelo mental compartilhado necessário para projeto e manutenção continua sendo domínio de engenheiros humanos
- A complexidade continua aumentando durante a manutenção, e LLMs, que são preditores de tokens em nível de texto, podem ampliar a entropia do programa com mudanças desnecessárias ou estranhas
- A IA pode ser usada como ferramenta, mas não se deve depender dela como muleta; é preciso continuar investindo nas competências fundamentais de engenharia e no pensamento profundo que já eram valiosos em 2019
Riscos de engenharia criados pela dependência de LLMs
- A atitude de chamar um LLM de “amigo” está mais para um eufemismo que beneficia o usuário do que para uma parceria real
- Engenheiros com essa visão geralmente priorizam velocidade, ou são pressionados a priorizá-la
- LLMs conseguem produzir muito código rapidamente, mas seu uso vem acompanhado de uma longa cauda de riscos
Cinco riscos evidentes na geração de código
-
Risco de saída
- LLMs podem produzir resultados claramente errados, como código que não compila
- O caso mais perigoso é uma saída incorreta sutil e difícil de detectar, como um bug lógico
- O risco aumenta quando quem escreve o prompt não tem qualificação para avaliar o resultado
- Um exemplo é a situação em que um gerente de projeto pede código-fonte
-
Risco de entrada
- LLMs não contestam prompts com perguntas indutivas, premissas incorretas ou contexto incompleto
- Por exemplo, um pedido como “forneça uma implementação de lista thread-safe em C#” pode gerar 200 linhas de código plausível, mas a pergunta real pode ser “como tornar este código thread-safe?”
- Nesse caso, a resposta poderia ser uma única linha de código usando
System.Collections.Concurrent - O LLM não reconhece o caso do XY Problem, porque isso não foi pedido
-
Desaceleração futura
- LLMs podem reduzir a qualidade de uma base de código muito rapidamente
- Sem guardrails fortes, código gerado por LLMs pode parecer normal por fora, mas se transformar por dentro em um espaço insalubre e não funcional
- Isso é tratado como um problema mais urgente do que a discussão comum sobre dívida técnica
-
Infantilização do usuário
- Em indivíduos e organizações que transferem pensamento e resolução de problemas para LLMs, o talento pode desaparecer
- Engenheiros sêniores podem perder oportunidades de aprender por meio de dificuldades produtivas, enfraquecendo sua capacidade de resolver problemas e seu pensamento crítico
- Engenheiros juniores podem deixar de desenvolver essas competências desde o início e, depois, ter dificuldade para mentorar futuros juniores
- O ThoughtWorks Technology Radar Volume 32 aborda casos em que a confiança baseada em IA sacrifica o pensamento crítico
- Coding as Craft: Going Back to the Old Gym enfatiza uma colaboração intencional com IA para preservar a programação como ofício
- Thoughts on Thinking considera que LLMs podem entregar pensamentos prontos, mas não o crescimento intelectual de desenvolvê-los por conta própria
-
Perda de prazer
- Muitos desenvolvedores relatam que o uso de IA tira o estado de fluxo e o prazer da criação
- Código gerado por IA pode se tornar código doloroso de ler e modificar
- Um texto relacionado é The Hidden Cost of AI Coding
Duas competências que LLMs não substituem
- Diante da preocupação de que engenheiros experientes se tornem desnecessários por causa da IA, as competências de programação que LLMs não conseguem oferecer se resumem a duas
- Essas competências são teoria do programa e entropia do programa
Teoria do programa: o código não é o programa em si
- Programming as Theory Building, de Peter Naur, vê a programação como uma atividade de formar insights ou uma teoria sobre um problema
- Na visão de Naur, o programa não é o código-fonte, mas uma construção mental compartilhada, ou seja, uma teoria ou projeto
- O código deriva desse projeto, mas o produto valioso está mais no projeto do que no código
-
Experimento mental das duas equipes
- Duas equipes A e B, com a mesma competência, ficam em salas separadas sem comunicação entre si
- A equipe A escreve um programa, como um jogo de xadrez em terminal, enquanto a equipe B espera ou joga xadrez de verdade
- Depois que a equipe A termina, o código-fonte é entregue à equipe B, e ambas as equipes precisam adicionar um recurso, como um jogador de xadrez virtual
- A equipe que produzirá a melhor solução é a equipe A
- A equipe A tem um modelo mental fresco do programa que acabou de criar
- A equipe B não tem esse modelo
- Como programas continuam sendo modificados após a criação inicial, ter apenas o código-fonte, sem uma compreensão internalizada do projeto, aumenta o custo de mudança
- Isso se conecta à experiência de entrar pela primeira vez em uma grande base de código existente, começar com produtividade quase zero e ver a produtividade aumentar à medida que a teoria do programa é carregada na mente
-
LLMs e teoria do programa
- LLMs atuais não lembram além da janela de contexto, portanto não conseguem dominar a teoria, o projeto ou a construção mental
- Quem consegue obter e manter a teoria do programa são os humanos
Entropia do programa: a capacidade de reduzir ou resistir à complexidade
- A complexidade é uma força fundamental contra a programação e está relacionada à entropia
- The Mythical Man-Month, de Fred Brooks, vê a construção de programas como um processo de redução de entropia, e a manutenção como um processo de aumento de entropia
- Na visão de Brooks, mudanças em programas depois da construção inicial inevitavelmente tornam o código-fonte mais complexo
- Ainda assim, mudanças que se harmonizam com o projeto podem desacelerar o aumento da complexidade
-
LLMs e entropia do programa
- LLMs são preditores de tokens e operam apenas no nível do texto
- LLMs não conseguem raciocinar no nível conceitual de ideias, diagramas ou especificações de requisitos
- Quem já colocou um grande bloco de código em um LLM tende a ver que ele aplica mudanças desnecessárias e estranhas
- Quanto mais longa a conversa, mais o resultado pode se desviar
- A capacidade de reduzir a complexidade do código ou resistir à complexidade está nos humanos
Como usar IA em engenharia
- Se você esperava que a IA elevasse sua carreira de engenharia ao próximo nível, ela pode agir no sentido oposto
- LLMs podem acelerar a incompetência, mas não substituem a engenharia humana
- O apelo comercial da IA está em comoditizar a engenharia para reduzir custos
- Porém, assim como o uso de talentos de engenharia no exterior produz resultados mistos, LLMs também vêm com limites e riscos
- O ciclo de hype da IA pode acabar chegando ao pico
- Empresas que hoje usam IA em excesso arcarão com custos de longa cauda e poderão mudar de direção ou desaparecer
- A proposta de valor de longo prazo dos humanos na engenharia não muda
- O mundo ainda precisa de competência técnica e pensamento profundo
- E pagará por essas competências
- A IA continuará existindo, mas deve ser usada como ferramenta, não como uma muleta da qual se depende
- É preciso continuar investindo nas competências básicas de engenharia que eram consideradas valiosas em 2019
1 comentários
Opiniões no Hacker News
Às vezes parece que o discurso sobre programação com IA reflete a diferença entre engenheiros de software e cientistas de dados/engenheiros de machine learning
Ambos lidam com requisitos ambíguos e bugs difíceis de reproduzir, mas, em geral, engenheiros de software constroem software que deve sempre funcionar de uma forma específica, então reprodutibilidade, testes e ferramentas maduras são importantes
Já engenheiros de machine learning lidam por natureza com modelos probabilísticos, e os testes também costumam girar mais em torno de métricas de avaliação como “saída correta em 90% dos casos” do que de produzir uma saída específica
Por isso, uma forma de pensar voltada a lidar com uma IA que nunca é totalmente confiável é mais natural no lado de machine learning, e assistentes de programação acabam sendo avaliados como “80% está certo e me poupa trabalho; os 20% restantes eu corrijo”
Quando trabalhei na Amazon, muitas vezes soluções baseadas em machine learning se encaixavam bem em problemas reais para os quais não existia uma abordagem clássica. Por exemplo, predição de movimento baseada em mapas de grade e classificação de imagem/mapa de grade se integravam bem aos pipelines existentes de estimação e controle e eram úteis
Por outro lado, em certa startup, um gerente de nível baixo me repreendia repetidamente porque eu desconfiava de uma abordagem baseada em aprendizado para o problema de estimar ao longo do tempo a orientação de um plano estacionário. Como a equipe não entendia o básico de mapeamento ou filtragem e assumia que “mais dados resolvem”, o pipeline inteiro de controle do veículo estava sendo alimentado por estimativas arbitrárias de rotação que piscavam e saltavam
Essa lacuna é realmente grande, e seria bom ter uma forma melhor de identificá-la em entrevistas
Uma vez ouvi o arquiteto sênior da empresa reclamando depois de uma reunião: um grande diferencial de venda do nosso produto sempre foi a precisão e correção, mas o time de machine learning de outro escritório não entendia isso e achava que 80–90% de acurácia já era suficiente para os clientes
Isso lembra a discussão sobre se uma taxa de letalidade de 1% numa doença pandêmica é pequena ou grande. 1 é o menor inteiro positivo, mas 1% de 300 milhões são 3 milhões
Mas acho que o texto não está falando só disso. Ele trata das preocupações de meta nível de quem faz engenharia de software e de como a IA se encaixa nisso, e acho que acertou em cheio ao falar de “entropia do programa”
Grande parte de construir produtos de software é administrar entropia. É preciso continuar avançando num ritmo adequado enquanto se aumenta o código e o número de pessoas, e fazer com que todos entendam como as peças se encaixam e como adicionar novas peças. Talvez um dia a IA torne isso mais fácil, mas, por enquanto, muitas vezes ela piora a entropia
Isso não teria sido um problema tão grande se pessoas com interesses envolvidos não estivessem tentando convencer todo mundo de que “não, a IA pode ser usada imediatamente para tudo”
Essa premissa é tão absurda que é difícil até refutá-la pela lógica, e até agora tem sido extremamente bem-sucedida como uma narrativa baseada em fé para atrair investimentos massivos e maquiar otimização de quadro de pessoal orientada a lucro
Concordo fortemente com a premissa do texto e com a maior parte dos argumentos concretos, mas também vejo lados positivos no uso cotidiano de LLM. Para referência, trabalho na indústria de software há uns 30 anos
Lidar com código gerado por IA faz você ler código. O desenvolvimento fica mais próximo de uma sequência de revisões de código do que de uma jornada de criação a partir do zero, e, para desenvolvedores solo, isso tem a vantagem de simular e ensinar responsabilidades que normalmente são mais fáceis de aprender em equipe
Também fica claro rapidamente que, para trabalhar com LLMs, o desenvolvedor precisa entender o problema de forma clara e em camadas bem estruturadas. Pedir algo grande de uma vez só normalmente faz você dar um tiro no próprio pé, então abordar pela perspectiva de design, escrever especificações detalhadas e implementar por partes ajuda a definir os limites e as interfaces dos blocos conceituais
LLMs podem ser vistos como um poderoso acelerador para ajudar desenvolvedores juniores a crescer em direção ao papel de sênior. Com a orientação adequada, eles expõem o processo das lições que pessoas mais experientes aprenderam com o tempo. Não acho que seja tudo sombrio, nem que a IA vá substituir desenvolvedores; no momento ela é muito disruptiva, mas no fim deve encontrar seu lugar em algum ponto entre as outras ferramentas
Dá para dizer que revisar código criado com ajuda de LLM leva a ler um código mais sem graça, mas ainda assim acho que se aprende. Já li muito código gerado por LLM e com frequência aprendo expressões idiomáticas com as quais não estava familiarizado ou chamadas de biblioteca que eu não conhecia
Para desenvolvedores seniores, LLMs são um acelerador ainda mais poderoso. Eles conseguem criar prompts melhores porque sabem o que existe e o que não vale a pena tentar
Basta olhar as notícias recentes: as demissões continuam em Big Techs, empresas de tecnologia de médio porte e pequenas empresas de tecnologia
Lembra de quando diziam que a impressão 3D iria substituir toda a manufatura?
A IA está mais próxima desse sentimento do que da singularidade
Também dá para dizer que os LLMs não melhoraram algo, mas apenas expuseram falhas sistêmicas; ainda assim, o impacto em si é inegável. Dezenas de formatos de aula que eram padrão há 2 anos já não funcionam mais
Isso inclui especialmente todo o ensino online e remoto e, ironicamente, o ChatGPT surgiu justamente quando muitas universidades começaram a investir nisso após a Covid. É um impacto na escala de todo o ensino superior e médio no mundo
O setor aeroespacial é um bom exemplo. Muito do que a SpaceX e as startups mais novas da área fazem talvez não fosse possível sem peças impressas em 3D. Componentes como bicos, câmaras de combustão e turbobombas são frequentemente impressos
Ainda assim, essa comparação não parece justa. Quando eu fazia engenharia mecânica, a impressão 3D me permitia prototipar mais rápido e mais barato e cometer erros, o que na verdade melhorou minhas habilidades de engenharia
Ela não substituiu toda a manufatura, mas teve um papel importante no design e não atrofiou a habilidade de quem a usa
LLMs são impressionantes para escrever código, mas péssimos para possuir e manter esse código
Cada linha aceita sem compreensão é entendimento emprestado, e na manutenção isso é pago com juros altos. Parece velocidade grátis, mas na prática está mais para dívida técnica com juros de uns 40% ao ano
Nosso grupo precisa encontrar uma forma de automatizar a digitação com IA, mas não automatizar o pensamento
Mas não entende, e pelo modo como funciona, não pode entender
Portanto, toda linha de LLM aceita sem compreensão é, na verdade, entendimento inexistente. É apenas uma linha de código cuspida por um modelo probabilístico, e continua sem ser compreendida até ser vista por uma entidade capaz de realmente entender o contexto, o sistema e o design da base de código. Hoje, a única entidade conhecida assim é o ser humano
No desenvolvimento tradicional eu não gosto muito de nenhum dos dois, mas hoje os LLMs tornam ambos mais fáceis e mais úteis
E a “regra das três” praticamente deixa de valer entre componentes. O impacto do código precisa ser local, ou fazer parte de uma biblioteca de base extremamente robusta; um dos dois. Os casos intermediários fazem a complexidade de refatoração explodir
O maior sofrimento até agora foi o risco de entrada de que “LLMs não contestam prompts indutivos”
O mais frustrante é que eu posso nem perceber que estou conduzindo na direção de algo específico. Faz sentido, pensando em como LLMs funcionam, mas até uma única palavra escrita de forma ambígua pode enviesar o resultado para um rumo ruim e me levar ao oposto do que eu queria, enfiando-me na toca do coelho errada
Quando percebo, já estou no meio de um lamaçal de código remendado que mal funciona. A linguagem humana é tão ambígua e inespecífica que isso quase explica por que inventamos linguagens formais com regras, justamente para permitir precisão
Pessoalmente, também senti que minhas habilidades estavam se deteriorando rápido por causa das ferramentas de IA. Houve uma época em que, por preguiça, eu recorria à IA para toda tarefa pequena, mas, ao dar um passo atrás, percebi que nem economizava tanto tempo assim e, ao contrário, me cansava muito mais rápido lendo dezenas ou centenas de linhas de código, pensando em como a IA errou e corrigindo
Não medi isso, mas, no geral, acho que perdi muito mais tempo do que economizei com ferramentas de IA
O problema real é que a IA de fato é útil para muitas tarefas, mas quem a usa se divide em dois grupos. De um lado, gente que a aplica em trabalhos complexos onde pequenos erros se acumulam rápido; de outro, pessoas mais do tipo gerencial, que veem 200 linhas de código que não entendem sendo cuspidas na tela, chamam um app de TODO que mal funciona de “MVP” e pensam “se isso consegue fazer isso, então também consegue fazer o seu trabalho com facilidade”
Se a resposta comum for que eu usei errado ou que o modelo estava errado, eu gostaria que primeiro lessem meu comentário anterior https://news.ycombinator.com/item?id=44055448 para entender o contexto da minha experiência com essas ferramentas
Em outras palavras, a IA é minha assistente, mas a responsabilidade por entregar um resultado de qualidade e com boa manutenção continua sendo minha
Dito isso, do ponto de vista mais amplo, basta pensar na calculadora simples. A calculadora destruiu a capacidade de cálculo mental das pessoas. A IA vai fazer isso com escrita, comunicação, resolução de problemas etc.
Parece que os modelos se agarram a alguma palavra-chave específica em algum ponto do fluxo do prompt, abandonam a lógica tradicional e empurram para um caminho mais estreito que nem resolve direito o problema original. No fim, só aumenta a frustração e a infelicidade do lado humano
Para evitar a deterioração das minhas habilidades, tento usar IA só em tarefas pequenas e claras que eu antes resolveria pesquisando no StackOverflow. Em vez de buscar “como faço X?”, faço a mesma pergunta ao modelo e uso a resposta não como verdade, mas como orientação para resolver o problema
Ainda assim, hoje há coisas que a IA realmente facilita. Por exemplo, se existe um exemplo para imitar, como “faça igual a esta página, mas use dados x em vez de y”, muitas vezes é mais rápido do que procurar a documentação. Há o indício de que pode alucinar, mas também há boa chance de isso melhorar com o tempo
A melhoria que eu gostaria de ver, junto com uma precisão melhor no geral, é que ela encontrasse a solução mais simples sem que eu precise dizer isso toda vez. O maior defeito ao soltar ChatGPT, Claude etc. hoje é que eles produzem um monte de lixo rapidamente e não param para dizer “isso vai ficar complexo demais para lidar depois”. O texto original argumenta que só um humano que entende a arquitetura inteira consegue resistir à entropia; não sei se isso nunca vai melhorar, mas hoje esse parece ser o maior problema
Na primeira rodada, normalmente aparecem as principais suposições que o modelo está fazendo, e daí dá para ir afunilando e esclarecendo
Lendo comentários antigos mostrando que várias tentativas já foram feitas, parece que a experiência da pessoa com LLMs é muito mais ampla que a minha. Mesmo assim, como não vi essa técnica, deixo registrada caso ajude alguém
Frases como “não consegue inferir ideias, diagramas e especificações de requisitos” e “só humanos conseguem reduzir complexidade” parecem casos em que há uma ideia interessante seguida de afirmações específicas claramente erradas
Isso é muito fácil de fazer. Basta pedir código mais simples. Eu uso bastante para obter uma segunda opinião e tenho tido bons resultados
Se você não consulta o modelo, não obtém nem respostas complexas nem respostas simples. Escolher consultar por padrão também é uma escolha, não algo inerente ao conceito de LLM
Também uso bastante para converter entre código e ideias/diagramas em ambos os sentidos. Não entendo por que fazem afirmações tão fortes que a prática diária desmente
O texto repete uma lógica estranha que parece certa à primeira vista, mas não se sustenta quando examinada de perto. A conversa sobre Naur já virou meme e é repetida como se fosse um insight sobre a realidade, mas esquece outra regra fundamental e prática da engenharia de software: qualquer programa não trivial logo ultrapassa a capacidade de uma única pessoa de manter a teoria completa na cabeça
Quase nunca trabalhamos com uma teoria de programa realmente adequada. Linguagens de programação, técnicas, metodologias e ferramentas evoluem todas na direção de permitir que as pessoas trabalhem melhor sem entender a maior parte do código
Nesse ponto, humanos compartilham limitações semelhantes às dos LLMs; apenas administramos melhor isso porque não precisamos esperar até nos ser permitido mais um loop de raciocínio para obter outra perspectiva
Acho que uma lógica parecida pode ser aplicada a tecnologias de mapas como Google Maps ou Apple Maps. O argumento é que, ao usar essas ferramentas, a capacidade de navegar no mundo físico, o senso de direção e a noção geográfica se atrofiam
Na prática, isso não está exatamente errado. Hoje em dia, muita gente tem dificuldade para encontrar o caminho sem uma muleta como o Google Maps, e a relação com o mundo físico também mudou em vários aspectos
Mas, no passado, muita gente também não era especialmente boa em se localizar. Especialmente em áreas desconhecidas, a capacidade média de ir do ponto A ao ponto B com segurança e consistência claramente aumentou muito
E, para a pequena minoria que tem talento natural para geografia e orientação, ferramentas como Google Maps não substituíram essa capacidade, mas a complementaram
Acho que com a IA vai acabar sendo algo parecido, em escala maior. Certamente há trade-offs e algumas técnicas e habilidades vão se perder, mas muito mais gente vai conseguir fazer coisas que antes não conseguia, e uma minoria vai passar a fazer melhor o que já faz
Claro, nem sempre é assim. Mapear o mundo inteiro é uma tarefa extremamente complexa, cheia de exceções e casos de borda. Mas, comparado com a saída de um LLM, a diferença é enorme. Mesmo deixando a temperatura em 0 e regenerando o mesmo prompt várias vezes, a saída varia bastante
Além disso, como LLMs lidam com uma faixa conceitual muito mais ampla, as pessoas vão acabar usando isso no lugar da própria cabeça em muitas situações em que realmente não deveriam. Só com mapas já tem gente que entra com o carro num lago porque o Google Maps disse que era caminho; nem dá para imaginar o que acontece quando alguém trata a saída de um LLM como verdade absoluta e substitui o próprio raciocínio por ela
Onde eu moro, o Google Maps é melhor do que taxistas em 90% dos casos
IA não é melhor nem do que alguém que está fazendo esse trabalho há poucos dias
Na prática, 70% dos funcionários fazem o trabalho tão porcamente que a IA frequentemente entrega o mesmo ou até melhor
A dificuldade de verdade é que quem já fazia tudo de qualquer jeito continua inútil mesmo usando IA, enquanto o restante aprende e evolui junto com ela
Com direção totalmente autônoma é parecido. O FSD é melhor do que motoristas humanos ruins, bêbados ou mandando mensagem, e há muitos desses nas ruas
Fico curioso sobre de onde o autor tirou a sensação de que “[IA] não consegue trabalhar no nível conceitual”
O que os LLMs recentes vêm demonstrando repetidamente é que eles claramente conseguem operar no nível conceitual, por exemplo traduzindo corretamente, de acordo com o contexto, um conceito de uma língua para outra
Dizer que eles não “entendem” conceitos como um humano entende é outra questão. Eles não “entendem” dor porque nunca a experimentaram, mas humanos também falam o tempo todo sobre coisas que nunca viveram diretamente. Se isso é aceitável ou não é outro assunto
Isso é um modelo fraco de alguns aspectos de algo como associação. Por exemplo, “dog” se associa a “cat”. Mas não modela coisas como composicionalidade, implicação ou o papel que termos desempenham em condicionais contrafactuais
Ainda assim, se a pergunta for parecida com os dados de treino, é possível obter à força uma capacidade conceitual aparente. Se alguém perguntou “cachorros seriam felizes brincando em Marte?” ou um conjunto de perguntas suficientemente parecido, então “dog” pode ser posicionado perto do agrupamento de “fatos literais” e de alguns contrafactuais já conhecidos
Para ver a diferença entre isso e uma capacidade mental real, basta notar que combinações conceituais de profundidade arbitrária são infinitas e podem ser compostas por um número infinito de contrafactuais. Uma criança com apenas elementos básicos e imaginação consegue avaliar essa diversidade infinita
É por isso que LLMs são mais usados em áreas estreitas em que o “trabalho conceitual” necessário é muito bem documentado e suficientemente estável, especialmente engenharia de software
Estou cada vez mais inclinado a transformar 90s.dev em uma comunidade sem IA. Um lugar focado na arte antiga de escrever bom software e que acolha todos que aprimoraram essa habilidade
O que seria necessário para começar? Um fórum? Uma mailing list? Um modelo que agregue blogs de vários autores, como o hackernoon?
Criei uma mailing list provisória para os interessados em https://github.com/sdegutis/90s.dev/issues/2; para receber e-mails sobre o tema, basta assinar ou comentar
Fóruns saíram de cogitação porque foram destruídos por LLMs e bots. Para algo assim funcionar, teria de ser só por convite, e cada pessoa que recomendasse alguém teria de se responsabilizar pela própria árvore de convites
A comunidade teria de ser boa o bastante para que perder o acesso incentivasse bom comportamento. Em certas comunidades online, esse modelo funciona muito bem