Claude’a yazdırıp Codex’e elettirmek — iki ajanı tek bir repoda paylaştırmaya yönelik pratik iş akışı deseni

Son zamanlarda X ve Discord’da "Claude Code ile Codex’i birlikte kullanıyorum" diyen yazılar belirgin biçimde arttı; herkes çok iyi olduğunu söylüyordu, ben de gerçekten öyle mi diye yaklaşık bir ay boyunca iki aracı aynı repoya kurup çalıştırdım. Uygulamaya geçmeye kalkınca nereden başlanacağı, iki aracı çakışma olmadan nasıl paylaştırmak gerektiği, AGENTS.md ile CLAUDE.md dosyalarının aynı içerikle doldurulup doldurulamayacağı gibi kamyon dolusu karar noktası çıkıyor. Benzer kaygılar yüzünden başlayamayanların deneme-yanılma sürecini azaltabilmesi için bunu 8 bölümlük bir müfredat biçiminde düzenledim.

İkili ajan iş akışı basit. Aynı modele hem kendi kodunu yazdırıp hem de kendi kodunu inceletirseniz, kendi yazdığı varsayımları olduğu gibi kabul ettiği için boşlukları yakalayamaz. Bu yüzden yanına advisory (engelleyici olmayan) bir ikinci inceleyici model koyan bir yapı kuruyorsunuz. Claude Code ana yazar, Codex ise advisory inceleyici. Mesele hangisinin daha zeki olduğu değil, modellerin farklı olması. İkisinden biri diğerinin geçidi haline geldiği anda iş akışı bozulduğu için advisory rolünü asla engelleyiciye çevirmemek en büyük kural oluyor.

Arka plan — toparlarken yeniden fark ettiğim değişim

• Eskiden soru şuydu: "En iyi AI kodlama aracı hangisi?"
• Şimdiki soru şu: "İki veya daha fazla aracı nasıl paylaştırmalıyız?", "Bir aracın kör noktalarını başka bir araçla nasıl kapatırız?"
• Claude Code’un slash komutları ve alt ajanları, Codex’in review/exec ayrımı, AGENTS.md gibi bağlam dosyaları derken; bu ikili yapıyı iş akışına yerleştirmek ilk kez gerçekçi bir seçenek haline geldi

İkili yapı deseninin özü (bir ay kullanırken özellikle etkileyici bulduğum kısımlar)

• advisory asla engelleyici değildir — Codex CRITICAL bir sorun bulsa bile push geçer. Bir kez engelleyiciye dönüştüğünde model tarafındaki bir kesinti tüm işi durdurur ve tek bir false positive yüzünden kullanıcı --no-verify ile hook’u tamamen atlamaya başlar
• CLAUDE.md / AGENTS.md aynı içerikle doldurulmaz — yazara "nasıl yapılacağı", inceleyiciye ise "neden şüphe etmesi gerektiği" verilir. %80’den fazla örtüşüyorsa, görev paylaşımının fiilen yapılmadığının işaretidir
• codex review --base ile codex exec kullanım senaryosuna göre ayrılır — review doğrudan git’i okuyarak temiz çalışır ama büyük PR’larda token tüketimi patlar; exec ise diff’i doğrudan prompt’a koyarak maliyeti kontrol etmeyi sağlar. 100 dosyayı aşan değişikliklerde exec’e geçmek tipik bir desen
• pre-push hook için iki aşamalı secret savunma hattı — dosya desenleri (.env, *.pem, secrets/) push abort; satır içi regex’ler (sk-, ghp_, AKIA…) ise yalnızca uyarı. advisory için "never block" kuralı model çıktısı kuralıdır; secret dosyalarının push edilmesi ise ayrı bir güvenlik olayıdır, burada engelleme doğru tercihtir
• Tek bir graceful degradation sarmalayıcısıyla hepsini emmek — varsayılan JSON envelope + --raw Markdown, bash-native timeout, her zaman exit 0. Çağıran taraf sadece status’a bakıp dallanır

Bir ay kullandıktan sonra değişenler

• Merge öncesinde yakalanan hata sayısı arttı. Claude’un "iyi yazdım" diye oldukça kendinden emin olduğu yerlerde Codex’in race condition veya eksik null kontrolü yakaladığı durumlar epey sık yaşandı
• PR açtıktan sonraki gün geri dönüp "bunu neden böyle yazmışım" deme hali neredeyse kayboldu. Farklı bir bakış bir kez devreye girdiği için geriye dönük inceleme maliyeti düştü
• Kendi koduna tekrar bakmaya dayalı self-review yorgunluğu belirgin biçimde azaldı. Sanki bir insan inceleyici daha eklenmiş gibi
• Migration SQL’i veya ödeme akışı gibi geri döndürmesi zor değişikliklerden hemen önce başka bir modelin bir kez daha bakıyor olması psikolojik olarak en büyük farkı yarattı

Müfredat yapısı (8 bölüm, 5 parça)

• Part 1 iki ajanı birlikte kullanma zihniyeti · 1 bölüm — tek ajanlı yapının kör noktaları, maliyetin ne zaman haklı görülebileceği
• Part 2 ortam ve bağlam · 2 bölüm — VSCode + Claude Code + Codex CLI temel kurulumu, AGENTS.md ile CLAUDE.md görev paylaşımı
• Part 3 inceleme otomasyonu desenleri · 3 bölüm — advisory sarmalayıcı betiği, slash komutlu çok aşamalı pipeline, pre-push hook otomasyonu
• Part 4 operasyon kılavuzu · 1 bölüm — iş türüne göre araç seçim ağacı, maliyet ve model kılavuzu, Security & Privacy bölümü
• Part 5 boilerplate · 1 bölüm — kendi reponuza doğrudan kurabileceğiniz sarmalayıcı, hook ve CLAUDE.md/AGENTS.md şablonları paketi

Toparlarken aklımda kalanlar

• İkili yapının gerçek değeri, "iki aracın birbirinin geçidi haline gelmemesi". Bir kez engelleme izni verirseniz, taraflardan biri çöktüğünde iş durur; tek bir false positive’de kullanıcı hook’u tümden baypas etmeye başlar ve hook’un kendisi işlevsiz hale gelir
• AI araçları hızlandıkça belirleyici değişkenin "hangi aracı kullandığınız"dan çok "birden fazla aracın kör noktalarını nasıl üst üste bindirip kapattığınız" olduğuna dair bir his var. Tıpkı insan kod incelemesini birden fazla kişiden istememizin mantığı gibi
• AI kodlama araçlarıyla çalışırken kendi kodunuzu tekrar kendiniz incelemenin yeterince güven vermediğini hissedenler ya da Claude Code ile Codex’i birlikte kurup kurmama kararını erteleyenler için faydalı olabileceğini düşünerek paylaşıyorum. Yanlış anladığım veya hatalı toparladığım bir nokta varsa yorumlarda belirtirseniz düzeltirim.

[ajh508]

Ben trilateral-validation adını verdiğim bir doğrulama becerisini, claude subagent (fresh context) + codex + gemini’yi bile ekleyerek oluşturup kullanıyorum.
Ufak tefek hatalardan ziyade, yönün kendisini değiştirmeniz gereken deney veya tasarımlarda ana geliştirmeyi Claude ile yapıyor, doğrulamayı ise GitHub App bağladığım gpt 5.5pro’ya yaptırıyorum. (codex pro modeli desteklemediği için...)
Prodüksiyon geliştirmesi yapmıyorum, sadece araştırma yaptığım için aklıma gelmemişti ama galiba bir git hook da kurmam gerekecek.

[ku9cu]

Bunu bu şekilde yapanlar olduğu söyleniyor; nasıl bir yöntem izlediklerini merak ediyorum.
İki aracı ayrı ajanlar olarak bağlamadan, geliştiricinin ihtiyaç duydukça her birini doğrudan çağırması mı söz konusu,
yoksa Git Hook sırasında Codex’in otomatik olarak inceleme yapmasını sağlayacak bir ayar mı yapılıyor, bunu merak ediyorum.

[neostom432]

Biz ikisini de kullanma yaklaşımında karar kıldık.

Slash command akışının içine Codex çapraz inceleme aşamasını ekledik (/ship içinde planlama → uygulama → doğrulama → Codex incelemesi → raporlama şeklinde); aynı zamanda pre-push hook’a da aynı incelemeyi bağladık. Yalnızca slash command olursa acil durumlarda insanlar doğrudan push atıp incelemeyi atlayabiliyor, yalnızca hook olursa da sonuç ancak push’tan hemen önce çıktığı için geç kalıyor.

Her iki yolda da Codex CLI’ı doğrudan çağırmıyoruz; bir kez sarmaladığımız tek bir bash script’ini (codex-review.sh) iki taraftan da aynı şekilde çağırıyoruz. Bu script timeout, kimlik doğrulama kontrolü, secret kontrolü ve çıktı formatını tek bir yerde yönettiği için, ister slash command ister hook olsun, çağıran taraf temiz kalıyor.

Kilit nokta, Codex inceleme sonucuyla asla engelleme yapmamak. CLI çökmüş olsa ya da CRITICAL çıksa bile push aynen geçiyor, biz sadece sonucu yazdırıyoruz. Bunu bir kez bile engelleyici hale getirirseniz, Codex gerçekte sorun olmayan kodu yanlış işaretlediğinde kullanıcı push yapmak için hook’u atlayan seçeneği (git push --no-verify) kullanmaya başlıyor; bu alışkanlık haline gelirse, hook tanımlı olsa bile fiilen hiç çalışmıyormuş gibi bir duruma dönüşüyor. Bu yüzden engelleme gerektiren kontrolleri (lint·type·test, secret dosya push’u) ayrı gate’lere ayırıyoruz, modelin görüşünü ise yalnızca referans olarak tutuyoruz.

Script, slash command ve hook gövdesi Track 4~6 chapter’larda aynen yer alıyor; isterseniz onlara da bakabilirsiniz.