- As discussões atuais sobre LLMs estão acontecendo sem uma base quantitativa clara
- A experiência de cada usuário é muito fragmentada, e quase não se compartilham elementos centrais como o ambiente real de uso ou o conhecimento de contexto
- Devido à sua natureza não determinística, até a mesma tarefa pode gerar resultados diferentes em momentos distintos, o que limita a confiabilidade
- As alegações exageradas de líderes do setor acabam incentivando aceitação acrítica e expectativas excessivas
- Na prática, o autor também usa vários ferramentas de IA no dia a dia e compartilha a experiência real de conseguir o resultado desejado apenas em cerca de metade das tentativas
Debate em torno dos LLMs e visão sobre a tecnologia
Críticas aos LLMs e o clima ao redor
- Nos debates recentes sobre IA, especialmente LLMs (modelos de linguagem de grande escala), criou-se um ambiente em que perspectivas críticas costumam ser tratadas com desdém como "opiniões de pessoas que não entendem a tecnologia de verdade"
- Em espaços como o Hacker News, repete-se a reação de que "fazer perguntas sobre IA revela ignorância sobre sua essência"
A diferença de experiência entre usuários
- Sobre a utilidade real dos LLMs, há uma divergência entre usuários que dizem "ajuda até certo ponto" e outros que afirmam "já tentei de tudo, mas não serve para muita coisa"
- Essa diferença existe porque não são compartilhados critérios concretos nem informações detalhadas sobre a experiência
- em que tipo de projeto foi usado
- qual era o estado da base de código (projeto novo, código maduro, código-fonte privado etc.)
- qual era o nível de especialização do usuário e o quanto essa especialização se conectava ao problema real
- quanto esforço adicional foi necessário para refinar e realmente colocar em produção o resultado gerado pelo LLM
A dificuldade de comparar experiências e a não determinismo
- Mesmo que um usuário compartilhe todas as informações em detalhes, a comparação de experiências com a de outro usuário continua praticamente impossível
- LLMs e agentes de automação são, por natureza, não determinísticos
- mesmo ao pedir a mesma coisa da mesma forma para o mesmo problema, obtém-se um resultado diferente a cada vez
- há muitos fatores variáveis, como o tipo de projeto, o modelo usado, as ferramentas e a linguagem, o que dificulta uma validação consistente
Líderes do setor e expectativas exageradas
- Há muitos casos em que líderes do setor enfatizam em excesso os resultados dos LLMs
- Exemplo: um líder do setor relatou que, usando o "Claude Code", conseguiu corrigir bugs antigos com uma facilidade surpreendente, e isso recebeu grande repercussão pública sem compartilhamento de detalhes
- informações essenciais como tamanho do código, dificuldade do bug, trabalho adicional necessário e a linguagem ou framework usados foram omitidas, enquanto apenas a mensagem muito positiva se espalhou
- casos assim registram mais de 1,8 mil reações positivas e 204 repostagens, mostrando como o marketing exagerado se espalha com facilidade
Experiência de uso e percepção da realidade
- O autor também usa diariamente várias ferramentas de IA, como v0 da Vercel, Claude Code e Midjourney
- criou um app de monitoramento em SwiftUI sem ter conhecimento de Swift
- gerou automaticamente pôsteres para eventos com Midjourney
- escreveu funções de servidor MCP baseadas em Elixir, entre outras experiências
- Mas a taxa de sucesso é de cerca de 50%, e os resultados nunca são consistentes
- Às vezes os LLMs realmente parecem mágica, mas na prática não passam de modelos estatísticos não determinísticos
- Nesse contexto, o debate do setor estaria preso apenas a uma dicotomia (mágica vs. engenharia)
Conclusão
- O cenário em torno dos LLMs e da IA tende a preferir imaginação exagerada, expectativa e crença, sem um sistema de verificação sólido e claro
- É importante não abandonar o pensamento crítico e continuar tentando verificar em detalhe as funções e os efeitos reais
- O que importa no debate é o compartilhamento de informações concretas e quantitativas
- É necessário um olhar equilibrado sobre os limites e as possibilidades dos LLMs
1 comentários
Comentários no Hacker News
Fico frustrado ao ouvir a diretoria no meu trabalho falar em aumento de produtividade de 10x. Alguns até repetem isso porque os primeiros adotantes da empresa disseram exatamente isso. Mas essa expectativa é alta demais. A lei de Amdahl pesa bastante aqui: passo a maior parte do meu tempo não programando, mas pensando e me comunicando. Mesmo que programar fique realmente 10x mais rápido — e na maioria dos casos não fica — o ganho total de produtividade seria só de 10 a 15%. Ainda assim é um resultado bem bom, mas não é 10x
Talvez porque meu trabalho atual seja mais voltado a P&D, os LLMs me ajudam tanto na parte de "pensar" quanto na de "programar" (a parte de comunicação eu resolvo bem por conta própria). Usar LLM para pensar parece um pouco como dominar a busca na web 20 anos atrás. Os buscadores antigos exigiam que eu soubesse o que procurar; agora o LLM descobre até o que eu deveria procurar primeiro — e às vezes ainda procura por mim. Coisas que antes eu classificaria como difíceis agora consigo resolver facilmente com ajuda de LLM. Hoje faço cerca de 1/3 das minhas buscas na web com o ChatGPT o3. Não consigo mais imaginar abrir mão disso. E ainda tem o fator psicológico de o LLM ajudar a organizar pensamentos incompletos e servir como interlocutor. Isso faz muita coisa parecer bem menos intimidante, e essa diferença também é grande
Na minha empresa a situação é parecida. Os ganhos de produtividade alegados pelos primeiros adotantes internos costumam ser medidos de forma muito estreita, ou então a conta em si é meio frouxa
Os LLMs talvez acelerem mais desenvolvedores sênior do que júnior (porque o júnior nem sempre consegue distinguir bem código bom de código ruim). Um sênior usando um workflow aprimorado com LLM talvez chegue à produtividade que antes exigia dez juniores. E um dev ruim pode até tornar a produtividade efetivamente negativa, porque consome o tempo do sênior. Até um júnior razoável acaba preso em tarefas repetitivas que o LLM já faz melhor. Então acho plausível que empregos realmente desapareçam
Se usar ferramentas de LLM só aumenta a produtividade em 10–15%, mas o custo dessas ferramentas faz o custo de contratação subir 10–15%, então não vejo grande vantagem. É preciso considerar o custo total da produção
Em projetos pessoais, eu facilmente chego perto de 10x mais velocidade. Mas em empresas isso não encaixa bem por causa de discussões com várias equipes, mudanças de requisitos, revisão de PR etc. Esse tipo de design otimizado e de padrões padronizados só funciona em startup pequena ou projeto solo. Quando várias pessoas entram, só chegar a consenso já é difícil. Para a IA dar o melhor resultado, tudo precisa estar padronizado, mas na prática tudo fica um pouco desalinhado, então é difícil obter esse efeito em organizações reais. Talvez 10x seja possível entre poucos devs muito alinhados, mas em ambiente corporativo é quase impossível. Acho que a IA combina mais com gerência intermediária e planejamento de projeto
Eu sou exatamente o tipo de pessoa de quem o autor está reclamando. Lancei um produto greenfield numa época em que o ChatGPT ainda era bastante limitado. Depois usei Claude com copiar/colar entre web chat e XCode, e mais tarde Cursor. Às vezes apareciam erros de build, mas mesmo assim minha produtividade foi pelo menos 3x maior. Agora, com agentes melhores e o Claude 4 disponível, eu quase não programo mais. Atuo como Architect/Manager e uso meu conhecimento para dirigir bem os agentes. Estou numa startup e faz meses que não escrevo uma linha de código diretamente. Eu reviso tudo antes de abrir PR e testo com bastante rigor, mas a combinação Cursor+Sonnet é absurda. Contagem de linhas não importa, e na verdade especialistas antigos do codebase vivem vindo me perguntar sobre bugs pequenos. Com Claude eu até mexi em trabalho de frontend, então tento me policiar. Não é só jogar prompts: faço pesquisa cuidadosa, planejamento e exploração passo a passo. Conhecimento de domínio é essencial. Mesmo assim, me surpreende que haja gente que não consiga tirar tanto proveito disso. Parece que vejo dois artigos desse tipo por semana
Minha experiência é parecida, mas em outro contexto: sou estudante de PhD. Eu era cético com LLM, mas depois do Claude Code minha forma de trabalhar mudou completamente. Ainda assim, a curadoria continua inteiramente por minha conta — o que é uma soft skill importante do doutorado, além de os LLMs perderem rápido o objetivo e o contexto, ou simplesmente não lembrarem. Se você consegue se comunicar com precisão, dá para organizar computação com o CC de um jeito que antes era impossível. Não é que programar fique mais fácil; surge um formato completamente diferente de trabalho
Tenho curiosidade sobre o processo real de validação e inspeção: como você revisa rapidamente código não confiável gerado por LLM, se o LLM também escreve os testes unitários, qual é o tamanho médio dos prompts etc.
O ponto é se você confia diretamente na saída do LLM. Ele não entende o contexto completo do projeto, e alucina bastante, então precisa de validação
Acho que a qualidade do código de LLM ainda é fraca no geral. Muitas vezes precisa de várias rodadas de correção, e aí escrever eu mesmo acaba sendo mais rápido. Mas para refatorações mecânicas em larga escala, agentes são muito úteis. Em vez de montar macros complexas de vim ou scripts de AST, uso agente
Pessoalmente, acho que passar meses sem escrever uma linha de código seria entediante demais
Você acabou de confirmar exatamente o que o post do blog dizia: alegações difíceis de verificar, promessas gigantescas de resultado etc. E a conta até parece recém-criada
Na minha visão, a maior parte do trabalho real no setor de serviços é manual: mover dados entre planilhas de Excel, CRM, e-mail e de volta para Excel. Em empresas grandes, acho que deve haver umas cem vezes mais funcionários em tempo integral fazendo esse tipo de trabalho repetitivo do que engenheiros de software. Então pouco importa se o LLM não sabe OCaml; se ele for só um pouco melhor que um humano no Excel, já gera valor enorme. Se você conectar e-mail, CRM e Excel com algo como MCP, a taxa de erro e de alucinação cai bastante. Humanos também são não determinísticos, então para esse tipo de processo determinismo não é tão importante. LLM e crypto são completamente diferentes em utilidade e adoção. Isso me lembra a popularização dos smartphones. Até meus amigos não técnicos agora usam LLM para muita coisa diferente
Acho que a comparação com crypto não ajuda muito. Tecnicamente não tem relação nenhuma. O que existe é excesso de confiança na tecnologia. Para quem nunca teve contato nem com automação básica, LLM pode parecer ficção científica. Nunca antes essa área ficou tão mainstream. Acho que daqui para frente vai ser um faroeste cheio de sucessos e fracassos, opiniões diversas e experiência prática. O lado bom é que agora até a ideia de app do seu amigo pode ser experimentada diretamente
Só que os FTEs que fazem limpeza manual de dados também têm responsabilidade de validar resultado, cumprir prazo e responder legalmente. O LLM não consegue checar exceções temporárias fora de contexto, como por exemplo um valor que deveria ser 0 por ser feriado. Só isso já pode justificar perfeitamente um FTE dedicado à validação
Fiquei curioso com essa proporção de 100 FTEs de trabalho manual de pipeline de dados para cada engenheiro de software. Imagino que isso valha para alguns tipos de empresa, mas não vejo a maior parte do trabalho de back office/data entry como sendo assim. Concordo com o impacto da IA, mas sou cético com a ideia de que o trabalho white-collar como um todo seja quase só e-mail e entrada de dados
Acho que você está subestimando a complexidade desse tipo de função
Como programador aposentado, não consigo imaginar entregar responsabilidade mission-critical a código gerado probabilisticamente. Se for algo que só precisa de um pequeno ajuste para ficar utilizável, aí até entendo. Fora da programação — brainstorming, pensamento criativo, apoio à pesquisa — os LLMs são impressionantes. Eu os trato como parceiros de raciocínio. Eles erram, mas geralmente dá para detectar fácil validando com outras fontes ou pedindo revisão a outro LLM
Eu também sou do tipo automaticamente cético, mas quando usei na prática ele superou minhas expectativas em todos os aspectos. Em poucas horas avancei de protótipo a lançamento em projetos que teriam levado meses. As coisas que eu já sabia fazer ficaram mais rápidas, e até coisas que eu não conseguia fazer — e que antes exigiriam terceirização ou contratação — passaram a ser possíveis por um custo pequeno e em pouco tempo. Claro que não é perfeito e tem coisas irritantes, como ignorar instruções explícitas e mentir, mas para mim foi um divisor de águas
Usar LLM como parceiro de raciocínio parece funcionar bem por um tempo, mas em algum momento começam a aparecer delírios. O LLM é muito bom em induzir a falsa impressão de que sabe ou raciocina. Isso é ainda mais perigoso em áreas que eu não domino. Num buscador, dá para comparar confiabilidade pelas fontes; no LLM isso não acontece. E detectar os erros nem sempre é fácil
Sou desenvolvedor há 40 anos e comecei a usar LLM há alguns meses; mudou bastante minha forma de trabalhar. Colo mensagens de erro de logs e consigo correções em um minuto, faço brainstorming de arquitetura, recebo sugestões de soluções novas etc. Eu valido o código, mas me surpreendo todos os dias com a precisão e a inteligência. (Não tem nada a ver com crypto)
Sou cético com LLM, mas no fundo todo código escrito por humanos também é probabilístico. É por isso que existem code review, testes unitários, pair programming e guias. Nem a saída do LLM nem a de uma pessoa devem ser usadas sem crítica. Minha preocupação é que LLM não é mágica e pode acabar sendo usado de forma nociva para despejar boilerplate, ignorando eficiência, segurança, refatoração e outros valores de longo prazo, exceto nos casos em que realmente ajuda
Na minha opinião, a área em que os LLMs são melhores é data science. A entrada e a saída são claras, então fica fácil validar o resultado. Se você conhece as características dos dados, também é fácil mandar gerar código de teste. Quando o problema exige contexto, o Claude Code muda bastante o jogo. Exemplo: extrair múltiplas mensagens dentro de cada pacote UDP de um arquivo PCAP, filtrar, fazer pattern matching, separar para testes etc. Se eu digo "escreva testes unitários para todas essas funções", o LLM consegue até fazer autoverificação
Eu uso LLM quase todos os dias há um ano, e em 90% dos casos ele resolve meu problema. Não sei em que momento opiniões negativas sobre AI/LLM deveriam ser levadas realmente a sério. Pela minha experiência, nunca foi questão de jogar o codebase inteiro lá dentro e esperar mágica; sempre fiz perguntas exatas e específicas sobre coisas que eu conheço e entendo, e aplico as soluções de modo verificável. Se não for assim, você está usando LLM errado. Para sentir a mágica de verdade, o segredo é um uso pequeno, cotidiano e consistente
Num tom de paródia de Weatherman: "funciona sempre com 60% de probabilidade". Eu também uso GPT e Claude no Cursor todo dia. O GPT o3 é bom para busca de conhecimento geral, e o Claude às vezes falha. O modelo em si é meio burro, mas de vez em quando acerta em cheio. Acho que dá para usar produtivamente se você souber o que quer e souber domar o LLM
Também acho difícil acreditar nessa afirmação de que "na minha experiência, funciona em 90% dos casos"
Parece que o autor está irritado com comentários imprecisos dos debatedores. Na prática, acho que os próprios usuários/promotores, por baterem nisso todos os dias, conhecem bem os problemas e limitações dos LLMs. Tradução, transcrição, geração de código até certo porte e outros problemas que antes eram impossíveis ou quase impossíveis agora estão totalmente ou quase totalmente resolvidos
Tradução, transcrição e geração de código eram mesmo quase impossíveis? Google Translate, Whisper e outras coisas do tipo já existiam há muito tempo
Quem revela defeitos reais são os detractors, e não os promoters; muitas vezes os promotores é que exaltam LLM sem crítica, como se fosse solução para tudo
Ultimamente tenho achado o uso de AGI e AI muito vago, especialmente em artigos científicos. No mínimo, gostaria que cada artigo deixasse clara a própria definição. Se você definir claramente o que é AGI, então dá até para provar logicamente que uma certa IA atende ou não à definição. Mesmo que isso pareça não ter utilidade prática, ainda é muito melhor do que usar termos sem sentido. Hoje parece que usam AGI sem definir e depois escapam da discussão. A Wikipedia fala em "quase todas as tarefas cognitivas em nível humano ou superior", mas isso é impossível de medir. Fico me perguntando por que usar um termo tão vazio
Nem todo mundo precisa usar a palavra com exatamente o mesmo sentido. Basta você ter seu próprio critério para AGI, mesmo que a maioria não concorde. Para mim, crypto originalmente é cryptography. O critério dominante e o meu critério pessoal podem ser diferentes
Se existe uma definição de AI, é "aquilo que ainda não foi realizado", como explica o efeito IA
Recentemente minha empresa começou a usar LLM. A primeira tarefa foi transcrever 20 mil ligações de atendimento ao cliente e extrair dados delas — produtos comparados, problemas, casos de uso típicos etc. Uma pesquisa que antes levaria semanas ficou pronta em poucas horas. Montamos até uma nova estratégia de negócio e obtivemos valor real com isso. LLM é excelente como motor de processamento de linguagem natural. Tem muito marketing exagerado, mas para nós foi algo concretamente útil. É só uma ferramenta; não sinto necessidade de provar isso para ninguém
Acho que o hype não é totalmente inofensivo. Ele pode distorcer o mercado, gerar investimento excessivo, enxugamento organizacional e expectativas impossíveis. Artigos desse tipo são necessários para esfriar o mercado e as expectativas. Quem vende LLM normalmente não fala só de resumir ligações de atendimento; fala de todo tipo de cenário exagerado de substituição de pessoas
Parece que só quem nunca teve experiência resolvendo processamento massivo de dados de forma confiável diz que LLM não serve para nada. Hoje até tradução pode ser feita com muito mais contexto
Pessoas respeitadas do setor de tecnologia dizem diretamente que GenAI ajuda muito na produtividade de desenvolvimento. O significado pode variar de 5% a 100%, mas no mínimo isso deveria bastar para tratar como uma ferramenta bastante útil. Não acho que seja preciso números concretos como linhas de código, bytes ou CPU para sustentar essa afirmação
A tecnologia de LLM certamente vai acabar encontrando usos adequados, mas já tem gente demais usando errado e isso não tem mais volta. Muitos desenvolvedores iniciantes vão fracassar assumindo riscos, muito investimento vai ser desperdiçado, e as empresas já estão tão comprometidas que não conseguem mais desistir e resolveram apostar tudo