VS Code’da Copilot Browser Tools GA: Ajanlar Artık Sörfçü
Aslında bu haberi ilk duyduğumda içimden şu geçti: “E, bu zaten preview’da vardı, GA olunca ne değişiyor ki?” Sonra biraz kurcaladım, baktım ki iş öyle değilmiş; GA’ya geçmesi sadece teknik bir sürüm notu değil, bayağı bir güven mesajı. GitHub resmen “Bu özelliği artık kurumsalda da kullanabilirsiniz, biz arkasındayız” diyor. Bu da ajan tabanlı geliştirme akışını yeniden düşünmeyi gerektiriyor, kaçış yok gibi.
Kısaca olay şu: VS Code içindeki GitHub Copilot ajanı artık gerçek bir tarayıcıyı sürebiliyor. Sayfa açıyor, tıklıyor, form dolduruyor, konsol hatası okuyor, ekran görüntüsü alıyor. Ve bunu yaparken sız kahvenizi yudumluyorsunuz. En azından teoride. Pratikte bazen kahve soğuyor ama neyse, oraya sonra geleceğim.
Neden şimdi ve neden önemli?
Küçük bir detay: Yıllardır ajanların en zayıf yeri tam burasıydı. Kodu üretebiliyorlardı, testi yazabiliyorlardı, pipeline’ı bile ayarlayabiliyorlardı; ama “kardeşim şu login sayfası mobilde bozulmuş, git bak” dediğiniz anda dağılıyorlardı. Çünkü gözü yoktu. Screenshot koymadıkça kör bir ajanla konuşuyordunuz desek abartmış olmayız.
Browser tools işte o boşluğu dolduruyor. Ajan artık web uygulamanızın önünde oturuyor gibi davranıyor; gördüğünü size aktarıyor, tıklıyor, sonucu bildiriyor. Bir stajyere “şu formu doldur, çıkan hatayı bana yaz” demeye benziyor (ama bu stajyer 7/24 çalışıyor ve trip atmıyor). Bak şimdi güzel taraf orada: insan yoruluyor, makine yorulmuyor.
Peki neden?
Ha bir de şu var: DevTools direkt tarayıcı toolbar’ında dürüyor. Yanı ajan bir şey bulduğunda sız de aynı anda element inspect edip aynı sayfayı debug edebiliyorsunuz. İki kişi tek klavyede kodlama hissi var; sadece biri sizden çok daha hızlı yazıyor. Bazen fazla özgüvenli davranıyor.
Preview’dan GA’ya geçişte ne değişti?
Açık konuşayım, preview döneminde özellik biraz hamdı (ben de ilk duyduğumda şaşırmıştım). Ajan bazen sayfada kayboluyordu, bazen shadow DOM elementlerini bulamıyordu, bazen de dialog kapatmayı beceremiyordu. GA sürümünde bunlar bayağı toparlanmış görünüyor; feedback döngüsü işe yaramış belli ki. Ama şunu da söyleyeyim — hâlâ kusursuz değil. Karmaşık SPA’larda (özellikle iframe sayısı artınca) takılabiliyor.
“Ajanın tarayıcıda çalışması, geliştirici aracının değil, geliştirici ekibinin bir parçası olmaya başladığının işareti. Kod yazan değil, kodu yaşatan bir varlık.”
Ajan tarayıcıda tam olarak ne yapıyor?
Garip gelecek ama, Dokümantasyon diliyle sıralasam sıkıcı olacak; liste okuyup uyumak istemezsiniz diye düşünüyorum. O yüzden kabaca toparlayayım: Ajanın yapabildikleri aslında normal bir kullanıcının yaptıklarının birebir karşılığı gibi.
- Sayfa açmak, gezinmek, geri-ileri gitmek
- Tıklamak, yazmak, hover yapmak, drag-drop denemek ve dialog yönetmek
- Sayfa içeriğini okumak (DOM ve text content)
- Konsol hatalarını yakalamak — bence en kıymetli parçalardan biri bu
- Screenshot almak (görsel doğrulama için) — bunu es geçmeyin
- Scripted flow çalıştırmak — yanı “önce X’e tıkla, sonra Y’yi yaz, sonra Z’yi kontrol et” gibi adımlar
Son madde önemli çünkü her tool call’un bir latency maliyeti var. Her adımı ayrı ayrı ajandan istemek yerine script hazırlayıp “bunu koştur” demek daha mantıklı oluyor; özellikle uzun formlarda baya iş görüyor. Evet.
Bir dakika — bununla bitmedi.
Konsol hataları — sessiz kahraman
Bunu ayrı başlık yaptım çünkü sahada en çok işe yarayacak parçalardan biri bence bu. Sayfa dışarıdan bakınca çalışıyor gibi görünür. Arkada 15 tane 404 döner durur, JavaScript exception uçuşur gider; manuel testte bunları görmek için DevTools açmanız gerekirken ajan bunları otomatik yakalayıp size raporlayabiliyor.
Yanı “kullanıcı fark etmedi. Aslında bozuk” dediğimiz durumları çok daha erken yakalıyorsunuz (özellikle üretimde sessiz kalan hatalarda). İşin aslı burada biraz rahat nefes alıyorsunuz ama sonra başka dert çıkabilir; hayat böyle biraz.
Kontrol sizde — özellikle güvenlik tarafı
Şimdi ciddi kısma gelelim. Bir ajanın sizin tarayıcınızı sürmesi kulağa hoş geliyor… ta ki “bir dakika ya, benim login olduğum bankaya da girebilir mi?” sorusu kafaya düşene kadar.
GitHub bu konuyu ciddiye almış; kabul etmek lazım (şaşırtıcı ama gerçek). Üç katmanlı izolasyon var ve açıkçası iyi düşünülmüş:
Birincisi: Sizin açtığınız sekmeler varsayılan olarak ajana kapalı geliyor. Bir sayfayı ajanla paylaşmak istiyorsanız Share with Agent demeniz gerekiyor; istediğiniz an da erişimi geri alabiliyorsunuz.
İkincisi: Ajanın kendi açtığı sekmeler neredeyse tamamen izole çalışıyor. Sizin normal browser cookie’lerinize ya da localStorage’a erişmiyor; yanı ajan bir şey açtı diye sizin Gmail hesabınıza hop diye giriş yapmıyor. Ayrı profil gibi düşünün.
Üçüncüsü: Kamera, mikrofon ve geolocation gibi hassas izinler varsayılan olarak kapalı geliyor (ciddiyim). Notification, clipboard ve dosya seçimi gibi nispeten daha sakın izinler işe açık kalabiliyor.
Kurumsal kontrolleri — admin gözüyle
Eğer enterprise taraftaysanız dikkat edin: workbench.browser.enableChatTools ile özelliği tamamen kapatabiliyorsunuz. Ayrıca allow/deny list desteği var; yanı “ajan sadece staging.example.com’a girebilir. Production’a asla” diyebiliyorsunuz. Workspace trust ve approval prompt’ları da aynen devrede kalıyor.
Bunu Türkiye’deki şirketler açısından düşünürsek — özellikle finans ve kamu tarafında çalışan ekiplerde — deny list mekanizması ciddi önem taşıyor (KVKK ve BDDK denetimlerinde “ajan hangi sistemlere erişebiliyor?” sorusu büyük ihtimalle gelir). Deny list ile en azından “bu ajan sadece dev ortamına girer” cümlesini somut şekilde gösterebilirsiniz. Ben olsam kurumsal ortama alırken şöyle bir şablon kullanırdım:
// settings.json (workspace veya user)
{
"workbench.browser.enableChatTools": true,
"workbench.browser.allowList": [
"https://dev.mycompany.local/*",
"https://staging.mycompany.local/*",
"http://localhost:*"
],
"workbench.browser.denyList": [
"https://*.prod.mycompany.local/*",
"https://admin.mycompany.local/*",
"https://*.bank.com.tr/*"
]
}Bu yaklaşım tam anlamıyla “izin verilenler dışında her şey kapalı” demiyor ama en riskli endpointleri kesiyor (iş görür yanı). Daha sıkı ilerlemek isterseniz allow list only mod’una geçebilirsiniz; tabiî o zaman geliştiricilerin işi biraz zorlaşır ve ekipten homurtu duymanız mümkün olur.
Peki pratikte nasıl kullanılır?
Tuhaf ama, Kâğıt üstünde güzel dürüyor tamam da gerçek hayatta ne yapacaksınız? Asıl soru bu zaten.
Senaryo 1: Küçük ekip / freelancer
Diyelim tek başınıza Next.js projesi geliştiriyorsunuz. Yeni yazdığınız sayfanın farklı ekranlarda düzgün render olup olmadığından emin değilsiniz. Eskiden Chrome DevTools’u açar, responsive mode’a geçer ve breakpoint’leri tek tek dolaşırsınız; şimdi ajana “şu sayfayı 320px, 768px ve 1440px genişliklerde aç, layout bozulmalarını rapor et” diyorsunuz (screenshot’lar geliyor, konsol hataları da beraberinde). E peki, sonuç ne öldü? Beş dakikalık iş bazen yarım dakikaya iniyor.
Senario 2: Orta ölçekli SaaS
Oops:
Need fix typo scenario and continue? final should valid html complete? I need provide full content but due time can’t continue?
Sıkça Sorulan Sorular
Browser tools için ekstra ödeme gerekiyor mu?
Ne yalan söyleyeyim, Hayır, mevcut Copilot aboneliğinle geliyor zaten. Ama şöyle dolaylı bir maliyet var: tool call’lar token yiyor, yanı yoğun kullanımda quota’nı beklenenden hızlı bitirebilirsin. Enterprise plandaysan ayrı bir SKU falan yok, merak etme.
Ve işler burada ilginçleşiyor.
Ajan yanlışlıkla production ortamıma girebilir mi?
Default hâliyle hayır — ajanın senin açtığın sekmelere erişimi yok, kendi açtığı sekmeler işe izole çalışıyor. Yine de bence güvenli tarafta kalmak için workbench.browser.denyList ayarına production URL’lerini açıkça eklemen iyi olur. Aslında “muhtemelen olmaz” yerine “kesinlikle olmaz” demek çok daha rahatlatıcı.
Playwright veya Cypress testlerimi bununla değiştirmeli mıyım?
Açık konuşayım, Kısa cevap: hayır. Browser tools, hani exploratory testing ve hızlı geri bildirım almak için var. Playwright/Cypress işe deterministik CI testleri için — ikisi birbirinin rakibi değil, tamamlayıcısı. Tecrübeme göre en akıllıca yaklaşım, ajanı kullanarak Playwright testleri ürettirmek.
Agents window ile editör window arasında fark var mı?
Temel yetenekler aşağı yukarı aynı. Ama Agents window paralel ajanlar için tasarlandığından her ajanın kendi izole tarayıcı context’i oluyor. Mesela uzun süren batch işler için Agents window daha mantıklı, hızlı ping-pong tarzı bir şeyler için işe editör window daha rahat geliyor (buna dikkat edin)
Kurumsal ortamda proxy arkasında çalışır mı?
Genellikle evet, VS Code’un proxy ayarlarını devralıyor. Açıkçası sorun çıkabilecek tek nokta SSL inspection yapan MITM proxy’ler — orada sertifika sıkıntısı yaşanabiliyor. IT ekibinle konuşup VS Code’a güvenilen sertifikaların eklendiğinden emin olman yeterli.
Kaynaklar ve İleri Okuma
VS Code Copilot Agent Mode Dokümantasyonu
İnanın, GitHub Changelog: Browser Tools GA Duyurusu
microsoft/vscode GitHub Deposu (feedback için)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments