GitHub Copilot app: Ajanlarla Çalışmanın Yeni Düzeni
Geçen ay, İstanbul’da bir müşteride tam da şunu konuştuk: “AI ajanları hız kazandırıyor ama işler biraz dağınık hâle geldi mi?” Cevap netti: evet. Bir ekip aynı anda üç farklı akış yürütüyor, biri hata kök nedenini araştırıyor, biri backlog’daki işi tamamlıyor, diğeri de pull request yorumlarını toparlıyor… ama hepsi ayrı pencerelerde, ayrı notlarda, ayrı kafalarda (ki bu çoğu kişinin gözünden kaçıyor). İşin aslı şu ki, bu tablo bana 2024’ün başında Avanade tarafında görüştüğüm bir kurumsal dönüşüm projesini hatırlattı; hız artmıştı. Görünürlük azalmıştı.
GitHub’ın yeni Copilot app yaklaşımı tam burada anlam kazanıyor. Masaüstünde bir kontrol merkezî gibi çalışması bence boş bir pazarlama cümlesi değil; gerçekten ihtiyaçtan doğmuş bir fikir. Yine de açık konuşayım, kağıt üstünde çok iyi görünen bu tip araçlar pratikte ilk günden sihir yapmıyor. Mesela büyük ekiplerde süreç disiplininiz zayıfsa, uygulama tek başına kurtarmıyor. Hatta biraz hayal kırıklığı bile yaratabiliyor.
Evet, doğru duydunuz.
Şunu fark ettim: Benim gözümde bu duyurunun en önemli tarafı şu: GitHub artık sadece kod barındırılan yer değil, ajanların da “yaşadığı” bir çalışma alanına dönüşüyor (buna dikkat edin). AZ-305 ve AZ-104 hazırlanırken yıllardır öğrendiğim şeylerden biri hep aynıydı; platform ne kadar güçlü olursa olsun, asıl mesele önü iş akışına doğru yerleştirmek (en azından benim deneyimim böyle). Burada da mesele o.
Ajanların Hızlandığı Yerde Neden Yeni Bir Masaüstü Katmanı Gerekli?
Agentic development güzel bir kavram ama küçük bir detayı var: kontrol edilmezse çorba oluyor. Bir ajan issue çözerken diğerinin aynı dosyaya dokunması, review feedback’in takip edilememesi ya da test sonucu ile üretilen kod arasında bağ kopması… bunlar sahada sık gördüğümüz şeyler. 2025’te Ankara’daki bir finans kuruluşunda buna benzer bir durum yaşamıştık; ekipler paralel çalışıyordu ama kimin neyi denediği belli değildi. Sonuç? Gereksiz tekrar iş ve bayağı vakit kaybı.
Copilot app’in iddiası tam da burada devreye giriyor: işleri tek ekrandan görüp yönetmek. Bu fena değil, hatta baya işe yarar. Çünkü insan beyni sekme sekme gezmeyi sevmez; en azından benim hiç sevmediğim kesin. Bilhassa sabah başlayıp öğlene kadar on iki farklı pencere arasında gidip geliyorsanız, context switching sizi sessizce kemiriyor.
Evet, doğru duydunuz.
Bir de şu var: ajan sayısı arttıkça “ne çalışıyor, ne bekliyor, ne patladı” soruları çoğalıyor. Eğer bunu düzgün göremezseniz üretkenlik yerine gürültü büyüyor. İşte masaüstü deneyimi burada mantıklı hâle geliyor.
My Work görünümü neden önemli?
Açık konuşayım, My Work ekranı bana göre işin kalbi. Aktif oturumları, issue’ları, pull request’leri ve arka plandaki otomasyonları tek yerde görmek kulağa basit geliyor ama pratikte büyük rahatlık sağlıyor. Ben 2019’da kendi lab ortamımda çoklu branch yönetimini manuel yaparken benzer bir ihtiyacı acı şekilde öğrenmiştim; insan takip etmediği şeyi kaybediyor.
Tuhaf ama, Mesela kurumsal yapılarda bu görünürlük hayatı çünkü herkes aynı repo üzerinde çalışmıyor olabilir. Biri güvenlik düzeltmesi yapar, diğeri performans iyileştirir, üçüncüsü test otomasyonu koşturur… Hepsini ayrı kartlarda görmek ciddi fark yaratır.
Yine de eksik tarafı yok mu? Var tabi. Eğer organizasyonunuzda. Kötü etiketleme alışkanlığı varsa veya issue disiplininiz zayıfsa My Work sadece daha şık bir karmaşa üretir (ben de ilk duyduğumda şaşırmıştım)
Ajanların verimli olması için önce görünür olması gerekiyor; görünmeyen işi yönetemezsiniz.
İzole Çalışma Alanları: worktree Mantığı Neyi Değiştiriyor?
Beni en çok heyecanlandıran detaylardan biri her oturumun kendi git worktree’sinde koşması öldü. Teknik olarak bu şu demek: aynı branch’in temiz ve izole kopyalarıyla paralel çalışabiliyorsunuz. Düşünün ki mutfakta üç kişi aynı anda yemek yapıyor ama herkesin tezgâhı ayrı — karışıklık azalıyor. Daha fazla bilgi için github ile ilgili önceki yazımız yazımıza bakabilirsiniz.
Bu model küçük ekiplerde bile faydalı; fakat enterprise tarafta asıl değer orada çıkıyor. Çünkü büyük kurumlarda paralel ajanın birbirine çarpması sadece can sıkmaz, bazen release sürecini de geciktirir. Ben Logosoft tarafında yürüttüğümüz bir Azure danışmanlığı sırasında bunu birebir gördüm; izolasyon yoksa debug süresi uzuyor, ekip morali düşüyor. Daha fazla bilgi için Agent Optimizer ile Kurumsal Yapay Zekâyı Pişirmek yazımıza bakabilirsiniz.
Bununla birlikte worktree yaklaşımı kusursuz değil. Disk kullanımı artabilir, local makinenizde kaynak tüketimi — itiraz edebilirsiniz tabi — hissedebilirsiniz ve bazı geliştiriciler ilk başta “ben zaten branch ile hallediyorum” diyebilir. Haklılar da… kısmen. Ama ajan ölçeğinde branch yetmiyor; paralel çalışma başka seviyede düşünülmeli. Daha fazla bilgi için Azure Cosmos DB’de Silinenleri Görmek: Change Feed’in Sessiz Gücü yazımıza bakabilirsiniz.
| Konu | Klasik akış | Ajan-native akış |
|---|---|---|
| Görünürlük | Sekmeler arasında dağınık | Tek merkezden takip |
| Paralel çalışma | Zor ve riskli | Daha güvenli worktree izolasyonu |
| Review takibi | E-postalar ve yorumlar içinde kaybolabilir | Aynı bağlamda görülebilir |
| Ekip ölçeği | Küçük ekipte idare eder | Büyük kurumsalda daha anlamlı |
Kurumsal Tarafta Asıl Soru: Hız mı Kontrol mü?
Bi saniye — Açık konuşayım, birçok şirket AI araçlarını “daha hızlı kod yazsın” diye alıyor ama sonra en büyük sorun review yükü oluyor. Kod üretmek kolaylaşıyor; kodu doğrulamak işe daha önemli hâle geliyor. GitHub’ın bu üründe kontrol merkezine ağırlık vermesi bu yüzden doğru yönde atılmış adım.
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz farklılaşıyor. Bizde çoğu zaman tool satın — ki bu tartışılır — almak kolaydır ama süreç tasarlamak zor gelir… hani klasik hikâye vardır ya: araç var ama kullanım standardı yoktur! Mesela orta ölçekli firmalarda agent sayısı artınca kim hangi çıktıyı niye kabul etti sorusu havada kalabiliyor.
Küçük startup için önerim net olurdu: önce birkaç kilit iş akışı seçin ve önü ölçün. Her yere ajan koymayın; gerekirse sadece bug triage veya PR review destek akışıyla başlayın. Enterprise yapıdaysanız işe governance şart — erişim sınırları, kayıt tutma politikaları ve kalite kapıları olmadan ilerlemek riskli olur. Daha fazla bilgi için Build 2026: AI Ajanlarında Ölçümden ROI’ye Geçiş yazımıza bakabilirsiniz. Bu konuyla ilgili Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı? yazımıza da göz atmanızı tavsiye ederim.
Maliyet tarafını hafife almayın
İşin garibi, Maliyet konusu da önemli tabiî ki… Azure dünyasında yıllardır gördüğüm şey şu: teknoloji iyi olsa bile kullanım disiplini yoksa fatura şişer! Copilot planınız var diye sınırsız rahatlık sanmayın; özellikle yoğun ekiplerde kullanım eğilimleri hızla değişebiliyor.
Eğer bütçeniz dar işe önce kapsam daraltın, sonra genişletin derim ben. Mesela tüm repolar yerine yüksek etki alanlarına odaklanın; production hotfix’ler veya müşteri etkisi yüksek servisler gibi (inanın bana)
Düzgün başlangıç için pratik adımlar
- En çok zaman yiyen üç iş akışını seçin. (bence en önemlisi)
- Ajanlara net rol verin; her işi her ajana açmayın.
- PR review için kabul/red kriterlerini yazılı hâle getirin.
- Kimin hangi session’ı başlattığını loglayın.
- Döngüyü haftalık olarak gözden geçirin ve gereksiz otomasyonu kapatın.
Sahada Ne Öğrendim? İki Küçük Hikâye…
Nisan 2024’te İzmir’de bir üretim firmasına gitmiştim; ekip Copilot kullanıyordu ama herkes kendi penceresinde boğuluyordu desem yeridir. Orada temel problem model değildi — organizasyondu. Araç vardı ama ortak görünüm yoktu. Bu yeni uygulama o tip ekiplerde gerçek anlamda nefes aldırabilir.Eylül 2025’te işe Ankara’da bir SaaS ekibiyle çalışırken başka bir şey fark ettim: geliştiriciler hızlıydı. Review kültürü gerideydi. Ajanlar kod üretiyor, insanlar sonradan yakalıyordu. İşte tam burada agent-native masaüstü deneyimi “kim ne yaptı?” sorusunu daha net hâle getiriyor (evet, doğru duydunuz). Bence en kıymetli yanı bu.Bazıları buna gereksiz bulabilir, özellikle küçük takımlarda. Doğru olabilir. Ama kurumsal tarafta her saniyenin maliyet olduğu yerde görünürlük lüks değil, ihtiyaç oluyor. Hatta bazen ufak görünen düzenlemeler büyük krizleri önlüyor—bu kısmını defalarca gördüm.
Nerede Güzel, Nerede Ham?
>
Sıkça Sorulan Sorular
GitHub Copilot app tam olarak ne?
Araya gireyim: Aslında şöyle düşün: Copilot app, ajan tabanlı geliştirme işleri için masaüstü odaklı bir kontrol merkezî gibi çalışıyor. Issue, pull request, arka plan oturumları ve aktif işleri — hepsini tek yerden görebiliyorsun.
Kime daha uygun?
Bunu yaşayan biri olarak söyleyeyim, Küçük ekipler de kullanabilir tabiî, hızlı başlamak için iyi bir seçenek. Ama bence asıl değer büyük, paralel çalışan kurumsal yapılarda ortaya çıkıyor. Yanı birden fazla ajanın aynı anda iş yaptığı ortamlarda farkı çok daha net hissediyorsun.
Tamamen otomatik mi çalışıyor?
Hayır, ve açıkçası iyi ki de öyle değil. İnsan onayı hâlâ kritik bir yerde dürüyor. Tecrübeme göre en sağlıklı model, ajanın üretip insanın doğruladığı hibrit yapı oluyor.
Peki ya maliyet?
Kullanım yaygınlaşırsa operasyon maliyeti dolaylı biçimde artabiliyor — mesela review süresi, eğitim ihtiyacı, süreç yönetimi gibi şeyler devreye giriyor. Bence en mantıklısı küçük başlayıp ölçmek.
Kaynaklar ve İleri Okuma
- GitHub Copilot app duyurusu — orijinal kaynak yazı
- GitHub Copilot Resmî Dokümantasyonu
- Azure DevOps Resmî Dokümantasyonu
- GitHub Copilot özellik sayfası
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder