Yani, Geçen ay İstanbul’da bir ekip toplantısındaydık ve konu tam bu noktaya geldi: “İnsanlar issue açsın, yapay zekâ kodu yazsın, PR oluştursun… ama gerçekten çalışır mı?” Açık konuşayım — ilk duyduğumda içimden “yok artık” dedim. Çünkü kâğıt üstünde her şey pırıl pırıl duruyor; pratikte ise eksik bilgi, yarım bırakılmış açıklama, aklına bile gelmeyen edge case’ler derken iş bir anda dağılıveriyor, ve siz kendinizi “tamam bu seferlik elle halledelim” derken buluyorsunuz.
Yine de Anthropic’in Claude Code için GitHub Actions tarafında sunduğu bu yaklaşımı görünce merak sardı beni. Hani bazen bir araç çıkar, bakarsın ve “tamam, bu işin iskeletini kurar” dersiniz ya — işte burada da aynen o his var. En çok da bug fix ve feature geliştirme gibi tekrar eden işlerde fena değil. Hatta doğru kurgulanırsa baya iş görüyor.
Bunu biraz açayım.
Neden bu otomasyon fikri dikkat çekiyor?
Benim gördüğüm en büyük mesele şu. Ekipler çoğu zaman işi başlatmakta değil, işi düzgün tarif etmekte zorlanıyor. Bir bug geliyor, ekran görüntüsü var ama adımlar yok. Feature isteği geliyor ama veri modeli belirsiz. Sonra geliştirici oturup yarım saat soru soruyor, karşı taraf “ya şöyle bir şey işte” diye anlatıyor, hiçbir şey netleşmiyor. İşin aslı şu ki Claude Code gibi bir ajanı devreye almanın gerçek değeri tam da burada başlıyor — işi başlamadan önce doğru çerçevelemek.
Bu akışta kullanıcı doğrudan GitHub Issue içine gerekli bilgileri giriyor. Bug ise beklenen davranış, mevcut davranış ve yeniden üretme adımları; feature ise sürücü versiyonu, veri spesifikasyonu ya da minimum gereksinimler… Yani klasik “bir bakar mısınız?” seviyesinden çıkıp daha düzenli bir talep formatına geçiyorsunuz. Kulağa küçük bir değişiklik gibi geliyor, ama fark ciddi.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Ben 2024 sonbaharında Kadıköy’de küçük bir SaaS projesinde benzer bir akışı elle kurmuştum. Orada issue metni ne kadar düzenliyse otomasyonun o kadar iyi sonuç verdiğini net gördüm. Dağınık giriş, dağınık çıktı. Çok basit bir denklem.
Claude Code’u otomasyona bağladığınızda asıl kazanç “kod yazdırmak” değil; işi baştan doğru çerçevelemek oluyor.
Akış nasıl kuruluyor?
Buradaki mantık oldukça net. Kullanıcı issue açıyor, uygun etiketi ekliyor, GitHub Actions tetikleniyor ve Claude Code’a bağlam aktarılıyor. Sonra araç ilgili değişiklikleri hazırlayıp PR oluşturuyor. Yani insan elinin girmesi gereken yer bayağı ortadan kalkmıyor — sadece tekrarlayan ilk taslak işi makineye bırakılıyor. Bence bu ayrımı sağlam tutmak şart.
İlginç olan şu ki, Bu modelde üç parça öne çıkıyor: issue şablonları, workflow dosyası. Claude Code action entegrasyonu. Her biri tek başına büyük bir olay değil gibi görünüyor… ama birlikte çalışınca sistem gerçekten nefes alıyor. Mesela küçük ekiplerde “her bug için aynı sohbeti yeniden yapmak” inanılmaz zaman yiyor — ve o zaman sessiz sedasız gidiyor, kimse fark etmiyor.
Hmm, bunu nasıl anlatsamdı…
Bir de şu var, bunu atlamamalı: Bu yapı sadece hata düzeltme için değil, küçük özellik talepleri için de kullanılabiliyor. Mesela belirli bir API sürücüsünün güncellenmesi ya da ufak bir UI davranışı eklenmesi gibi işler… Peki bunu neden söylüyorum? Çok karmaşık mimari kararları tamamen ajana bırakmak hâlâ riskli, bunu özellikle vurgulayayım.
Issue şablonları neden kritik?
Şablonlar bana göre işin sessiz kahramanı. Çünkü Claude’a ne verirseniz onu alırsınız — eksik veri verirseniz tahmin yürütür, yanlış yönlendirme verirseniz saçmalar (nazikçe söyleyeyim). Bu yüzden bug fix template içinde açıklama, beklenen davranış, yeniden üretme adımları ve hata log’u olması mantıklı. Bunlar olmadan sistem kör uçuyor.
Açık konuşayım, Bunu geçen hafta Levent’teki editör masasından bakarken tekrar düşündüm. Bir arkadaşım kendi takımında sadece serbest metin issue kullanıyordu ve AI tarafı sürekli eksik kalıyordu, hep bir şeyler atlıyordu. Sonra template’e geçti; üç haftada hem geri dönüş sayısı düştü hem de PR kalitesi toparlandı. Basit ama etkili. Bazen en sade çözüm en iyi çözüm oluyor.
Workflow neden işin omurgası?
Açık konuşayım, GitHub Actions tarafı olmasa bu sistem sadece güzel bir fikir olarak kalırdı. Workflow tetikleyicisi sayesinde etiketli veya yeniden açılmış issue’lar yakalanıyor ve Claude Code devreye giriyor. Olay tamamen manuel olmaktan çıkıyor; iş biraz bant sistemi gibi akıyor, bir sonraki adım kendiliğinden geliyor. 2600 Sayfalık Bir Dönüşüm Motoru: SEO’yu Koda Dökmek yazımızda bu konuya da değinmiştik.
Peki neden?
Ama burada ufak bir hayal kırıklığımı paylaşayım. Her şeyin otomatik olması kulağa harika geliyor — ama bazen yanlış etiketleme yüzünden istemediğiniz yerde süreç başlayabiliyor (ki bu çoğu kişinin gözünden kaçıyor). Bunu yaşadım, can sıkıcı. O yüzden label kontrolü şart. Hatta mümkünse birkaç güvenlik filtresi daha koymak iyi olur, sonradan uğraşmak yerine baştan oturtmak daha sağlıklı.
Örnek yapı taşlarına yakından bakalım
Şunu fark ettim: Aşağıdaki tabloya kabaca bakınca bile yaklaşımın mantığı anlaşılıyor: NZXT Flex Davasında 3,45 Milyon Dolarlık Uzlaşma: Ne Değişiyor? yazımızda bu konuya da değinmiştik.
| Bileşen | Ne işe yarıyor? | Şu ufak detaya bakın: nokta |
|---|---|---|
| Issue Template | Kullanıcıdan düzenli bilgi topluyor | Eksiği az olmalı |
| GitHub Actions | Süreci tetikliyor ve bağlıyor | Tetikleyici yanlış seçilmemeli |
| Claude Code Action | Kodu analiz edip değişiklik üretiyor | Araç izinleri sınırlı tutulmalı |
| PR Oluşturma Adımı | Çıktıyı incelemeye hazır hale getiriyor | Daha sonra insan onayı şart |
# Basit düşünce akışı
Issue açılır
→ Etiket kontrol edilir
→ GitHub Actions tetiklenir
→ Claude Code bağlamı okur
→ Değişiklik önerir
→ PR oluşturulur
→ İnsan gözden geçirirKüçük ekip mi, kurumsal yapı mı?
Doğrusu, Küçük ekiplerde avantaj gayet açık: hız kazanıyorsunuz. Bir startup’ta iki geliştirici varsa ve ikisi de aynı anda müşteri sorunlarını çözmeye çalışıyorsa, böyle bir otomasyon baya rahatlatıyor. Neyse, en çok da tekrar eden bug’larda insan beynini koruyan türden bir rahatlık bu — küçük görünüyor ama birikince önemli hale geliyor.
E tabi enterprise tarafta durum farklı. Orada her şey kayıt altına — itiraz edebilirsiniz tabi — alınmalı, hangi tool ne erişti bilinmeli ve secrets yönetimi titizlik ister — aksi halde sabah kahvesi boğaza dizilir. Claude Code’un yetkilerini dar tutmak burada çok önemli; aksi halde otomasyon verimli olmaktan çıkıp risk alanına kayıyor. Ve o noktadan geri dönmek çok daha pahalıya geliyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Kazanç nerede ortaya çıkıyor?
- Daha temiz issue girdisi
- Daha hızlı ilk taslak PR üretimi
- Daha az manuel tekrar
- Daha standart geliştirme dili
Bunların hepsi kulağa sıradan gelebilir. Evet, sıradan. Ama günlük operasyon içinde ciddi fark yaratıyorlar, çünkü bu küçük sürtünmeler birikerek insanı yıpratıyor. Bir dakika, şunu da ekleyeyim: en büyük kazanç bazen zamandan çok zihinsel yükün azalması oluyor. Geliştirici artık sıfırdan başlamıyor, önceki bağlamı kullanarak ilerliyor. Bu da özellikle yoğun sprint dönemlerinde, herkesin kafasının şiştiği anlarda fark yaratıyor.
Nerede iyi çalışır, nerede tökezler?
Neyse, şunu fark ettim: Açık konuşayım: bu sistem her probleme çözüm değil. Küçük düzeltmelerde ve net tanımlanmış feature taleplerinde iyi iş çıkarıyor, bunu söyleyebilirim. Ama mimari refactor, belirsiz ürün kararları ya da çapraz takım bağımlılıkları olan konularda aynı başarıyı beklemek fazla iyimser olur (inanın bana). Dur bir saniye — bunu şöyle söylemek daha doğru: araç size başlangıç sağlar, ama direksiyon hâlâ sizde olmalı. Her zaman.
Beni en çok ikna eden nokta kontrollü kullanım oldu. “Her şeyi AI halletsin” yaklaşımı değil — “tekrar eden işleri hızlandırsın” yaklaşımı. Bu çizgi korunursa sistem sağlam duruyor. Korunmazsa kısa sürede gürültüye dönüşüyor ve siz kendinizi AI’ın çıktılarını düzeltmek için daha fazla zaman harcarken buluyorsunuz, ki bu tam tersi bir etki. Peki bunu neden söylüyorum? Evet.
Bence en mantıklı kullanım senaryoları neler?
– Küçük bug fix işleri
– Net kabul kriteri olan özellikler
– Dokümantasyona dayalı düzeltmeler
– Testi kolay yazılabilen görevler
Doğrusu, Buna karşılık belirsiz ürün kararları, tasarım odaklı revizyonlar veya güvenlik açısından hassas değişiklikler için hâlâ insan müdahalesi şart. Aynen öyle. Bir ara bunu kendi yan projemde denedim; Ankara’da ev ofisimde yaptığım testte AI kodu yazdı ama kenar durumunda boş string kontrolünü atladı. Peki bunu neden söylüyorum? İşte tam orada frene bastım. Daha fazla bilgi için claude konusundaki yazımız yazımıza bakabilirsiniz.
Peki benim çıkarımım ne?
Bence bu tarz otomasyonlar yazılım dünyasında yeni normalin habercisi. Ama romantize etmeye hiç gerek yok — Claude Code mucize yaratmıyor, yalnızca iyi tanımlanmış işleri seri hale getiriyor. Ve dürüst olmak gerekirse, bu bile yeterince değerli. Çünkü birçok ekip zaten kod yazmaktan çok iletişim boşluklarını doldurmaya zaman harcıyor, ve bu sessiz sedasız akan bir kayıp. Ha bu arada, özellikle Türkçe çalışan ekiplerde issue şablonunun sade olması ekstra önemli — uzun uzun anlatılan ama hiçbir şeyi netleştirmeyen formlar kimseye yaramıyor, aksine insanları formdan soğutuyor.
Neyse uzatmayayım. Düzgün input artı kontrollü workflow artı insan onayı — gayet kullanışlı bir kombinasyon. Sonrası detay… ve biraz disiplin. Bitti.
Sıkça Sorulan Sorular
Claude Code GitHub Actions ile gerçekten tam otomatik çalışır mı?
Kendi deneyimimden konuşuyorum, Evet, belirlediğiniz tetikleyicilere göre çalışabilir. Pratikte tam otomatik yerine yarı otomatik düşünmek daha sağlıklı olur. Peki, en çok da PR öncesi insan incelemesi koyarsanız kalite ciddi biçimde artar. En azından ben böyle yapmayı tercih ederim.
Bug fix ile feature geliştirme aynı akışta yönetilebilir mi?
Evet, ayrı issue şablonlarıyla yönetilebilir.
Bug fix için yeniden üretme adımları gerekirken feature tarafında veri modeli. Sürüm bilgisi daha önemli.
Aynı workflow’u paylaşmaları sorun olmaz; yeter ki etiketleme düzgün olsun.
Küçük takımlar için bu yöntem mantıklı mı?
Bence evet.
Hatta küçük takımlar için faydası daha görünür olabilir çünkü tekrar eden işleri azaltır ve ilk taslağı hızlandırır.
Ama süreç çok gevşek kurulursa faydadan çok karmaşa yaratabilir.
O yüzden sade başlayın derim.
Claude Code ile oluşturulan PR’lar doğrudan merge edilmeli mi?
Eh, Hayır.
Doğrudan merge etmek iyi fikir değil çünkü AI bazı detayları atlayabilir veya yanlış varsayım yapabilir.
PR büyük ihtimalle kod incelemesinden geçmeli; testler de mümkünse otomatik koşmalı.
Kaynaklar ve İleri Okuma
Anthropic Claude Code Action GitHub Sayfası
GitHub Actions Resmî Dokümantasyonu
Anthropic Docs Resmî Belgeleri
Claude Code Eklenti Ekosistemi: 12.000+ Plugin Rehberi
Agentic Yapay Zekâda İz Sürmek: Monitor Et, Ölç, Kurtul
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.
