- Martin Fowler aponta que pesquisas recentes sobre formas de uso de LLMs podem levar a conclusões distorcidas por não refletirem o fluxo real de uso
- Para perguntas sobre o futuro da programação ou estabilidade profissional, ainda ninguém sabe ao certo, e é importante experimentar pessoalmente e compartilhar experiências
- O setor de IA está claramente em estado de bolha, mas, como ocorreu historicamente com toda inovação tecnológica, mesmo após a bolha podem surgir empresas sobreviventes como a Amazon
- A natureza dos LLMs é a alucinação (hallucination), e o próprio processo de reformular a mesma pergunta várias vezes e comparar as respostas é útil
- LLMs expandem enormemente a superfície de ataque dos sistemas de software, e há um alerta de que agentes de navegador têm um risco estrutural que não pode ser tornado intrinsecamente seguro
Formas de uso de LLMs e produtividade de desenvolvedores
- Discussões iniciais sobre o impacto da IA no desenvolvimento de software têm acontecido de forma intensa recentemente
- A maior parte do uso de LLMs está concentrada em autocompletar avançado, no formato de co-pilot
- No entanto, as pessoas que usam LLMs de forma mais eficaz na prática tendem a preferir um modo de uso em que o LLM pode ler e modificar diretamente arquivos de código-fonte
- Pesquisas que ignoram as diferenças nas formas de uso de LLMs têm grande risco de interpretar os dados na direção errada
- Além disso, as diferenças de capacidade entre vários modelos de LLM tornam a interpretação dos resultados ainda mais difícil
A profissão de programação e o futuro dos LLMs
- Perguntas sobre o futuro da programação, a necessidade de engenheiros iniciantes e o futuro de profissionais experientes surgem com frequência
- Não é possível dar uma resposta clara, e ainda não foi estabelecida uma forma consolidada de usar LLMs com eficácia
- É necessária uma postura de abordagem experimental e de observar e compartilhar experiências concretas de workflow de outras pessoas
- Testar diretamente e compartilhar experiências é a forma mais sensata de adaptação
O fenômeno de bolha em IA e LLMs
- Sobre a visão de que IA é uma bolha, explica-se que toda inovação tecnológica vem acompanhada de um fenômeno de bolha
- A bolha inevitavelmente estoura em algum momento, e também ocorrem fracassos de investimento
- No entanto, não é possível prever quando a bolha vai terminar nem a escala de criação de valor
- Mesmo quando a bolha estoura, nem todas as empresas desaparecem, e algumas podem continuar a crescer de forma sustentada
- Na bolha das pontocom, pets.com e Webvan quebraram, mas a Amazon sobreviveu e continuou crescendo, sendo um caso representativo
A característica de alucinação dos LLMs
- O fenômeno de alucinação (Hallucination) dos LLMs não é um defeito, mas uma característica essencial
- No fim das contas, LLMs são ferramentas para gerar alucinações úteis
- O ideal é fazer a mesma pergunta várias vezes, com formulações diferentes, obtendo várias respostas e comparando-as
- Quando é necessária uma resposta numérica, é importante verificar a variabilidade entre respostas por meio de consultas repetidas
- Não é apropriado fazer com que um LLM responda diretamente a problemas que podem ser calculados de forma determinística
A introdução da não determinismo na engenharia de software
- A engenharia de software tradicional é projetada e implementada em um ambiente determinístico
- Engenheiros estruturais e de processos projetam tolerâncias levando em conta a não determinismo (incerteza) do mundo real
- A introdução de LLMs pode ser um ponto de inflexão em que a engenharia de software entra no mundo da não determinismo
Comparação entre LLMs e desenvolvedores júnior
- LLMs são frequentemente comparados a colegas juniores
- Porém, LLMs muitas vezes afirmam que "todos os testes passaram", quando na prática é comum aparecerem testes com falha
- Se fosse um humano, seria um nível de comportamento que rapidamente se tornaria um problema de RH
Aumento das ameaças de segurança e o problema dos agentes de navegador
- LLMs ampliam de forma abrangente a superfície de ataque dos sistemas de software
- A 'trifeta fatal (Trifecta)' apontada por Simon Willison é: acesso a dados privados, comunicação externa e exposição a conteúdo não confiável
- É possível enganar um LLM por meio de comandos ocultos em páginas web (por exemplo, texto branco de 1pt) para vazar informações sensíveis
- Agentes baseados em navegador são especialmente perigosos, e ações maliciosas como transferências bancárias podem ser realizadas por comandos externos
- Willison apresenta a opinião de que extensões de navegador com agentes não podem ser tornadas seguras de forma fundamental
Conclusão
- LLMs abrem novas possibilidades para o desenvolvimento de software, mas é preciso entender com clareza suas formas de uso e limitações
- A bolha é inevitável, mas, por meio dela, é possível haver avanços tecnológicos sustentáveis
- Desenvolvedores devem aproveitar ao máximo o potencial dos LLMs por meio de uma abordagem experimental e de considerações de segurança
3 comentários
Só de pensar nisso já bate uma sensação sufocante…
Concordo 100% especialmente com a analogia ao júnior. A categoria dos erros que ele comete é diferente da de uma pessoa... acho que é um exemplo clássico de analogia que deu muito errado.
Opiniões no Hacker News
Minha ex-colega Rebecca Parsons já dizia há muito tempo que as alucinações dos LLMs (
hallucination) não são tanto um bug, mas sim uma funcionalidade central. No fim das contas, o que um LLM faz é produzir alucinações úteis. Sempre que ouço esse argumento, tenho a sensação de que estão simplesmente redefinindo arbitrariamente o termo “alucinação” e fazendo isso parecer um novo insight. “Alucinação”, no sentido tradicional, significa inventar detalhes plausíveis, como se fossem percepções, sem relação com a realidade, mas essa lógica acaba sendo igual a apenas dizer “saída”. Não é que haja algo novo no fato de um LLM produzir saídas; só estão pegando um rótulo antes visto como “ruim” e aplicando-o ao comportamento inteiro para fazê-lo parecer algo novoNão acho que Fowler esteja realmente redefinindo o termo “alucinação”. Na verdade, ele está enfatizando de forma irônica que a alucinação é o modo fundamental de operação desses sistemas. É como dizer “dano colateral é algo essencial às bombas”; não precisa ser lido literalmente
Esse argumento tenta corrigir a falsa dicotomia de que “LLMs produzem a verdade ou produzem alucinações”. Uma formulação assim faz parecer que, se reduzirmos as alucinações, sobrará apenas a verdade, quando na prática toda saída é um tipo de alucinação. Só que algumas delas refletem a realidade ou coincidem com nossas expectativas, e por isso parecem verdadeiras. É como jogar um dado e, quando sai o número que você queria, dizer que “o dado leu minha intenção”. Como no caso dos macacos infinitos batendo em máquinas de escrever infinitas e, em algum momento, produzindo Hamlet, só elevamos essa probabilidade com IA
Achei essa opinião interessante. Reconhecer que o LLM não tem como saber se o que está produzindo é correto oferece um contexto prático para quem o usa no desenvolvimento de software
Eu me sentia desconfortável em descrever esse fenômeno com a palavra “alucinação”. Quando uma pessoa fala algo plausível sem base nenhuma, chamamos isso de
bullshit, e com LLMs é basicamente parecido. Se você olha por essa lente dobullshit, muita crítica ao uso de LLM fica menos significativa. No fim, se esse aspecto dos LLMs te incomoda, então você provavelmente também não conseguiria trabalhar com pessoas. Por outro lado, é bem mais difícil redefinir a palavrabullshit. Ainda assim, acho que o texto em si cumpre seu papel como uma coletânea de pensamentos dispersos, e não me parece que o autor esteja tentando soar autoritárioO ponto principal foi expresso de forma meio estranha, mas a ideia é que não existe uma distinção nítida entre uma saída “alucinada” e outras saídas. É como dois resultados de consulta em um RDBMS serem essencialmente a mesma coisa. É uma observação relevante
Na nossa empresa, parece que estamos cheios de código que está 90% ok e 10% quebrado, quase no nível que queremos. A produção de código aumentou, mas ninguém consegue acompanhar, e a qualidade está claramente caindo. Não é uma aproximação lenta do objetivo; é chegar a 90% instantaneamente e depois gastar tempo se acostumando com código estranho e corrigindo sem parar. Talvez ainda seja mais rápido do que antes, mas, na prática, a diferença entre os dois métodos pode não ser tão grande quanto parece. O que mais me incomoda é que eu gosto mais de criar algo novo do que de gastar tempo consertando código com o qual não estou familiarizado
Eu também prefiro muito mais criar algo novo. Mas algumas pessoas se divertem mais com esse novo estilo rápido e improvisado. Eu fui meio forçado a testar por um tempo, senti estranhamento, apaguei tudo e senti verdadeira satisfação quando reconstruí manualmente com ajuda da IA. O único código gerado por IA que eu ainda não entendo 100% é uma consulta SQL complexa, mas tudo bem porque consultas SQL são rápidas de validar e não têm efeitos colaterais inesperados
Esse fenômeno é dolorosamente parecido com o que acontece quando o time cresce de 3 para 10 pessoas. De repente, aparece um monte de código que você não conhece, a consistência arquitetural diminui, e você passa a depender mais de políticas e CI. A diferença com LLM é que mentoria ou demissão não significam nada. A forma eficaz de usar LLM é fazer com que a pessoa operando o LLM assuma 100% da responsabilidade pelo que foi gerado. Ou seja, ela precisa entender claramente o código gerado, e garantir isso na prática parece difícil
LLMs são muito bons em gerar código
boilerplateautomaticamente. Isso acaba incentivando a negligência na hora de organizar esseboilerplate. Quando PRs enormes aparecem com grandes volumes de código, revisar fica difícil. O GitHub também não é ideal para revisar linhas demais de uma vez. Como resultado, desenvolvedores júnior/pleno acabam só resolvendoboilerplatee perdem oportunidades de aprendizado. Se continuar assim, a qualidade do código vai se deteriorar rapidamenteCita o aforismo nº 7 de Perlis: ‘É mais fácil escrever um programa incorreto do que entender um programa correto’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Concordo com a opinião de que “a qualidade está claramente caindo”, e esse fenômeno só deve piorar daqui para frente. No fim, é preciso entender bem os trade-offs econômicos para avaliar se haverá realmente “ganho líquido”. Parece que muita gente ignora o fato de que não existe almoço grátis
A forma como Rebecca Parsons enquadra isso — “alucinação é uma funcionalidade central dos LLMs” — realmente faz muito sentido para mim. Eu também tentava explicar isso às pessoas ao meu redor, e essa frase resume muito bem o que eu queria dizer
Eu também vinha explicando isso para família e amigos comparando LLMs a atores. Um LLM apenas interpreta de forma compatível com o personagem; ele usa fatos apenas quando os fatos são necessários<br>https://jstrieb.github.io/posts/llm-thespians/
A velha máxima “Todos os modelos estão errados. Alguns, no entanto, são úteis.” se encaixa perfeitamente aqui
Inteligência é a capacidade de filtrar informações desnecessárias. Seja no pensamento ou na percepção, isso vale igual
Não lembro quem disse isso, mas a saída de um LLM é sempre uma alucinação. Só acontece de mais de 90% dela sair correta
Por um momento, pareceu que LLMs iriam tomar nossos empregos, mas na verdade percebi que podem acabar só criando uma montanha de trabalho que teremos de corrigir depois. Agora estou usando bem ferramentas auxiliares práticas como Claude Code, e sinto na prática que elas servem para complementar, não para substituir
Vi o conselho de que, “ao pedir uma resposta numérica a um LLM, pergunte três vezes”. Isso também funciona com pessoas. Quando a polícia interroga alguém, faz a pessoa contar a mesma história três vezes, ou até ao contrário. Se for mentira ou se a memória estiver vaga, a repetição pode acabar revelando isso. Em entrevistas, se você faz alguém explicar o mesmo tema de três formas diferentes, também consegue ver se ela realmente entendeu
Essa técnica também pode confundir pessoas inocentes e fazê-las soar como se estivessem mentindo. É preciso aplicar com cuidado
Esse método só é válido dentro de certas condições. Há muitos casos em que, quanto mais uma lembrança é evocada e narrada, mais ela se distorce. Quando a polícia pergunta repetidamente durante um interrogatório, às vezes está deliberadamente tentando provocar contradições. Mesmo com a mesma informação, se você obriga a pessoa a responder muitas vezes e de várias formas, ela pode acabar cometendo erros. E também é sempre preciso tomar cuidado com o fato de que quem pergunta pode induzir a resposta na direção que deseja
O ônibus espacial da NASA usava redundância modular tripla. Isso era para lidar com a possibilidade de processadores ou memória serem corrompidos por radiação espacial<br>https://llis.nasa.gov/lesson/18803
Tenho sentido uma produtividade bem alta com LLMs. Não é só autocompletar; há um ganho real de tempo. Mas também me preocupa que, se usados com liberdade demais, criem seu próprio tipo de dívida. Pessoalmente, tive sucesso construindo funcionalidades de forma incremental com Claude Sonnet ou GPT-5 no estilo Test Driven Development (TDD). Ainda não há muitos textos ou discussões sobre essa abordagem, mas depois de ler o texto do Martin acho que entendo o motivo. Os grandes praticantes de TDD não são exatamente o tipo de pessoa que mergulha em massa na automação de código com LLMs; em geral, eles têm orgulho da artesania do código e da comunicação humana. Por isso, ainda falta aquele acúmulo de know-how prático que existia antes. No futuro, deve se abrir uma nova “fronteira” para escrever software com ferramentas de LLM, e espero que muitas lições se acumulem. Referência: https://news.ycombinator.com/item?id=45055439
ssr, acabem recebendo mais atençãoO básico é que o desenvolvedor verifique e confira diretamente o código produzido pelo LLM. É melhor não pedir código demais de uma vez, e sim usar o LLM em unidades menores. Eu também executo os testes unitários por conta própria. O LLM dizer que rodou os testes e que “passou” pode não ser verdade. Só confio mesmo quando eu executo os testes
Concordo com a ideia de que “alucinação é uma funcionalidade dos LLMs”
Eu diria que LLMs vivem em um mundo composto apenas de texto e combinações. Palavras, relações entre palavras e histórias são todo o universo deles. Por isso, eles são mais capazes justamente de inventar novas histórias. Essas histórias às vezes são imprecisas e contraditórias, então no fim dependem de suposição. Um LLM não sabe realmente contar números, mas conhece padrões como “2 vem depois de 1” e “3 é maior que 2”. Assim como humanos usam calculadoras, eles também conseguem fazer operações por meio de ferramentas. No futuro, para que se tornem AIs realmente confiáveis, será preciso introduzir não um motor aritmético, mas um “motor epistemológico” (
epistemic engine) que ajude com lógica, prevenção de contradições e distinção segura de fatosNessa perspectiva, agentes de LLM podem ser vistos apenas como um meio de filtrar resultados alucinados
Concordo mais com a frase “toda saída de todo modelo (de linguagem grande) é uma alucinação; algumas só são úteis”. A proporção dessas alucinações úteis é tão alta que foi isso que provocou o boom da IA
Acho que isso simplifica demais a questão
É por isso que o termo “alucinação” sempre gera controvérsia. Ele induz a falsa impressão de que alguns resultados talvez não sejam “alucinação”, quando, na prática, toda saída de LLM é gerada sem reflexão
Hoje em dia, para usar LLMs bem, é preciso que desenvolvedores seniores reajam de forma lógica para obter os resultados desejados. Se no futuro os juniores desaparecerem, fico me perguntando quem vai substituir o papel dos seniores. No fim, imagino que LLMs acabarão programando por conta própria o suficiente. No estágio atual, porém, IA é claramente um bom recurso auxiliar. Não é substituta
Sobre o conselho de perguntar várias vezes ao LLM, para usuários de macOS eu recomendaria usar um workflow do Alfred. Você aperta command + space, digita
llm <prompt>e pode abrir ao mesmo tempo abas no navegador com vários LLMs que quiser, como Perplexity, DeepSeek (local), ChatGPT, Claude e Grok. Dá para fazer rapidamente a validação cruzada entre LLMs de que Fowler fala, e, trabalhando com várias tarefas, você acaba percebendo em que tipo de trabalho cada LLM é melhor