- Existem desenvolvedores que têm dificuldade em gerar valor claro usando LLMs para programação
- Alguns usuários não estão satisfeitos com a qualidade da saída do LLM
- Em requisitos específicos ou problemas complexos, os LLMs tendem a ficar aquém do esperado
- Por outro lado, em automação simples ou tarefas repetitivas, há um certo nível de conveniência
- Desenvolvedores estão buscando formas de melhorar engenharia de prompts e fluxos de trabalho
Discussão sobre as dificuldades de usar LLMs para programação e como melhorar
O valor limitado dos LLMs
- Recentemente, muitos desenvolvedores vêm testando LLMs para programação como ChatGPT, GitHub Copilot e Claude para vários usos
- No entanto, uma parte considerável dos usuários relata não perceber o nível de ganho real de produtividade que esperava
- Especialmente em tarefas como escrita de algoritmos complexos, estruturação de código em larga escala e design da arquitetura de projetos, o código sugerido por LLMs costuma ser fragmentado ou ineficiente
Insatisfação com a qualidade da saída
- Alguns desenvolvedores afirmam que o código fornecido pelos LLMs inclui bugs ou entrega resultados imprecisos por não compreender bem o contexto
- Muitas vezes faltam explicações ou análises suficientes, ou o código não reflete adequadamente a complexidade e o contexto do projeto
Ajuda em áreas de uso simples
- Em aspectos de automação básica como geração de pequenos trechos de código, tarefas repetitivas e resolução de problemas simples de sintaxe, é possível confirmar uma conveniência clara
- O uso em tarefas rotineiras como testes unitários, refatoração e ajustes de estilo de código recebe avaliações positivas
Tentativas de melhoria
- Alguns desenvolvedores aplicam ativamente técnicas de engenharia de prompts para obter resultados melhores
- Eles também estão experimentando formas de usar LLMs que se encaixem no próprio fluxo de trabalho, além de combinações com várias ferramentas open source
Conclusão e aprendizados
- Por enquanto, reconhece-se que os LLMs não podem ser uma solução universal para todas as demandas de desenvolvimento
- A comunidade e os desenvolvedores seguem compartilhando experiências enquanto buscam estratégias de uso eficientes e formas de superar essas limitações
1 comentários
Comentários do Hacker News
Tenho a impressão de que existem dois tipos de desenvolvedor. Um grupo vive dizendo que LLM é um superpoder absoluto para programar e que a produtividade aumentou 100x, e o outro vê isso como uma ferramenta bem temperamental, que exige muito esforço manual para entregar só resultados medianos. Mas, se esse primeiro grupo realmente está tendo um salto tão revolucionário de produtividade com LLM, não era para essas pessoas já estarem dominando completamente o mercado e atropelando os concorrentes?
Em trabalho greenfield, sinto que minha produtividade aumenta 100x com LLM. Por exemplo, consigo gerar em minutos a estrutura básica de um app React com várias páginas, store Redux, autenticação etc. Se eu digo "agora adicione X", em geral ele entrega algo bom. Mas, em manutenção de sistemas existentes, adição de funcionalidades complexas ou contextos em que conhecimento de domínio é importante, LLM quase não ajuda. É bom para autocomplete ou completar funções, mas bate no limite muito rápido quando entra na implementação de uma funcionalidade inteira. Nesses casos, o tempo de mandar no LLM e o tempo de eu mesmo codar acabam sendo parecidos. Então normalmente eu primeiro escrevo um código stub com a estrutura que quero e deixo o LLM só preencher os espaços vazios. Acho que quem fala em produtividade 100x ainda só pegou a parte fácil, ou ainda não bateu na parte difícil. Na prática, 90% do trabalho é fácil, e os 10% finais são o que realmente pega, e aí o LLM não consegue entregar direito
Falando meio com ironia, quem diz 100x de produtividade na verdade está multiplicando um número pequeno por 100. Na fase de pesquisa, LLM ajuda demais. Por exemplo, recentemente precisei escrever explicitamente um código de álgebra linear especializado para alguns domínios, e como eu não podia usar bibliotecas como LAPACK, implementei tudo na mão. Numa situação dessas, usar LLM no lugar de livro de referência e ter as informações organizadas de uma vez realmente pode reduzir o tempo de pesquisa em 100x. Mas, quando deixei a implementação real do código com o LLM, ele colocou erros sutis que alguém sem experiência talvez nem percebesse. Um júnior poderia simplesmente deixar passar. Como valorizo revisão de código, acho difícil que a velocidade de escrita em si aumente tanto, por melhor que o LLM fique. Ainda assim, na fase de explorar e resumir o que escrever, ele acelera muito. No fim das contas, inovação e ideias criativas são o verdadeiro valor do mundo, e isso continua sendo papel do humano. LLM é um ajudante importante, mas acredito que código de alto valor agregado ainda precisa ser escrito por pessoas
Na prática, muita gente não pertence a nenhum desses dois grupos. Não é 100x de produtividade, mas também não é algo penoso de usar. Trabalho profissionalmente com programação há mais de 30 anos, e sempre precisei consultar coisas; esqueço com frequência sintaxe específica de linguagens. Também já tive trabalhos em que precisava alternar entre várias linguagens. Antes era preciso ficar revirando livros de referência, manuais e materiais ainda piores. Com motores de busca como Google melhorou um pouco, e plataformas como Stack Overflow foram um avanço ainda maior. Agora o LLM é só mais um passo adiante. Às vezes uma sugestão de autocomplete já é exatamente a pista que eu estava procurando. Claro, ignoro o que não serve, mas gosto do fato de que a interface de chat permite fazer perguntas de forma muito mais conversacional do que Google ou SO
Estou estudando matemática com Math Academy, ChatGPT e YouTube, especialmente 3Blue1Brown. Sem essa combinação seria um sofrimento; agora está sendo divertido. Quando fiz um curso parecido na University of Amsterdam, no passado, o ChatGPT ainda não era tão inteligente e foi muito mais difícil. O ChatGPT responde perguntas que um professor teria dificuldade de responder, o que é perfeito para mim, porque eu preciso entender até o pano de fundo cultural da matemática para me identificar com ela e chegar a soluções criativas. Por exemplo, perguntei por que se usa m em ângulos, e ele explicou que historicamente vem de measure. Isso me permite voltar a focar na matemática essencial. Ele também me explicou de forma fácil a fórmula de cálculo rápido da variância. Não é uma ferramenta para dominar o mundo, mas estou aprendendo conhecimentos que provavelmente eu não teria aprendido de outra forma. Claro, YouTube e Math Academy também têm um papel enorme
LLM cobre muitas áreas de forma ampla e dá superpoderes para quem não é especialista em tudo. Se você trabalha sempre só em uma área muito específica e profunda, ele ajuda menos. Por exemplo, escrever um Dockerfile com LLM numa situação em que isso só aparece uma vez por projeto e não existe um especialista em deploy é excelente. Também resolve erros pequenos de sintaxe ou probleminhas mais rápido do que o Google. Pedir para o LLM analisar trade-offs de arquitetura, mas tomar a decisão final por conta própria, também pode melhorar a produtividade. Só que é preciso limitar bem o escopo no prompt para evitar que o LLM faça besteira, e na prática ele com frequência inventa APIs que nem existem ou comete erros absurdos, então ainda exige várias rodadas de correção. Mesmo assim, ainda há ganho de velocidade
Eu também uso LLM de várias formas. Ele me ajuda em pequenos problemas de debugging, shell scripts, programação e perguntas em geral. No uso pessoal, além de Claude e OpenAI, escolho entre várias ferramentas como Google ou Perplexity a que der o melhor resultado. No trabalho, uso Claude, OpenAI e Google via Copilot no VSCode ou pela plataforma interna, e também brinquei um pouco com Copilot Studio. Trabalho assim há mais de um ano e meio; não usei todas as ferramentas o tempo todo, mas minha impressão geral é esta. Sem dúvida o LLM aumentou minha produtividade. Fiz experimentos em várias linguagens de programação e passei a entender melhor vários temas, então algumas tarefas realmente ficaram muito mais fáceis. Mas, independentemente do modelo ou da versão, quando o trabalho fica mais complexo, sai do trivial ou deixa de ser uma simples combinação de peças, todos eles tendem a falhar. Às vezes o tempo gasto consertando a saída ruim do LLM elimina totalmente o tempo que eu tinha economizado no começo. Minha conclusão honesta hoje é que LLM é útil para pequenos autocompletes de código, debugging e explicações, e só. Ainda não ameaça nossos empregos no curto prazo
LLM ajuda muito quando estou aprendendo uma biblioteca, API ou linguagem nova. Por exemplo, perguntar diretamente como renderizar texto em OpenGL é muito mais rápido do que ler uma documentação oficial enorme e caótica. Ou, quando preciso escrever boilerplate repetitivo e chato sem ter código anterior para usar como referência, o LLM é útil. Mas, na parte que considero o "trabalho de verdade", isto é, o código exclusivo e próprio do meu serviço, o uso do LLM no sentido de "escrever o código por mim" não é tão alto. Como engenheiro sênior, quase não gasto tempo codando em si; o importante é desenho de estrutura, refatoração de legado, problemas de performance, debugging de bugs raros etc. Como o LLM só acelera a escrita de código repetitivo, ele não ajuda tanto, a menos que você esteja começando projetos novos do zero toda semana. Se você ainda escreve muito boilerplate, talvez valha pensar em outras soluções mais fundamentais além de depender de LLM
Para ler documentação oficial caótica e explicar, LLM é claramente melhor do que um programador mediano. Nisso ele agrega valor de forma evidente. E existem linguagens com boilerplate demais mesmo
Não existe bala de prata, e a conceitualização é a parte realmente difícil. The Mythical Man-Month é um texto importante; vale a pena ler mais sobre isso
Não existe bala de prata. É curioso como continuamos esquecendo o conselho simples do Fred Brooks. Se você não criar expectativas exageradas e entender que há muito código com bug nos dados de treino, então o LLM naturalmente também terá bugs, ele fica muito mais útil. Não dá para terceirizar o design; eu mesmo preciso fazer o trabalho prévio, como dividir funções, e usar o LLM para reduzir a chatice em tarefas entediantes ou em áreas pouco familiares. Mas, mesmo quando o código é gerado pelo LLM, se eu vou assumir responsabilidade por ele, preciso ter conhecimento e validação próprios. Mesmo que o código do LLM pareça perfeito, defeitos podem estar escondidos, então preciso continuar estudando, desenvolvendo minhas habilidades e mantendo a desconfiança. Nunca confiar cegamente
Quando a escala do problema cresce, fica claro que o LLM perde utilidade. Ele é excelente para tarefas repetitivas ou find & replace complexo. Também é muito útil para código cotidiano e bem definido, como preencher métodos CRUD em recursos de API. Recentemente até pedi para o Claude Opus 4 revisar meus patches, e às vezes ele encontra erros e me ajuda a lembrar do que eu ainda preciso fazer. Mas, depois de um certo limiar de complexidade, a utilidade do LLM despenca. Por exemplo, quando é preciso mudar várias partes em muitos arquivos relativamente grandes, eu naturalmente já começo a inferir sozinho quais arquivos precisam ser alterados. Ainda assim, usar o LLM como "rubber duck" funciona bem. Se a IA acertar, ótimo; se não, eu simplesmente continuo por conta própria. No fim, o LLM ajuda só no início, e a maior parte das alterações eu teria de fazer mesmo. Ter um esqueleto inicial e ajustar do meu jeito ainda parece melhor do que escrever tudo do zero. Se o LLM claramente está sofrendo, eu não insisto. Se ele errou por causa de uma especificação ambígua, eu aponto isso; se ainda assim não conseguir, eu mesmo termino
Minha experiência é parecida. Descobri valor no LLM nos seguintes casos: ele cria muito bem componentes ou páginas React relativamente isolados, especialmente com bibliotecas de UI populares. Também produz funções puras bem definidas com uma confiabilidade razoável, e é fácil validar. Boilerplate de frameworks famosos ele faz de forma muito fácil e boa. Mas vejo gente ao meu redor falando de experiências poderosíssimas de ponta a ponta, e comigo isso simplesmente não acontece, o que chega a ser meio enlouquecedor. No dia a dia, mesmo me esforçando bastante, quando tento uma funcionalidade completa o LLM entra em colapso. Tentei com ferramentas como aider fazer algo simples como um recurso de email com template em Next.js, e nem isso saiu. Se eu quebrava em partes menores e pedia uma a uma, melhorava um pouco, mas o código existente começava a se degradar. Mesmo explicando os problemas, quanto mais eu fazia prompt, mais estranho ficava. No fim tentei corrigir manualmente, mas o código estava um caos completo
Já ouvi de amigos vibe coders que “meu padrão é alto demais”. Acho que vibe coder basicamente não revisa direito o código, então não tem padrão de qualidade. Se vibe coding realmente funcionasse, lugares como Google AI, com orçamentos gigantescos de GPU e TPU e os modelos mais recentes, já estariam melhorando produtos numa velocidade esmagadoramente superior à humana. Se isso estivesse mesmo acontecendo, nós não perceberíamos primeiro porque o trabalho dos desenvolvedores ficou mais fácil, e sim porque notícias absurdas e inesperadas começariam a aparecer; só muito depois saberíamos que a causa era IA
LLM é bom para código descartável, de uso único. Não é algo tão simples para desenvolvimento, manutenção, debugging e correção. Como a maior parte do código, na prática, é quase um "consumível" e não um produto em si, ele serve bem para isso. Mesmo se aplicarmos ideias como fast-food, linha de montagem ou produção automatizada, ainda existe uma diferença enorme. Um item produzido por máquina numa fábrica sai certo em 99,99% dos casos, então dá para confiar. Já com LLM, preciso verificar manualmente cada etapa; se eu não verificar, simplesmente não funciona. É impossível o LLM resolver isso sozinho com sucesso, 24 horas por dia, sem supervisão. É por isso que ele ainda não está tomando nossos empregos
Eu jamais pensaria em entregar um problema complexo inteiro para o LLM e esperar o resultado pronto. Essa não é a força dele. O verdadeiro valor do LLM está em dar "dicas" para avançar e pular partes simples mas demoradas. Dias atrás eu precisava montar uma string de log, e o LLM sugeriu de cara um código com formatação melhor do que a que eu tinha pensado. O que levaria 15 minutos ficou pronto em 30 segundos, e muito bem feito. É esse acúmulo de pequenos ganhos que gera valor