- Usando Cursor e Claude Code em paralelo, acumulei experiências em várias frentes, como desenvolvimento real em codebases grandes e consultoria de avaliação de LLM
- O Cursor ganhou destaque entre power users graças à UI/UX conveniente e ao acesso ilimitado à API, mas a introdução recente de rate limits severos restringiu drasticamente a experiência de uso
- No Claude Code, o Sonnet 4 mostrou alta confiabilidade e eficiência em compreensão e edição de código, além de lidar bem com contextos amplos; combinado com o Opus 4, também consegue resolver bugs de alta complexidade
- Há vários recursos avançados voltados para power users, como o ambiente CLI baseado em comandos e o uso de subagentes, e a experiência mostra que experimentar e explorar recursos de forma contínua é importante
- Entre os pontos fracos estão a falta de uma UI visual, a lentidão no copiar/colar, limitações para usar outros modelos e pedidos de melhorias adicionais, como checkpoints
De Cursor para Claude Code: o contexto da mudança
- Até recentemente, o Cursor era muito querido pelos desenvolvedores por causa do uso ilimitado da API e do fluxo intuitivo de revisão de diff
- Por isso, eu o usava principalmente para gerar código em Gumroad bounties e em trabalhos de consultoria ligados a engenharia de IA e avaliação de LLM, além de acelerar o entendimento de codebases
- Mas, a partir de meados de junho, foram introduzidos de repente rate limits agressivos, reduzindo fortemente a eficiência do trabalho e diminuindo bastante as vantagens do Cursor
- Entre vários modelos como Sonnet 4, Opus 4, GPT-4.1 e Gemini Pro 2.5, na prática os mais usados foram Sonnet 4 e Opus 4
- Por limitações como custo da API e perda de velocidade, passei a considerar até a assinatura Claude Code Max (US$ 200 por mês) e tentei uma migração mais séria
Impressões do uso real do Claude Code
- Coloquei o Claude Code para trabalhar em codebases open source de médio e grande porte em Python, Ruby e TypeScript (50M+ tokens) e experimentei loops de feedback com especificações e testes
- No começo, eu usava só entrada simples de comandos, mas fui aprendendo os comandos básicos e o modo plan, explorando formas mais profundas de uso
- Entrada simples de comandos → aprender comandos/modo de planejamento → alcançar automação e ganhos de produtividade com combinações claras de comandos
- Usei uma estratégia mista em que trato a resolução de problemas quase como uma conversa de consultoria: despejo todo o contexto no Claude, mudo para o Opus quando necessário para montar um plano (Plan mode) e deixo o Sonnet 4 executar o trabalho principal
- Também mando o Claude registrar e organizar informações em arquivos dentro da pasta
.claude, o que ajuda na gestão de contexto e a reduzir o incômodo de copiar/colar; recomendo usar em conjunto o Plan mode e o Auto-edit mode
- Gestão de contexto: em vez de usar compaction, prefiro iniciar chats novos periodicamente e orientar o modelo a anotar mudanças importantes em arquivos separados
Gestão de contexto e uso de subagentes
- O Claude Code oferece compressão de contexto, mas como isso pode ser lento e pouco eficiente, prefiro criar arquivos com os pontos principais e iniciar um novo chat
- Faço com que ele registre mudanças, notas e histórico em arquivos auxiliares como um Scratchpad, para reutilizar depois em trabalhos em branch ou na recuperação de sessão com
/resume
- Subagentes: permitem processar em paralelo várias tarefas dentro da codebase, como busca e análise, distribuindo o trabalho em uma estrutura multithread
- Internamente, isso gera uma configuração multiagente baseada em lista de ToDo, o que ajuda na gestão do contexto
Busca e uso de comandos
- No Cursor, é possível usar várias ferramentas como busca normal/semântica e agentic search, além de a busca ser rápida
- Já a busca no Claude Code pode ser lenta. Com subagentes, porém, dá para paralelizar o trabalho em codebases grandes
- Combinando sub-agents, a task tool e comandos como
/think e /ultrathink, dá para explorar grandes repositórios e dividir o trabalho
- É importante usar o atalho
Shift + ? para ver a lista de comandos e conferir rapidamente novos recursos
- Comandos de terminal (bash) podem ser executados com
!, inclusive em modo headless
- Há ainda vários recursos avançados embutidos, como tags de arquivo (
@arquivo), função de memorizar (system prompt personalizado por usuário) e uso de CLAUDE.md
Sonnet 4 vs Opus 4: comparação e dicas de workflow
- Sonnet 4: é mais rápido na maioria das situações e se destaca em contexto longo + trabalho com agentes. Tem vantagem em Python e tarefas de frontend
- Opus 4: tende a ficar confuso quando várias instruções se acumulam; nesse caso, vale registrar tudo em arquivo e começar um novo chat. É útil para destravar bugs difíceis quando o Sonnet 4 emperra
- Para problemas complexos, recomenda-se começar com o Opus e usar o Sonnet para codificação geral, em uma operação híbrida
Comandos personalizados e outras dicas
- Há suporte a comandos customizados como
/pr-comments e /review, com necessidade do Github CLI
- Ao trocar de branch, é possível reiniciar a conversa e montar workflows flexíveis, como revisão de diff em relação à main
- Pressionar
Esc duas vezes permite fazer fork da conversa de qualquer ponto
- Com
/permissions, é possível ajustar permissões antes da sessão
- Se tiver coragem, experimente usar o claude com
--dangerously-skip-permissions
- Recomendação de vídeo com dicas profissionais de Claude Code
O que quero testar daqui para frente
- Quero experimentar formas de definir e usar comandos personalizados diretamente
- Quero tentar automação de frontend usando servidores MCP, como um Playwright server
- O plano é focar em construir um loop de feedback em que o Claude tira screenshots, interpreta os resultados e melhora a UI iterativamente
- Também pretendo praticar todos os usos avançados sugeridos em how-i-bring-the-best-out-of-claude-code-part-2
- Pretendo me desafiar em otimização de prompts
- Quero definir com clareza critérios de avaliação (
rubric.md) e projetar um loop de avaliação/melhoria de prompts junto com arquivos com contexto (como pmd)
- O plano é evoluir isso para uma estrutura em que múltiplas instâncias do Claude sejam usadas: uma gera resultados com prompts, outra avalia, dá feedback e melhora o processo (sistema de agente único ou multiagente)
- Essa abordagem foi inspirada em um post do Nirant
- Também quero construir um sistema multiagente em que várias instâncias do Claude Code se comuniquem entre si por meio de logs de ações
Conclusão e pedidos de melhoria
- O Cursor é muito forte em UI/UX, mas o Claude Code estimula produtividade e espírito experimental em um ambiente amigável para CLI e power users
- É uma ferramenta em que aprendizado exploratório e experimentação trazem grandes recompensas, altamente recomendada para nerds/power users
Recursos que eu gostaria que melhorassem
- Integração de UI (Claudia como referência)
- Suporte a checkpoints como no Cursor. O Git existe, mas a forma do Cursor é conveniente demais
- Melhorar a qualidade de copiar/colar
- Suporte ao uso de vários modelos
1 comentários
Opiniões do Hacker News
Sempre que vejo gente elogiando Claude Code até o céu, não consigo deixar de sentir que ou são todos influenciadores, ou só fãs obcecados por ferramentas tradicionais como terminal, Emacs e Vim. Toda vez que leio comentários dizendo que Claude Code é muito melhor que Cursor, eu vou lá, assino e tento aplicar num codebase grande de TypeScript, mas o processo demora muito e a curva de aprendizado é alta. No fim, o resultado é igual ao Claude embutido no Cursor, só que mais lento e mais obscuro, então revisar o código fica mais difícil. Neste ponto, parece só que os fãs dos comentários ou estão sendo patrocinados, ou já pagaram 200 dólares e agora querem justificar a própria escolha. Sinceramente, o Cursor foi muito mais produtivo. Sou programador há 18 anos e escrevo bastante código todos os dias, alternando entre Gemini 2.5 Pro e Claude 4.0, e mesmo assim tenho tirado muito mais proveito do Cursor. Até agora ninguém conseguiu me convencer. Não vejo vantagem prática. Posso mudar de ideia depois, mas no momento não sinto absolutamente nada disso
Acho que a maioria das pessoas entende profundamente mal qual é a parte realmente difícil do desenvolvimento de software. Na prática, a maior parte do trabalho não é criar algoritmos complexos, mas pegar ideias existentes e encaixá-las bem. Só que tudo isso vem depois de especificação, design, arquitetura e outros trabalhos prévios. Criar programas assim num passe de mágica com IA parece legal e nas demos passa a sensação de que terminou rápido, mas o problema real é fazer um sistema direito, com padrão de qualidade, para ser usado por 30 anos. Para protótipos ou objetivos pontuais é excelente, mas para durabilidade de longo prazo tem limites claros
Para maximizar a produtividade com essas ferramentas, o essencial é ter ciclos de feedback muito curtos e rápidos. O modelo de autocomplete por tab do Cursor percebe intuitivamente o que o editor está tentando fazer, quase como se estivesse pisando num redutor de velocidade de forma brilhantemente inteligente. Eu não preciso quebrar a cabeça fazendo macroprogramação; se não quiser, é só cancelar com Esc, e se quiser posso ir migrando aos poucos para um modo mais agentic. Editores totalmente baseados em agentes levam 15 a 30 minutos e ainda quebram completamente o fluxo de trabalho. Revisar os resultados vira um trabalho por si só, exigindo muito mais atenção do que ciclos curtos de aceitar ou rejeitar. Também pesa a questão de conceder acesso à rede ou rodar offline, então só vale experimentar quando quero gerar código rápido e sem grande preocupação com manutenção, segurança ou confiabilidade. Fora isso, na verdade a produtividade cai. Vai melhorar no futuro, mas hoje ainda consigo resultados melhores no Cursor
Eu também me sentia assim antes, mas recentemente usei Claude Code de verdade e achei muito melhor que Cursor. Não sei explicar exatamente por quê, mas parece que o Claude entende melhor a estrutura geral e evita alterações desnecessárias. Claro que às vezes ainda preciso apontar a direção, mas a eficiência é bem maior. Uma característica é que normalmente ele mostra só um arquivo por vez, então fica muito mais fácil revisar. O Cursor abre vários arquivos ao mesmo tempo e o volume de mudanças é grande, então é difícil entender rápido. Para referência, eu uso a extensão do Claude Code na janela do terminal do VSCode. O Claude abre as abas dos arquivos que vai alterar e propõe as mudanças
O que as pessoas ainda não perceberam é que o Cursor não é um produto fechado e completo, mas um pacote de recursos que todas as outras ferramentas estão correndo para copiar. A lição real é que existe uma estratégia além de interfaces profundas: combinar soluções best-in-class de agentes com o editor que cada pessoa preferir. Essas experiências vão acabar se consolidando em “boas práticas”, e as pessoas vão aplicar isso naturalmente nos seus editores ou IDEs, enquanto esses forks de vscode vão desaparecer
Usei por menos de um mês no plano de 17 dólares e fiquei meio fascinado, meio frustrado. Escrevi 8 mil linhas em Rust e 12 mil em Markdown, separando a especificação de trabalho e as tarefas concretas para interagir com a IA quase como um test harness. Não sei se a mágica vem de subsídio de VC ou outra coisa, mas o Rust chegou a parecer uma linguagem de script. (Referência: o repositório GitHub é
knowseams)A melhor coisa da IA para mim é que, quando estou com preguiça, posso só dizer “faz isso aqui”. Não importa se o resultado fica bom ou ruim. Pelo menos ela cria um ponto de partida
Graças aos LLMs, acabou o medo da página em branco. Não preciso mais reconstituir mentalmente um contexto complexo; posso só perguntar “o que a gente estava fazendo mesmo?” ou “o que era esse código?”, e a IA explica rapidinho, então consigo voltar ao foco na hora. Também acelera muito rubber duck debugging e tarefas repetitivas e pequenas (
yak shaving), então é realmente útil. Eu ainda integro com Slack, Notion, Linear etc., então para mim virou uma ferramenta de gestão de tarefas e projetosMesmo quando quero fazer eu mesmo, peço para a IA montar um plano e deixo isso registrado em Markdown. Hoje mesmo pedi um plano de refactor, mas ela abordou errado um bloco de código protótipo em 40 arquivos, tentando reestruturar de baixo para cima. Se eu tivesse seguido por esse caminho por engano, provavelmente perderia muito tempo depurando. Ainda assim, ela me deu um ponto de ataque, e corrigi o plano e apliquei em uma hora. Se eu estivesse sozinho, talvez nem tivesse começado por causa da complexidade, ou teria desistido depois de ficar só repetindo documentação
No fim do dia, quando já não consigo mais me concentrar e o tanto que escrevo é parecido com o tanto que reverto, posso passar o volante para a IA e respirar um pouco. Em issues pequenas basta dar uma olhada rápida no diff; nas difíceis, se eu entender exatamente qual é o problema, consigo orientar e convencer a IA do caminho. Quando o trabalho chega a uns 40~60%, normalmente eu mesmo assumo e finalizo. No dia a dia, eu me concentro em pensar e desenvolver diretamente nos meus horários mais afiados, e deixo hora extra ou tarefas repetitivas para a IA, usando o tempo livre para me preparar para o dia seguinte ou fazer escrita e design de nível mais alto
Eu simplesmente vou caminhar e tomar café. Problemas humanos parecem mais naturais de resolver de forma humana
Claude Code é difícil de explicar. Depois que comecei a usar, tive até a sensação de que mudei de profissão. Eu já tinha colocado o Claude no centro do meu fluxo de trabalho, mas o Claude Code é literalmente Claude “turbinado”. Se você ainda não usou, recomendo sem hesitar. Foi a primeira vez que senti que estava realmente trabalhando com um engenheiro júnior
Minha experiência é o exato oposto. Eu mando fazer alguma coisa, ele leva alguns minutos e entrega algo, mas na prática o app quebra, e quando vou depurar vejo que ele trabalhou totalmente fora do alvo, então acabo jogando tudo fora. Mesmo assim continuo insistindo no Claude porque, como acontece com outras pessoas, quando funciona é bom demais. A realidade, porém, é que ele gera boilerplate, exige bastante depuração manual e, no pior caso, você perde uma hora e um monte de tokens
Usei hoje pela primeira vez no trabalho e foi uma mudança muito mais revolucionária do que o Cursor. Mesmo usando o mesmo foundation model, a experiência é completamente diferente. Um mês atrás a IA só deixava meu trabalho mais lento, mas hoje com Claude Code resolvi tudo em 20 minutos, e o custo da API nem chegou a 10 dólares. Precisei me preocupar muito pouco com gestão de contexto, e o Claude Code encontra sozinho o contexto necessário e consegue trabalhar de forma produtiva por muito mais tempo. O modo agent do Cursor só me parece útil para tarefas de 3 a 5 minutos, mas o Claude Code continua avançando sem se perder mesmo em tarefas de mais de 10 minutos. O uso de ferramentas também é excelente, e me impressiona como ele raramente entra em loop
Você disse que “parece trabalhar com um engenheiro júnior”, mas para mim às vezes é o contrário: eu sinto que sou o subordinado e o Claude é meu chefe. Eu apareço orgulhoso dizendo “olha essa coisa incrível que eu fiz!”, e a resposta é algo como “mas isso não foi o que eu pedi...”
Você pode explicar com mais detalhes em que tipos de tarefas, linguagens e domínios usou isso? Estou curioso porque os casos parecem muito diferentes entre si
Tive a mesma experiência. O Claude vai muito além de um simples júnior. Ele é bom demais em sugerir opções, recomendar decisões e visualizar trade-offs
Não existem muitos walkthroughs reais mostrando gente criando apps ou bibliotecas com Claude Code? Eu queria ver desenvolvimento de verdade com essa ferramenta, não só textos dizendo que “é incrível”. Seria ótimo se houvesse uma coletânea desses casos
No geral, tudo isso parece um pouco estranho. O Claude Code em si claramente é bom, e dá para usar para achar documentação ou Stack Overflow muito mais rápido. Mas se os rumores exagerados forem verdade, então não deveríamos estar vendo uma inovação absurda de software acontecendo numa velocidade enorme com essas ferramentas? O CEO da Stripe disse que as ferramentas de IA aumentam a produtividade em 100 vezes; se já se passaram 3 ou 4 meses, a Stripe não deveria estar lançando foguete agora? A Microsoft também entrou de cabeça em IA para programação, então por que o Teams continua parecendo ruim? Já faz mais de um ano que dizem que essas ferramentas são revolucionárias, mas na prática o mundo real ainda parece bem parecido com o de 3 ou 4 anos atrás
Duas tendências recentes me chamam atenção: (1) gente sem muita experiência usando IA em projetinhos triviais; (2) desenvolvedores especificando antecipadamente toda a arquitetura do app, arquivos, interfaces, stack tecnológica e framework de testes com um nível absurdo de detalhe, e então conduzindo o LLM minuciosamente para arrancar resultados aceitáveis exemplo no YouTube. Uns 80~99% do que se ouve em PR/YouTube, na prática, vem do primeiro grupo. A sensação de ganho de produtividade existe porque conversar com o LLM, documentar, conduzir e corrigir cansa menos do que desenvolver diretamente. Mesmo que o tempo ou o esforço total sejam iguais, a percepção melhora porque a expectativa diminui
Estou procurando streams ou casos reais no YouTube em que haja um boost de produtividade de verdade, mas ainda não vi nada que me faça pensar “uau, isso sim está rápido!”
Existem opiniões muito polarizadas, mas a maior parte das pessoas está em silêncio só fazendo commit no próprio canto (o que por si só já é irônico). No meu caso, dependendo da tarefa, sinto de forma bem real algo entre 1,5x e 10x de velocidade. O maior benefício é que, em tarefas puramente criativas, pontuais, de boilerplate ou refactor, a carga cognitiva cai bastante, então consigo manter um desempenho mais consistente. Ainda faço muito “codar na mão”, e reviso quase todas as linhas até o fim. Deixar rodando sozinho por horas é um pesadelo. Na prática, até em apps de produção mantidos há mais de 10 anos eu não tenho tempo de ir fazer propaganda em blog nenhum. Por outro lado, eu trabalho numa organização bem enxuta, então tenho o contexto do sistema inteiro nas mãos e consigo identificar problemas mais rápido. Em ambientes onde a eficiência pessoal é crucial, isso realmente amplia a base. Em organizações grandes é bem mais difícil ter essa experiência
Na minha experiência, ajuda muito manter um arquivo Markdown chamado Claude.md na raiz de cada pasta de código, adicionando um conjunto mínimo de regras como se fosse um pipeline. Assim, a geração e o posicionamento de testes seguem exatamente as pastas e o formato definidos, e eu evito a criação de arquivos de debug. Também imponho regras para impedir uma explosão de novas classes ou estruturas e para priorizar reutilização, exceto quando for realmente necessário criar algo novo. Também não escrevo prompts longos; normalmente só documento em forma de plano os pontos incertos. Mesmo em issues recentes que fogem do escopo de conhecimento do LLM, eu passo o mínimo possível de input extra. Desse jeito, consigo resultados consistentes de 1 input–1 output, inclusive com profundidade total aplicada. Recentemente até migrei do Claude Code para usar outros modelos grandes, como Opus, no modo CLI por um custo menor. A CLI é o verdadeiro poder. Estou rodando 60 a 70 agent streams ao mesmo tempo e gerenciando sem problema um codebase de 200 milhões de tokens (react/typescript/golang). Só precisei dar instrução extra uma ou duas vezes
Você consegue listar o que está operando com esses agent streams? Fiquei muito curioso
Também queria saber quais modelos você usa além dos da Anthropic. Testei o Kimi K2, mas não funcionou bem no meu caso
Fiquei curioso com o que exatamente você quer dizer com “agent streams”. Não consigo nem imaginar a carga cognitiva de gerenciar 60 ou 70 desses
Às vezes, em tarefas específicas, minha produtividade sobe drasticamente com Claude Code. Recomendo usar slash commands e transformar conversas anteriores em slash commands. Assim você vai acumulando aos poucos um conjunto de comandos primitivos cada vez mais reutilizáveis. No meu caso, deixei exemplos no GitHub make-command.md, improve-command.md
PSA: com este repositório, dá para conectar Claude Code a praticamente qualquer modelo. Dizem que o Kimi-K2 mais recente funciona muito bem
Também testei o Kimi-K2, e ele fica abaixo de Sonnet/Opus 4.0, mas no tool calling é melhor que Gemini 2.5 Pro. Se Claude Max (100~200 dólares por mês) pesa no bolso, eu recomendo bastante. Também gosto porque o modelo em si é muito enxuto, sem enfeites. A Anthropic talvez até devesse abrir o código do Claude Code; ele poderia virar o VSCode dos coding agents em CLI. E também recomendo opencode, que tem suporte nativo a todos os modelos e oferece recursos parecidos com Claude Code
Se for para usar vários modelos, eu simplesmente recomendo o sst/opencode (eu mesmo uso com Claude Pro)
Só para constar, para quem ainda não conseguiu usar CC: dá para baixar o cliente CC via npm e usar de graça
Eu estava brincando de “vibe coding” com Claude Code, local LLM, Continue e VSCode para fazer um app simples em Python, e aí descobri o plano gratuito do Claude e joguei lá o código em andamento junto com os resultados do LLM. Fiquei animado porque ele organizou e corrigiu erros e updates de uma vez, com bastante precisão. Então passei para a próxima etapa: montei no ChatGPT as especificações e prompts de um projeto de jogo 2d em pygame (estilo Manic Miner) e entreguei tudo ao Claude. A partir daí, o Claude começou a referenciar métodos que não existem ou a falar bobagem sobre diferenças de versão do codebase. Mesmo apontando com precisão os números de linha e o código ao redor, ele continuou me enrolando. Como eu poderia resolver isso? Não espero perfeição, mas parece que bati no mesmo limite dos local LLMs. Minha saúde não anda boa e faço isso de forma intermitente, então qualquer conselho ajudaria
É bem provável que você tenha caído num “inferno de código cheio de interfaces ambíguas e suposições escondidas”. Nesses casos, costuma funcionar melhor resumir todo o resultado anterior do ChatGPT, listar em profundidade o que o jogo atual faz e todas as funcionalidades, e então entregar esse documento ao Claude para ele quebrar os requisitos novamente do zero. O Claude consegue produzir amostras excelentes até em zero-shot e, no pior caso, dá para ir refinando iterativamente. Se ainda assim ele continuar inventando funcionalidades absurdas, eu recomendaria instalar o servidor MCP do context7 e pedir explicitamente para o Claude usar o context7
Isso é uma limitação fundamental da tecnologia dos LLMs. Eles geram probabilisticamente a sequência de tokens “mais plausível”, mas, quando “plausível” e “correto” não coincidem, não há muito o que fazer. E o critério de “plausibilidade” muda de modelo para modelo conforme o treinamento e o fine-tuning
Depois da configuração básica, queria saber que métodos adicionais vocês consideram para fazer essa ferramenta funcionar bem na prática. Em outras palavras: quais são as técnicas reais para estruturar contexto e codebase de modo que a ferramenta consiga se orientar sozinha com precisão? Deixei minhas ideias organizadas neste texto. Acho que metodologias melhores ainda vão surgir
Tenho obtido vários alphas com Claude Code, mas fico pensando em como escalar isso para o time inteiro. Queria saber se existe alguma forma boa de compartilhar dicas práticas e boas práticas para que colegas ou pessoas que eu gerencio consigam usar Claude Code com mais eficácia