Bir sabah, kahvenin daha ilk yudumunu almadan, bir issue’ya Copilot’u atadım. Eskiden bu işte agent’ın biraz “ısınmasını” beklerdik, o arada bir kahve daha doldurulur, hatta masanın üstü toparlanırdı. Bu sefer… şey, döndüm masaya, Copilot çoktan kodu kurcalamaya başlamıştı bile. İlk anda “tesadüf” dedim. Sonra GitHub Changelog’a baktım — meğer iş ciddiydi.
İnanın, GitHub, Copilot cloud agent’ın başlangıç süresini %20 daha kısaltmış. Hem de bunu Mart ayında gelen %50’lık iyileştirmenin üstüne eklemiş. Yanı toplamda bayağı hissedilir bir fark var — Peki nasıl? Cevap aslında egzotik değil: GitHub Actions custom images. Hani bazen çözüm gözünüzün önünde durur ya, işte tam o hesap (en azından benim deneyimim böyle)
Önce şunu netleştirelim: Cloud agent ne yapıyordu da yavaştı?
Garip gelecek ama, Copilot cloud agent’ı, sizin için arkada iş yapan bir asistan gıbı düşünün. İlginç, değil mi? Bir issue atadığınızda, @copilot mention’ladığınızda ya da Agents sekmesinden görev başlattığınızda — Copilot bulutta kendine bir ortam (environment) ayarlıyor, repo’yu klonluyor, bağımlılıkları kuruyor, sonra kodu yazmaya ya da değiştirmeye geçiyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bakın, Bu sürecin en sıkıcı kısmı başlangıç. Yanı agent’ın “ben hazırım” demesi. Çünkü bir runner ayağa kalkıyor, image çekiliyor, tooling yükleniyor, cache’ler sıralanıyor… Geliştirici tarafında bunu net hissediyorsunuz: “Tamam atadım, şimdi bekleyelim.” Beklemek kötü değil. Gereksizse sınır bozuyor.
Bekleme süresi azaldıkça, Copilot ile geliştirici arasındaki geri bildirim döngüsü de kısalıyor. Bu da garip. Gerçek bir etki yaratıyor: “Bunu Copilot’a atayayım, sonra başka iş yapayım” yerine, “Bir saniye, şuna anında baksın” diyorsunuz. Akış bozulmuyor yanı. Evet, küçük fark gıbı duruyor; pratikte davranışı değiştiriyor.
Custom Actions images neden önemli?
GitHub Actions’ta runner ortamı varsayılan olarak Microsoft’un hazırladığı generic image üzerinde çalışır. ubuntu-latest, windows-latest… İçinde Node var, Python var,.NET var, Java var, Docker var, kubectl var, Azure CLI var… Liste uzayıp gidiyor. Bu “her şey dahil” yaklaşımı çoğu zaman iş görüyor ama bir yan etkisi de var: boyut (bizzat test ettim)
Evet, doğru duydunuz.
Custom images dediğimiz şey işe sizin (ya da burada GitHub’ın Copilot ekibinin) ihtiyaca göre hazırladığı, gereksiz şişkinlikten arındırılmış. Önceden hazırlanmış image’lar. Copilot için ne lazımsa o var; gerisi yok. Siz ne dersiniz? Bu sayede:
- Image pull süresi düşüyor (katmanlar küçülüyor)
- Container start süresi kısalıyor
- Sık kullanılan tooling cache’lenmiş şekilde geliyor
- Bağımlılık çözümlemesi hızlanıyor çünkü çoğu hazır geliyor
Neyse uzatmayayım: İşin sırrı rocket science değil. Klasik bir “prebuild what you can, lazy-load what you must” yaklaşımı bu. Ama bunu doğru ölçümle yapmak gerekiyor; orası biraz uğraştırıyor. Hatta bazen ilk deneme insanı ters köşeye yatırıyor.
“Cold start” dediğimiz şey aslında kullanıcı deneyiminin gizli düşmanı. Kullanıcı bekledikçe ürünü daha “yavaş” algılıyor — gerçek hızdan bağımsız olarak. Copilot ekibi galiba bunun farkına iyi varmış.
Mart’tan bu yana toplam tablo
Şöyle söyleyeyim, Kabaca hesaplayalım. Diyelim ki Mart öncesi cold start ortalama 60 saniyeydi (bu gerçek rakam değil, örnek). Mart’ta %50 iyileşme gelince 30 saniyeye düşüyor. Şimdi onun üstüne bir %20 daha eklenince yaklaşık 24 saniye oluyor. Yanı 60’tan 24’e inmiş oluyoruz. Sıradan bir backlog grooming oturumunda 10 issue açtığınızı düşünün; tasarruf 6 dakikaya kadar çıkıyor. Az gıbı mi? Günde 5 kez yapıyorsanız haftada yarım saat eder. Aylık bakınca iki saati geçiyor olabilir. Bir ekip için işe… siz devamını tahmin edin. Daha fazla bilgi için Azure Data Studio Emekli Oldu: VS Code’a 10 Dakikada Geçiş yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Türkiye’de bu hızlanma ne anlama geliyor?
Açık konuşayım: Türkiye’deki kurumsal ekiplerin çoğunda Copilot cloud agent kullanımı henüz “mainstream” değil. Logosoft’ta gördüğüm kadarıyla müşterilerin önemli kısmı Copilot’u hâlâ inline completion aracı gıbı kullanıyor — yanı IDE içinde kod tamamlama tarafında kalıyorlar. Cloud agent gıbı otonom çalışan kısımlara geçiş biraz temkinli başlıyor. “Bizim repo’da kendi kafasına ne yapacak?” sorusu hemen geliyor (kendi tecrübem)
Geçtiğimiz aylarda bir bankacılık projesinde ekipteki senior’larla bu konuyu konuştuk. Endişelerinin ana kaynağı hız değildi aslında — kontroldü. “Bekleme süresi 2 dakika da olsa 20 saniye de olsa ben sonucu review edeceğim” dediler. Haklı oldukları taraf var tabii. Ama şunu da gördüm: bekleme süresi düştükçe geliştiriciler agent’ı daha küçük ve sık görevlerle beslemeye başlıyor. Bu da review yükünü hafifletiyor çünkü her seferinde gelen değişiklik küçük kalıyor. Daha fazla bilgi için Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktik yazımıza bakabilirsiniz. Bu konuyla ilgili Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımıza da göz atmanızı tavsiye ederim.
Yanı %20’lık hızlanma sadece teknik bir iyileştirme değil — Kullanım modelini de değiştiriyor. Türkiye’deki ekipler için bu şu anlama geliyor: “Copilot’u biraz daha deneyebilirim.” Hani küçük rakamlar vardır ya, dışarıdan sönük görünür ama davranışı oynatır; işte öyle bir şey (ki bu çoğu kişinin gözünden kaçıyor)
Enterprise vs küçük ekip: Kim daha çok faydalanır?
Bence iki uçta da kazanç var ama şekli farklı:
| Senaryo | Kazanç | Dikkat Edilecek |
|---|---|---|
| Küçük ekip / Startup | Hızlı iterasyon, MVP’de daha fazla deneme | Kotanız var — agent’ı bilinçsiz kullanmayın |
| Mid-size şirket | Backlog’dan basit issue’ları toplu temizleme | Branch protection ve review policy şart |
| Bir finans kuruluşundaki müşterimiz geçen ay sadece “logging seviyesini artır” gıbı tekrarlayan basit issue’ları Copilot agent’a atmaya başladı; sonuçta PR review queue’sunda 30+ küçük PR oluştu ama hepsi beş dakikada onaylandı ve insan eli değse en az yarım gün sürecek iş bayağı kısaldı. | ||
| İşte hızlanma tam burada işe yarıyor: küçük ama çok sayıda işi akıtınca fark büyüyor. | ||
| Evet. | ||
| Aşağıdaki satırlar görseldeki yapıyı korumak için aynen bırakılmıştır. |
Kısacası, bence iki uçta da kazanç var ama farklı şekilde:
Peki custom image mantığını kendi pipeline’ınıza nasıl uygularsınız?
İnanın, Burası önemli nokta aslında. GitHub’ın Copilot için yaptığını siz de kendi Actions workflow’larınızda yapabilirsiniz. Custom Actions image’lar artık herkese açık bir özellik hâline geldi sayılır. Azure DevOps Git Policy API: 10-15 Kat Hız Geldi yazımda da söylediğim gıbı, pipeline hızlandırması bazen büyük mimarı hamlelerden değil; küçük katman optimize etmelarından geliyor. Bu konuyla ilgili Copilot Student’tan GPT-5.3-Codex Çıktı: Ne Anlama Geliyor? yazımıza da göz atmanızı tavsiye ederim.
Şunu fark ettim: Düz bir örnek vereyim — Dockerfile‘ın tarafı şöyle olabilir:
<PRIVATE_PERSON><PRIVATE_PERSON><PRIVATE_PERSON><PRIVATE_PERSON>
Cache stratejisi unutulmasın
Image custom olsa bile dependency cache’i yine önemli kalıyor.
NuGet
npm
pip ne kullanıyorsanız
Actions cache mekanizmasını boşlamayın.
yazısında anlattığım mantık burada da geçerli:
Peki bu iyileştirmenin gölgesinde kalan ne var?
Eleştirel bakmak lazım — sadece övgü dolu yazı yazmak ne size fayda eder ne bana.
Şunu söyleyeyim:
%20 hızlanma güzel
ama Copilot cloud agent’ın asıl darboğazı startup değil
Yanı agent 2 saniyede başlasa ne ölür
eğer açtığı PR’ı üç kere reddediyorsanız?
Geçen ay bir e-ticaret müşterimde Copilot agent’a “ödeme akışındaki race condition’ı düzelt” diye basit bir issue verdik.
Agent 30 saniyede başladı
güzel.
Ama düzeltme önerisi tamamen yanlıştı — semaphore koymuş ama yanlış yere.
Yanı başlangıç hızı ayrı mesele
GitHub’ın bence asıl odaklanması gereken şey
agent’ın “domain context”i daha iyi anlaması.
Hız ikinci sırada gelsin.
Bir de şu var:
%20 figüre’u marketing’e çok yakıştırılmış bir rakam gıbı geliyor bana.
Hangı senaryoda?
Ne büyüklükteki repo’da?
Hangı dilde?
Bunlar açıklanmamış.
Microsoft bu tür rakamları çok seviyor (Azure’da AI servislerinde de aynı tutum)
ama saha gerçeği her zaman benchmark’a uymuyor.
“>
yazısında da konuya benzer şekilde değinmiştim —
pazarlama ile gerçek deneyim arasında her zaman biraz boşluk oluyor.
Peki pratikte şimdi ne yapmalısınız?
Kendi deneyimimden konuşuyorum, Eğer Copilot cloud agent’ı henüz denemediyseniz ilk adımlar kabaca şöyle: (bizzat test ettim)
- Küçük başlayın:<PRIVATE_PERSON>
- <PRIVATE_PERSON>
- L
‘leri sıklaştırın: </ol&gMaliyet tarafına minicik not düşeyim: Copilot cloud agent’ın kullandığı her premium request planınızın kotasından düşüyor.
Türkiye’deki kur farkıyla düşününce
ayda kişi başı $39 olan Copilot Business planında bile dikkatli kullanım önemli.
Hızlanma “daha çok kullanırım” kapısını aralıyor
ama o kapının içinden girerken cüzdanınızı da unutmayın.
Tam da öyle.
]
Sıkça Sorulan Sorular
Copilot cloud agent’ı kullanmak için ekstra bir şey ayarlamak gerekiyor mu?
Hayır, custom image iyileştirmesi GitHub tarafında zaten otomatik devreye giriyor. Yanı sizin hiçbir şeyi değiştirmenize gerek yok. Issue’ya Copilot’u atamaya devam edin — hız farkını hemen hissediyorsunuz.
Bu hızlanma her dilde ya da repoda aynı şekilde mi çalışıyor?
Resmî olarak böyle bir kırılım açıklanmadı açıkçası. Benim gözlemime göre: küçük-orta boy Node.js,.NET ve Python repo’larında etki gerçekten çok belirgin. Ama hani çok büyük monorepo’larda startup zaten dominant darboğaz değildi — oralarda fark daha az hissediliyor.
Custom Actions images’ı kendi workflow’larımda kullanabilir mıyım?
İlginç olan şu ki, Evet, bu özellik genel kullanıma açık. GitHub Container Registry’e push ettiğiniz custom image’larınızı self-hosted runner’larınızda referans verebiliyorsunuz. İlk kurulum biraz vakit alıyor, ama tecrübeme göre uzun vadede pipeline süreleri ciddi düşüyor.
Copilot Pro kullanıcıları da bu iyileştirmeden yararlanıyor mu?
Evet, ama Copilot Pro’da cloud agent kullanımı plan kotasıyla sınırlı. Business ve Enterprise planlarda çok daha rahat kullanıyorsunuz. Ücretsiz tier’da denemek için yeterli — aslında oldukça iyi bir başlangıç — ama production iş yükü için yetmiyor.
Hızlanma sayesinde Copilot’u daha “agresif” kullanmak mantıklı mı?
Mantıklı, ama dikkatli olun. Hız arttıkça issue’ları gözü kapalı atamaya başlayanları bizzat gördüm — sonuç: review queue’da kalitesiz PR çöplüğü. Yanı hız bir araç, asıl mesele hâlâ doğru görev seçiminde. Mantıklı değil mi? Bence önce küçük, iyi tanımlanmış issue’larla başlamak en sağlıklısı.
Kaynaklar ve İleri Okuma
Konuyu biraz daha derinlemesine incelemek isteyenler için resmî ve güvenilir kaynaklar:
- GitHub Copilot Cloud Agent Resmî Dokümantasyonu
- GitHub Changelog — Copilot ve Actions güncellemeleri
- GitHub Actions Custom Images & Actions Rehberi
- GitHub Engineering Blog — Performans ve mimarı yazıları
Son söz: %20’lık bir hızlanma kulağa “of, ne büyük şey” gıbı gelebilir. Ama hani bu tür kümülatif iyileştirmeler, geliştirici deneyimini sessiz sedasız dönüştürüyor. Mart’taki %50, şimdiki %20… Bir sonraki çeyrekte bir %15 daha gelirse açıkçası şaşırmam. İşte böyle, taş üstüne taş koya koya ilerliyoruz. Hadi siz de Copilot’a bir issue atın, kahveniz soğumadan agent çalışmaya başlasın.
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.
