Programação com LLMs (verão de 2025)
(antirez.com)- Atualização do relato de uso de LLMs pelo desenvolvedor do Redis, antirez
- LLMs de ponta como Gemini 2.5 PRO e Claude Opus 4 ampliam a capacidade dos desenvolvedores
- Com LLMs, é possível aumentar a eficiência do trabalho de várias formas, como eliminação de bugs, teste de ideias e expansão de conhecimento
- Também é possível lidar com áreas não especializadas ou novas tecnologias com facilidade, com a ajuda de LLMs
- No entanto, para a qualidade geral e a manutenção do código, a colaboração entre "humano + LLM" é essencial
- Para usar LLMs da melhor forma, é importante fornecer contexto suficiente e ter capacidade de comunicação clara
Mudanças no desenvolvimento com LLMs e pontos principais
LLMs de ponta (como Gemini 2.5 PRO e Claude Opus 4), com base em sua enorme capacidade de compreensão e habilidade de lidar com grandes volumes de código, atuam como uma forma de expandir a capacidade dos programadores
- Se você souber descrever problemas com clareza e estiver acostumado à comunicação iterativa
- é possível remover bugs antes do lançamento (ex.: no caso da implementação de Vector Sets no Redis, bugs foram eliminados imediatamente com code review do Gemini/Claude)
- dá para testar rapidamente se uma ideia funciona, escrevendo código experimental e avaliando desempenho
- torna-se possível fazer pair-design, baseado em experiência e intuição, combinando o amplo conhecimento especializado do LLM com a intuição humana
- ao fornecer instruções claras ao LLM, é possível concluir rapidamente partes da implementação de código
- também é possível se adaptar rapidamente a áreas desconhecidas (ex.: código em assembly 68000 para Amiga)
No texto anterior, 'LLMs e programação no começo de 2024', a utilidade dos LLMs já havia sido mencionada, mas nos últimos 1,5 ano os LLMs evoluíram de forma extraordinária
Para aproveitar os LLMs ao máximo, tanto humanos quanto LLMs precisam de certas capacidades e hábitos, e os princípios para isso são importantes
Moderação no Vibe Coding e princípios de colaboração entre humano + LLM
Hoje, os LLMs são excelentes como amplificadores da capacidade dos desenvolvedores, mas ainda não chegaram ao nível de resolver sozinhos, de forma autônoma, todo o trabalho
- Em projetos pequenos e pontuais, como testes e utilitários simples, é possível fazer design apenas com LLM
- Mas, em projetos grandes e fora do comum, usar apenas LLM traz grande risco de problemas como complexidade, código desnecessário e fragilidade estrutural
- A colaboração entre LLM + pessoa mostra o maior ganho de produtividade, mas isso pressupõe comunicação eficaz e experiência em gerenciar LLMs
- Em tarefas complexas, não se deve deixar tudo apenas para o LLM; é necessária uma estratégia em que o humano intervenha ativamente em todo o processo
A importância de fornecer contexto suficiente ao LLM
Para fazer o LLM entender corretamente a direção do desenvolvimento ou da correção de problemas, é indispensável fornecer informações amplas de contexto
- É recomendável fornecer artigos, a base de código alvo (de preferência o máximo possível dela) e a intenção do trabalho
- Isso inclui informações centrais como objetivo da implementação, abordagens desnecessárias ou frágeis, ideias principais viáveis, metas, invariantes e estilo de código
- Por exemplo, ao lidar com uma nova tecnologia que o LLM ainda não conhece (ex.: Redis vector sets), incluir o documento README no contexto permite obter imediatamente respostas em nível de especialista
Escolha do LLM e forma de uso
O LLM mais conhecido nem sempre produz, na prática, os melhores resultados
- Para programação, Gemini 2.5 PRO e Claude Opus 4 são especialmente eficazes
- Gemini 2.5 PRO se destaca em detecção de bugs complexos e resolução de problemas
- Claude Opus 4 é forte em escrever código novo e também oferece excelente experiência de uso
- Alternar entre os dois modelos aumenta a compreensão em projetos de design complexos
- Se fosse para escolher apenas um, a recomendação é Gemini 2.5 PRO
- Condições que devem ser seguidas ao usar LLMs
- Evitar agentes de código ou agentes integrados à IDE
- Permitir que o LLM veja diretamente todo o contexto (código, documentação etc.) para induzir as melhores respostas
- Ao usar recursos que mostram apenas parte do contexto, como RAG (baseado em recuperação de conhecimento), o desempenho piora
- Em cada etapa, a pessoa deve copiar/colar manualmente o código e acompanhar diretamente o fluxo
Conclusão – manter o controle é essencial
O surgimento de agentes que escrevem código sozinhos não está longe, mas no momento, a forma mais precisa de produzir código é com humanos colaborando ativamente com LLMs
- O papel do humano em decidir "o quê" e "como" fazer continua sendo central
- Ao usar LLMs, é possível crescer aprendendo novas tecnologias e conceitos além dos limites do conhecimento atual
- Ao controlar o código diretamente, é possível manter a consistência entre design e implementação e também minimizar a incerteza causada por erros do LLM
- Verificar periodicamente como a performance dos agentes está evoluindo também é uma estratégia inteligente
- Neste estágio, evitar o uso de LLMs pode significar ficar para trás nas mudanças; por isso, este é um momento em que uma forma equilibrada de uso é importante
1 comentários
Comentários do Hacker News
Estou achando triste a realidade em que modelos LLM proprietários como Gemini 2.5 PRO e Claude Opus 4 estão virando o padrão. Vejo de forma muito positiva o avanço dos LLMs e o poder deles como ferramenta, mas acho difícil entender por que os desenvolvedores, sejam famosos ou desconhecidos, continuam achando aceitável depender de um serviço pago de terceiros para programar. Antigamente era possível programar só com open source e ferramentas gratuitas. Tenho receio de que, daqui a alguns anos, depender de LLMs pagos vire algo tão inevitável quanto hoje seria programar sem IDE ou sem vim. Ficar dizendo que US$ 200 por mês não é nada não resolve o problema fundamental.
Os modelos abertos que hoje dá para rodar localmente ainda ficam atrás em qualidade e, acima de tudo, custam muito mais para operar. Quando der para rodar economicamente um modelo do nível do Claude 4 em um computador pessoal, aí muita gente vai tentar. No momento, um modelo como o Kimi K2 roda em dois Mac Studio de 512 GB, mas só o hardware custa uns US$ 20.000.
O modelo de assinatura faz parecer, no começo, que entrega uma relação custo-benefício excelente. Mas, aos poucos, o preço sobe, a qualidade cai, e no fim você acaba preso ao serviço. Fica parecendo o episódio "Common People" de Black Mirror.
Pessoalmente, acho difícil acontecer um futuro em que todo desenvolvedor fique inevitavelmente subordinado a LLMs pagos. No longo prazo, as pessoas vão perceber que o próprio ato de produzir código em massa é o problema. Código é dívida, e quando código instável ou lento vai se acumulando, essa dívida também cresce. A IA não vai desaparecer, mas quando o entusiasmo diminuir, vai aumentar o entendimento sobre onde e como ela deve ser usada. Também fico na dúvida sobre o que acontece quando o dinheiro de investimento secar. OpenAI e Anthropic não são lucrativas e precisam de capital contínuo para manter o estado atual. Se a evolução dos LLMs já estiver perto do limite, o investimento também pode ir embora; aí o custo de uso pode subir ou os serviços podem até desaparecer completamente.
Realisticamente, acho que isso não é um grande problema. Se não houver um motivo concreto de ganho de produtividade, não há por que continuar preso a um serviço caro e pouco amigável. Os modelos abertos também estão melhorando de forma constante, então, se a distância para eles não for grande, não haverá necessidade de continuar usando. Se o avanço dos LLMs não parar e continuar íngreme, então nós também não vamos conseguir competir com os métodos antigos e teremos que migrar para outra área. Em resumo, acho que não há motivo para tanta preocupação. Também sinto que o valor das grandes empresas de modelos está muito superestimado em relação à realidade.
Quero acrescentar algo à ideia de que dá para programar com open source e ferramentas gratuitas. A JetBrains é uma empresa mais antiga do que muitos dos seus colegas, e o Visual Basic/C++/Studio da MS facilitou o desenvolvimento para Windows, mas tudo isso era pago.
Não concordo com a expressão "PhD-level knowledge". O objetivo de um doutorado não é adquirir conhecimento existente, e sim aprender a fazer pesquisa. Esse é um ponto que costuma ser mal compreendido em discussões sobre IA, e a expressão “conhecimento de nível PhD” fica com um sentido bem nebuloso.
Além da ideia de que um PhD é um processo de aprendizado de pesquisa, o ponto central também é saber fazer perguntas. O LLM está mais para um "trabalhador preguiçoso com muito conhecimento"; ele não formula perguntas por conta própria nem explora hipóteses. Para dar um exemplo real, pedi ao Claude Code (Max Pro) para comentar a quantidade de assertions de teste, e ele acabou introduzindo um bug com base em uma suposição errada do plano original. Só quando eu mandei reescrever o plano ele conseguiu encontrar a causa e corrigir. Por exemplo, o motivo de um objeto ORM ter valores
nullera a ausência de umrefreshapós o commit, e o fato de ele ter sido carregado em outra sessão de banco, permanecendo como estava mesmo após o encerramento da sessão.Concordo. Ele tem conhecimento em nível de especialista, mas não consegue fazer tão bem aquilo em que humanos são bons. Por exemplo, um LLM pode escrever um programa brilhante de uma vez, do começo ao fim, mas tem dificuldade para melhorá-lo de forma iterativa.
Mesmo entendendo que um PhD é mais do que conhecimento, o simples fato de agora existir uma forma fácil de acessar esse conhecimento já tem um valor enorme. Em uma empresa antiga onde trabalhei, o LLM chegou a dar respostas bastante úteis para perguntas obscuras que só alguém com PhD conseguiria responder, algo como, grosseiramente, "o que acontece quando se aplica uma tensão em determinada direção na interface entre dois materiais?".
Depois de concluir o PhD, a pessoa não passa a se importar mais com a matéria em si; no fim, o importante é ter aprendido a fazer pesquisa.
Acho que qualquer discussão sobre programação com LLM precisa necessariamente mencionar o domínio tratado e a linguagem de programação usada. Essas duas variáveis têm um impacto muito maior do que a forma de usar o LLM. Se alguém gosta ou não de programar com LLM, a primeira pergunta deveria ser que tipo de problema essa pessoa estava resolvendo, e você mesmo deveria tentar resolver esse problema com IA para entender de verdade a posição dela. Caso contrário, a conversa sempre degenera para coisas como "você usou errado" ou "eu tentei e achei ruim".
Com base na minha experiência de ter passado alguns meses trabalhando com foco em agentic coding, concordo com tudo do post. Os LLMs de ponta são os mais fáceis de usar por enquanto, mas espero que os modelos abertos logo alcancem esse nível. Você pode pedir ao LLM para sugerir uma abordagem nova ou apresentar uma que você já conhece. Às vezes o LLM tende a complicar as coisas, então basta perceber isso cedo ou pedir um refactoring. Com a chegada de diferentes modelos, a situação também vai continuar mudando. Nem toda tarefa exige necessariamente o melhor modelo disponível. Para funcionalidades simples ou correções de bug, o Copilot também é um ponto de partida bem razoável. Espero que todo mundo aproveite o processo de experimentar coisas diferentes e aprender em meio a essas mudanças.
Usei a GitHub action do Claude em algo como 10 a 20 issues para implementação e review de PR, e concordo que isso funciona melhor como ferramenta de ampliação do que como automação cega; literalmente acerta e erra. Mudanças pequenas e funcionalidades/refactors modestos com bons testes quase sempre dão certo de forma quase automática. Rodando como action, a vantagem é que eu posso fazer outra coisa ao mesmo tempo, e fica ainda melhor se o Claude também escrever a issue. Mas, a partir de um porte médio, muitas vezes ele produz algo que parece plausível, mas na prática não funciona. Isso pode até ser culpa minha por falta de cobertura de testes, mas é algo que acontece com frequência. Mesmo escrevendo issues mais detalhadas ou variando o prompt, os resultados são decepcionantes. Trabalhos grandes então nem se fala. O recurso de review de PR é útil em tarefas pequenas e médias, mas também gera muita verificação inútil. Em resumo, acho que ainda falta bastante para o LLM programar sozinho. O uso mais eficiente é deixar que ele escreva pequenas tarefas e esperar o PR chegar. Na maior parte dos trabalhos, especialmente os de porte médio, eu principalmente dou direcionamento ao Claude e quase não preciso programar, então a produtividade de fato sobe bastante. Também testei o Gemini e, se deixar por conta própria, o código sai oscilando de forma imprevisível. Aqui dentro também fazemos review de PR com Copilot, mas sem muito efeito. Talvez em codebases grandes o Gemini tenha mais utilidade.
Diferentemente do OP, depois de um mês mergulhado intensamente nessa área, senti que Gemini 2.5 PRO e Opus 4 dão resultados melhores em discussões abstratas como arquitetura. Já para implementação de código individual, foi mais eficiente delegar ao Sonnet. O 2.5 PRO e o Opus ficam muitas vezes rondando a resposta certa e se corrigindo repetidamente, enquanto o Sonnet vai de forma mais direta até a resposta, embora precise de instruções suficientemente detalhadas.
Isso é totalmente plausível. Na prática, Sonnet/Opus 4 podem ser mais fortes no melhor caso, mas em alguns aspectos ficam atrás em consistência ou alinhamento até mesmo do Sonnet 3.5v2 (também chamado de 3.6) ou até do 3.7. Além disso, modelos também são objetos complexos, então dependendo do domínio um modelo que “parece mais fraco” pode funcionar melhor. E ambientes interativos e ambientes voltados a agentes usam técnicas de reinforcement learning diferentes, então o desempenho do modelo muda de acordo com a forma de uso.
Dados estatísticos internos reais também mostram que o Opus e o Gemini 2.5 pro têm desempenho inferior ao Sonnet 4 em ambientes realistas link com estatísticas relacionadas
Eu também tive uma experiência parecida. Uso o Gemini 2.5 Pro no AI Studio para validar e refinar grandes ideias de design e depois levo os requisitos para o Claude Code, que em geral codifica tudo de forma limpa. Testei recentemente o Gemini CLI e ele fica muito atrás do Claude Code em habilidade de programação: muitos erros de sintaxe, dificuldade para sair de loops, e o resultado fica prolixo e rápido demais para acompanhar. Já o Claude Code é excelente em debugging. Para resolver problemas de “visão geral”, o DeepSeek R1 também vale a pena, embora seja muito lento e tenha alta taxa de acerto.
Um exemplo prático da realidade de IAs/LLMs escreverem código às vezes extremamente ineficiente link para o blog relacionado
Tive a experiência de que, quando primeiro peço ao LLM apenas para explicar a tarefa desejada, e então vou dando feedback no meio do caminho por algumas iterações, a qualidade do código que vem depois melhora bastante. Fazer com que ele confirme primeiro um plano detalhado funciona bem.
Pela minha experiência, tarefas repetitivas e simples no frontend, que são fáceis de validar, podem ser delegadas ao vibe coding. Mas, no dia a dia, uso mais o LLM como parceiro de sparring para revisar meu código e avaliar alternativas. Mesmo quando as recomendações são absurdas ou têm falhas lógicas, fico satisfeito porque ele me ajuda a não deixar passar coisas óbvias demais e também corrige meu hábito de tentar coisas excessivas quando enfrento problemas complexos e enrolados.
Não entendo exatamente o que o OP quer dizer. Será que ele está sugerindo colar manualmente um arquivo C do redis na janela de chat web do Gemini Pro?