Sıfır İnsan Dokunuşu: Jira Ticket’larından Bitbucket Pull Request’lerine

Basit ama iddialı bir soruya cevap bulmak istedik: Küçük ve iyi tanımlanmış bir değişikliği yayına almak için gereken tek insan eylemi bir Jira ticket’ı açmak olsaydı ne olurdu? Onu üstlenen bir geliştirici yok, kodu yazan kimse yok, test etmeyi hatırlaması gereken kimse yok; sadece bir ticket giriyor ve diğer uçtan, bir insanın inceleyip merge etmesine hazır bir pull request çıkıyor.

Biz de bunu inşa ettik ve ardından en bariz alternatife karşı gerçekten ayakta kalıp kalmadığını test ettik: aynı şeyi editörünün içinde doğrudan Claude kullanarak geliştiren bir geliştirici.

1. Sistem Mimarisi: Otonom Döngü

Sıfır insan dokunuşlu bir sistemi güvenilir kılmak için her şeyi tek seferde yapmaya çalışan tek bir LLM prompt’una güvenemezsiniz. Bağlam penceresi çalıştırma loglarıyla şiştikçe halüsinasyonlar hızla birikir.

Bunun yerine modüler, duruma dayalı (state-driven) çoklu agent mimarisi kurduk.

Pipeline nasıl çalışıyor:

Sistem, bir ticket’ın durumu “Ready for AI development” olarak değiştiği anda tetiklenir. Oradan itibaren hiçbir insan müdahalesi olmadan dört aşamadan geçer:

Aşama 1: Planlama

Tek satır kod yazılmadan önce kod tabanı incelenir ve bir plan oluşturulur: seçilen yaklaşım, yapılacak değişikliklerin adım adım dökümü, dikkat edilmesi gereken riskler ve doğrudan ticket’tan türetilen, somut ve kontrol edilebilir kabul kriterleri. Bu son kısım göründüğünden daha önemli: belirsiz bir ticket açıklamasını, göz kararı bakmak yerine bir makinenin daha sonra nesnel olarak doğrulayabileceği bir şeye dönüştüren şey tam olarak budur.

Aşama 2: Uygulama

Ayrı bir AI agent planı alır ve gerçek kodu yazar. Değişiklik tamamlandığında sonucu kendine ayrılmış bir branch’e commit eder.

Aşama 3: Bağımsız Doğrulama

Asıl işi yapan aşamanın bu olduğunu düşünüyoruz. Uygulayıcının tercihlerini neden yaptığını hiç görmeyen ayrı bir süreç, planın kabul kriterlerine göre gerçek, çalıştırılabilir testler yazar ve bunları gerçek koda karşı çalıştırır. Arayüzle ilgili değişikliklerde bu, kodu okuyup çalıştığını varsaymak değil; gerçek bir tarayıcıyı gerçek tıklamalarla yönetmek ve ortaya çıkan gerçek durumu kontrol etmek demektir.

Aşama 4: Hedefli düzeltme (gerekirse)

Doğrulama bir şeyi reddederse, dar yetkili bir aşama yalnızca işaretlenen sorunu düzeltir; alakasız temizlik yok, yaklaşımı baştan tasarlamak yok. Ardından sonuç yeniden doğrulamadan geçer. Bu döngü sabit bir tur sayısıyla sınırlıdır; böylece gerçekten tıkanmış bir ticket sonsuza kadar kaynak tüketmek yerine açıkça başarısız olur.

Her şey geçtiğinde otomatik olarak bir pull request açılır, ticket güncellenir ve ticket’ı açan kişiye bildirim gider. Merge konusunda son kararı yine bir insan verir. Pipeline’ın görevi insanları döngüden tamamen çıkarmak değil, önlerine incelenebilir bir sonuç koymaktır.

2. Teste Tabi Tutmak

Bu sistemin gerçek bir kaldıraç sağlayıp sağlamadığını değerlendirmek için onu, AI kullanan bir geliştiricinin standart iş akışıyla kıyasladık.

Görev: Sürükle-bırak sütunları, kart sıralaması ve kalıcı durum güncellemeleri olan bir Kanban board özelliği geliştirmek.

İki yaklaşımı karşılaştırdık:

1. Tamamen Otomatik Pipeline: Jira ticket tetikleyicisi -> Otonom çoklu agent pipeline’ı -> Bitbucket PR.
2. Etkileşimli Geliştirici Oturumu: Editör içi bir AI agent (Claude Code / Cursor) kullanan bir geliştirici; planlama, uygulama, doğrulama ve düzeltme için aynı prompt’ları adım adım elle kullanıyor.

Tamamen otomatik tarafta tek bir çalıştırmayla yetinmedik. Birebir aynı pipeline’ı, birebir aynı ticket’a karşı iki kez çalıştırdık: bir kez Claude Sonnet 5, bir kez de Claude Haiku 4.5 ile. Bunu özellikle, geri kalanı tamamen aynı olan bir süreçte alttaki modeli değiştirdiğinizde gerçekte neyin değiştiğini görmek için yaptık. Etkileşimli oturumda Claude Sonnet 5 kullandık.

Bulduklarımız şunlar:

Metriklerin Dökümü

Planlama ve uygulama, etkileşimli oturumda biraz daha yavaştı ama dramatik bir fark yoktu.

Sonra doğrulama aşaması geliyor ve tüm karşılaştırmanın şekli değişiyor. Etkileşimli oturum, doğrulama ve düzeltmeye diğer tüm adımların toplamından çok daha fazla zaman harcadı. Buna karşılık iki otomatik çalıştırma da kendi işlerini kontrol etmeyi, etkileşimli oturumun kodu yazmayı bitirmesinden bile daha hızlı tamamladı.

İki yaklaşım da çalışan kod üretti. Hiçbiri belirtilen gereksinimlere göre gerçekten bozuk değildi. Ancak pürüzleri bulma şeklimiz farklıydı.

Bulduklarımıza geçmeden önce, üçünün de ortaya ne çıkardığına bakalım:

Otomatik pipeline çalıştırması (Claude Sonnet 5)

Otomatik pipeline çalıştırması (Claude Haiku 4.5)

Etkileşimli (editör tabanlı) uygulama

İlk bakışta üçü de kullanılabilir bir Kanban board gibi görünüyor: etiketli üç sütun, görev kartları; genel yapı üçünde de doğru. Farklar ancak onları gerçekten kullanmaya başladığınızda ortaya çıkıyor.

1. Otomatik Pipeline Çalıştırması (Claude Haiku 4.5)

Takılı Kalan Hover Durumu:

Sütunlar, imleç başka bir sütuna geçtikten sonra bile bazen hover edilmiş ya da seçili görünmeye devam ediyordu. Ticket’ları taşırken zaman zaman hem başlangıç sütunu hem de yeni hedef sütun aynı anda vurgulanmış görünüyordu; aşağıda görebilirsiniz:

Muhtemel neden: hover/active class’ı mouse-enter’da ekleniyor, ancak mouse-leave’de güvenilir şekilde kaldırılmıyordu.

Yük Altında Layout Hatası:

Bunu, layout’un gerçekten aşırı yüklendiğinde nasıl davrandığını görmek için bir sütuna bilerek 15–20 görev yükleyip diğer sütunları görece boş bırakarak test ettik. O tek sütunun kendi başına uzaması ya da kaydırılabilir olması yerine üç sütun birlikte yeniden boyutlandı.

Bunlardan hangisinin gerçekten hata olduğu konusunda net olmakta fayda var. Takılı kalan hover durumu gerçek bir aksaklık; istenmeyen bir davranış ve her seferinde tekrarlanabiliyor.

Sütunların yeniden boyutlanması ise farklı: hiçbir şey bozulmadı ya da hata vermedi, kod tam olarak yazıldığı şeyi yaptı. Bunu bir kusurdan çok bir tasarım kararı olarak tanımlamak daha doğru; boyutlandırmayı kolay varsayılan olarak üç sütun arasında paylaştırmak. Yanlış değil, sadece iyi bir tercih değil. Bu yüzden onu “hata” değil, “tasarım kusuru” olarak kabul etmek gerekir.

2. Etkileşimli Oturum (İnsan + Editörde Sonnet 5)

Bırakma Alanının Hizalama Sorunu:

Bu sorun, kartları normal şekilde sürükleyip bırakma alanlarına dikkat ederken ortaya çıktı. Görmek biraz zor ama “In Progress” sütununa dikkatli bakarsanız arkasında vurgulanmış küçük mavi bir alan görebilirsiniz. Bu alan, kullanıcı başka bir sütundan bir ticket sürüklemeye çalıştığında, ticket’ın taşınmış sayılması için bırakılması gereken yeri göstermek üzere beliriyor. Sütunda zaten ticket’lar varsa bırakma alanı göstergesini görmek gerçekten zorlaşıyor: alan, kabaca mevcut ticket kartlarının toplamı kadar büyük olduğu için mevcut ticket’lar, yeni bir kartın nereye bırakılabileceğini gösterecek alanı görsel olarak örtüyor.

Dar Etkileşim Sınırları:

Bu sürümü test ederken edindiğim deneyime göre ikinci bir eleştiri de şu: geçerli bırakma hedefini gösteren mavi alan, aşağıdaki görselde görebileceğiniz gibi sütunun görünen gerçek sınırlarından belirgin şekilde daha küçüktü:

Yani bu da aslında bir hata değil, bir karar kusuru. Daha iyi tercih, bırakma hedefini küçük bir iç alanla sınırlamak yerine tüm sütunu geçerli bir bırakma hedefi yapmak olurdu. Mevcut hâliyle board’u kullanmak olması gerekenden daha zahmetli; etkileşim teknik olarak çalışıyor, sadece kullanıcıdan daha fazla hassasiyet bekliyor.

3. Otomatik Pipeline Çalıştırması (Claude Sonnet 5)

Kusursuz Sonuç:

Diğer iki bölüm çoğunlukla nelerin ters gittiğiyle ilgili olduğu için açıkça belirtmekte fayda var: Sonnet 5 ile yapılan otomatik çalıştırmada bu sorunların hiçbiri yoktu. Hover durumu denediğimiz her etkileşimde doğru davrandı. Layout, Haiku’nun çalıştırmasını bozan aynı aşırı yüklenmiş sütun testinde düzgün şekilde ayakta kaldı. Bırakma alanı hâlâ tüm sütunu kapsamıyor olsa da her zaman görünürdü ve boyutu doğruydu.

Sonuç Özeti

Bunların hiçbiri zor bir görev değildi; sürükle-bırak bir Kanban board mütevazı bir istek. Bu da üç yaklaşımın da sonunda eleştirilecek bir şey ortaya çıkarmasını daha dikkat çekici kılıyor. Not etmekte fayda var: buradaki her doğrulayıcının Playwright’a ve gerçek bir Chromium tarayıcıya erişimi vardı ve yalnızca hataları kontrol etmesi değil, görsel olarak test etmesi de açıkça istenmişti.

Bu da etkileşimli oturumdaki bırakma alanı sorununu daha belirgin kılıyor: doğrulamaya açık ara en fazla zamanı harcamasına rağmen bu görsel sorun yine de gözden kaçtı. Yine de hiçbir yerde gerçek, endişe verici bir hata yoktu; hiçbir şey bozulmadı ya da normal kullanımı engellemedi.

Burada açık ara kazanan Sonnet’in otomatik çalıştırmasıydı: hiçbir sorun yoktu ve hem kalitede hem de sürede etkileşimli oturumu geride bıraktı. Haiku’nun otomatik çalıştırmasında gerçek sorunlar vardı ama tamamen görseldi; board baştan sona tamamen kullanılabilir kaldı. Haiku, Sonnet 5’ten daha zayıf bir model olduğu için bu anlaşılabilir.

3. Temel Çıkarımlar ve Mühendislik Dersleri

Arka Planda Çalışan Pipeline’lar Mühendisin Rolünü Değiştiriyor

İnsanı tamamen devreden çıkarmanın mümkün olduğunu kanıtlamaya çalışmıyorduk bile. Son aşamanın kendi pull request’ini merge etmesine izin vermek oldukça kolay olurdu; mimaride buna engel olan hiçbir şey yok. Bunu bilerek yapmadık.

Nedeni yukarıdaki sonuçlar bölümünde duruyor. Haiku’nun çalıştırmasında takılı kalan bir hover durumu ve yük altında yanlış boyutlanan bir layout vardı. Bunların hiçbiri bir testi bozmadı, hiçbiri bir kabul kriterinden kalmadı ve hiçbiri tamamen otonom bir pipeline’ın kendi işini merge edip ticket’ı tamamlandı olarak işaretlemesine engel olmazdı. “Bu teknik olarak çalışıyor ama ben bunu yayına almazdım” dedirten şeyi yakalayan hâlâ gerçek PR’a bakan bir insan ve şu an bu pipeline’daki hiçbir şey bu kararı kendi başına veremiyor. Bu yüzden merge butonu bir insan kararı olarak kalıyor.

Pipeline’ın değiştirdiği şey, o insan muhakemesinin nereye harcandığı.

• O noktaya kadar sıfır aktif geliştirici zamanı. Geliştirici ticket’ı açıp başka işlere geçiyor; kod onun makinesinde ya da onun mesaisinde yazılmıyor.
• Her seferinde eksiksiz uygulama. Doğrulama ve test yazımı, o gün ticket’ın kimde olduğuna ya da o kişinin başka ne kadar işi olduğuna bağlı değil.
• İnceleme bir kez, en sonda, bitmiş bir iş üzerinde yapılıyor. Mühendisin işle ilk gerçek teması, satır satır yönlendirdiği yarım kalmış bir diff değil; tamamlanmış ve test edilmiş bir pull request.

Geliştirici bu döngüden kaybolmuyor. Sadece montaj hattını işleten kişi olmayı bırakıp, hattan çıkan ürünün yeterince iyi olup olmadığına karar veren kişi oluyor.

Peki, en baştaki soruya dönelim: Bir ticket açmak gerçekten gereken tek insan eylemi olabilir mi? Neredeyse. Pull request’i hâlâ bir insan inceliyor ve merge edip etmemeye o karar veriyor; bu kararın da tam olarak orada kalması gerektiğini düşünüyoruz. Ama o noktaya kadarki her şey, baştan sona, kimse izlemeden çalıştı.