6 semanas usando o Claude Code
(blog.puzzmo.com)- Desde a adoção do Claude Code, a forma de escrever e manter código mudou drasticamente — a ponto de poder ser comparada à “chegada da fotografia ao mundo da programação”, permitindo implementação rápida e liberdade de expressão
- Tarefas repetitivas e vistas como “dívida técnica” (migrações, troca de framework etc.) agora podem ser tocadas rapidamente até sozinho e em paralelo, com quase nenhum peso extra junto ao trabalho principal
- Um padrão de desenvolvimento experimental de “testar primeiro e decidir depois”, gerando e apagando com facilidade testes/abstrações/código experimental, trouxe ganhos de produtividade e insight
- Prototipagem de jogos, colaboração e deploys experimentais aceleraram muito — designers de jogo conseguem transformar ideia em execução em poucas horas, mesmo sem programar
- Em ambientes favoráveis ao Claude Code, como monorepo, stack técnica clara e codebase atualizada, a velocidade e a flexibilidade do trabalho de desenvolvimento melhoram bastante
Introdução: mudanças após adotar o Claude Code
- Ao usar o Claude Code nas últimas 6 semanas, ficou clara uma mudança significativa na forma de escrever e manter código
- Parece ter surgido uma “liberdade de expressão” em que não é mais preciso escrever todo o código manualmente
- Com Claude Code, é possível conceber a estrutura inteira de uma vez e produzir o resultado por meio de revisão e edição
- Assim como o surgimento da fotografia reduziu o apelo de desenhar tudo à mão, o processo de entrada e produção na programação também está mudando profundamente
- Essa mudança pode causar insegurança, mas o surgimento de ferramentas baseadas em LLM está provocando uma mudança de paradigma na programação
1. Como o Claude Code mudou a escrita e a manutenção de código
- Trabalhos como migração, refatoração e redução de dívida técnica, que antes levavam de semanas a meses, passaram a ser feitos em paralelo e concluídos nesses 6 semanas após a adoção do Claude Code
- Exemplos: conversão de centenas de componentes React Native para React, substituição do sistema RedwoodJS, migração de Jest→Vitest, server-side rendering, refatoração do design system, upgrade para Node 22 etc.
- Side projects e backlog que antes exigiam “reservar um cronograma separado” agora podem ser tocados no tempo livre junto com o trabalho principal, com quase nenhuma sobrecarga
- A antiga lógica de “dívida técnica exige tempo reservado → grande esforço concentrado” foi quebrada, e surgiu uma imediaticidade em que se pode começar, avançar e concluir na hora
2. Cultura de desenvolvimento experimental: “teste primeiro e decida depois”
- Quando surge uma ideia, primeiro se testa com Claude Code, aprendendo por meio de ciclos repetidos de geração e remoção automática de itens como código de teste
- Mesmo sem uma estratégia consolidada de testes de frontend, foi possível gerar e apagar na hora diferentes abordagens de teste para cada PR com Claude Code, acumulando experiência e ajudando a definir a direção geral
- Até reflexões sobre ideias e abstrações podem ser validadas e exploradas rapidamente no modo “tentar diretamente → sem custo alto se falhar”
- Como o custo do fracasso caiu drasticamente, o ciclo de experimentação-aprendizado-decisão acelerou muito
3. Mudanças no desenvolvimento paralelo e na colaboração
- Usando dois clones de git/perfis de VSCode, é possível tocar trabalhos independentes em cada clone (por exemplo, um para preparar PRs e outro para desenvolvimento experimental)
- Enquanto o Claude Code trabalha em um clone, dá para continuar em paralelo no outro, ou diferenciar claramente cada ambiente com temas/portas distintos
- Isso permite escrever Pull Requests em paralelo, evitar conflitos de porta no servidor de desenvolvimento e melhorar a eficiência
4. Revolução no processo de protótipos de jogos e desenvolvimento experimental
- O processo de criar protótipos de jogo → distribuir internamente → coletar feedback → publicar ou descartar, que antes levava de semanas a meses, passou a permitir que até designers escrevam código e publiquem no site em poucas horas após a adoção do Claude Code
- O ciclo de ideia → execução → feedback da equipe → encerramento do experimento ou transição para produção (reescrita) ficou dramaticamente mais curto
- Por outro lado, surgem novas questões operacionais, como gestão de jogos temporários e critérios para formalização ou descarte
5. Uso do Claude Code no coding e na colaboração do dia a dia
- Durante a triagem semanal, é possível usar a ação do GitHub do Claude Code para gerar PRs e fazer experimentos na hora, aplicando pequenos issues imediatamente
- Quem usa Claude Code com mais eficácia são membros da equipe com domínio tanto de produto quanto de tecnologia e com iniciativa, os “full-breadth developers”
- "Full-breadth developers": ajuda um único desenvolvedor a conduzir com liberdade todo o fluxo de trabalho
- Quando humanos mantêm o papel de revisar código, fornecer contexto e decidir/corrigir, a produtividade e a criatividade de toda a equipe aumentam
6. Ambientes de codebase favoráveis ao Claude Code
- Monorepo: como todo o código, schema de DB, API e lógica de tela ficam em um só lugar, o Claude Code é ideal para entender contexto e automatizar tarefas
- Adoção de uma stack padronizada (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap etc.), que o LLM entende e automatiza com facilidade
- Manter a codebase atualizada e minimizar legado maximiza a eficiência do uso de LLMs
7. Limites do Claude Code e mudanças percebidas na prática
- Mudanças quantitativas, como número de PRs/commits, não são tão grandes, mas a sensação de velocidade, flexibilidade e produtividade no trabalho melhorou muito
- O Claude Code funciona como um pair programmer de nível “júnior experiente+” — quando o engenheiro cuida da qualidade, da lógica e do contexto do código, ele vira um ótimo parceiro
- Em tarefas repetitivas, redução de dívida técnica e avanço rápido de side projects, ele oferece uma experiência de trabalho qualitativamente diferente
8. Estratégia de “implementação paralela” recomendada para juniores e aprendizes
- Não há necessidade de ficar obcecado demais com as tendências mais recentes do ecossistema de LLMs
- Para desenvolvedores iniciantes, a recomendação é escrever o código por conta própria e depois pedir ao Claude Code a mesma tarefa, para então comparar e aprender com a análise
- Com as soluções do Claude Code, é possível absorver rapidamente diferentes abstrações e padrões reais de trabalho
- Usando o LLM como “concorrente + mentor”, dá para evoluir ao mesmo tempo em capacidade prática e percepção do ecossistema atual
- O Claude Code é como um celular: não precisa ficar sempre ligado
- No fim, o importante é manter o controle e usá-lo com eficiência
9. Explosão de side projects e experimentos de curto prazo
- Pequenos experimentos, ferramentas e melhorias em blog, que antes eram difíceis por falta de tempo e energia, agora podem ser feitos com Claude Code em poucas horas
- Ideia → implementação imediata → sem grande custo se falhar — isso facilita tocar experimentos criativos e projetos pessoais em paralelo à produção
10. Exemplos reais de conversas com Claude Code e code review
- Há exemplos concretos de pedidos, geração de código, execução, correção e revisão em casos como script de limpeza de DB, puzzle REPL e layout de PDF de palavras cruzadas
- Erros de LLM (raciocínio, exagero, hardcoding etc.) podem ocorrer — para obter valor real, o engenheiro precisa necessariamente fazer a validação lógica e assumir a responsabilidade pela qualidade
11. O lugar do Claude Code na engenharia e conclusão
- O Claude Code é especialmente bom em receber contexto amplo, como código de referência, screenshots e explicações adicionais
- O Claude Code é um programador assistente de nível “post-júnior (acima de júnior experiente)” — com paciência infinita e grande velocidade, é muito eficiente como parceiro de trabalho
- Design, qualidade e controle final ficam com o engenheiro humano, enquanto o Claude Code amplia enormemente o alcance e a velocidade de implementação, experimentação e automação
- Isso viabiliza um ambiente de desenvolvimento em que se deixa para trás a limitação de “precisar programar linha por linha manualmente” e se pode focar mais em design, controle de qualidade e inovação
7 comentários
Eu também estou usando o Claude Code com muita satisfação.
Acho que já faz umas 6 semanas que estou usando também.
Concordo com a maior parte do conteúdo.
https://jeho.page/essay/2025/07/15/claude-code.html
Opiniões no Hacker News
Depois de usar o Claude Code por cerca de 2 semanas, apesar de eu normalmente ser cético em relação a IA para programação, fiquei realmente impressionado. Para ganhar experiência, existe uma certa curva de aprendizado, e é essencial fornecer o contexto adequado e dividir bem as tarefas. Claro, é preciso saber programar; se você simplesmente jogar para a IA tudo o que não sabe, com certeza vai dar problema. Como tenho mais de 25 anos de experiência, sinto confiança para revisar qualquer resultado que o Claude Code produza e corrigir quando estiver errado. Há uns 10~15 anos, eu sonhava com algo como uma interface neural em que não fosse necessário escrever código diretamente, e o Claude Code dá a sensação de realizar isso até certo ponto. Às vezes eu batia no limite diário de uso e passei a usar bastante o modelo Gemini CLI 2.5 pro como substituto, mas nem dá para comparar com o Claude Code. O Gemini é tão frustrante que não consigo usar. Antigamente eu jamais imaginaria pagar mais de 100 dólares por mês por uma ferramenta de desenvolvimento, mas estou considerando seriamente fazer upgrade para o plano Max.
Acho que essa ferramenta combina bem com situações em que um desenvolvedor sênior pode aconselhar e orientar um júnior. Pelo que ouço de outros desenvolvedores sêniores ao meu redor, muitos reclamam que os juniores acabam gerando com LLMs código ainda mais estranho, mais lento, vulnerável em segurança ou simplesmente bagunçado, e depois mandam PR sem sequer entender o código. Para mim, o uso mais útil é gerar boilerplate (se eu der a descrição, ele até cria o desenho das classes), converter JSON em classes ou outros formatos, e fazer perguntas como “o que há de errado com este código?” ou “como um engenheiro de nível Staff mudaria isso?”. Já aconteceu de o Claude Code encontrar bugs antecipadamente em código que eu mesmo tinha digitado.
O interessante é que as pessoas céticas em relação a “vibe coding” costumam ter expectativas baixíssimas até realmente experimentarem a ferramenta. Muita gente acha que o código gerado por LLM vai ser lixo e trata exemplos extremos como se fossem a média. Mas, quando usam de fato, acabam se surpreendendo com o quanto é melhor do que esperavam. Claro, não dá para montar do nada um SaaS de 1 bilhão de dólares com uma equipe de 10 pessoas usando Claude Code, mas ainda assim muita gente subestima o poder real da ferramenta.
Na prática, sendo rigoroso, você não está fazendo vibe coding. Está mais próximo de engenharia de software com apoio de IA. Vibe coding significa aceitar qualquer código que a IA produzir e seguir em frente sem entender nada. Como a definição do termo varia de pessoa para pessoa, talvez seja melhor não confiar demais nesse rótulo.
Até poucos meses atrás, eu também não pagava mais de 20 dólares por nenhum serviço de assinatura, mas hoje pago 200 dólares por mês no plano Max 20. Sou um desenvolvedor de origem eslovaca morando nos EUA, com 20 anos de experiência, e eu mesmo ainda me surpreendo com isso. Já usei outras ferramentas, mas sempre foi difícil sentir um ganho de produtividade e eficiência tão direto quanto este. O Claude Code realmente está em outro nível. Claro, ainda precisa de acompanhamento nos detalhes, mas meu fluxo é usar o Plan Mode para definir cuidadosamente os requisitos e o plano de mudanças no código; quando concordo 100% com isso, executo, e depois faço code review do resultado. (Erros de compilador, testes unitários e problemas de lint a IA corrige sozinha.) Parece ter um engenheiro júnior extremamente rápido, um pouco excêntrico, mas muito bem informado. O desenvolvimento de software está claramente indo nessa direção, e esse é o futuro.
Ultimamente tenho achado que os modelos Claude não são muito confiáveis para escrever ou modificar SQL. Por exemplo, montam bem as cláusulas de condição, mas não colocam parênteses para agrupar
AND/OR, e o Gemini pro consegue detectar isso corretamente como bug.Concordo profundamente que o Claude Code está claramente à frente de todas as ferramentas concorrentes. Desde 2023 venho criando minhas próprias ferramentas de CLI para geração de código com IA e diria que já experimentei praticamente todas as principais opções. Me identifiquei muito com vários dos métodos do autor:
docs/external-deps).Sobre o segundo item (começar com uma boa especificação), tenho curiosidade sobre como você organiza isso na prática. Você separa em um documento Markdown? Até que nível de detalhe vai? Também concordo com o conselho de “ter testes desde o início”, mas na prática, quando existe algum hook de testes, às vezes o Claude acaba pulando a criação inicial dos testes e apenas repete correções sem validar bugs nem premissas. Já cheguei a usar flags para ativar e desativar comportamentos relacionados a testes.
Um monorepo economiza seu tempo, mas aumenta muito mais as chamadas de ferramenta e o consumo de tokens do Claude. Acho melhor a abordagem de selecionar só os arquivos necessários e passá-los para a IA, como o Aider faz. Não entendo bem por que o Claude é tão popular. O Aider é melhor em quase todos os aspectos e ainda permite integrar vários LLMs diferentes.
Para usar o CC direito, é preciso ter uma estrutura de projeto bem organizada. Em um projeto Django com testes, tipos e documentação bem montados, o CC fez quase tudo muito bem, embora tenha precisado de orientação no caminho. Recentemente também estou fazendo um side project para rodar o CC offline com modelos locais. A primeira versão ficou boa com ajuda do ChatGPT, mas quando migrei para o CC, ele passou a dar voltas nos problemas centrais, contornar os erros e, em vez de refatorar o código existente ou corrigir bugs, tinha o hábito de criar arquivos e scripts novos o tempo todo.
Fiquei curioso se você formata a documentação externa diretamente dentro do projeto. A maioria dos projetos só tem documentação em sites, então queria saber se você realmente investe tempo em criar arquivos Markdown limpos separadamente.
O verdadeiro poder do Claude Code vai além de simplesmente programar: ele consegue controlar o computador inteiro. Se existir uma ferramenta de CLI, o Claude pode usá-la; e, mesmo que não exista, muitas vezes ainda assim ele surpreende se você pedir. Por exemplo, já deixei com ele tarefas diversas como cortar/redimensionar imagens, extrair mp3 de vídeos do YouTube e remover trechos silenciosos de arquivos de áudio. Isso tem me poupado um tempo enorme. Eu mal lembro como era antes. Acho que nunca mais vou conseguir voltar ao jeito antigo.
Em vez de conectar o Claude ao seu computador real, é melhor dar a ele um computador separado (e não a sua máquina principal). No meu caso, tenho uma IDE rodando em uma VM na nuvem, conecto o Claude nela e acesso tudo pelo navegador (https://brilliant.mplode.dev). Na minha opinião, esse é o UX ideal, o mais próximo de operar agentes de verdade. Não precisa preparar terminal nem
ssh; basta fazer login, e a instância é criada/pausada automaticamente. No fim, é como abrir direto por link um Claude + uma instância Linux pessoal + uma IDE. No futuro, pretendo subir várias instâncias como eu quiser e controlar de forma granular permissões, sistema de arquivos e permissões de contêiner (JWT etc.). Se surgir uma falha ou algo que exija revisão, basta entrar direto na IDE e resolver. Nem precisa de UI separada; dá para ver tudo pelos painéis da IDE ou até abrir o webapp diretamente no contêiner. Faz tempo que eu não ficava tão empolgado com o avanço da tecnologia.Embora tudo pareça ótimo, se você olhar apenas para o código produzido, os dados mostram quase nenhuma diferença entre antes e depois. Mesmo trabalhando com o Claude, commits, PRs e linhas de código não mudam muito em relação ao passado. Ou seja, IA para programação passa uma sensação de “a produtividade aumentou” e de “é bom criar algo sem colocar tanto a mão”, mas na prática ainda exige muita revisão, correção e re-prompting, e o volume total de saída acaba parecido. E, ao transferir as partes difíceis para a IA, sua própria capacidade de design e raciocínio vai enfraquecendo aos poucos. Se você passar um mês usando só Claude e outros LLMs e depois tentar fazer um app pequeno sozinho, não só o código, mas a própria arquitetura geral vai parecer mais difícil. No longo prazo, há um risco real de o codebase ir se deteriorando lentamente e isso acabar ficando negativo (pelo menos com a geração atual de LLMs).
Antes eu montava um a um comandos do ImageMagick como
mogrifydo jeito antigo. Com apoio de ferramentas de IA, estou economizando uma quantidade absurda de tempo.Pedi ao Claude que diagnosticase a causa de um Linux PC meu que ficava travando, e ele analisou os logs com
journalctlaté descobrir a origem. Foi uma ajuda muito concreta na solução do problema.Outro caso: gerar sites estáticos ficou muito fácil. Posso escrever um texto em qualquer sintaxe e pedir ao Claude Code para transformar aquele post no formato do meu blog, e ele resolve. Por exemplo, basta escrever “insira a imagem
image.jpeg” que ele faz na hora. É muito conveniente não ficar preso a Markdown ou ao formato do Hugo.Como alguém que usou Claude code de 12 a 16 horas por dia, descobri algumas dicas:
O item 5 também funciona além de Docker, se você integrar com o servidor MCP do Playwright para fazer o Claude verificar UI e requisições imediatamente. 6. Comece em plan mode e itere no plano até gostar dele. 7. Use agressivamente o recurso de slash command (
/comando) como mini-prompts para melhoria contínua, fornecimento de contexto e até instruções para usar ferramentas externas comogh. O compacting não deve ser feito abruptamente no 0%; é melhor aplicar em um ponto intermediário adequado. Pode haver discordância sobre o item 1 (recomendar sonnet).Eu tendo a evitar Docker, mas fiquei muito curioso com a dica 5 (usar o Claude para orquestração de Docker). Queria saber que formato de prompt você usa.
Também tive sucesso criando primeiro um arquivo
plan.mdmuito detalhado (conexões entre sistemas, arquitetura geral etc.) e depois deixando ferramentas como claude-loop (https://github.com/DeprecatedLuke/claude-loop) rodarem durante a noite, para eu aplicar patches manualmente de manhã.Fiquei curioso sobre como alguém consegue usar Claude Code 16 horas por dia.
Às vezes o Claude mexe demais dentro do contêiner. Eu só queria que ele entendesse o código, mas ele começava a executar o projeto de inúmeras formas dentro do contêiner e acabava deixando tudo mais estranho. Antigamente também já aconteceu de ele pipear arquivos para comandos de CLI e não produzir efeito nenhum — um exemplo dessa tendência quase obsessiva de sair executando coisas.
Não sei o quão bom o Claude Code realmente é (nunca usei diretamente), mas há um ponto que me deixa em conflito. Quero refatorar um projeto pessoal em
gdscript(tipo Python), lento e bagunçado, para C#, deixando mais limpo e rápido. É um desafio novo para mim e tem bastante valor educacional. Se eu usar o Claude, sinto como se estivesse tirando de mim mesmo uma oportunidade valiosa de aprender (algo que talvez ajudasse meu crescimento no longo prazo). Se eu não usar, sinto que estou só investindo tempo precioso em um trabalho tedioso, que no fundo será automatizado no futuro. Fico preso nesse dilema o tempo todo.Em 35 anos de carreira como desenvolvedor, uso IA apenas quando eu mesmo conseguiria resolver, mas não quero fazer porque é chato ou repetitivo. Por exemplo, deixei com o Claude a tarefa de ajustar um schema Open API 3.0 porque, se eu fizesse isso manualmente, não aprenderia nada. Também peço para a IA gerar código de exemplo. Quando surge algo realmente novo para aprender, organizo em flashcards em apps como Anki SRS ou anoto em um blog TIL. Ou então implemento os exemplos várias vezes com as próprias mãos para transformar isso em experiência. O ponto central é que o aprendizado só se fixa de verdade quando você conecta o novo conhecimento ao cérebro pelo menos duas vezes. É como aprender uma palavra nova em linguagem natural e usá-la integrada em 3 frases diferentes.
Se você não revisar diretamente o código gerado (ou seja, se não aprender C# o suficiente), o codebase vai se degradar num piscar de olhos. Programar com LLM tende a acumular erros, então isso precisa melhorar; caso contrário, vira um monte de lixo impossível de manter. Alguns amigos meus dizem que fazem a IA gerar testes suficientemente bons para detectar os problemas cedo, mas eu ainda não consegui usar esse método. Meu código é muito mais orientado à lógica do que a algoritmos, então escrever testes também fica meio nebuloso.
Trabalhando há 16 anos como desenvolvedor profissional, senti que o Claude Code facilitou muito resolver coisas nas quais eu ficava travado batendo cabeça. Para aprender coisas novas rápido, ferramentas de IA (especialmente no modo “ask”, de perguntas e respostas) são eficazes, e eu uso ativamente analogias, casos e técnicas de memorização. Se o objetivo é um aprendizado profundo por meio de crescimento lento, então o jeito clássico, feito manualmente, ainda é melhor mesmo sendo mais lento. Mas, se o objetivo é aprender rápido, usar IA também não é uma má opção. Se você só quer entregar resultado, é importante escrever bem a especificação e cuidar bem dos testes. No fim, seja qual for o método, acho que o importante é continuar construindo coisas.
Houve uma época em que estava na moda em blogs dizer “crie sua própria biblioteca x”. É no processo de implementar algo por conta própria que mais se aprende. Por exemplo, se você quer entender roteamento client-side, pode criar seu próprio router. Na era dos LLMs, qualquer coisa pode ser substituída por código de biblioteca, mas, se eu realmente quiser aprender C#, é melhor fazer a portabilidade eu mesmo. Se eu só precisar do resultado e quiser focar em outras partes, aí posso delegar ao Claude. Aprender necessariamente envolve uma fase de dor; se for fácil demais, na verdade você não aprendeu nada.
Antes da IA, a moda era copiar e colar. Amigos que arrancavam código do Stack Overflow sem nem entender o motivo acabavam não aprendendo nada. Acho que não há problema em pedir à IA conselhos ou explicações conceituais. Mas, se você pedir para ela escrever tudo por você, aí com certeza não há aprendizado. Dito isso, também é sábio preservar o seu tempo como desenvolvedor. Há infinitas coisas para aprender; então, se seu objetivo é desenvolvimento de jogos, talvez portar trabalho em GDscript não seja uma experiência indispensável. Claro que ainda há aprendizado envolvido.
Depois de cerca de 3 semanas programando com Claude Code, eu, com 10 anos de experiência, trabalho principalmente com Python ML/engenharia de dados. Vejo várias razões:
Eliminar a dor de começar é enorme. Antes havia várias coisas que eu pensava “eu faria isso se tivesse tempo”; agora, com alguns prompts, consigo executar. Na prática, eu queria fazer o jogo NYT Connections no terminal, e ficou pronto em 3 prompts (https://github.com/jleclanche/connections-tui).
O item 4 me marcou especialmente. Antes era natural deixar testes ou dívida técnica para depois, mas agora basta dizer “precisa disso” que um test suite razoavelmente bom é gerado automaticamente. Talvez não fique perfeito, mas pelo menos tarefas de dificuldade intermediária passaram a ser cobertas com mais consistência.
Como alguém curioso, parte de uma minoria que continua tentando programar com agentes, venho pensando por que minha experiência é tão diferente da narrativa dominante. Acho que a chave está nesta explicação:
Eu gostaria de questionar se ainda existe mesmo um ambiente em que as pessoas pintam e pagam por pinturas. Parece que a maior parte do artesanato, empurrada para fora por processos modulares e produção em massa, agora vale menos pelo produto em si e mais pela experiência compartilhada entre produtor e consumidor por meio da imaginação. Não é apenas comprar um objeto na Amazon; a relação com o artesão e o processo criativo passam a ser consumidos como narrativa. Acho que a programação vai precisar caminhar nessa direção para sobreviver no futuro.
Também entendo muito bem esse ponto de vista. Reconheço a utilidade da programação com agentes para tarefas pequenas, correção de bugs e rascunhos. O que eu não entendo é por que o debate a favor/contra fica tão intenso quando, no fim, estamos falando de várias interfaces envolvendo um pequeno número de modelos. Também continuo pensando sobre o impacto disso para desenvolvedores juniores. Se a IA automatizar code review também, minha vida provavelmente ficará ainda mais feliz.
Não acho que essa analogia seja totalmente válida. Historicamente, a pintura era o único meio de reproduzir o mundo real, mas arte não é simples cópia da realidade; é a interpretação do criador. É por isso que as pessoas ainda pintam. Se você vê programação como arte, pode continuar programando. Mas muita gente tem como objetivo criar produtos, e o próprio produto é a arte. Se a IA permite chegar mais rápido a esse objetivo, então naturalmente a melhor escolha pode ser usar IA. Ao mesmo tempo, sinto certa saudade da época de “code monkey” (fazer programação pura). Parece que estamos indo para um cenário em que todo mundo vira tech lead, cuidando apenas de direção, code review e decisões técnicas. É um pouco triste mexer menos diretamente no código no trabalho.
Uma analogia mais adequada seria a transição de ferramentas manuais (
hand-tool) para ferramentas elétricas (power tool). A comparação pintura-fotografia parece exagerada demais, porque ali se trata do surgimento de uma nova mídia. Programação com agentes não é uma revolução nesse grau.Tentei usar bastante o Claude Code, mas ele é lento demais e está sempre meio fora do lugar, o que me deixa frustrado. Na maioria das tarefas, não sinto que ele economize energia mental. Em alguns casos ajudou, mas tantas vezes o resultado me decepcionou que eu não tenho vontade de usar com frequência. Por exemplo, pedi para converter meu
.zshrcpara nushell, e mesmo após 30 minutos de luta não funcionou; olhar a documentação oficial com as próprias mãos teria levado menos de 10 minutos. Esse tipo de experiência frustrante me deixa com muita resistência em voltar a usar o Claude.Minha experiência também foi parecida com essa. Tentei usar para ajudar a escrever testes, mas no fim quase sempre tive de reescrever tudo do zero. Com debugging, nunca obtive nenhum resultado útil. Só achei realmente aproveitável para conversões de scripts muito simples (como parsing de saída de comandos) ou scaffold de projetos novos (mas com que frequência fazemos isso?). Para portabilidade simples de código até serviu, mas tive muito mais fracassos do que sucessos.
Queria saber se você já testou algo como o context7 MCP. LLMs tendem a ser fracos em linguagens menos populares ou domínios incomuns. Tenho a impressão de que abordagens como a do context7, que buscam referências diretamente de fontes atualizadas, funcionam melhor.
Por causa de RSI e síndrome do túnel do carpo, eu vinha programando cada vez menos, mas graças ao Claude consegui voltar a programar (com a dor reduzida para um décimo). Era uma tecnologia que eu preferia rejeitar, mas agora ela se tornou indispensável para eu continuar minha carreira.
Tenho ouvido muitas histórias parecidas. Para pessoas com RSI, ferramentas como Claude são um verdadeiro divisor de águas, porque tornam muito mais leves os trabalhos repetitivos e entediantes, como boilerplate. Antes, só de ver código repetitivo, meu punho e meu psicológico já doíam; agora isso praticamente desapareceu, e eu consigo focar mais em problemas abstratos e novos, o que tornou programar mais prazeroso. Existe a preocupação de que “essas ferramentas possam encerrar carreiras”, mas eu acredito no contrário: que elas podem salvar a minha.
Desde que comecei a usar o Claude, minha dor de RSI praticamente desapareceu. Especialmente porque consigo substituir tarefas repetitivas por comandos e frases muito precisos. Também ouvi muitos casos de uso com reconhecimento de voz, e isso parece abrir uma porta importante para acessibilidade.
Acho que seria ainda mais útil se fosse possível usar o Claude Code diretamente por voz. No MacOS existem opções gratuitas de TTS/ASR, e com BYOK também dá para conectar outros motores de voz (https://github.com/robdmac/talkito).
Se você usar um app de STT/reconhecimento de voz suficientemente preciso e conveniente, também é eficaz para transmitir contexto detalhado ao Claude Code. Depois de testar vários apps desse tipo, o Wispr Flow foi o que mais me agradou, por reunir modo hands-free com atalhos de teclado, precisão e velocidade. Só gostaria que também houvesse suporte a apps locais.
Fiquei curioso se você faz a entrada de texto em si por voz.
Concordo muito com a opinião do autor do ponto de vista de manutenção. Antes eu apenas criava TODOs ou tickets para refatorações e lembretes, mas agora, graças ao Claude, vou implementando essas coisas na hora. Isso reduziu muito o esforço repetitivo. Também ficou muito mais fácil testar rapidamente ideias de refatoração e descartá-las se eu não gostar. A energia de ativação para esse tipo de trabalho caiu bastante. Concordo também que, se você sair rodando agentes de IA em paralelo/offline sem critério, isso pode acabar levando a burnout e piora da qualidade do código, então é preciso manter isso no modo de supervisão humana. Também escrevi algumas reflexões adicionais em https://www.modulecollective.com/posts/agent-assisted-coding...
Sinto exatamente o mesmo que o autor do post original, rsrs
Paguei US$ 200 e, em uma hora, resolvi um problema dificílimo de quatro anos.
Provavelmente eu sozinho... com o Cursor, jamais conseguiria resolver.
Alguém saberia me dizer qual é a diferença entre usar o Claude Code e usar o Cursor + Claude LLM?
Estou usando o Cursor, mas estou pensando em migrar para o Claude Code.
Quando você fala de Claude LLM, está se referindo à chave da API?
Ou está falando dos modelos Agent que ficam abaixo da janela de chat?
Eu também usava o Cursor com bastante satisfação, mas batia no limite de uso com frequência, então mesmo pagando o plano de $60 eu ficava apreensivo, com medo de atingir o limite de novo.
Por causa disso, eu alternava com o gemini cli e isso me gerava bastante estresse.
Cursor + Claude 4 Sonnet já era bom o suficiente, mas o maior problema era que, depois de um dia, eu atingia o limite, e quando isso acontecia não podia usar por um mês inteiro.
Cursor + Claude 4 Opus eu nem tinha coragem de experimentar.
No fim, como o Claude Code é baseado em cli e não depende das características da IDE, decidi testar.
No começo usei o plano de $20, mas ele também não tem Opus.
Então, quando eu estava prestes a bater no limite, resolvi pagar $200 com a mentalidade de "vou usar só por um mês para testar".
E aí um novo mundo se abriu. Opus... realmente é de outra categoria...
Agora estou no quarto dia usando o plano de $200, e estou resolvendo todos os problemas difíceis que eu vinha deixando para depois haha
Não dá para editar o texto.
Acho que não era um mês, e sim um dia. Acho que foi isso. Passei o mês inteiro apreensivo.
E também briguei bastante com o Cursor, mas
com o Claude Code não brigo tanto.
Nossa, muito obrigado pela resposta detalhada.
Eu também estou usando o Cursor no modo Auto porque bati no limite e não tive outra opção, mas acho que vou ter que migrar mesmo.