AVISO: Este é o segundo post que escrevi sobre minha palestra no Global Scrum Gathering Munich, e embora eu não ache que você precise ler ambos os posts em ordem, sugiro fortemente que leia os dois para ter a totalidade das ideias que estou compartilhando. Então, aqui vai o link para o primeiro:
Agora, vamos voltar às nossas armadilhas e também falar sobre uma “guerra” que está acontecendo pelos últimos 40 anos: a Guerra dos Editores. Pode parecer uma guerra boba, ou uma simples questão de preferências, mas confie em mim: não é apenas tribalismo geek, é sobre filosofias fundamentalmente diferentes de interação humano-computador.
Eu sou um usuário de NeoVim. Isso significa que sou um daqueles geeks que prefere digitar código no terminal ao invés de usar algo mais moderno como VSCode. Enquanto uso NeoVim eu nunca uso meu mouse ou touchpad: apenas digito coisas e uso um monte de combinações de teclas para navegar pelo código. Mas não estou sozinho! O primeiro editor Vi foi criado em 1976 e desde então sua popularidade só cresceu entre os mais geeks dos desenvolvedores de software.
Por quê? Bem, vamos explicar isso enquanto falamos sobre uma das armadilhas que mencionei em Munique:
Armadilha 4: A Visão de Túnel na Codificação
Vi e seus irmãos (Vim, Neovim) se tornaram populares porque permitiam que desenvolvedores navegassem pelo código mais rápido. Ao invés de mover sua mão para o mouse, rolar para baixo, selecionar uma parte do código que você quer mudar e então digitar a mudança, esses editores propuseram uma ideia diferente: eles teriam modos. Enquanto no modo INSERT, tudo que você digita no teclado apareceria na tela, assim como acontece em qualquer outro editor. Mas no modo NORMAL, cada tecla no seu teclado pode ser usada para navegar pelo código.
Por exemplo: se você pressionar 3wce você instantaneamente mudaria o conteúdo da terceira palavra naquela linha. (Algo como: Vá para a 3ª Word Change até seu End).
Basicamente cria um dialeto para que você possa dizer ao seu editor onde você quer ir e o que quer fazer com seu código sem precisar usar mouse, menus, etc. E acelerar como navegamos pelo código é importante porque desenvolvedores de software gastam mais tempo navegando e entendendo o código do que escrevendo.
Um gráfico representando os resultados de uma pesquisa sobre como desenvolvedores gastam seu tempo
Então, por que estamos focando em usar LLMs para gerar código quando também podemos usá-los para nos ajudar a entender o código? Quer dizer, eles são ótimos programadores, não estou negando isso. Mas na minha experiência eles podem fornecer muito mais valor explicando o código ao invés de apenas criá-lo.
Aqui está um exemplo prático de como fiz isso: estou atualmente escrevendo um software para melhorar as atividades práticas que realizo nas minhas aulas. E em algum momento decidi pedir ao Claude para explicar minha própria arquitetura para mim. Como o Claude se destaca em output de texto, achei que seria legal usar uma ferramenta como Mermaid, uma ferramenta que transforma inputs de texto em diagramas elegantes. Pedi ao Claude para explicar a estrutura usando MarkDown e Mermaid, e colei o resultado em um editor de texto compatível com ambas as tecnologias chamado Typora. Aqui está o resultado:
Essa é uma ótima documentação que pode ser usada para explicar tanto aos desenvolvedores do meu time quanto ao próprio LLM como a arquitetura funciona! Especialmente porque o diagrama pode ser lido pelo LLM como um simples input de texto, minimizando a quantidade de tokens consumidos em cada interação.
A questão é que, não importa se você escreveu o código manualmente ou se um LLM escreveu a coisa toda para você, você ainda será responsável pelas consequências. Portanto, entender o que está acontecendo é fundamentalmente importante.
Lembre-se: se algo funciona e você não sabe como, quando parar de funcionar você não saberá o porquê.
Armadilha 5: O Viés de Volume
Algumas pessoas ainda estão reclamando da qualidade do código gerado por LLMs e discordo fortemente dessa opinião. Na minha experiência, o código gerado é na verdade muito bom.
O que me incomoda é a quantidade de código.
Especialmente porque não acredito em “vibe coding” (isto é: confiar no código gerado e nem dar uma olhada nele). Preciso revisar o código e garantir que está fazendo o que deveria fazer porque… sou um adulto responsável? Então, quando o LLM muda 8 arquivos e adiciona 200 linhas de código para cada prompt que faço, meu trabalho se torna extremamente doloroso e bem, sem graça. Tentei múltiplas abordagens e diferentes prompts para reduzir esse problema mas ainda não encontrei uma solução.
Para ser justo, o Claude 4.0 apresentou uma grande melhoria quando se trata dessa armadilha específica, e acho que teremos uma solução definitiva para isso num futuro próximo. Mas ainda não chegamos lá.
Um prompt, MUITAS mudanças
O que sinto é que ao invés de nos ajudar a andar mais rápido, os LLMs estão nos ajudando a dar passos maiores. Ambas as abordagens podem nos ajudar a cobrir uma distância maior na mesma quantidade de tempo, mas a segunda também vem com um alto custo quando você está andando na direção errada. O modelo de negócio também contribui para isso: quando uso o Cursor, por exemplo, tenho tokens/interações limitados, o que me incentiva a tirar o máximo de cada prompt.
Conclusão
Escrever sobre trabalhar com LLMs é uma coisa estranha. Eu sinceramente acredito em tudo que escrevi neste post hoje. Mas as coisas estão mudando rápido, e este post pode envelhecer como leite ou vinho dependendo dos próximos desenvolvimentos. Se você valoriza aprender mais sobre esse tópico, sugiro fortemente que faça duas coisas: use para criar algo ao invés de apenas ler sobre isso no LinkedIn (melhor ainda: se afaste do LinkedIn de uma vez), e tente ler diferentes opiniões sobre o assunto. O livro de Karen Hao “The Empire of AI” pode ser um bom começo.
