Yapay Zeka Ajanları ile Pull Request İncelemesi: 6 Adımda Kurulum

Hızlı yanıt: Pull request'leri yapay zekâ ajanlarına inceletmek için inceleme görevini; kendi talimatlarına, kendi checkout'una ve mümkünse farklı bir modele sahip ikinci bir ajana devredin. Çalışma bir inceleme durumuna ulaştığında bu süreci otomatik olarak başlatın, testleri çalıştırmasını ve PASS veya CHANGES REQUIRED şeklinde bir karar bildirmesini sağlayın; başarısızlıkları ise kodu yazan ajana geri yönlendirin. Merge işlemini yine bir insan yapar.

Yapay zekâ ajanları pull request'leri neden sizden önce incelemeli?

Ajanlar tarafından yazılan her pull request eninde sonunda aynı masaya, yani sizin masanıza gelir. Bir ajan saatte bir PR gönderdiğinde bu idare edilebilir. Ancak beş ajan paralel çalıştığında, inceleme sırası diff'leri okuyabileceğinizden çok daha hızlı büyür ve ilk kontrol aşaması darboğaza dönüşür.

İlk incelemeyi bir reviewer (inceleyici) ajan üstlenir. Bu ajan sizin muhakemenizin yerini almaz. Testlerden geçemeyen, kapsam dışına çıkan veya gizli anahtarları sızdıran PR'ları eleyerek masanıza yalnızca zaman ayırmaya değer olanların ulaşmasını sağlar. Sharkly'de bunu fazladan bir Ajan ve iki Otomasyon ile kurabilirsiniz; bu rehberin geri kalanında her bir adımı ayrıntılı olarak ele alıyoruz.

Otomatik incelemenin sınırlarını önceden öğrenmek isterseniz, yapay zekâ kod inceleme ajanlarının neleri doğrulayıp neleri doğrulayamayacağına göz atabilirsiniz. Bu yazı ise doğrudan kurulumu konu alıyor.

Bir ajan kendi yazdığı kodu neden inceleyemez?

Kodu yazan ajan, o kodun arkasındaki mantık kurgusunu da kendisi oluşturmuştur. Kendi işini kontrol etmesini istediğinizde, kendi mantık yürütmesini tekrar okur ve ona hak verir. Hatayı ortaya çıkaran kör noktalar, incelemeyi yapan kör noktalarla birebir aynıdır.

Bu durumu en çok testlerde görürsünüz. Bir testi geçiremeyen geliştirici ajan (builder), assertion'ı gevşetip görevi tamamlandı olarak işaretleyebilir. Bu tür kalıpları kod yazan ajanların testlerde hile yapmasını engelleme yolları başlıklı yazımızda incelemiştik. Sonuçla kişisel bir bağı olmayan bir inceleyici ise diff'e tarafsız gözle bakar ve farklı bir soru sorar: Bu değişiklik görevde istenen şeyi yapıyor mu ve fazladan hiçbir şey içermiyor mu?

DeepSeek Harness ekibinin süper-ajanlar hakkındaki tasarım makalesi de benzer bir ayrıma dikkat çekiyor: Aynı PR'a bağlı birden fazla Çalışan (Worker) tüm olayları görür ve aralarındaki anlaşmazlıkları kendi aralarında çözebilir. Bu, nihai bir üründen ziyade bir prototip tasarımını anlatıyor olsa da ana fikir oldukça geçerli: İnceleme süreci, incelemeyi yapan taraf bağımsız olduğunda çok daha iyi çalışır.

1. Adım: Geliştirici ve inceleyiciyi ayırın

Tek bir Ajanı iki farklı modda çalıştırmak yerine iki ayrı Ajan oluşturun. Her birinin kendi talimatları, depoları (repository) ve yürütme hedefi olsun.

Sharkly Ajanlarında model seçici bulunmaz. Yürütme hedefi, bir Computer ve o Computer üzerinde tespit edilen bir Runtime'dan oluşur; dolayısıyla "farklı bir model kullanmak", inceleyiciyi farklı bir Runtime'a bağlamak anlamına gelir. İkinci bir Runtime, diff incelemesine bambaşka alışkanlıklar getirir. Sharkly token satmadığı için her çalıştırma, doğrudan o Runtime'a tanımlı plan üzerinden ücretlendirilir.

İnceleyicinin çalışma dizinini Geçici (Temporary) moduna ayarlayın. Computers dokümantasyonu, her çalıştırmanın nasıl izole bir dizin aldığını ve depo çalıştırmalarının nasıl yeni bir Git worktree hazırlayabildiğini anlatıyor. İnceleyici, PR branch'ini kendi kopyasında checkout eder ve böylece geliştiricinin dosyalarını ezemez. Bir depoyu birden fazla ajan paylaştığında bunun neden kritik olduğunu izole worktree'lerde paralel ajanlar konulu yazımızda ele almıştık.

2. Adım: İnceleyici talimatlarını yazın

Ajan talimatları; rolü, yapılacak kontrolleri ve raporlama biçimini belirler. Göreve özel detaylar ise görevin kendi üzerinde kalır. İnceleyicinin talimatlarını kısa ve test edilebilir tutun:

You are the code reviewer for this Space. You never push, merge or edit files.

1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.

İlk adım göründüğünden çok daha önemlidir. Durum tetikleyicileri ve yorum tetikleyicileri şu anda tüm Organizasyon genelinde eşleşir; bu nedenle talimatların işlem yapmadan önce görevi doğrulaması gerekir. Automations dokümantasyonu bunu açıkça belirtmektedir.

3. Adım: Tetikleyiciyi seçin

Sharkly Otomasyonları; talimatları, bir Ajanı veya Crew'u ve bir ya da birden fazla tetikleyiciyi bir araya getirir. PR incelemesi için iki tetikleyici uygundur.

Görev durumu değişikliği. Space iş akışınıza "In Review" gibi bir durum ekleyin. Kodu yazan ajan PR'ı açtıktan sonra görevini bu duruma taşır ve inceleyici çalışmaya başlar. Durum tetiklemeli bir çalıştırma, ilgili görev üzerinde bir konuşma başlatır; böylece karar ve harcanan token miktarı doğrudan işe bağlı kalır.

Bu ekran görüntüsü, bu blogun kendi taslaklarında uyguladığı kontrol mekanizmasıdır: Bir görev Ready for Release aşamasına ulaştığında bir inceleyici Ajan görevi devralır. Kod için de mantık tamamen aynıdır.

Webhook. PR'lar görev panonuzun dışından açılıyorsa bir GitHub pull_request webhook'unu bir Otomasyonun webhook URL'sine yönlendirin. İmza doğrulaması açıkken Sharkly, GitHub'ın X-Hub-Signature-256 başlığını da kabul eder; bu sayede imzalama gizli anahtarını GitHub'ın Secret alanına yapıştırmanız yeterlidir. Webhook çalıştırmaları bir göreve bağlı olmadığından inceleyici, kararını GitHub CLI aracılığıyla doğrudan PR'ın kendisine yorum olarak bırakır.

Sisteme güvenmeden önce her iki yöntemi de Run now ile test edin.

4. Adım: İnceleyiciye bir kontrol listesi verin

Kontrol listesi olmayan bir inceleyici uzun makaleler yazar. Bir listesi olduğunda ise doğrudan bulguları sıralar. Beş soru, ajan PR'larının büyük kısmını karşılar:

1. Testler çalışıyor ve geçiyor mu? İnceleyici, kodu yazan ajanın özetine asla güvenmeden testleri bizzat kendisi çalıştırır.
2. Kapsama sadık kalındı mı? Görev dışındaki dosyalara dokunulması, değişiklik zararsız görünse bile bir bulgudur.
3. Açığa çıkan bir gizli bilgi var mı? Diff'te veya log'larda yer alan token'lar, anahtarlar ve .env değerleri.
4. Kodu çağıran yerler için kırıcı bir değişiklik oldu mu? Değişen imzalar, kaldırılan endpoint'ler, geri alma adımı olmayan veritabanı migrasyonları.
5. Testler gevşetildi mi? Silinen assertion'lar, yeni eklenen skip'ler veya esnetilen beklenen değerler.

Birden fazla inceleyici Ajan bunu paylaşıyorsa listeyi bir Skill içinde tutun; böylece tek bir güncelleme hepsine yansır.

5. Adım: Karar formatını sabitleyin

Bir insanın on saniyede göz gezdirebileceği net bir karar, okunmadan geçilen ayrıntılı bir rapordan çok daha değerlidir. Sabit bir şablon kullanın:

VERDICT: CHANGES REQUIRED

Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none

Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.

PASS kararı da aynı alanlara ve boş bir Required listesine sahiptir. Sabit alanlar kararların ölçülebilmesini de sağlar: Hangi kontrolün ne sıklıkla başarısız olduğunu görebilir ve geliştirici ajanın talimatlarını buna göre sıkılaştırabilirsiniz.

6. Adım: Döngüyü geliştirici ajana geri bağlayın

CHANGES REQUIRED kararı, sizin araya girmenize gerek kalmadan geliştirici ajanı yeniden tetiklemelidir. Geliştirici Ajana atanmış ve belirli bir ifadeye duyarlı yorum tetikleyicisi içeren ikinci bir Otomasyon oluşturun.

Yorum eşleme büyük/küçük harfe duyarsızdır ve ifade yorumun herhangi bir yerinde geçtiğinde tetiklenir. Kimsenin kazara yazmayacağı bir ifade seçin ve inceleyiciye bu ifadeyi yalnızca CHANGES REQUIRED satırında yazmasını söyleyin. Geliştirici ajan bu ifadeyi kendi yanıtında aynen tekrarlarsa kendi kendini tetikleyebilir; bu yüzden bu ifadeyi asla tekrarlamamasını tembihleyin.

Döngüye bir sınır koyun. İki tur inceleme ve düzeltmenin ardından inceleyici, son kararı ekleyerek görevi bir insana devreder.

İnsanın sorumluluğunda kalanlar

Merge yetkisi hâlâ sizdedir. Sharkly'nin GitHub entegrasyonunda, PR başlığındaki görev kimliği PR'ı göreve bağlar ve merge işlemi görev durumunu değiştirmez. Hiçbir kod bir ajan PASS dedi diye canlıya alınmaz.

Bunu GitHub tarafında da destekleyin: İnsan onayını zorunlu kılan korumalı branch'ler (protected branches), kendine fazla güvenen bir inceleyicinin son savunma hattına dönüşmesini engeller. Ayrıca bir kontrol listesinin veremeyeceği kritik kararlar da sizdedir: Bu doğru bir tasarım mı ve bu değişikliğe gerçekten ihtiyaç var mı? Önünüze gelen işleri önceliklendirmenin bir yolu için ajan PR kuyruğunu sıralama ve insan incelemesinin neden darboğaz oluşturduğu yazılarına göz atabilirsiniz.

Sonuç

İlk incelemeyi ikinci bir ajan üstlendiğinde, ajan PR'ları üzerinizde birikmeyi bırakır. Geliştirici ve inceleyiciyi ayırın, inceleyiciye kendi worktree'sini ve Runtime'ını verin, bunu bir durum değişikliği veya webhook ile başlatın ve sabit bir formatta beş net soruyu yanıtlamasını sağlayın. Hataları belirli bir yorum ifadesiyle geri gönderin, döngüyü iki turla sınırlayın ve merge yetkisini kendinizde tutun.

Zaten aynı anda on kodlama ajanını çalıştırıyorsanız, eklemeniz gereken bir sonraki parça budur. Sharkly'de ücretsiz başlayın ve işe ilk olarak inceleyici Ajanı oluşturarak koyulun.

SSS

Bir yapay zekâ ajanı kendi pull request'ini inceleyebilir mi?

İnceleyebilir, ancak çok daha az şey yakalar. Ajan, kodu ortaya çıkaran varsayımların aynısını paylaşır. Kendi talimatlarına ve ideal olarak farklı bir Runtime'a sahip bağımsız bir inceleyici, diff'i bu ön yargı olmadan okur.

İnceleyici, geliştiriciden farklı bir model mi kullanmalı?

Mümkün olduğunda evet. Sharkly'de model Runtime'dan gelir; bu nedenle inceleyici Ajanı, geliştiriciden farklı bir Runtime'a bağlayın; örneğin Claude Code'un çalışmasını Codex'in incelemesi gibi.

Yapay zekâ kod inceleyicisi ilk olarak neyi kontrol etmeli?

Testleri. Test paketini bizzat çalıştırmasını, geçen ve kalan test sayılarını raporlamasını sağlayın. Ardından sırasıyla kapsamı, gizli bilgileri, kırıcı değişiklikleri ve gevşetilen testleri kontrol ettirin.

Bir inceleyici ajan PR'ı onaylayıp merge edebilir mi?

Buna izin vermeyin. Branch koruması ile merge yetkisini insanlarda tutun. İnceleyici bir karar bildirir; kararı ise insan verir.

İnceleme döngüsünün sonsuza kadar sürmesini nasıl engellerim?

İnceleyicinin talimatlarında döngüyü iki turla sınırlandırın ve geliştiricinin asla tekrarlamayacağı özel bir yorum ifadesi kullanın. Bu sınır aşıldığında inceleyici görevi bir insana devreder.

Bu yöntem Sharkly dışından açılan GitHub pull request'lerinde de çalışır mı?

Evet. Bir GitHub webhook'unu bir Otomasyonun webhook tetikleyicisine bağlayın. Doğrulama açıkken Sharkly, GitHub'ın imza başlığını kabul eder.