Kod üretiminin ötesi: GitHub'ın agentic engineering rehberi
GitHub, kod üretimi hızlandıkça darboğazın planlama, review ve prodüksiyon sorunlarını araştırmaya kaydığını söylüyor ve dört aşamalı bir agentic iş akışı öneriyor. Yazı, tek haftada 1,2 milyar commit ve yoğun AI kullanımında %441 uzayan review süreleri gibi çarpıcı rakamları her aşamaya denk gelen Copilot özellikleriyle eşleştiriyor.
Kilit noktalar
- GitHub, bu ekimde tek haftada 1,2 milyarın üzerinde commit ölçtü; bu bir yıl öncesine göre büyük artış ve 2025'in tamamından fazla.
- Yazıda aktarılan Faros AI araştırmasına göre AI kullanımı düşükten yükseğe geçen ekiplerde pull request'ler review'da %441 daha uzun bekliyor.
- Önerilen iş akışı dört aşamadan oluşuyor: Plan, Build, Verify ve Observe; her aşamanın kendi Copilot yüzeyi var.
- Plan Mode, Copilot implementasyona başlamadan önce yaklaşımları karşılaştırıp planı onaylamanızı sağlıyor; GitHub Agentic Workflows issue'ları otomatik etiketleyip triage edebiliyor.
- Copilot görevleri cloud sandbox'larda ve izole repo kopyalarında çalıştırıyor; session continuity aynı oturumu cihazlar ve istemciler arasında taşıyor.
- Review tarafında stacked pull request'ler, derinliği ayarlanabilen Copilot code review, AI Scan ve AI secret detection, Agentic Autofix ve Agent Merge öne çıkıyor.
GitHub'a göre kod üretimi hızlandıkça darboğaz planlama, review ve prodüksiyon sorunlarını araştırmaya kaydı. Yazı, ekimde tek haftada 1,2 milyar commit atıldığını (bir önceki yıla göre %400'den fazla artış) ve Faros AI araştırmasında AI kullanımı düşükten yükseğe geçen ekiplerde pull request'lerin review'da %441 daha uzun kaldığını aktarıyor. Önerilen çözüm, Plan, Build, Verify ve Observe aşamalarına yayılan bir agentic iş akışı.
Pratikte bu; Slack veya Teams içinde Copilot ile gereksinim toplamak, yaklaşımı netleştirmek için Plan Mode kullanmak, cloud sandbox ve oturum sürekliliğiyle görevleri arka planda sürdürmek, stacked pull request'ler ve Copilot code review ile diff'leri küçültmek, gözlemlenebilirlik araçlarına connector'larla bağlanıp release sonrası inceleme yapmak anlamına geliyor. Yazının ana tezi, artık kıt olan kaynağın yazma hızı değil, karar verme olduğu.
Gerçek dünyada kullanımı
- Tasarım dokümanı, uyumluluk notu ve eski bir pull request'in üç ayrı araçta durduğu ve önce bunların birleştirilmesi gereken bir API değişikliği.
- Review kuyruğu; mantık değişikliklerini, formatlamayı ve üretilmiş testleri tek PR'da karıştıran büyük refactor'larla tıkanmış bir ekip.
- Release'in ertesi sabahı aralıklı timeout'ları kovalayan, log, release geçmişi ve müşteri bildirimlerini eşleştiren nöbetçi geliştirici.
- Uzun agent görevlerini başlatıp toplantıdayken veya başka bir makinedeyken çalışmaya devam etmesini isteyen bir geliştirici.
Neden önemli
Zamanınız yazmaya değil review ve incelemeye gidiyorsa yalnızca üretim hızını optimize etmek sizi daha verimli yapmaz; otomatikleştirmeye değer asıl kısım kodun etrafındaki iş akışı.