LLMs são coisas boas e ruins ao mesmo tempo

Minha posição sobre LLMs

Bem, eu venho pensando bastante sobre o uso de LLMs. Não vou fazer um guia de prompts, dizer que a inteligência artificial vai acabar com a programação ou defender que todo mundo precisa usar essas ferramentas.

Também não é um texto anti-IA. Eu uso LLMs e, para ser sincero, uso bastante.

LLMs são coisas boas e ruins ao mesmo tempo. Eu sei que isso parece uma resposta meio covarde, de quem não quer escolher um lado, mas é literalmente o que eu penso. A mesma coisa que torna uma LLM útil também pode tornar ela perigosa.

Ela diminui o atrito entre ter uma ideia e ver alguma coisa funcionando. Só que também diminui o esforço entre não saber direito o que está fazendo e produzir um resultado que parece correto.

Esse é o meu ponto principal: o custo de fazer algo errado caiu, o custo de fazer algo funcional caiu, mas o esforço mental do processo também está caindo.

Essa discussão não começou agora

Na verdade, essa discussão é bem antiga. Se não me engano, até Edsger W. Dijkstra entrou nessa pira ao falar sobre ferramentas, linguagens e o trabalho de programar.

Digo “se não me engano” porque é bom conferir antes de atribuir qualquer coisa a alguém que já morreu e não pode aparecer no X para me chamar de burro. O texto linkado é The Humble Programmer, uma palestra de 1972.

Dijkstra não estava falando de LLMs e nem fazendo uma crítica específica ao BASIC. O ponto era mais amplo: computadores mais poderosos não eliminam a dificuldade da programação. Pelo contrário, eles permitem que a gente tente resolver problemas maiores e mais ambiciosos.

Ele também falava sobre como ferramentas e linguagens influenciam os hábitos de pensamento de quem usa elas. É aí que a comparação fica interessante. Uma ferramenta não apenas executa uma tarefa. Ela também muda a forma como a gente pensa sobre essa tarefa.

O custo de fazer errado caiu

Antes de usar uma LLM, se eu quisesse criar uma coisa qualquer, precisava pelo menos pesquisar como começar. Isso não quer dizer que eu entendia tudo, mas existia uma fricção mínima: procurar a documentação, abrir um exemplo, descobrir o nome de uma propriedade, compilar, quebrar e tentar entender por que quebrou.

Agora posso escrever:

Crie um tema para o Hugo com foco em SEO e qualidade de leitura, usando tons em preto e laranja inspirados em abelhas.

Em poucos segundos existe alguma coisa para abrir e olhar. Talvez seja uma porcaria. Talvez nem compile. Talvez seja uma porcaria que compila, que é uma categoria especialmente perigosa. Mas existe alguma coisa.

Isso é ótimo para experimentar. Uma ideia que antes morreria porque parecia trabalhosa demais agora pode virar um protótipo. O custo de testar uma hipótese ficou bem menor.

O problema é quando eu confundo um protótipo funcionando com uma solução que eu entendi.

Uma LLM consegue criar um tema que renderiza, tem uma aparência razoável e até segue algumas boas práticas de SEO. Só que isso não quer dizer que eu saiba explicar o HTML, o CSS, a acessibilidade, o sistema de templates ou as decisões de responsividade daquele tema.

Pode funcionar muito bem até o dia em que alguma coisa sair do caminho feliz. Aí a pergunta deixa de ser “a LLM consegue criar?” e passa a ser “eu consigo manter o que ela criou?”.

Fazer funcionar e entender são coisas diferentes

E aqui vem a parte chata: é possível produzir mais usando uma LLM e aprender menos no processo.

Não vejo contradição nisso. Posso terminar uma tarefa, entregar um resultado e ainda assim sair dela sem um modelo mental melhor do que eu tinha antes.

Enquanto tudo funciona, qualquer implementação parece inteligente. O problema aparece quando preciso alterar alguma coisa sem pedir para a LLM refazer tudo, localizar um erro ou tomar uma decisão que não apareceu na resposta dela.

Aprender costuma exigir um pouco de resistência. Ler uma documentação confusa, testar uma hipótese ruim, escrever um exemplo pequeno e descobrir que a primeira ideia estava errada fazem parte do processo. Se eu removo toda essa resistência, talvez esteja removendo também o exercício que fazia a informação ficar na minha cabeça.

Não estou dizendo que toda dificuldade é boa. Repetir código burocrático por horas não me torna um programador melhor. Mas existe uma diferença entre remover trabalho repetitivo e remover a necessidade de pensar.

Como eu tento usar LLMs na programação

Minha regra, pelo menos por enquanto, é simples:

Escreva para a LLM aquilo que você já sabe, em passos bem curtos. O que você não sabe, procure na documentação e escreva com suas próprias mãos — pelo menos até entender o que está fazendo.

Não é uma regra universal e provavelmente vai mudar. É só uma forma de impedir que a ferramenta pule justamente a parte que eu queria aprender.

Quando já conheço o problema, uma LLM ajuda bastante. Posso pedir um esqueleto de código, uma refatoração mecânica, testes para casos que já defini, uma conversão entre formatos ou uma explicação de um trecho específico. Nesses casos, pelo menos tenho algum mapa para perceber quando a resposta está indo para o mato.

O cenário muda quando não conheço o assunto. Se eu não sei como uma API funciona, qual é a garantia de uma biblioteca ou quais são as limitações de um formato, a resposta mais bonita do mundo ainda pode estar errada.

Nesse caso, começo pela documentação, pelos exemplos oficiais e pelo código-fonte quando for necessário. Depois posso usar a LLM para resumir um trecho, comparar duas alternativas ou explicar palavras que não conheço. A documentação é a fonte; a LLM entra como alguém que me ajuda a ler.

Um exemplo: pedir um tema para o Hugo

O exemplo do tema mostra bem essa diferença. Posso fazer um pedido amplo:

Crie um tema para o Hugo com foco em SEO e qualidade de leitura, usando tons em preto e laranja inspirados em abelhas.

Ou posso descrever algumas restrições técnicas:

Crie um tema para o Hugo. Use media queries para responsividade em desktops e telas pequenas, use unidades rem para tipografia e espaçamento, limite a largura do texto a uma medida confortável e mantenha a direção de leitura adequada para o português.

O segundo pedido é melhor porque comunica mais decisões. Também corrige um problema do meu exemplo original: o recurso usado para adaptar um layout a diferentes tamanhos de tela é, em geral, uma media query, não simplesmente um media type.

Parece um detalhe pequeno, mas ele mostra uma coisa importante: usar palavras técnicas não é a mesma coisa que entender a técnica.

Se eu não sei a diferença, posso escrever um prompt cheio de termos corretos pela metade e receber um resultado que parece profissional. A LLM não vai necessariamente me impedir de fazer uma pergunta ruim. Ela pode simplesmente preencher as lacunas com alguma coisa plausível.

Além disso, “foco em SEO” é uma instrução muito vaga. SEO não é só colocar uma palavra-chave no título. Tem estrutura semântica, títulos hierárquicos, descrição, links internos, URLs, desempenho, acessibilidade e outras decisões que dependem do contexto.

Uma LLM pode ajudar a levantar esses pontos. O que ela não deveria fazer é me convencer de que eu já entendi tudo só porque produziu um arquivo grande e bonito.

Ainda vale a pena usar

Apesar de tudo isso, eu não quero parar de usar LLMs.

Quando usadas com algum critério, elas reduzem o tempo gasto com código repetitivo, ajudam a transformar uma ideia em um primeiro experimento e tornam menos assustador abrir um projeto desconhecido. Também são úteis para conversar sobre alternativas, encontrar casos de teste e perceber que eu esqueci alguma condição óbvia.

Para quem trabalha sozinho, isso pesa ainda mais. Nem sempre tenho alguém para perguntar como uma biblioteca funciona ou para revisar cada decisão pequena. Uma LLM pode ser uma interlocutora inicial, mesmo sem substituir uma revisão de verdade.

Às vezes o maior ganho não é terminar mais rápido, é conseguir começar. Um protótipo ruim ainda pode ensinar alguma coisa, desde que eu trate ele como protótipo e não como produto pronto.

Mas a conveniência começa a dar ruim quando vira dependência.

Existe uma falsa sensação de conhecimento. A resposta vem organizada, cheia de exemplos e com uma confiança irritante. É fácil aceitar uma afirmação sem conferir a documentação ou copiar um código sem entender suas consequências.

Também dá para terceirizar todas as decisões. Se eu peço para a LLM escolher a arquitetura, a biblioteca, o modelo de dados e a estrutura dos diretórios, talvez receba um projeto coerente. Só que a coerência da resposta não significa que as escolhas sejam boas para o meu problema.

E tem a homogeneização. Se todo mundo pede para a LLM “seguir as melhores práticas”, muita coisa começa a parecer igual. Às vezes isso é bom, já que padrões existem por algum motivo. Mas também podemos parar de perguntar se o padrão resolve o problema real ou só parece familiar.

Por fim, a LLM pode simplesmente estar errada. Pode inventar uma função, misturar versões de uma biblioteca, esquecer uma restrição de segurança ou afirmar que algo é impossível quando não é. A responsabilidade pelo código continua sendo minha, mesmo quando a primeira versão veio de outra coisa.

Conclusão

O que estou tentando fazer é escrever primeiro o objetivo e as restrições com minhas próprias palavras, quebrar o trabalho em partes pequenas, pedir ajuda para uma parte específica, conferir a documentação, testar e ler o diff.

Se existe alguma mudança que eu não consigo explicar, não considero que terminei. Tenho um artefato, não necessariamente conhecimento.

No geral, LLMs são boas e ruins ao mesmo tempo porque diminuem o custo de quase tudo. Isso inclui experimentar, prototipar e automatizar tarefas chatas. Também inclui pular etapas, aceitar respostas erradas e produzir algo que eu não sei manter.

Não quero parar de usar LLMs. Seria uma decisão meio estúpida fingir que uma ferramenta útil deixou de existir só porque pode ser usada de maneira ruim. Também não quero entregar meu processo inteiro para um modelo e chamar isso de produtividade.

Meu objetivo é usar a LLM onde eu já tenho algum mapa. Quando estou entrando em um assunto desconhecido, prefiro abrir a documentação, ler devagar e escrever uma parte na mão. Depois posso voltar para a ferramenta com perguntas melhores.

Então fica a regra por enquanto: escreva para a LLM aquilo que você já sabe, em passos curtos; o que você não sabe, procure na documentação e tente entender antes de terceirizar.

Fui!