Por que desenvolvedores humanos ainda são melhores que LLMs

• O criador do Redis, antirez, usa IA e LLMs com frequência, mas considera que, neste momento, a capacidade humana de resolver problemas ainda está muito à frente da dos LLMs
• Ele vivenciou diretamente as limitações dos LLMs durante o processo de correção de um bug complexo no Redis Vector Sets
• Os algoritmos sugeridos pelos LLMs ficam em soluções padronizadas ou simples
• A abordagem criativa de desenvolvedores humanos é mais favorável para propor soluções inovadoras às quais os LLMs têm dificuldade de chegar
• LLMs são muito úteis para validar ideias ou atuar como interlocutor, mas a criatividade final continua sendo humana

---

Introdução: comparação entre humanos e LLMs

• Eu não tenho absolutamente nenhuma aversão a IA e LLMs
• Há muito tempo uso LLMs no dia a dia, de várias formas, como testar ideias, revisar código e explorar alternativas
• O nível atual da IA é claramente prático e impressionante, mas enfatizo que a diferença em relação à inteligência humana ainda é grande
• Escrevi este texto porque senti a necessidade disso, num momento em que até uma discussão equilibrada sobre IA tem ficado difícil

O caso do bug no Redis Vector Sets

• Recentemente eu estava corrigindo um bug relacionado ao Vector Sets no Redis
• Como meus colegas do Redis estavam ausentes, introduzi uma proteção adicional contra corrupção de dados de arquivo (RDB/RESTORE)
  • Isso fica desativado por padrão e funciona como uma camada extra de segurança para tentar impedir corrupção mesmo quando o checksum passa
• O problema surgiu na otimização de velocidade da serialização em RDB da representação em grafo da estrutura HNSW
  • As listas de conexões entre nós são armazenadas como inteiros e, na desserialização, restauradas como ponteiros
  • Por causa de características da própria implementação do HNSW (garantia de conexões mútuas), em caso de corrupção do grafo ou da memória podem ocorrer os seguintes problemas
    • Pode estar registrado que A se conecta a B, mas B não se conecta a A (erro de numeração etc.)
    • Ao remover o nó B, por violar a conexão mútua, o link A→B pode permanecer e depois, numa busca B->A, causar um bug de use-after-free
• Depois de carregar os dados, é necessário verificar se todos os links satisfazem a condição de serem 'mútuos'
  • Ao aplicar um algoritmo puro, a complexidade é O(N^2). Em grandes volumes de dados (~20 milhões de vetores), foi confirmado que a velocidade de carregamento dobrou de 45s para 90s

Aplicação de LLMs e suas limitações

• Conversando com o Gemini 2.5 PRO, perguntei por um método mais eficiente e analisei as sugestões do LLM
  • Primeira sugestão do LLM: ordenar a lista de nós vizinhos e aplicar busca binária (binary search), um método já muito conhecido
  • Como isso não trazia grande melhora, pedi mais ideias, mas não obtive respostas melhores
• O método alternativo que propus: usar uma tabela hash para registrar e remover pares de links (A:B:X, ordenando e removendo a distinção de direção)
  • O LLM avaliou a ideia como boa, mas apontou como desvantagens o desempenho na geração das chaves e no hashing
  • Também sugeri uma melhoria de eficiência ao tratar chaves de tamanho fixo com memcpy, sem snprintf

Criatividade humana vs. limitações dos LLMs

• Propus então uma ideia usando a técnica de XOR em um acumulador, sem tabela hash
  • Pares de ponteiros (e informações de nível) são acumulados com XOR; quando a conexão é mútua, eles se anulam (0), e quando há ausência, sobra um padrão
  • No entanto, foi apontada a possibilidade de colisões e a previsibilidade dos ponteiros (o LLM também concordou com isso)
• Melhoria adicional: combinar semente aleatória/hashing (murmur-128 e semente de urandom) e aplicar XOR em um acumulador de 128 bits
  • No final, verifica-se se o valor do acumulador é 0 para determinar se a conexão mútua foi satisfeita
  • O LLM avaliou que esse método também é eficiente e mais robusto contra erros gerais e até contra atacantes externos

Conclusão

• No fim, concluí a análise para decidir se deveria adotar a abordagem com base em sua confiabilidade
• Neste caso, ficou claro que a abordagem criativa e fora do padrão de um desenvolvedor humano foi superior às respostas limitadas oferecidas pelo LLM
• LLMs são extremamente úteis para validar ideias e atuar como interlocutor intelectual (no papel de 'pato inteligente')
• Porém, na capacidade de chegar à solução criativa final, a superioridade humana continua evidente

[nb13557]

o Redis vai ficar para trás em breve

[aer0700]

Parece uma corrida de bicicleta contra corrida a pé.

[ethanhur]

antirez é um desenvolvedor humano de elite, do 1%. Acho que desenvolvedores humanos do 1% continuarão sendo melhores que os LLMs. Mas não sei como será com os outros 99%.

[spp00]

Já tentei fazer troubleshooting com IA várias vezes, tudo falhou, e no fim acabei resolvendo o problema por conta própria.

[softer]

Acho que os LLMs parecem sofisticados e criativos porque foram treinados com textos desse nível, e porque inúmeros cientistas validaram esse conhecimento e elevaram a qualidade dos dados de treinamento para melhorar os resultados.

Mas, com o tempo, as tendências mudam e, dependendo da situação, é preciso um tipo diferente de criatividade, então no fim das contas não é a pessoa que usa a ferramenta que precisa exercer a criatividade de acordo com a própria realidade..

[GN⁺]

Opiniões do Hacker News

• Isso bate exatamente com a minha experiência. Na verdade, o grande valor que um assistente com LLM me entrega é funcionar como um rubber duck bem inteligente. Às vezes esse “pato” até rebate minhas opiniões e até ajuda a refinar melhor meu pensamento. (O que é rubber duck debugging?) Mas acho que a pergunta central que todo mundo quer pular é: “esse valor vai continuar existindo daqui a 2 anos?”. Eu também não sei a resposta

  • Para mim, LLM não é rubber duck, é mais uma “máquina de respostas erradas”. Existe aquele ditado de que a melhor forma de conseguir uma resposta na internet é postar uma resposta errada; para mim ele cumpre exatamente esse papel. Se eu mando o LLM fazer uma tarefa simples, mas chata, ele entrega algo tão absurdamente errado que eu fico irritado e acabo fazendo eu mesmo na força do ódio

  • Um pato excessivamente confiante, com segurança muito acima da própria capacidade real. Já vi gente demais se perder conversando com LLM

  • Para mim, LLM é como um desenvolvedor júnior trabalhando abaixo de mim: conhece bem APIs, mas falta bom senso em arquitetura. Acabo revisando a maioria dos PRs 3 ou 4 vezes antes de mandar para review do time, preocupado com erros esquisitos. O lado bom é que isso me deixa livre para usar o cérebro em outros problemas

  • Se esse valor vai se manter daqui a 2 anos? Para mim, a preocupação maior não é “quero encerrar essa discussão”, e sim “será que a gente chega até lá daqui a 2 anos?”. O mundo está tão instável agora que nem dá para prever como vai estar em 6 meses

  • Para mim, LLM parece um colega de pair programming. Alguém com quem posso discutir ideias, que faz review de código e sugere alternativas. E também posso aprender vendo ele usar recursos que eu não conhecia

• Lendo esta seção de comentários, parece que muita gente está se agarrando a ideias como “humanos são indispensáveis”, “LLM não sabe debugar”, “LLM leva você para o caminho errado”. Claro que isso é verdade, mas a geração automática de código evoluiu absurdamente desde 2 anos atrás, quando isso era impossível, e continua avançando num ritmo rápido. Pode ser que daqui para frente a melhora desacelere, tipo uma “lei de Pareto”, mas com certeza vai continuar progredindo. Recentemente, no r/fpga, eu contei que consegui usar LLM para criar a primeira versão de um testbench, e fiquei muito surpreso ao ver pessoas que nem tentaram descartando a possibilidade por completo

  • Essa atitude é muito comum entre profissionais especializados. Eu também passei pelo /r/law e senti na hora esse clima de desprezo automático depois de ouvir as falas do Dario Amodei sobre IA na área jurídica. Talvez seja um mecanismo de adaptação ou acomodação à realidade, mas acho isso muito ruim para a capacidade de se preparar para mudanças econômicas e sociais

  • É parecido com a época em que assembly era a base e surgiram as linguagens de programação, quando programadores zombavam delas dizendo que eram ineficientes, pouco flexíveis e simplificadas demais, independentemente de isso ter relação com a realidade. É uma reação natural, sem muita relação com o valor real da nova tecnologia

  • Os LLMs tiveram um crescimento explosivo por um tempo, mas os modelos mais recentes às vezes até parecem ter piorado. Eles dão bons resultados para gerar testes, mas quando se usa LLM profundamente em tarefas como implementar novas features, a coisa começa a ficar estranha. Funciona bem para projetos novos ou webapps simples, mas não ajuda tanto em refatoração de código grande ou legado, nem em adicionar funcionalidades. Por exemplo, vejo com frequência Claude ou ChatGPT inventando absurdos sobre a API inteira do D3

  • No fim das contas, você está construindo seu próprio substituto, enquanto seus colegas estão agindo com cautela

  • O ChatGPT-4o mostra uma capacidade impressionante para escrever VHDL. Hoje mesmo tive resultados surpreendentes prototipando um controlador de baixo nível

• O contexto necessário para escrever software de verdade de forma adequada é vasto demais para um LLM. Software é, por si só, “o negócio codificado”. Como o LLM vai saber todas as condições especiais prometidas pelo time comercial aos clientes e as regras implícitas de cada departamento? O que ele consegue resolver hoje é algo genérico e limitado. Passou de duas classes ou de 20 a 30 arquivos, até os melhores LLMs se perdem e perdem o foco. Como não mantêm bem o contexto, acabam gerando churn de código inútil. Para LLM realmente substituir um desenvolvedor, vai precisar absorver muito mais contexto, coletar contexto da organização inteira e manter uma linha de raciocínio por projetos longos. Quando esses problemas estiverem de fato perto de serem resolvidos, aí sim eu começo a me preocupar de verdade

  • Recomendo experimentar a janela de contexto de 1M do Gemini 2.5 Pro. Coloquei todo o codebase do meu pequeno projeto de ETL, com 100 mil tokens, e o resultado foi bem razoável. Não é perfeito, mas já é um bom sinal da mudança dos tempos

• Sempre que se discute se LLM vai substituir desenvolvedores, todo mundo esquece que engenharia de software real envolve muito mais do que escrever código. Escrever código é, na verdade, uma parte pequena. O importante são as habilidades sociais, a análise de requisitos e descobrir o que o cliente realmente queria, sendo que muitas vezes nem o próprio cliente sabe direito o que quer, e o engenheiro precisa se virar para descobrir isso. Se isso já é difícil para humanos, não tem como um LLM dar conta

  • No fim, isso é um problema de feedback loop, ou seja, um processo iterativo imediato em que o cliente usa de fato e dá opinião. Interfaces de chat são excelentes para esse ciclo de feedback, e agentes conseguem produzir versões novas rapidamente. LLM consegue sim lidar com abstrações, sistemas de vários componentes, arquitetura geral e análise de requisitos. A questão central é a velocidade da iteração. A robustez e o IQ dos modelos continuam melhorando. A automação já entrou em toda a engenharia de software. Provavelmente, daqui a 5 anos, um humano sem assistência vai ser um grande gargalo. Quem não se integrar profundamente com IA inevitavelmente vai ficar para trás

  • Esse já era exatamente o problema na onda de offshoring dos anos 2000. Times no exterior tinham dificuldade para questionar pedidos de mudança ou levantar problemas, então simplesmente faziam o que era mandado, e o resultado só ia se acumulando. Acho que algo parecido vai acontecer com IA. E o resultado deve ser parecido também

  • LLM, para começar, nem faz engenharia de software de verdade. Mas isso não é exatamente o problema. Na prática, muitos programas bem-sucedidos funcionam bem sem “engenharia de software”. Em ambientes onde ninguém se importa com a estrutura de custos de cloud, isso é ainda mais verdade. Na verdade, acho que no futuro pessoas com sensibilidade técnica, como parceiros de negócio de TI, vão criar apps inteiros sem ajuda de engenheiros de software. Isso já é realidade diária no setor de energia verde. Só que o problema explode quando passa a ser necessário manutenção, escala e eficiência. É aí que coisas como “usar lista ou generator em Python” passam a importar, e onde a engenharia de verdade se torna necessária

  • Daqui a 5 anos, talvez a gente quase não projete mais código. A quantidade de código digitado por mim já caiu absurdamente em comparação com 1 ano atrás. Mesmo assim, isso é só uma parte do processo; não significa que os desenvolvedores vão desaparecer

  • Por outro lado, o papel do simples “coder” já está sendo bastante substituído. Essa é justamente a área em que LLM vai bem. Tem muito coder sem cérebro que só olha ticket do tipo “receba essa API e devolva tal valor”, sem entender nada de demanda do cliente ou análise, e essa parte está sendo eliminada rapidamente. Engenharia de software de verdade é outra coisa completamente diferente, mas não dá para ignorar que a demanda por coders simples era enorme

• Um ponto muito importante é que só humanos têm a capacidade de lidar com os conceitos abstratos de um programa e com a resolução criativa de problemas. O programador é o arquiteto da lógica, e o computador transforma formas de pensamento humano em instruções. A ferramenta imita humanos e consegue gerar código para tarefas específicas, mas não substitui o papel fundamental de abstrair, projetar e construir. Se o modelo passar a não só escrever código, mas criar projetos inteiros a partir de uma especificação, então o papel do desenvolvedor vai mudar de novo

• É sempre preciso partir da ideia de que “o que é melhor” depende da tarefa. LLM já é muito melhor do que eu em trabalhos repetitivos e formais, como acertar sintaxe de CSS ou lembrar como chamar bibliotecas conhecidas. Antes, essas “tarefas miúdas” consumiam muito do meu tempo; agora são resolvidas quase instantaneamente, e isso me agrada bastante

  • Para styling mais fundamental, indo além do CSS básico, o resultado do LLM é até ruim. Quando é difícil explicar claramente o efeito desejado, ou quando o trabalho fica mais sutil, ele com frequência não entrega o resultado mais importante e fica preso em um único caminho

  • Em coisas em que sou ruim, como SQL, o LLM é muito melhor do que eu. Em coisas que conheço bem, como CSS, ele vai pior. O critério aparece com bastante clareza

  • Concordo tanto com a frase “é melhor do que a maioria dos desenvolvedores” quanto com a ideia de que o LLM parece melhor justamente porque muita gente não sabe CSS. Na prática, muita gente odeia CSS, nunca aprende direito e usa à força, o que gera essa confusão. Se a empresa quer economizar e não consegue contratar um verdadeiro especialista em CSS, aí o LLM vira alternativa; se tem condição de contratar alguém realmente bom, então nem se compara. No fim, o concorrente real do LLM é o desenvolvedor fraco

  • Em linguagens principais ou em áreas que eu não domino exatamente, o autocomplete do LLM ajuda muito. Mas se você não desenvolve essa capacidade de “lembrança reflexa” e depende só do LLM, corre o risco de não ter repertório para avaliar o que a ferramenta recomenda e acabar preso a soluções ruins

• Fico feliz que tanta gente se preocupe com “código bom”, mas tenho medo de que no fim isso não signifique nada. A indústria de software já foi absorvida pelo mundo dos negócios faz tempo, e nem sei mais exatamente desde quando isso aconteceu (desde a carta aberta do Bill Gates em 1976?). O verdadeiro problema é que acionistas e executivos se importam cada vez menos com o código, desde que o lucro suba. Sem resistência cultural de desenvolvedores e usuários, essa estrutura tende a continuar

  • Sobre essa ideia de que sem resistência cultural de desenvolvedores e usuários está tudo perdido, eu queria dizer que ainda existem empresas que fazem código bom e que nem tudo é um caos completo. O problema não é qualidade de código, e sim uma questão ética: você concorda ou não com objetivos de negócio capitalistas? O mais importante é equilibrar software bonito e realidade. Eu também sou desenvolvedor e fundador, adoro open source e engenharia, mas ao mesmo tempo quero viver com conforto suficiente

  • Código é o motor do negócio. Código ruim leva a negócio ruim. Há uma diferença gritante entre equipes de hospedagem própria, com firewall físico, VMware, proxies e afins, e cloud pública, com QEMU, netfilter e hardware commodity. Quem engoliu quem, e o que vem pela frente, ninguém consegue prever

• Ontem à noite eu passei horas brigando com o o3. Nunca fiz um Dockerfile na vida, então em vez de aprender, tentei jogar um repositório do GitHub para o o3 resolver tudo automaticamente. Acabei desperdiçando horas debugando o resultado. Ele vivia acrescentando coisas que nem existiam, apagando o que não existia ou misturando tudo, além de confundir conceitos básicos como a diferença entre python3 e python. No fim, fiquei puto, fui procurar no Google Docs e resolvi rápido. IA é uma ótima ferramenta, mas não é solução mágica; alguém sempre precisa estar “acordado” vigiando

  • Dica: recomendo usar Claude ou Gemini. Em tarefas de programação, eles alucinam bem menos. Ou então habilite a opção de busca na internet no o3 para melhorar a capacidade de consultar documentação online. Leva tempo para se adaptar, então não dá para esperar que seja um mago; a curva de aprendizado para usar bem é alta, e nisso ele se parece com outras ferramentas de desenvolvimento como vim/emacs. E no ChatGPT também dá para melhorar o uso de busca na internet apertando o “botão do globo”

• Empresas que usam LLM/IA para aumentar a produtividade dos funcionários vão prosperar; empresas que tentarem substituir os funcionários completamente tendem a fracassar. No curto prazo, talvez CEOs e executivos fiquem satisfeitos com resultados imediatos e façam escolhas que corroem o crescimento futuro

  • É exatamente isso. O certo é usar LLM como assistente do programador; substituição total não funciona. O caminho correto é adotar a tecnologia com moderação

  • Acho bem interessante essa ideia de que substituir funcionários pode gerar valor de curto prazo e beneficiar a empresa. Ou seja, no médio e longo prazo isso pode prejudicar a empresa, mas temporariamente ainda pode fazer a ação subir

  • Assistente de código é uma ferramenta comum e praticamente obrigatória; não é uma arma para substituir pessoas. Numa era em que o concorrente também pode comprar a mesma assinatura de IA, isso não substitui gente

• Compartilhando experiência de campo: antes eu era desenvolvedor, agora sou gestor, mas ainda escrevo código. Assistentes com LLM ajudam, mas às vezes também incomodam. Quando começam a despejar sugestões de código inesperadas, podem levar o trabalho para uma direção diferente da intenção original, e revisar isso consome tempo. Talvez seja questão de configuração, mas eu gostaria que o padrão fosse só aparecer quando eu chamasse explicitamente por comando. Uma coisa é certa: mesmo quando deixo o LLM escrever código inteiro ou funções completas, eu sempre passo por revisão manual

  • O editor Zed tem esse tipo de modo de “sugestões sutis” (saiba mais). Queria que todos os editores oferecessem algo assim

  • Hoje em dia, fazendo várias coisas em startup, eu não gosto muito de UIs geradas por LLM. Os blocos básicos são úteis, mas se eu delego blocos longos de código ao Claude, preciso de inúmeras rodadas de retrabalho até chegar ao resultado que eu queria

[redcrash0721]

https://freederia.com Assim como no site do cientista de IA, eles vão manter uma relação de coexistência.