AI agent kullanan geliştirme ekiplerinde GitHub neden kaynak doğrusu olmalı?
AI geliştirme hızını artırdıkça local klasörler, worktree'ler, preview ortamları ve agent branch'leri çoğalıyor. Bu nedenle tek bir canonical kaynak belirlemek eskisinden daha önemli. Ben bu rolü GitHub'a veriyorum.
Tek geliştirici olsanız bile bugün aynı projede aynı anda birkaç 'çalışan' olabilir: Lovable preview, Cursor agent, Claude, Codex, local IDE ve production deploy. Bunların her biri kodun bir sürümünü görüyor olabilir. Sorun, hepsinin çok hızlı çalışması.
AI çağında kaynak doğrusu bir Git alışkanlığı değil, koordinasyon mekanizmasıdır.
Local'de çalışıyor artık yeterli bir cümle değil
Bir agent özelliği kendi worktree'sinde düzeltebilir. Başka bir agent main'den farklı bir branch açmış olabilir. Lovable farklı commit'i preview ediyor olabilir. Production ise daha eski bir hash'i çalıştırıyor olabilir. Hepsi kendi bağlamında 'doğru' olabilir.
local != worktree != preview != main != productionBu eşitsizlikleri tamamen ortadan kaldırmak mümkün değil. Ama hangi noktanın canonical olduğunu belirlemek mümkün.
Neden GitHub?
Çünkü repository yalnızca dosya deposu değil. Commit geçmişi, branch, review, issue, release ve CI aynı karar zincirinde birleşiyor. Bir değişikliğin nereden geldiğini ve nereye gittiğini takip edebiliyorum.
| Katman | GitHub'ın verdiği cevap |
|---|---|
| Kim değiştirdi? | Commit / PR geçmişi |
| Neden değişti? | PR açıklaması ve commit bağlamı |
| Ne değişti? | Diff |
| Doğrulandı mı? | Checks / review |
| Production hangi sürüm? | Deploy commit referansı |
Preflight ile başlıyorum
Agent'ın ilk görevi kod yazmak değil, doğru yerde olduğunu kanıtlamak. Özellikle birden fazla repo veya worktree varsa bu basit kontrol saatler kazandırabilir.
pwdgit remote -vgit branch --show-currentgit statusgit log -1 --onelineRepo, remote ve branch beklenen değerlerle uyuşmuyorsa değişiklik yapmaması gerektiğini prompt seviyesinde açıkça belirtiyorum.
Her agent'a kendi bağlamını veriyorum
Bir agent implementation yapıyorsa, diğeri aynı anda aynı dosyada 'iyileştirme' yapmamalı. Paralel çalışmayı dosya ve domain sınırlarıyla yönetmek gerekiyor.
const agentScope = { branch: 'feature/x', owns: ['src/domain/x/**'], readOnly: ['src/domain/auth/**'], forbidden: ['package.json'],};PR benim için agent'ın sözünü kanıta çeviren yer
Agent 'üç dosya değiştirdim' diyebilir. PR gerçek diff'i gösterir. 'Testler geçti' diyebilir. Check sonucu bunu kanıtlar veya kanıtlamaz. Bu ayrım AI ile çalışırken önem kazandı çünkü doğal dildeki rapor ile repository gerçekliği aynı şey değildir.
- PR scope dışı dosya değişikliklerini görünür yapar.
- Review ikinci bir agent veya insan tarafından bağımsız yapılabilir.
- Merge kararı implementation kararından ayrılır.
- Geri dönüş noktası açık kalır.
Main'e merge olmak production'a çıkmak değildir
Kaynak doğrusu GitHub olsa bile release kapısını ayrı tutmayı seviyorum. Özellikle mobil build, migration, mağaza yayını veya maliyetli workflow'larda merge ile deploy arasında manuel karar noktası sürprizleri azaltıyor.
const gates = [ 'implementation', 'review', 'merge', 'deploy approval', 'production verification',];Commit geçmişi gelecekteki agent'ların hafızası
İyi commit mesajı yalnızca bugünkü ekip için değil, bir ay sonra repository'yi okuyacak başka bir agent için de bağlam. 'Changes' yerine kararın niyetini anlatan küçük commit'ler, AI tarafından okunabilir bir proje hafızası oluşturuyor.
Agent sayısı arttıkça daha fazla otomasyona değil, daha net bir gerçeğe ihtiyacınız var.
Benim için o gerçek GitHub. Araçlar değişebilir. Agent'lar değişebilir. Preview ortamı değişebilir. Ama ürünün hangi koddan oluştuğu ve hangi kararların merge edildiği tek yerde izlenebilir kalmalı.
AI ile Ürün İnşa Etmek
Vibe coding'den agent orkestrasyonuna, Lovable prototipinden güvenli AI workflow'una: hız kazanırken ürün ve mimari kontrolünü kaybetmemek üzerine bir dizi.