Lanzamiento de Claude Code para VSCode

• Extensión que integra Claude Code de Anthropic con VSCode para mejorar la experiencia de programación de los desarrolladores
• Solo funciona si Claude Code está instalado por separado

Funciones principales

• Instalación automática: al ejecutar Claude Code en la terminal de VSCode, la extensión se detecta e instala automáticamente
• Reconocimiento de contexto de la selección: el texto seleccionado en el editor se incluye automáticamente en el contexto de entrada de Claude
• Compatibilidad con vista Diff: los cambios de código (diff) pueden revisarse directamente en el visor integrado de VSCode
• Atajos de teclado: con combinaciones como Alt+Cmd+K, puedes enviar fácilmente el código seleccionado al prompt de Claude
• Reconocimiento de pestañas: Claude identifica la información de los archivos abiertos en VSCode, lo que permite asistencia de código según el contexto
• Opciones de configuración: si en /config defines la herramienta diff como auto, puedes activar fácilmente las funciones relacionadas con la integración con el IDE

• Es una versión de lanzamiento inicial (early release), por lo que pueden presentarse errores durante el uso o algunas funciones incompletas

[digitect38]

Una diferencia clara con Cursor

1. Cursor está atado a VSCode. En cambio, Claude Code usa un enfoque de CLI (command line interface), así que se puede usar con cualquier herramienta.

2. Cursor en la práctica aprovecha otros LLM, mientras que Claude Code está especializado en Claude. Aun así, al comparar el rendimiento, claramente lleva ventaja. Esto también es así frente a Gemini 2.5 Pro (tomando .NET como referencia; puede variar según el lenguaje).

[bluekai17]

Entonces, ¿en qué se diferencia de Cursor?

[iolothebard]

No, en vez de hacerlo para Windows (no WSL), siguen distrayéndose con otras cosas… —,.—;;;

[wahihi]

WSL también es parte del sistema operativo Windows, pero parece que no saben usarlo... Como desarrollan solo con GUI, o de plano no conocen nada de CLI...

[yeorinhieut]

Con WSL, también está el problema de que el rendimiento del sistema de archivos baja muchísimo (wsl2), y además tiene la desventaja de depender de Hyper-V para la virtualización. También hay muchos casos en los que no se puede usar WSL.

[namojo]

Yo también coincido. En mi empresa también está prohibido usar WSL, así que~ al final lo dejé. Logré arreglármelas de algún modo saltándome el certificado SSL, pero resulta que WSL no funciona.

[ng0301]

jajaja, totalmente de acuerdo

[melong0124]

¿En qué se diferenciará de Git Copilot?

[digitect38]

Mientras que Copilot está especializado en los IDE de Microsoft y, francamente, está a un nivel bastante básico, Claude funciona en CLI / Git Bash, por lo que puede usarse en varios entornos y su capacidad de programación es relativamente más alta.

[kimjoin2]

También hay un plugin para IntelliJ.
La diferencia con un CLI simple es que reconoce de inmediato los archivos o líneas que estás viendo o seleccionando en el IDE.
Por supuesto, también puedes ejecutarlo en una terminal normal e iniciar la integración con el comando /ide.

[GN⁺]

Comentarios en Hacker News

• Creo que integrar programación basada en agentes dentro de un IDE existente va en la dirección equivocada. Es mejor una forma de gestionar varios Git worktree y que cada agente funcione al mismo tiempo. No hace falta esperar más de 20 minutos a que Claude Code termine una tarea. Por eso hice yo mismo una UI para gestionarlo, y poco a poco está evolucionando hacia un nuevo tipo de IDE para gestionar/revisar varios agentes. A diferencia de antes, no se trabaja una sola cosa a la vez. https://github.com/stravu/crystal
  • Yo personalmente pienso distinto. Uso Cursor todos los días en proyectos comerciales. Los agentes en segundo plano son útiles en ciertas situaciones, pero la mayor parte del tiempo solo generan distracción. La forma de programar que prefiero es concentrarme en un solo objetivo e ir acercándome iterativamente a la solución. Mientras espero a que termine una tarea, reviso documentación o información relacionada para pensar en el siguiente paso. También es muy importante revisar el código existente o los cambios para entender con precisión el estado actual. La idea de gestionar varios agentes para cada tarea no va con mi estilo. Hay demasiado cambio de contexto y multitarea.
  • Lo que siempre me pregunto con este tipo de propuesta de flujo de trabajo es cómo se puede gestionar mi contexto personal. Incluso en revisiones de código de compañeros, en vez de entender y validar perfectamente todo el código, normalmente solo verifico rápido errores grandes, como estilo de código o buenas prácticas. Así puedo revisar muchos PR rápidamente en un día. Para trabajo más importante, cuando soy responsable, pruebo la branch y reviso la implementación con detalle. Como repito esto en cada actualización del PR, consume mucho tiempo. Si varios agentes proponen diff al mismo tiempo, sobre todo cuando hace falta validación, me pregunto cómo manejar el cambio de contexto, y cómo gestionar las dependencias entre módulos cuando una actualización afecta sutilmente otras tareas.
  • Este mismo enfoque también se podría hacer igual como plugin del IDE.
  • ¡Qué buena herramienta! Me da curiosidad por qué no usaste el Claude Code TS SDK. Instalé el paquete, pero parece que la estructura ejecuta directamente el comando claude por separado. Por cierto, también te recomiendo revisar electron-trpc. El manejo de IPC se vuelve mucho más simple.
  • Esta herramienta también está muy bien, pero resuelve un problema distinto. Los agentes en segundo plano tienen dos problemas grandes. 1) Hay una barrera de entrada para configurar correctamente entornos aislados. La dificultad varía mucho según el proyecto, desde elegir un contenedor sencillo hasta casos donde configurar todas las dependencias es un infierno. En cambio, si trabajas dentro del IDE, normalmente ya está todo listo. 2) La gente tiene que aprender cómo el agente construye el código. Si el agente funciona dentro del IDE y yo puedo aconsejarlo o corregirlo en tiempo real, eso ayuda mucho más a largo plazo que un agente en segundo plano.
• Lo que yo quisiera es lo siguiente: un entorno con soporte potente para cambio de contexto basado en git worktree dentro de la misma ventana del IDE; un framework para conectar agentes basados en terminal a cada branch de worktree; un entorno que eventualmente evolucione hacia un mejor protocolo abierto para diff, notificaciones de solicitud de permisos y notificaciones de progreso; una barra lateral para monitorear el estado y las notificaciones del agente por cada branch de worktree; y una interfaz para responder rápido, como si fueran notificaciones, a mensajes del agente a través de varias branch. Hay herramientas standalone para gestionar agentes con funciones así, pero cuando quieres meterte de inmediato como ingeniero real, no puedes usarlas bien. También hace falta integración con ventanas de prueba en navegador o instancias de emulador/simulador móvil por branch. Además debe tener autocompletado de código basado en modelos rápidos, soporte para varios language servers y un ecosistema de extensiones que cumpla bien el papel de un IDE de alta calidad. Ahora mismo estoy gestionando por separado Windsurf, Claude agent, navegador web y simuladores móviles en varios escritorios de macOS. Es muy incómodo.
  • Lo que quiero es un agente de programación con capacidades de depuración. Quiero seguir el stack, ver valores de variables locales y argumentos, y mirar realmente qué está pasando por dentro en vez de usar print o assert.
  • Sobre eso de reaccionar rápido a mensajes del agente en varias branch como si fueran notificaciones, yo también intenté hacer un plugin para VSCode. Era una función para que Claude saltara directamente a archivo y línea; funcionaba hasta cierto punto, pero tenía el problema de quedarse colgado constantemente.
• La verdad no entiendo bien cuál es la diferencia real entre Cursor y Claude Code. Probé ambos y, como en la empresa lo cubren, simplemente me pasé a Cursor. Fuera de CLI vs UI, ambos hacen ediciones multiarchivo y no encontré grandes diferencias. Ojalá termine pronto esta etapa incómoda de transición en la que hay que usar varios editores al mismo tiempo o ir y venir entre JetBrains y Cursor.
  • En calidad y utilidad sí hay una gran diferencia. Claude Code es totalmente agentic. Le asignas una tarea y la implementa completa por su cuenta, generando código bastante bueno y funcional. Puede probar, hacer commit, ejecutar comandos, acceder a sistemas remotos, depurar, etc. No optimiza el uso de tokens, así que en el primer intento suele producir código de mayor calidad que Cursor, pero también cuesta más. El modo agente de Cursor todavía está en una etapa temprana. Cursor se parece más a una herramienta para editar archivos, mientras que Claude Code cumple un rol más parecido al de un desarrollador junior.
  • Muchas veces uso ambas herramientas juntas. Cursor como IDE, y Claude Code ejecutándose en la terminal del IDE. En términos de rendimiento, la forma agentic es distinta, y aunque usen el mismo modelo base, hay diferencias en análisis del codebase, uso de submodelos, integración con herramientas, etc.
  • Me sorprende que no notes mucha diferencia. Para mí Claude es muy superior en todo. Uso principalmente scala, python, js y dart. Con Claude tengo un asistente increíblemente productivo. Es especialmente útil para cambios pequeños y medianos. Si lo usas bien y planeas bien, se siente casi mágico. Tiene algo de duplicación de código, pero nada grave. Cursor requería tantos retoques que al final solo me hacía más lento.
  • Claude Code de verdad impresiona. Se siente como si hubiera otro programador sentado conmigo en la terminal. No es perfecto y hay que ayudarlo hasta que entienda bien lo que quieres hacer. Pero si le das el contexto adecuado, de verdad sorprende. En mi caso ni siquiera le hice entender por completo el proyecto, y tampoco lo uso para TypeScript ni desarrollo web.
  • Cursor exige cambiar a un IDE aparte, a menos que ya uses VSCode, mientras que Claude Code (o Aider) modifica los archivos del proyecto directamente desde la terminal, en paralelo con tu IDE actual. En mi caso uso la combinación vim+tmux+bash, así que prefiero asistentes por CLI, pero esta ventaja también aplica para quien use otro IDE GUI que no sea VSCode.
• La semana pasada me sorprendió más bien que no hubiera una gran reacción cuando github introdujo límites a las solicitudes premium de copilot. Supongo que cuando empiece a haber gente que realmente choque con esos límites, habrá una reacción mayor. Qué bueno que existan productos competidores.
  • Con Claude Code, 10 dólares pueden desaparecer en un instante en una sola ejecución.
• Me pregunto si hay alguna ventaja especial frente a usar VSCode Copilot en modo Agent + Claude Sonnet 3.7 o 4. Quisiera saber qué me estoy perdiendo.
  • Tienes que probar Claude Code tú mismo para responder esa pregunta. No tiene sentido debatirlo solo aquí. Si usas terminal Linux como entorno principal, te va a enganchar enseguida. También hay que leer la documentación sí o sí. Usa CLAUDE.md, y para tareas grandes haz documentos de planificación en formato markup; luego itera varias veces entre plan-corrección y delega la implementación. Cuando te acerques al límite de contexto, es mucho más eficiente escribir la memoria a un archivo, hacer /clear y luego volver a leerla.
  • Intenté integrar Playwright MCP con el modo agente de Copilot, pero fracasé. Se instala y hasta aparece en la selección de herramientas, pero al final Copilot no permite el acceso a la funcionalidad.
• Me pregunto cuál es la ventaja de esta solución frente a usar backend de Claude en modo agente de Copilot
  • Otras explicaciones de este hilo (en especial https://news.ycombinator.com/item?id=44353972) también aplican a vscode copilot.
  • Después de usarlo unos días, esta integración mejoró la incomodidad de tener que abrir archivos manualmente para revisar actualizaciones. En modo terminal, todo se procesaba en segundo plano y no sabía qué estaba pasando, pero en un IDE integrado puedes verlo todo en tiempo real. Eso sí, los nombres que pone el agente, como Pondering, Twerking, Juggling, etc., al principio se sienten novedosos pero pronto dejan de servir.
• Es una pregunta algo tangencial, pero me gustaría saber si alguien usa Roo en VSCode. Y también si la función de navegador de Roo se integra bien con Claude proporcionado por GitHub copilot.
• Según entiendo, si ejecutas Claude Code desde VSCode (o Cursor), esto se instala automáticamente. ¿No hace falta buscarlo e instalarlo aparte, verdad?
  • ¿No se siente un poco invasivo eso de que Claude Code se instale automáticamente cuando lo ejecutas desde VSCode?
  • Sí. También está indicado en la página de la extensión.

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

• Al darme cuenta de que Claude Code entiende varios pasos de una sola vez, mi flujo de trabajo empezó a cambiar. Mi forma de pensar por archivo se ha ido transformando poco a poco en unidades únicas de acción como “separar módulos, escribir pruebas y refactorizar las llamadas”. Claude también lo entiende como una sola unidad (modo de máximo esfuerzo). Este cambio modifica gradualmente la forma de abordar la programación. Me preocupo menos por la sintaxis, escribo más scaffolding y agrupo más tareas para resolverlas juntas. Es algo sutil, pero con un impacto grande a largo plazo. Me pregunto qué tan pronto llegará el momento en que empecemos a mejorar intencionalmente la estructura del codebase —más plano, con menos desvíos y con metadata declarativa— para que los agentes LLM puedan explorarlo mejor.
  • Antes de llamar futuro a eso, ya está pasando. Armin Ronacher también aumentó la proporción de código que escribe en Go frente a Python porque los LLM entienden mejor Go. Un colega mío también migró una app de escritorio a Rust porque, gracias al tooling y al sistema de tipos, resulta más fácil de explorar para un agente. Ya se está moviendo la conversación hacia documentar de forma que sea más fácil de leer para la IA.
  • Sigo pensando en esto al escuchar que los LLM claramente funcionan mejor en lenguajes como Go, con tipado estático claro, sintaxis concisa y estilo consistente. Dependiendo de cuánto podamos dejar de preocuparnos por la complejidad innecesaria derivada de las herramientas —lenguaje, framework, bibliotecas, etc.— podremos dedicar más recursos mentales a resolver problemas más esenciales.
• ¡Qué bueno que Claude Code también vaya a llegar a Jetbrains! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • No entiendo por qué este comentario tiene tantos votos negativos. Yo también tengo la misma expectativa. Gracias por compartirlo.

[namojo]

Al usar Claude Code, siento que algo parecido al concepto de MSA —dividirlo todo tanto como se pueda en unidades tipo microservicio y encargarse de cada una como una sola unidad— sería lo más eficiente.