Claude Code para VSCode é lançado

• Extensão que integra o Claude Code ao VSCode para aprimorar a experiência de programação dos desenvolvedores
• Funciona apenas se o Claude Code estiver instalado separadamente

Principais recursos

• Instalação automática: ao executar o Claude Code no terminal do VSCode, a extensão é detectada e instalada automaticamente
• Reconhecimento de contexto da seleção: o texto selecionado no editor é incluído automaticamente no contexto de entrada do Claude
• Suporte à visualização de diff: é possível conferir as alterações de código (diff) diretamente no visualizador integrado do VSCode
• Atalhos de teclado: com atalhos como Alt+Cmd+K, é fácil enviar o código selecionado para o prompt do Claude
• Reconhecimento de abas: o Claude identifica as informações dos arquivos abertos no VSCode, permitindo suporte de código adequado ao contexto
• Opções de configuração: em /config, ao definir a ferramenta de diff como auto, fica mais fácil ativar os recursos relacionados à integração com a IDE

• Como se trata de uma versão inicial (early release), pode haver bugs durante o uso ou alguns recursos incompletos

[digitect38]

Diferença clara em relação ao Cursor

1. O Cursor está preso ao VSCode. Já o Claude Code, por ser no formato CLI (command line interface), pode ser usado com qualquer ferramenta.

2. O Cursor na prática utiliza outros LLMs, enquanto o Claude Code é especializado no Claude. Mas, comparando a capacidade, ele claramente leva vantagem. Isso também vale na comparação com o Gemini 2.5 Pro (com base em .NET; pode variar de acordo com a linguagem).

[bluekai17]

Então, qual é a diferença em relação ao Cursor?

[iolothebard]

Poxa, em vez de fazer para Windows mesmo (sem ser WSL), ficam toda hora inventando moda… --,.--;;;

[wahihi]

WSL também faz parte do Windows, mas pelo visto você não sabe usar... Desenvolve só pela GUI, então não conhece nada de CLI, ou nem isso...

[yeorinhieut]

Ao usar o WSL, também existe o problema de o desempenho do sistema de arquivos cair bastante (wsl2), além da desvantagem de a virtualização depender do Hyper-V. Também há muitos casos em que não é possível usar o WSL.

[namojo]

Também concordo. Na minha empresa também é proibido usar WSL, então acabei desistindo. Depois de dar um jeito de contornar o certificado SSL, vi que WSL não funciona mesmo.

[ng0301]

kkkkkk, concordo demais

[melong0124]

Qual seria a diferença em relação ao Git Copilot?

[digitect38]

O Copilot é especializado na IDE da Microsoft e, francamente, está mais para nível iniciante, enquanto o Claude funciona em CLI / Git Bash, então pode ser usado em vários ambientes e tende a ter um nível de programação relativamente mais alto

[kimjoin2]

Também existe plugin para o IntelliJ.
A diferença para um CLI simples é que ele reconhece imediatamente os arquivos e as linhas que você está vendo ou selecionando na IDE.
Claro, também dá para executar em um terminal comum e iniciar a integração com o comando /ide.

[GN⁺]

Comentários no Hacker News

• Acho que integrar coding baseado em agent a IDEs existentes é a direção errada. É melhor gerenciar vários Git worktrees e deixar cada agent rodando ao mesmo tempo. Não precisa ficar esperando mais de 20 minutos o Claude Code terminar uma tarefa. Por isso acabei criando minha própria UI para gerenciar isso, e ela está evoluindo aos poucos para um novo tipo de IDE voltado a gerenciar/revisar vários agents. Diferente do modelo tradicional, não é fazer uma tarefa de cada vez. https://github.com/stravu/crystal
  • Eu pessoalmente penso diferente. Uso o Cursor todos os dias em projetos comerciais. Agents em background são úteis em algumas situações, mas na maior parte do tempo só geram distração. O jeito de programar de que eu gosto é focar em um objetivo e ir iterando até chegar na solução. Enquanto espero uma tarefa terminar, vou explorando documentação ou informações relacionadas para pensar no próximo passo. Também é muito importante revisar o código existente ou as mudanças para entender com precisão o estado atual. A ideia de gerenciar vários agents para cada tarefa não combina com o meu estilo. Tem troca de contexto e multitarefa demais.
  • O que eu sempre me pergunto nessas propostas de workflow é como eu conseguiria gerenciar meu contexto pessoal. Mesmo em code reviews de colegas, em vez de entender e validar perfeitamente todo o código, eu normalmente só verifico rapidamente erros grandes, como estilo de código ou best practices. Assim consigo revisar muitos PRs por dia com rapidez. Para trabalhos mais importantes, quando sou o responsável, testo a branch e confiro a implementação com cuidado. Como repito isso a cada atualização do PR, acaba consumindo muito tempo. Se vários agents propõem diffs ao mesmo tempo, especialmente quando precisam de validação, fico pensando em como lidar com a troca de contexto e também como gerenciar dependências entre módulos quando uma atualização afeta sutilmente outro trabalho.
  • Dá para fazer exatamente esse mesmo modelo também como plugin de IDE.
  • Ferramenta muito legal! Fiquei curioso por que você não usou o Claude Code TS SDK. Parece que o pacote foi instalado, mas a estrutura acaba executando o comando claude diretamente. Aliás, recomendo dar uma olhada em electron-trpc também. O tratamento de IPC fica muito mais simples.
  • Essa ferramenta também é legal, mas resolve um problema diferente. Agents em background têm dois grandes problemas. 1) Existe uma barreira de entrada para configurar corretamente ambientes isolados. A dificuldade varia muito de projeto para projeto, indo desde escolher um contêiner simples até um inferno de configuração de todas as dependências. Já ao trabalhar dentro da IDE, normalmente tudo já está pronto. 2) As pessoas precisam aprender como o agent constrói o código. Se o agent roda na IDE e eu posso orientar ou corrigir em tempo real, isso ajuda muito mais no longo prazo do que um agent em background.
• O que eu queria é o seguinte: um ambiente com suporte forte a troca de contexto baseada em git worktree dentro da mesma janela da IDE; um framework para conectar agents baseados em terminal a cada branch/worktree; com o tempo, algo que evolua para um protocolo aberto melhor para diffs, notificações de pedido de permissão e notificações de progresso; uma barra lateral para monitorar o estado e os alertas dos agents por branch/worktree; e uma interface para responder rapidamente às mensagens dos agents em várias branches, como se fossem notificações. Ferramentas standalone de gerenciamento de agents têm esse tipo de recurso, mas quando quero mergulhar direto como engenheiro, não consigo realmente usá-las bem. Também seria preciso integração por branch com janelas de teste em navegador ou instâncias de emulador/simulador mobile. E ainda precisaria ter autocomplete de código com modelos rápidos, suporte a vários language servers e um ecossistema de extensões à altura de uma IDE de alta qualidade. Hoje estou gerenciando Windsurf, Claude agent, navegador e simulador mobile separados em vários desktops do macOS. É muito incômodo.
  • O que eu quero é um agent de programação com recursos de depuração. Quero seguir a stack, inspecionar variáveis locais e valores de argumentos e, em vez de usar print ou assert, realmente olhar por dentro e ver o que está acontecendo.
  • Sobre responder rapidamente às mensagens dos agents em várias branches como se fossem notificações, eu também tentei fazer um plugin para VSCode. Era uma função para o Claude pular direto para arquivo e linha, e até funcionou até certo ponto, mas havia um problema de travamento constante.
• Não entendo muito bem qual é a diferença real entre Cursor e Claude Code. Já usei os dois e, como a empresa dava suporte, acabei migrando só para o Cursor. Fora CLI versus UI, os dois fazem edição em múltiplos arquivos, então não encontrei uma diferença tão clara. Espero que esse período meio estranho de ter que usar vários editores ao mesmo tempo ou alternar entre JetBrains e Cursor acabe logo.
  • Em termos de qualidade e utilidade, os dois são bem diferentes. Claude Code é totalmente agentic. Você entrega uma tarefa e ele implementa tudo por conta própria, produzindo código muito bom e funcional. Ele consegue testar, fazer commit, executar comandos, acessar sistemas remotos, depurar etc. Não tenta otimizar uso de tokens, então costuma gerar código de melhor qualidade logo na primeira tentativa do que o Cursor, mas por isso também custa mais. O modo agent do Cursor ainda está num estágio inicial. O Cursor é mais uma ferramenta de edição de arquivos; o Claude Code é mais como um desenvolvedor júnior.
  • Muita gente usa os dois juntos. Cursor como IDE, Claude Code rodando no terminal da própria IDE. Em termos de performance, a abordagem de agent é diferente e, mesmo usando o mesmo modelo-base, existem diferenças na análise da codebase, uso de submodelos, integração com ferramentas etc.
  • Acho curioso você não sentir muita diferença. Para mim, o Claude é muito superior em tudo. Uso principalmente scala, python, js e dart. Com o Claude, ganhei um assistente absurdamente produtivo. Ele é especialmente útil para mudanças pequenas e médias. Se você planeja bem e usa direito, parece magia. Tem um pouco de duplicação de código, mas só isso. O Cursor exigia tanto ajuste manual que no fim só me deixava mais lento.
  • O Claude Code é realmente impressionante. Parece que tem outro programador sentado comigo no terminal. Não é perfeito, e você precisa ajudar até ele entender direito o que você quer. Mas, quando o contexto está bem alinhado, é realmente surpreendente. No meu caso, nem cheguei a fazer ele entender o projeto inteiro, e nem uso com TypeScript ou desenvolvimento web.
  • O Cursor exige mudar para uma IDE separada, a não ser que você já use VSCode por padrão, enquanto o Claude Code (ou Aider) modifica os arquivos do projeto direto pelo terminal, em paralelo com a sua IDE atual. No meu caso uso a combinação vim+tmux+bash, então prefiro assistentes em CLI, mas essa vantagem também vale para quem usa outra IDE gráfica que não seja VSCode.
• Quando o github introduziu na semana passada o limite de solicitações premium do copilot, fiquei até chocado por não ter havido uma reação maior. Imagino que a reação venha de verdade quando mais gente começar a bater no limite. Ainda bem que existem concorrentes.
  • No Claude Code, dá para torrar 10 dólares em uma única execução num piscar de olhos.
• Queria saber se existe alguma vantagem especial em relação a usar o VSCode Copilot no modo Agent com Claude Sonnet 3.7 ou 4. Queria entender se estou deixando passar alguma coisa.
  • Você precisa experimentar o Claude Code de verdade para responder essa pergunta. Ficar debatendo isso aqui não adianta muito. Se você usa terminal Linux como ambiente principal, vai se apaixonar na hora. E leia a documentação também. Use CLAUDE.md, transforme tarefas grandes em documentos de planejamento em markup e vá iterando entre planejamento, revisão e implementação. Quando estiver perto do limite de contexto, escrever a memória em arquivo, dar /clear e ler de volta depois torna tudo muito mais eficiente.
  • Tentei integrar Playwright MCP com o modo agent do Copilot, mas não consegui. Ele instala e até aparece na seleção de ferramentas, mas no fim o Copilot não permite acesso ao recurso.
• Queria entender qual é o ganho dessa solução em relação a usar o backend Claude no modo agent do Copilot
  • Outras explicações neste tópico (especialmente https://news.ycombinator.com/item?id=44353972) também se aplicam ao vscode copilot
  • Depois de usar por alguns dias, achei que essa integração melhorou o incômodo de ter que abrir os arquivos manualmente para ver as atualizações. No modo terminal, tudo acontecia em background e eu não sabia o que estava rolando, mas numa IDE integrada dá para ver tudo em tempo real. Dito isso, os nomes que o agent coloca, tipo Pondering, Twerking, Juggling e outros, parecem novidade no começo, mas logo deixam de servir para muita coisa.
• Pergunta meio fora do assunto, mas queria saber se alguém usa Roo no VSCode. E também se o recurso de navegador do Roo se integra bem com o Claude oferecido pelo GitHub copilot
• Pelo que eu sei, se você rodar o Claude Code no VSCode (ou Cursor), isso é instalado automaticamente. Então não precisa procurar e instalar manualmente, certo?
  • O fato de o Claude Code instalar automaticamente no VSCode quando é executado... isso não parece um pouco invasivo?
  • Sim. Está explicitado na página da extensão.

  Auto-installation: When you launch Claude Code from within VSCode’s terminal, it automatically detects and installs the extension
  

• Comecei a perceber que o Claude Code entende várias etapas de uma vez, e isso começou a mudar meu workflow. Em vez de pensar arquivo por arquivo, fui migrando para unidades de ação únicas como “separar módulos, escrever testes, refatorar os pontos de chamada”. E o Claude também entende isso como uma unidade só (modo de esforço máximo). Essa mudança vai alterando aos poucos a forma de programar. Você se preocupa menos com sintaxe, escreve mais scaffolding e passa a agrupar várias tarefas. É sutil, mas o impacto de longo prazo é grande. Fico pensando em quanto tempo vai demorar até começarmos a melhorar deliberadamente a estrutura das codebases para que agentes LLM consigam navegar melhor nelas, com organização mais plana, menos indireções, metadados declarativos etc.
  • Antes mesmo de chamar isso de futuro, já está acontecendo. Armin Ronacher aumentou a proporção de código que escreve em Go em vez de Python justamente porque LLMs entendem melhor Go. Um colega meu também migrou um app desktop para Rust porque, graças ao tooling e ao sistema de tipos, fica mais fácil para agents navegarem. O foco já está se deslocando para documentar de uma forma mais legível para IA.
  • Tenho pensado bastante nisso ao ouvir que LLMs funcionam claramente melhor em linguagens como Go, com tipagem estática explícita, sintaxe concisa e estilo de escrita consistente. Dependendo do quanto não precisamos nos preocupar com complexidade desnecessária derivada das ferramentas — linguagem, framework, biblioteca etc. — conseguimos usar melhor nossos recursos mentais para resolver os problemas que realmente importam.
• Estou animado que o Claude Code também vai chegar ao Jetbrains! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • Não entendo por que esse comentário recebeu tantos downvotes. Eu também estou animado. Valeu por compartilhar.

[namojo]

Ao usar o Claude Code, acho que algo parecido com o conceito de MSA faz sentido: dividir o máximo possível em unidades no nível de microserviços e deixar cada uma responsável por uma única unidade parece ser o mais eficiente.