Por que decidi reduzir meu uso de LLMs
(zed.dev)- Alberto Fortin, engenheiro de software com 15 anos de experiência, tinha grandes expectativas em relação à adoção de LLMs (modelos de linguagem de grande porte), mas acabou enfrentando várias limitações em ambientes de produção
- Durante a reconstrução de uma infraestrutura baseada em Go e ClickHouse, ele percebeu na prática os pontos fortes e fracos da IA e sentiu que, mesmo com a evolução dos modelos, os problemas centrais continuavam sem solução adequada
- Ele aponta que existe uma ilusão de ganho de produtividade e que, na prática, bugs e problemas inesperados acabam aumentando
- A lição principal é tratar o LLM como um assistente (assistant) e entender que o design central e as decisões devem continuar nas mãos do desenvolvedor
- "A IA é inovadora, mas ainda não está completa, então é preciso uso equilibrado e uma visão realista da situação"
A experiência e a reflexão de Alberto Fortin sobre LLMs
- Alberto Fortin, engenheiro de software com 15 anos de experiência, adotou LLMs de forma ativa no seu trabalho de desenvolvimento, com expectativas muito altas
- No processo de reconstrução da infraestrutura com Go e ClickHouse, ele enfrentou vários desafios e limitações, o que o levou a escrever um post de blog sobre a distância entre a IA e o desenvolvimento real
- Mais recentemente, ele fez uma análise adicional para verificar se modelos mais novos, como o Claude Opus 4, resolveram esses problemas
- A experiência de Alberto oferece lições práticas para engenheiros que estão considerando adotar LLMs no ambiente profissional, além de uma visão realista sobre onde a ferramenta entrega valor e onde estão seus limites
Principais citações de Alberto sobre sua experiência com LLMs
> "Fiquei realmente surpreso ao perceber que não era apenas uma questão de comportamento incorreto ou funcionalidade que não funcionava. Como desenvolvedor que teria de manter esse código nos próximos anos, o código precisa estar limpo o suficiente."
> "Parecia que o problema seria resolvido logo, mas então surgia um novo erro em seguida, e eu acabava levando mais umas duas semanas para resolver aquilo também. Essa experiência se repetiu."
> "Quando eu passava a saída de erro para o LLM, ele até dava uma nova resposta, mas frequentemente acabava complicando ainda mais as coisas ou quebrando outras partes."
A percepção sobre expectativas exageradas em relação aos LLMs
> "Quando usamos pela primeira vez pequenos recursos como autocomplete, todos os desenvolvedores ficam impressionados. Parece até que ele está lendo seus pensamentos, e isso faz a expectativa crescer demais."
> "Você começa a achar que a produtividade no desenvolvimento pode aumentar 10 vezes, mas na prática existe uma tendência a criar esse nível de expectativa rápido demais."
Redefinindo papéis e expectativas
> "A maior diferença foi a mudança na forma como eu enxergo os papéis. Eu sou o arquiteto e desenvolvedor sênior, e o LLM é apenas meu assistente. Eu faço o planejamento, e o LLM assume um papel de apoio."
> "Depois que perdi a confiança nele, deixei de delegar funcionalidades importantes. Passei a usá-lo apenas em tarefas menores, como refatoração."
> "Comecei a corrigir os bugs por conta própria. Quando você entende completamente a base de código, resolver o problema diretamente é muito mais rápido e eficiente."
Mudança de perspectiva sobre os LLMs e conselhos
> "Como desenvolvedor sênior, reconheci para mim mesmo que o fato de a adoção de LLMs não se encaixar tão bem não significa falta de capacidade da minha parte. O ponto central é manter meu modo de trabalho e usar a IA como apoio."
> "É verdade que houve um avanço de nível com a evolução da tecnologia, mas ela ainda não chegou ao próximo estágio. Tomada de decisão e arquitetura continuam sendo responsabilidade humana."
> "A revolução da IA é impressionante, mas neste momento precisamos de expectativas equilibradas e realistas."
2 comentários
> https://pt.news.hada.io/topic?id=20955
Comentário no Hacker News
Acho que uma das razões pelas quais sinto que estou gastando tempo demais no HN é ver a mesma discussão se repetir em quase todo post e comentário. LLM é interessante, mas o código gerado é complexo, não traz sensação de autoria e, como eu não tenho a estrutura inteira na cabeça do mesmo jeito que teria com código escrito por mim, fica difícil de manter. Serve para scripts curtos que você não pretende manter, mas em projetos grandes vira problema. Por outro lado, há quem diga que é incrível montar workflows que distribuem tarefas entre vários agentes de LLM e depois juntam tudo, mas quase nunca mostram código de verdade e passa mais a impressão de exibicionismo
Acho que esse resumo captou muito bem o ponto central. LLM aumenta absurdamente a velocidade de desenvolvimento, mas como eu não entendo o código inteiro, fica difícil descobrir quando e onde algum problema surgiu. No fim, é como se eu fosse um desenvolvedor recém-chegado tentando se adaptar ao próprio projeto. Por isso, faço commits com frequência e periodicamente peço ao LLM para explicar o código de novo. Nesse processo, muitas vezes o próprio LLM encontra os bugs. Em tarefas de escopo mais limitado, como análise de dados, dá para avançar rápido mantendo controle suficiente. Já em codebases grandes, se você não tiver capacidade e hábitos adequados para usar LLM direito, a chance de virar bagunça é enorme. Escrever prompts, gerenciar contexto, controlar o ritmo, organizar o trabalho e revisar com precisão o que o LLM produz são habilidades essenciais de uso de LLM. Ninguém ainda ensina isso formalmente, então todo mundo está aprendendo na base da tentativa e erro. Mesmo assim, depois que você experimenta, é difícil voltar ao que era antes. Dá para delegar ao LLM as tarefas chatas ou repetitivas. Depois de mais de 20 anos programando, eu também já não tenho a mesma paciência de antes, e ideias cuja implementação eu não conheço bem ficam muito mais eficientes de tocar com ajuda do LLM
Gosto dessa forma de pensar programação como um processo de "construção de teoria". Veja Programming as Theory Building. Não tenho aversão ao uso de AI em si. O que não apoio é a postura de abdicar da responsabilidade pelo resultado do código gerado. Assim como ao usar ferramentas como
grep, o resultado produzido pela ferramenta só tem valor se você assumir responsabilidade por ele. Com código gerado isso vale ainda mais, e não é algo que se resolva só com um disclaimerConcordo com esse cansaço em relação a textos sobre AI. É verdade que as opiniões se dividem. Ainda assim, existem exemplos de gente que de fato publica o próprio código. Armin Ronacher, criador de Flask/Jinja2/Sentry, colocou no YouTube um vídeo de workflow e uma apresentação da biblioteca de AI que ele mesmo fez, e eu também faço algo como 50% a 80% do meu projeto open source com AI. Veja cijene-api
Tenho a impressão de que os grupos de usuários se distribuem como uma curva em sino. De um lado, há quem se sinta sobrecarregado porque o LLM despeja código demais no estilo dele próprio, então o contexto não entra na cabeça do usuário. Em compensação, para quem antes não conseguiria implementar nada sozinho, o LLM abriu a porta para tentar construir qualquer coisa. E há ainda outro grupo: pessoas que até conseguiriam implementar sozinhas, mas devagar, e que usam o LLM como se fosse um exército de desenvolvedores juniores, concentrando-se só em lembrar o nível do algoritmo geral enquanto montam projetos muito maiores com mais rapidez
Não me parece tão diferente de trabalhar em uma codebase grande com mais de 25 desenvolvedores contribuindo ao mesmo tempo. Na minha organização, 160 engenheiros cuidam do frontend e da camada intermediária, e o tempo todo preciso fuçar código sem dono claro, com
git blamemostrando o nome de um terceirizado de três anos atrás. LLM parece funcionar bem em escala pequena, mal em escala média e voltar a fazer sentido em projetos grandes quando usado em módulos pequenosLLM ajuda bastante a atingir meus objetivos, mas também me dá a sensação de enfraquecer minha própria capacidade de programar. É como esteroide: o músculo cresce rápido, mas há muitos efeitos colaterais, e no momento em que você para tudo parece desmoronar de uma vez. Como empresas se importam mais com resultados rápidos do que com saúde, isso fica ainda pior. Passei a usar com mais moderação, tentando manter um limite saudável
Parece que, graças ao LLM, muitos desenvolvedores esqueceram as lições enfatizadas em "Simple Made Easy". O código que LLM produz é excelente para gerar uma "Ball of Mud" (um amontoado caótico de código complexo, difícil de refatorar e manter). O verdadeiro poder está em quebrar problemas complexos em partes pequenas, fazer cada componente pequeno funcionar de forma simples, e deixar que a interação entre eles implemente a complexidade. Quando cada componente é simples, fica mais fácil entender, depurar e prever desempenho. Se um dia LLM realmente passar a seguir esse princípio muito bem, talvez aí de fato os desenvolvedores deixem de ser necessários
Na verdade, você também pode dizer explicitamente ao LLM qual direção quer seguir. A diferença entre quem acha LLM útil e quem não acha depende de entender em que ele é forte e fraco, e de saber prever que a qualidade do resultado muda conforme o input (o prompt). Por exemplo, eu prefiro perguntar ao LLM como quebrar um problema complexo para ver se deixei passar algo, e depois delegar a implementação concreta. Não peço que ele gere um projeto grande inteiro sem orientação alguma
O problema de "Ball of Mud" não acontece só no código. No meu trabalho também há líderes dizendo que precisamos "adotar AI de forma agressiva", e já vi a ideia de colocar até sistema de deploy e operação complexa nas mãos de AI. No fim, é colocar outra caixa-preta complexa em cima de um sistema já complexo, com a lógica de que "para entender a caixa-preta, precisamos de uma nova caixa-preta" — para mim isso não faz sentido. O clima coercitivo dentro da organização às vezes até me faz achar que sou eu quem está pensando errado
Mesmo que LLM se tornasse realmente perfeito, será que os desenvolvedores deixariam mesmo de ser necessários? Não acho que ninguém queira um LLM rodando 24/7 como uma "máquina de produzir software" sem parar. No fim, ainda será preciso alguém para decompor problemas e descobrir qual software realmente precisa ser construído. Hoje nós chamamos essas pessoas de desenvolvedores de software
No fim, cheguei a uma conclusão parecida. LLM é ruim quando usado para preencher uma codebase inteira no estilo autocomplete. O problema é perder o modelo mental de quem faz o quê e onde. Funcionou muito melhor para mim usar LLM como um StackOverflow personalizado, só para explicar palavras-chave, resumir conceitos pouco familiares e indicar direções, enquanto a implementação e as decisões reais ficam por minha conta
Eu também uso assim, mas o cursor continua insistindo em sugerir mudanças no código. Queria saber se existe algum truque para fazê-lo apenas inspecionar sem mexer no conteúdo da codebase
No meu caso é diferente. Se eu sempre revisar com cuidado o código que o LLM sugere, consigo ter bastante clareza sobre o que está onde e como as partes interagem
Também venho reduzindo bastante a frequência de uso. Houve muitos casos em que a resposta do LLM estava errada. Então, hoje em dia eu só pergunto em qual manual ou documentação devo procurar, e verifico o conteúdo real por conta própria. Esse método ajuda a desenvolver a capacidade de localizar informação e reduz a dependência tanto de buscadores quanto de LLM. LLM é só uma ferramenta, e nem é das mais confiáveis
Tem um ponto que ninguém mencionou: às vezes LLM reduz a produtividade. Quando ele conduz você para o caminho errado com uma resposta plausível, a perda de tempo pode ser séria. No geral, ele costuma ajudar, mas verificar a base factual é importante e, na prática, muitas vezes implementar direto acaba sendo mais rápido
Os limites do LLM são claros. Ele é muito poderoso, mas tem dificuldade para fazer saltos criativos no nível humano. Por exemplo, para a pergunta "No Android não dá para fazer bind em portas abaixo de 1000; então como rodar um servidor web?", tanto Claude quanto Gemini só deram três soluções óbvias: 1) proxy reverso 2) root 3) usar uma porta mais alta. A solução real que eu queria era registro HTTPS RR (referência relacionada). Os dois conhecem essa especificação, mas não conseguem aplicá-la ao contexto. Só cheguei à resposta quando eu mesmo acrescentei o contexto
Na verdade, não acho tão estranho o LLM não ter recomendado isso. É difícil esperar que ele sugira uma especificação nova que nem o Chrome suporta oficialmente, e eu mesmo talvez não tivesse pensado nisso
Também anotei essa informação. Conversando de verdade com LLM ultimamente, percebi que tratar a ferramenta com um pouco de tolerância, como se fosse uma pessoa, reduz o estresse. Por exemplo, ao programar com cursor, se eu aponto que "faltou isso aqui", às vezes penso que eu mesmo poderia ter cometido o mesmo erro. Também usei LLM como parceiro de "clube do livro" e "clube do cinema" para discutir dois filmes, e embora ele tenha errado situações de personagens, não precisa estar 100% correto; se você oferecer a mesma tolerância que oferece a uma pessoa, a conversa flui muito melhor. É bom manter essa postura positiva ao conversar com AI
Já tinha ouvido falar de registros SRV, mas sempre pareceram pouco usados; HTTPS RR eu não conhecia. O suporte prático também parece melhor do que o de SRV
É o problema clássico de LLM: ele só adiciona a resposta à lista de soluções depois que você mesmo menciona qual era a resposta certa
Se você especificar com clareza suficiente o objetivo e as restrições, o ChatGPT o3 oferece essa solução. Só que ele informa corretamente que funciona apenas em navegadores mais recentes. Exemplo de referência
Depois de usar bastante a versão Enterprise do ChatGPT, aprendi algumas coisas com o tempo. Não funciona bem despejar grandes quantidades de código; o ideal é trabalhar com funções bem independentes ou classes pequenas. Em pedidos de geração ou conclusão de código, cerca de 10% dos casos dá para resolver com instruções adicionais, mas a qualidade cai, e em uns 25% dos casos a qualidade simplesmente não melhora por mais que você explique. Nessas horas, é melhor ignorar e resolver por conta própria. Em compensação, para revisar código recém-escrito ele é bem útil. Metade dos comentários não serve para nada e alguns são ambíguos, mas às vezes ele já apontou bugs ou problemas realmente importantes. Também é melhor não jogar várias páginas de uma vez; vale mais dividir e enviar em partes. Em áreas de nicho como shader HLSL ou SIMD, quase não consegue responder por falta de dados de treinamento. No geral, ajuda a melhorar a qualidade do código. Como eu valido em unidades pequenas de código, a arquitetura vai sendo particionada em funções/classes/módulos e a qualidade geral melhora
Em desenvolvimento de software de longo prazo, o uso mais atraente de LLM talvez seja como um "gerador avançado de boilerplate". Ele já é ótimo para tarefas de uso único que não exigem manutenção, mas também é muito útil no desenvolvimento de longo prazo para código repetitivo difícil de abstrair, como testes. No começo eu tinha resistência, mas agora estou satisfeitíssimo. As partes tediosas e repetitivas viraram um novo jogo interessante de "otimização de prompt", e minha produtividade aumentou bastante. Escrever prompts e revisar código termina muito mais rápido do que fazer trabalho mecânico. Assim, sobram só as partes interessantes que realmente exigem pensar
Percebi que, no fim, LLM na programação e em várias outras tarefas se parece com uma "dieta da moda". Todo mundo quer uma solução rápida e fácil, mas no fim não existe atalho mágico. Conveniência sempre vem com trade-offs, e em algum momento todo mundo acaba aceitando essa realidade