VSCode için Claude Code yayımlandı

• Anthropic’in Claude Code aracını VSCode ile entegre eden ve geliştiricilerin kodlama deneyimini güçlendiren bir eklenti
• Yalnızca Claude Code ayrı olarak kurulmuşsa çalışır

Başlıca özellikler

• Otomatik kurulum: VSCode terminalinde Claude Code çalıştırıldığında eklenti otomatik olarak algılanır ve kurulur
• Seçili alan bağlamını algılama: Editörde seçilen metin Claude’un giriş bağlamına otomatik olarak eklenir
• Diff görünümü desteği: Kod değişiklikleri (diff) doğrudan VSCode’un yerleşik görüntüleyicisinde incelenebilir
• Klavye kısayolları: Alt+Cmd+K gibi kısayollarla seçilen kod Claude istemine kolayca gönderilebilir
• Sekme farkındalığı: Claude, VSCode’da açık olan dosyaların bilgisini anlayarak duruma uygun kod desteği sağlayabilir
• Ayar seçenekleri: /config içinde diff tool auto olarak ayarlanırsa IDE entegrasyonuyla ilgili özellikler kolayca etkinleştirilebilir

• İlk yayımlanan (early release) sürüm olduğundan, kullanım sırasında hata oluşma olasılığı veya bazı tamamlanmamış özellikler bulunabilir

[digitect38]

Cursor ile belirgin farkı var

1. Cursor, VSCode’a bağlı. Buna karşılık, Claude Code CLI (command line interface) tabanlı olduğu için her türlü araçla kullanılabiliyor.

2. Cursor fiilen başka LLM’leri kullanırken, Claude Code Claude’a özelleştirilmiş. Ancak yetenek karşılaştırmasına bakıldığında belirgin biçimde üstün. Bu, Gemini 2.5 Pro ile kıyaslandığında da böyle (DotNet temelinde, dillere göre farklılık gösterebilir).

[bluekai17]

O zaman bunun Cursor'dan farkı nedir?

[iolothebard]

Yani Windows için olanı da (WSL değil) yapmıyorlar da durmadan başka işlerle uğraşıyorlar… -,. -;;;

[wahihi]

WSL de Windows işletim sisteminin bir parçası ama nasıl kullanılacağını bilmiyor galiba... Sadece GUI ile geliştirme yapıyor, CLI'ı ise hiç bilmiyor ya da...

[yeorinhieut]

WSL kullanıldığında dosya sistemi performansının ciddi biçimde düşmesi gibi bir sorun da var (wsl2) ve sanallaştırmanın Hyper-V'ye bağımlı olması gibi bir dezavantajı da bulunuyor. WSL'in kullanılamadığı durumlar da oldukça fazla.

[namojo]

Ben de katılıyorum. Benim şirketimde de WSL kullanımı yasak olduğu için uğraşıp durdum ama sonunda vazgeçtim.
SSL sertifikasını aşarak bir şekilde halletmeyi başardım derken, meğer WSL çalışmıyormuş.

[ng0301]

hahahah, çok katılıyorum

[melong0124]

Git Copilot ile ne farkı var acaba?

[digitect38]

Copilot, MS IDE'lerine özgü ve açıkçası oldukça başlangıç seviyesi kalırken, Claude CLI / Git Bash üzerinde çalıştığı için çeşitli ortamlarda kullanılabiliyor ve kodlama yeteneği görece daha yüksek.

[kimjoin2]

IntelliJ eklentisi de var.
Basit bir CLI ile arasındaki fark, IDE’de görüntülediğiniz ya da seçtiğiniz dosya ve satırları doğrudan algılaması.
Elbette normal terminalde çalıştırıp /ide komutuyla entegrasyonu da başlatabilirsiniz.

[GN⁺]

Hacker News görüşleri

• Mevcut IDE'lere agent tabanlı kodlamayı entegre etme yaklaşımının yanlış yön olduğunu düşünüyorum. Birden fazla Git worktree'yi yönetmek ve her bir agent'ın aynı anda çalışması daha iyi. Claude Code'un işi bitirmesini 20 dakikadan fazla beklemek gerekmiyor. Bu yüzden bunu yönetmek için arayüzü kendim yaptım ve giderek birden fazla agent'ı yönetip incelemeye yönelik yeni bir IDE türüne evriliyor. Eskisinden farklı olarak aynı anda tek bir iş yapılmıyor. https://github.com/stravu/crystal
  • Ben kişisel olarak farklı düşünüyorum. Her gün Cursor'ı ticari projelerde kullanıyorum. Background agent'lar belli durumlarda faydalı olsa da çoğu zaman sadece dikkat dağıtıyor. Benim tercih ettiğim kodlama tarzı, tek bir hedefe odaklanıp yinelemeli biçimde çözüme yaklaşmak. İşin bitmesini beklerken dokümantasyon ya da ilgili bilgileri tarayıp sonraki adımı düşünüyorum. Mevcut kodu veya değişiklikleri inceleyerek şu anki durumu doğru anlamak da çok önemli. Her iş için birden fazla agent yönetme fikri benim tarzıma uymuyor. Fazla fazla context switching ve multitasking yaratıyor.
  • Bu tür iş akışı önerilerinde her zaman merak ettiğim şey, kişisel bağlamımı nasıl yöneteceğim. Ekip arkadaşlarının code review'larında da tüm kodu kusursuz biçimde anlayıp doğrulamak yerine, daha çok büyük hataları hızlıca kontrol ediyorum; örneğin code style, best practice'ler gibi. Bu sayede günde çok sayıda PR'ı hızlıca inceleyebiliyorum. Daha önemli işlerde, yani sorumluluğun bende olduğu durumlarda, branch'i test ediyor ve implementasyonu dikkatle kontrol ediyorum. PR her güncellendiğinde bunu tekrar ettiğim için çok zaman alıyor. Birden fazla agent aynı anda diff önerirse, özellikle doğrulama gerektiğinde context switching'i nasıl yöneteceğim ve tek bir güncelleme başka işlere ince şekilde etki ettiğinde modül bağımlılıklarını nasıl idare edeceğim diye düşünüyorum.
  • Aynı yaklaşım bir IDE eklentisi olarak da uygulanabilir.
  • Harika bir araç! Claude Code TS SDK'yı neden kullanmadığını merak ediyorum. Paketi kurmuşsun ama onun yerine doğrudan claude komutunu çalıştıran bir yapı var gibi görünüyor. Bu arada electron-trpc'ye de bakmanı öneririm. IPC işlemleri çok daha kolaylaşıyor.
  • Bu araç da harika ama çözdüğü problem farklı. Background agent'ların iki büyük sorunu var. 1) İzole ortamı düzgün kurmak için giriş bariyeri var. Zorluk seviyesi projeye göre çok değişiyor; basitçe konteyner seçmekten tüm bağımlılıkları kurmanın cehenneme dönmesine kadar gidebiliyor. Oysa IDE içinde çalışırken genelde her şey zaten hazır oluyor. 2) İnsanların agent'ın kodu nasıl derleyip çalıştırdığını öğrenmesi gerekiyor. Agent IDE içinde çalışır ve ben ona gerçek zamanlı tavsiye ya da düzeltme verebilirsem, bu uzun vadede background agent'lardan çok daha faydalı olur.
• Benim istediğim şey şu: git worktree tabanlı context switching'i aynı IDE penceresinde güçlü biçimde destekleyen bir ortam, her worktree branch'i için terminal tabanlı agent bağlayabilen bir framework, sonunda diff'ler, izin isteme bildirimleri ve ilerleme bildirimleri için daha iyi bir açık protokole evrilen bir yapı, her worktree branch'i için agent durumunu ve bildirimleri izleyen bir kenar çubuğu ve tüm branch'lerdeki agent mesajlarına bildirim gibi hızlı yanıt vermeyi sağlayan bir arayüz. Bağımsız agent manager araçlarında bunlar var ama gerçek bir mühendis olarak hemen işe dalmak istediğimde bu tür araçları etkili kullanamıyorum. Her branch için tarayıcı test pencereleri veya mobil emulator/simulator örnekleriyle entegrasyon da gerekli. Hızlı model tabanlı kod tamamlama, çeşitli language server desteği ve yüksek kaliteli bir IDE olmanın getirdiği eklenti ekosistemi de olmalı. Şu anda birden fazla macOS masaüstünde Windsurf, Claude agent, web browser ve mobil simulator'u ayrı ayrı yönetiyorum. Bu yöntem çok zahmetli.
  • Benim istediğim, debugging özelliği olan bir kodlama agent'ı. Stack'i takip edebilsin, local variable ve argument değerlerine bakabilsin, print ya da assert yerine içeride gerçekten neler olup bittiğini görebileyim.
  • Birden fazla branch'teki agent mesajlarına bildirim gibi hızlı tepki verme özelliğiyle ilgili olarak, ben de VSCode için bir eklenti yapmayı denemiştim. Amaç Claude'un doğrudan dosya ve satıra atlayabilmesiydi; bir noktaya kadar çalıştı ama sürekli takılma sorunları vardı.
• Cursor ile Claude Code arasındaki gerçek farkın ne olduğunu pek anlamıyorum. İkisini de kullandım ve şirket desteklediği için sadece Cursor'a geçtim. CLI ile UI farkı dışında, ikisi de çoklu dosya düzenleyebildiği için belirgin bir fark göremedim. Birden fazla editörü aynı anda kullanmak ya da JetBrains ile Cursor arasında gidip gelmek zorunda kaldığımız bu garip geçiş döneminin bir an önce bitmesini istiyorum.
  • Kalite ve işe yararlılık açısından ikisi arasında büyük fark var. Claude Code tamamen agentic bir yaklaşım. Ona işi veriyorsun, bütünü kendi başına implemente ediyor ve oldukça iyi, çalışan kod üretiyor. Test edebiliyor, commit atabiliyor, komut çalıştırabiliyor, uzak sistemlere bağlanabiliyor, debugging yapabiliyor. Token kullanımını optimize etmiyor; bu yüzden ilk denemede Cursor'dan daha kaliteli kod çıkıyor ama maliyeti de daha yüksek oluyor. Cursor'ın agent modu hâlâ erken aşamada. Cursor daha çok dosya düzenleme aracı gibiyken Claude Code daha çok junior bir geliştirici gibi davranıyor.
  • Ben çoğu zaman iki aracı birlikte kullanıyorum. Cursor IDE, Claude Code ise IDE içindeki terminalde çalışan araç oluyor. Performans açısından agent yaklaşımı farklı ve aynı temel modeli kullansalar bile codebase analizi, alt modellerin kullanımı, araç entegrasyonu gibi konularda fark var.
  • Fark hissetmemene şaşırdım. Bana göre Claude her açıdan çok üstün. Çoğunlukla scala, python, js ve dart kullanıyorum. Claude ile aşırı verimli bir asistan elde ediyorum. Özellikle küçük ve orta boy değişikliklerde çok kullanışlı. İyi planlayıp kullanınca adeta sihir gibi geliyor. Biraz kod tekrarı oluyor ama o kadar. Cursor ise çok fazla düzeltme istediği için beni yavaşlattı.
  • Claude Code gerçekten etkileyici. Sanki terminalimde benimle birlikte oturan başka bir programcı var gibi. Kusursuz değil ve ne istediğimi doğru anlayana kadar yönlendirme gerekiyor. Ama bağlam düzgün verildiğinde gerçekten şaşırtıcı. Benim kullanımımda projeyi tamamen anlamış da değil ve TypeScript ya da web geliştirme için de kullanmıyorum.
  • Cursor ayrı bir IDE'ye geçmeyi gerektiriyor (zaten VSCode kullanmıyorsan), Claude Code ise (veya Aider) mevcut IDE yanında terminalde doğrudan proje dosyalarını düzenliyor. Ben vim+tmux+bash kombinasyonu kullandığım için CLI asistanlarını tercih ediyorum ama bu avantaj, VSCode dışındaki başka GUI IDE kullananlar için de geçerli.
• Geçen hafta GitHub'ın Copilot için premium istek sınırı getirdiğinde büyük tepki olmaması beni daha da şaşırttı. Gerçekten sınıra takılan insanlar ortaya çıkınca daha büyük tepki olacağını tahmin ediyorum. Rakip ürünlerin olması gerçekten sevindirici.
  • Claude Code'da tek bir çalıştırmada 10 doların uçup gitmesi işten bile değil.
• VSCode Copilot'u Agent modu + Claude Sonnet 3.7 ya da 4 ile kullanmaya kıyasla bunun özel bir avantajı var mı merak ediyorum. Gözden kaçırdığım bir şey varsa bilmek isterim.
  • Bu sorunun cevabını verebilmek için Claude Code'u bizzat deneyimlemek gerekiyor. Burada tartışmanın pek anlamı yok. Linux terminalini ana çalışma ortamın olarak kullanıyorsan hemen bağlanırsın. Dokümantasyonu da mutlaka oku. CLAUDE.md kullan, büyük işleri markup biçiminde plan dokümanlarına dök ve planı tekrar tekrar gözden geçirip düzenleyerek implementasyonu ona yaptır. Context limitine yaklaşınca belleği dosyaya write edip /clear sonrası yeniden okutma yöntemini kullanırsan çok daha verimli oluyor.
  • Playwright MCP ile Copilot agent modunu entegre etmeye çalıştım ama başaramadım. Kuruluyor ve araç seçiminde de görünüyor ama sonunda Copilot bu özelliklere erişime izin vermiyor.
• Copilot agent modunda Claude backend kullanmaya kıyasla bu çözümün avantajı nedir merak ediyorum.
  • Bu başlıktaki diğer açıklamalar (özellikle https://news.ycombinator.com/item?id=44353972) VSCode Copilot için de geçerli.
  • Birkaç gün kullandıktan sonra şunu fark ettim: Bu entegrasyon sayesinde, yapılan güncellemeleri görmek için dosyaları tek tek açma zahmeti azaldı. Terminal modunda her şey arka planda yürüdüğü için ne olduğunu göremiyordum ama IDE entegrasyonunda her şeyi gerçek zamanlı görebiliyorsun. Yalnız agent'ın verdiği isimler (Pondering, Twerking, Juggling gibi) ilk başta eğlenceliydi ama kısa sürede anlamsız geliyor.
• Konudan biraz sapmış bir soru olacak ama VSCode'da Roo kullanan var mı merak ediyorum. Bir de Roo'nun tarayıcı özelliği, GitHub Copilot'un sunduğu Claude ile iyi çalışıyor mu?
• Bildiğim kadarıyla VSCode'da (veya Cursor'da) Claude Code'u çalıştırınca bu otomatik kuruluyor. Ayrı gidip kurmaya gerek yok, doğru mu?
  • Claude Code'un VSCode içinde çalıştırıldığında otomatik kurulması biraz istilacı hissettirmiyor mu?
  • Evet. Extension sayfasında da açıkça yazıyor.

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

• Claude Code'un birden fazla adımı tek seferde anlayabildiğini fark ettikçe iş akışım değişmeye başladı. Dosya bazlı düşünmekten giderek “modülü ayır, testleri yaz, çağrı noktalarını refactor et” gibi tekil eylem birimlerine geçiyorum. Claude da bunu tek bir birim olarak anlıyor (maximum effort modunda). Bu değişim, kod yazma yaklaşımını yavaş yavaş dönüştürüyor. Söz dizimiyle daha az uğraşıyor, daha fazla scaffolding yazıyor ve birden fazla işi paketleyip birlikte ele alıyorum. İnce bir fark ama uzun vadeli etkisi büyük. Yakında, LLM agent'ların daha iyi gezinebilmesi için codebase yapısını özellikle iyileştirmeye — daha düz yapı, daha az dolaylılık, daha deklaratif metadata gibi — ne kadar çabuk başlayacağımızı merak ediyorum.
  • Bunun gelecek olduğunu söylemeden önce zaten başlamış durumda. Armin Ronacher'in Python yerine daha fazla Go yazmasının nedeni de LLM'lerin Go'yu daha iyi anlaması. Bir iş arkadaşım da masaüstü uygulamasını Rust'a taşıdı; çünkü tooling ve type system sayesinde agent'ların gezinmesi daha kolay oluyor. Zaten düşünce yönü, AI'ın daha kolay okuyacağı şekilde dokümantasyon yazmaya kaymış durumda.
  • LLM'lerin Go gibi net statik tiplere, sade sözdizimine ve tutarlı yazım biçimine sahip dillerde gerçekten daha iyi çalıştığını duydukça bunu daha çok düşünüyorum. Araçların — dil, framework, kütüphane vb. — doğurduğu gereksiz karmaşıklığı ne kadar az dert edersek, zihinsel kaynaklarımızı o kadar daha özdeki problem çözümüne ayırabiliyoruz.
• Claude Code'un JetBrains'e de gelmesine sevindim! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • Bu yoruma neden bu kadar eksik oy verildiğini anlamıyorum. Ben de aynı şekilde heyecanlıyım. Paylaştığın için teşekkürler.

[namojo]

Claude Code kullanırken, sanırım MSA'ya benzer bir yaklaşımla işi mikroservis birimleri düzeyinde bölünebildiği kadar bölüp her birini tek bir birim olarak devretmenin en verimli yöntem olabileceğini düşünüyorum.