Minha experiência com Claude (Code) Max
DISCLAIMER/ Meu principal objetivo aqui não é estritamente debater sobre o futuro da LLM ("daqui a X anos, você verá"), é sobre o agora. Os desafios apresentados e se realmente vale a pena pagar 200 dólares para ter acesso a um modelo como o Claude Opus 4.1.
Eu estou realmente muito dividido sobre o Claude (Code) Max. Ele é tão bom quanto um júnior, as vezes (bem as vezes) parece até um pleno e, claro, longe de ser um sênior. E meu maior problema com ele esse momento é que: não quero ter um júnior e ter que cuidar desse júnior que simplesmente não tem a capacidade de evoluir.
Eu sei que muita gente faz o miojo da programação e as LLM funcionam bem para isso. Quer fazer sua LP com Stripe? Vai estar pronta em um instante, não tenho dúvidas. Mas, eu não nasci ontem, mesmo no meu workflow mais básico de micro aplicações já tem muito código proprietário, padrões bem definidos e processos estabelecidos. Eu já tenho um código e uma estrutura validada até para esse tipo de micro-saas que a galera anda fazendo, por exemplo. Tudo construído ao longo do meus mais de 20 anos de experiência. Então aqui o Claude é inútil.
Minhas observações tem mostrado que para rascunhos, ele sempre se sair melhor do que não ter nada. Ele funciona para scripts em python. Consegue lidar com PHP. Também tem um pézinho no Java, C# e C. Mas, definitivamente se sai melhor em JavaScript (porque será né?). Nesse caso em específico, tenho que dar o braço a torcer que no front-end, embora os componentes não sejam bem otimizados e faça o uso indevido e excessivo de hooks, acredito que ele faz o papel que qualquer pleno em React faria.
Do outro lado, quando trabalho com projetos mais elaborados, com scripts mais complexos, desde API's com várias integrações, processos, etc, até algoritmos de análise e processamento de dados. O Claude se saí muito mal e desorganizado. E eu estou usando o melhor modelo deles no momento. Criei até uma série de documentos padrões que deixo em (./docs/standards), reescrevo o CLAUDE.md manualmente, converso apenas em inglês e decidi até me especializar em uma série de cursos específicos para otimização do Claude Code e "engenharia" de prompt (embora ache isso uma bullshit). Ainda sim, ele simplesmente é pior que um júnior na maioria dos casos.
Não falo nem sobre o nível de implementação, mas sobre a estratégia que a Anthropic decide aplicar ao CLI, ao modelo e ao raciocino ao implementar as coisas. Até de uma limitação intrínseca da arquitetura transformer, por exemplo. Mesmo um júnior, sendo um profissional curiosos e interessado, sabe o momento de perguntas as coisas (ou até peca pelo excesso) para corrigir a sua rota. Um LLM não e isso atrapalha muito (pelo menos no meu caso).
Para mim o que falta nesses agentes em geral é uma capacidade de interromper o fluxo de raciocínio e auto refletir "perai, não estou encontrando isso no projeto, deixa eu perguntar antes de continuar" ou ainda "será mesmo que essa é a melhor forma de escrever esse código, deixa eu perguntar para meu colega". Eu realmente esperava que o Claude Code me perguntasse mais. Não estou falando de "fiz o arquivo, posso editar", "posso executar esse comando", etc. Estou falando de um senso crítico que provavelmente LLMs não tem e não terão.
Por conta disso, elas não se tornam realmente valiosas para mim hoje. Sempre fico em uma cilada: deixo ele quebrar os padrões, recriar/copiar funções, fazer as loucuras e peripécias que ele costuma fazer desde que esteja funcionando; eu mesmo faço a manutenção disso; ou, entro em um loop "infinito" de prompts até que ele organize tudo exatamente como eu quero (e lá vai créditos). Sinceramente, se eu tiver que perder tempo de revisão e manutenção, prefiro um profissional que pelo menos saiba (de verdade) o que está fazendo. É muito complicado para mim aceitar código mediocre gerado por IA, menos ainda aceitar fazer manutenção em um código espaguetizado feito por uma máquina (possivelmente influência do meu TEA, TDAH e super dotação, sei que tem muita gente que não liga).
À exemplo, recentemente fui fazer um trigger de notificação. O tipo de coisa simples de fazer que, pelo tédio, seria ótimo se a IA fizesse. O objetivo era simples: no pós processamento do dado (em um queue job que já existia), verificar se existe um gatilho (arquivo de configuração pré-definido) para o registro, se for o caso executar a notificação em um novo queue job.
Para implementar isso, só teria que literalmente: ler os arquivos de configuração no startup do sistema para mantê-los em memória, adicionar um método na entidade que receberia um filtro de gatilho e retornar se o registro passou ou não no filtro. Passando no filtro, criaria um novo queue job para receber os dados daquele registro, fazer o tratamento e enviar a notificação. Literalmente iria editar dois arquivos e criar um.
Passei a task para o Claude com o passo a passo, com os objetivos e tudo mais. Oriento ele sempre a ler os padrões do projeto (em ./docs/standards) e escrever um plano de implementação para que possamos debater antes dele implementar. Ele criou um arquivo de implementação com ~500 linhas. Li, fiz as edições cortando excessos (~200 linhas), reescrevi e aprovei a to-do list e pedi para que ele prosseguisse (provavelmente gastei o tempo que eu levaria para implementar logo de uma vez, mas vida que segue).
30 minutos depois, após loops e loops de leituras de arquivos (a maioria desnecessário, mas desde que funcionasse quem sou eu para julgar), ele retorna com a conclusão. 10 arquivos criados, funções deduplicadas, interfaces novas completamente à parte dos padrões, mais de 1.000 linhas de código injetadas na base de código (esse programa hein?!).
E não, ele não foi um super gênio que revolucionou o sistema e adicionou funcionalidades que eu nem sabia que precisava. Ele só fez um monte de pacotes de if's e coisas completamente desnecessárias como: (1) além de utilizar a lib para fazer o parser do schema do arquivo de configuração (o que é correto), verificou de novo manualmente com um monte de if; (2) verificou os mesmos dados várias e várias vezes (porque o sistema é bem modularizado, então ele não conseguiu entender que uma vez verificado no topo da pilha e empacotado em um modelo de dados fechado, você não tem que verificar novamente os dados da mesma forma); (3) criou sua própria função de slugify, mesmo que essa já existisse no projeto, estivesse mencionada na documentação e já estivesse testada e validada; (3) optou pelo algoritmo mais lento possível ao realizar o match do filtro. E por aí vai.
No fim, dei um "git stash" e eu mesmo implementei em ~5 minutos. A grande questão que fica para mim hoje é: onde é que eu vou usar essas ferramentas? Fora o uso para pesquisa, rubber duck debugging... na hora do vamos ver, na implementação, parece que eu perco muito mais tempo com elas em relação as minhas atividades. E chega a ser cansativo e frustrante ver uma série de desenvolvedores (mais influenciando pessoas a comprarem cursos do que qualquer outra coisa) vendendo a ideia de LLM's além do que elas realmente são: um auto-completar muito poderoso (me desculpe se isso te machuca, mas é assim que um transformer funciona).
Minha aposta, portanto, tem sido mais em componentização de front-end, micro funcionalidades e scripts, ou, ainda, em projetos feitos todo por IA para que ela possa livremente seguir as loucuras que ela tenha junto a um processo de revisão mais flexível. Se eu confio nesse tipo de atividade? Não. Já hackeei vários sites da Lovable (reportando devidamente aos autores), já refiz trabalho feito por IA para clientes (por 10x mais do que costumo cobrar). Isso é o que realmente me assusta sobre o futuro do desenvolvimento de software. Ainda não aceitei o fato que tenho que aprender a abraçar código medíocre para trabalhar com ela, porque as vezes o esforço de revisar é muito maior.
Eu já trabalhei no passado liderando vários profissionais júnior/pleno. E acho que o que realmente falta para termos um ponto de ruptura na forma como desenvolvemos software com IA (seja com LLM ou uma nova arquitetura que possa surgir) é uma capacidade de senso crítico ou, pelo menos, uma presunção à burrice.
O que eu quero dizer é que, geralmente, eu espero que profissionais que não tenham expertise técnica o bastante, não apenas quebrem isso em pequenas tarefas (como LLMs até conseguem fazer), mas também questionem e debatam pré, durante e pós implementação. O custo do debate geralmente é muito mais baixo que o custo da manutenção.
Entendo que isso trás muito mais benefícios ao profissional do que ao projeto, mas sem dúvidas contribuí pela qualidade e manutenibilidade do código-fonte. O fato dos agentes de IA em geral não terem a capacidade de pausar o seu processo de pensamento para debaterem com um humano antes de prosseguir é algo que me incomoda bastante. Além do fato, é claro, da janela de contexto limitada, falta de memória, ausência de aprendizagem contínua e incapacidade real de julgamento.
Afinal, um LLM presumidamente sempre está certo porque ele está sempre gerando o próximo token. Ele não é capaz de entender que aquilo que ele sequer ainda gerou, não deve ser gerado. Não existe consciência, não existe AGI e certamente não irá existir dentro da arquitetura desses modelos de linguagem. Ingênuo quem acredita nisso.
Porém, acredito que forçar o modelo a duvidar de si mesmo, pausar a conversa e retomar durante a implementação do próprio código, poderia ser mais produtivo. Mas isso teria que fazer parte do modelo, assim como o raciocínio faz parte do modelo (embora seja apenas um loop de injeção de "auto crítica" simulada). Entendo que isso é bastante complicado e provavelmente impossível. E na minha opinião é isso que vai estourar a bolha de IA e matar o hype por completo nos próximos 6 meses se não tivermos uma mudança na arquitetura proposta.
O processo de raciocínio dos modelos, inclusive, não deixa de ser "engenharia" de prompt. E só uma tentativa de gerar tokens mais relacionados as demandas principais. Só que isso não é suficiente para resolver nem 90% dos problemas que temos e parece que ninguém está disposto a aceitar isso para que possamos seguir em frente.
Um profissional júnior/pleno se desenvolve. Uma LLM não. Um profissional, independente do nível, aprende a estrutura do projeto em uma tarde e lembra dela por meses, incorpora na sua experiência, uma LLM não. Sempre fui contra a ideia de que LLM são revolucionárias, que desenvolvedores serão substituídos ou que esse é o futuro da programação. Continuarei sendo enquanto essa for a arquitetura dominante.
Eu não vou nem entrar no mérito de como isso tem formado profissionais um pouco mais preguiçosos e menos técnicos... afinal, é uma questão de futurologia imaginar que teremos cada vez mais gente menos competente no mercado, que passará uma sensação cada vez maior de LLM serem mais impressionantes, que aumentará cada vez mais os custos com elas e valorizará profissionais que não usaram ela como muleta.
Chego ao fim dessa discussão não para dizer que LLM são irrelevantes. Eles são uma ferramenta, assim como um teclado substituí uma canela. Eles com certeza aceleram o processo de escrita (que nem sempre vai estar certo). Antes você ter um rascunho para trabalhar em cima do que não ter nada (talvez?!). As vezes esse rascunho pode atrapalhar muito. E outras vezes ele pode ser o suficiente para economizar uma tarde. Esse comportamento não determinista dentro do processo de desenvolvimento de software para mim é um regresso completo à capacidade humana.
Claro que gosto muito mais da ideia de LLM como um chat, não atoa ele nasceu assim. Você pode conversar com um "banco de dados" gigante. Ter "insights" imediatos e "destravar" pensamentos. Se antes eu conversava sozinho, com pessoas não técnicas ou similares, hoje conversar com uma LLM "contribuí" para que eu consiga pensar em alguma ou outra possibilidade. Ainda sim, coloco entre muitas aspas, pois vejo um problema aqui. A constante bajulação dos modelos, afirmações e presunção de certeza prejudicam muito o crescimento de uma conversa que realmente mudou a minha forma de ver uma nova feature ou processo de implementação.
Eu sei que vai ter uma galera que vai dizer "e o prompt?", mas tenho certeza que a maioria sequer sabe como a arquitetura transformer funciona. Que, para mim, é só um Google 2.0 que eu com certeza não vou deixar de usar. Agora, se vale os 200 dólares eu realmente não sei, estou vendo que gasto meus limites mais pelos vícios de tentativa e erro com a IA do que qualquer outra coisa. Sim, ainda é mais barato do que ter um júnior trabalhando contigo, mas eu pago pelo pacote da Adobe e também não é um problema. Quando custar 1000 dólares, ainda sim já vai dar para começar a repensar se vale o desperdício.