Claude ve Codex İçin Eşli Programlama, Kopyala-Yapıştır Olmadan

Son birkaç aydır geliştirme iş akışım şöyle görünüyordu: Claude Code ve Codex’i yan yana çalıştırıyordum. Aynı prompt, aynı hedef, ikisi de kod tabanını bağımsız olarak inceliyor. Planlama zamanı geldiğinde Claude planı hazırlıyor, ben de Codex’e kopyalayıp incelemesini istiyordum. Codex, Claude’un kaçırdığı şeyleri yakalıyordu — edge case’ler, yanlış varsayımlar, gözden kaçan dosyalar. Bulguları geri aktarıyor, Claude’un revize etmesini sağlıyor, revizyonu tekrar Codex’e kopyalıyor, ikisi de anlaşana kadar döngüyü devam ettiriyordum. Bazen önceki turdan değişiklikleri stage’e alıyordum ki Codex diff’leri daha net görebilsin. Sonra da kendim sonucu gözden geçiriyordum.

Gerçekten iyi çalışıyordu. İki model farklı şeyleri yakalıyor. Claude sentez ve iletişimde daha iyi. Codex daha dikkatli okuyor — kod yollarını takip ediyor, edge case’leri kontrol ediyor, erken “bitti” demiyor. Bağımsız araştırma yapıyorlar ve sonuçları daha iyi yapan tam olarak bu.

Ama aradaki aktarım berbattı.

Linkler kopuyordu, biçimlendirme bozuluyordu — ama asıl sorun bunlar değildi. Asıl sorun her aktarımın hâlâ bana bağımlı olmasıydı. Çıktıyı kopyala, diğer oturuma yapıştır, bekle, geri kopyala, tekrar yapıştır. Dikkatim döngünün içinde takılı kalıyordu, oysa çok daha faydalı bir yerde olabilirdi. Asıl acı buydu — bensiz ilerleyemeyen bir iş akışı.

İş akışının kendisini değiştirmek istemiyordum. Sadece insan mesaj taşıyıcısı olmayı bırakmak istiyordum.

Her Şeyi Doğrulayan Harness Makalesi

Sonra Anthropic’in Harness design for long-running application development makalesine denk geldim, bir YouTube videosunda bahsediliyordu. Baştan sona okudum ve makale aynı anda iki şey yaptı.

Birincisi, zaten deneyimlediğim şeyi doğruladı: ayrı bir oturumun, çalışmayı bağımsız olarak doğrulaması — onu inşa etmenin getirdiği çıpalama etkisi olmadan — daha iyi sonuçlar veriyor. Claude ve Codex ile tam olarak gördüğüm buydu.

İkincisi, o deneyimi daha net bir sisteme dönüştürdü. Daha çok “farklı model” kısmına odaklanmıştım. Makale “bağımsız değerlendirici” kısmını çok daha açık hale getirdi. Yeterince bağımsızsa başka bir Claude oturumu bile işe yarıyor. Ayrılığın kendisi taşıyıcı bir unsur.

Ve aslında mantıklı: orijinal oturum kodu hatalı olduğunu düşünseydi, zaten öyle yazmazdı. Bu, eşli programlamanın her zaman sağladığı faydanın aynısı — ikinci bir çift göz, yazarın beyninin filtrelediği şeyleri yakalar. Bu LLM’ler bu konuda bizden çok farklı değil.

Deneyimle doğrulanıp araştırmayla netleşen bu kombinasyon — işte tam o an oturdu. Bu sadece benim çalışma tarzımdaki kişisel bir tercih değildi. Genel olarak faydalı görünüyordu. İş akışını düzgün bir plugin’e dönüştürdüm ve adını TandemKit koydum.

Gerçekten Çözülmesi Gereken Koordinasyon Problemi

İlk tasarımımda dört üst düzey oturum vardı: Planner, Generator ve iki Evaluator — biri Claude, biri Codex. Düz metin dosyaları üzerinden koordine oluyorlardı. Bir oturum bittiğinde sync dosyasına yazıyor, diğeri arka planda o dosya değişene kadar bekliyordu. Claude’da kusursuz çalıştı. Ama Codex bir türlü güvenilir şekilde beklemiyordu. Ne denediysem — farklı dosya izleme yaklaşımları, farklı sinyal mekanizmaları — Codex ya sırasının geldiğini kaçırıyordu ya da beklemeyi tamamen atlıyordu.

Bunun için beşinci ya da altıncı geçici çözümümdeydim ki OpenAI’ın Claude Code için resmi bir Codex plugin’i çıkardığını keşfettim — codex-plugin-cc. Claude artık Codex’i dahili olarak çağırabilir, yanıtını görebilir ve aynı Codex oturumunu daha sonra devam ettirebilirdi. Tam da ihtiyacım olan şey.

Bu, Claude-Codex alışverişini görünmez yapmadı. Her şey hâlâ TandemKit/ altındaki markdown dosyalarına yazılıyor, her tur için bir dosya. Tam görev geçmişi diskte kalıyor — her araştırma, her yakınsama alışverişi, her değerlendirme kararı.

O arşiv de işe yarıyor. Haftalar sonra garip bir şey ortaya çıktığında, git geçmişi sadece commit mesajı vermiyor — commit’in arkasındaki tüm konuşmayı veriyor, böylece bir kararın neden verildiğini gerçekten araştırabiliyorsun. İş akışının kendisini geliştirmek için de harika: eski görevleri okumak, bir kuralın AGENTS.md‘ye veya yerel bir skill’e ait olduğunu fark etmenin genellikle en hızlı yolu.

Değişen kısım tesisattı. Kırılgan bir dördüncü terminali idare etmek yerine, TandemKit artık codex-plugin-cc üzerinden tek bir kalıcı Codex alt ajanını talep üzerine çağırıyor ve bağımsız bir geçiş gerektiğinde onu devam ettiriyor.

Görev (Mission) Aslında Nedir

Yaklaşık bir yıldır her gün yapay zeka ajanları kullanıyorum ve görev, sürekli vardığım iş boyutu: ayrı planlama, üretim ve değerlendirmeden fayda görecek kadar büyük, ama tamamının tek bir oturum setinde uygulanıp tamamen doğrulanabilecek kadar küçük.

Eğer iş bundan küçükse — hızlı bir tek dosya düzeltmesi, küçük bir refactor, basit bir yeniden adlandırma — doğrudan Claude Code kullanıyorum. TandemKit’in çok oturumlu döngüsü, bu tür değişikliklerin hak ettiğinden daha fazla token ve seremoni kullanıyor.

Eğer iş bundan büyükse, başlamadan önce bölüyorum. PlanKit tam burada doğal olarak devreye giriyor: fikirleri Ideas → Roadmap → Features → Missions aşamalarından geçiriyor. Bir şey “mission” aşamasına geldiğinde artık belirsiz bir özellik paketi değil — zaten oturum boyutunda bir iş parçasına şekillendirilmiş durumda.

Pratikte Yakın Zamanlı Bir Görev

Yapay zeka destekli uygulama yerelleştirme aracım TranslateKit’e App Store Connect yerelleştirme desteği eklemek istiyordum. Fikir basitti: App Store Connect’te uygulama meta verilerini manuel yönetmek yerine, geliştiriciler tüm yerelleştirmeler için isimleri, alt başlıkları, açıklamaları ve anahtar kelimeleri doğrudan TranslateKit içinde düzenleyebilecekti — Apple’ın API’si üzerinden senkronize edilerek.

Tek bir görev için fazla büyüktü. İkiye böldüm: biri App Store Connect API bağlantısı için — JWT kimlik doğrulama, kimlik bilgisi yönetimi, meta veri çekme, meta veri güncelleme — diğeri tüm bunları uygulamada görünür kılmak için gereken UI değişiklikleri. Önce veri katmanı, sonra UX katmanı.

Planlama sırasında Claude ve Codex, düşünmediğim edge case’leri ortaya çıkardı. Örneğin: kullanıcı yeni bir dil eklemek istiyorsa ama henüz yeni bir App Store Connect sürümü yoksa ne olacak? Yayınlanmış sürümler düzenlenemez, bu yüzden sistem karar vermeli — değişiklikleri yerel olarak önbelleğe al, kullanıcıdan önce sürüm oluşturmasını iste, ya da platformlar arası otomatik oluşturmayı teklif et.

Ve TandemKit yeni bir sürüm oluşturuyorsa, hangi numara olmalı? Geçmişe bakıp tahmin mi etsin? Kullanıcıdan yazmasını mı istesin? Yaygın sonraki sürüm seçenekleri mi sunsun? Bunlar ürün kararları, uygulama detayları değil ve herhangi bir kod yazılmadan önce spec’te yer almalı.

API görevinin değerlendirmesinde Claude başlangıçta özelliği geçti olarak işaretledi çünkü mutlu yol çalışıyordu ve mevcut sürüm testleri yeşildi. Codex daha az belirgin dalı takip etti ve asıl boşluğu buldu: düzenlenebilir bir App Store Connect sürümü henüz yokken, kod yeni sürüm kaydını oluşturuyordu ama aynı akışta yerelleştirme yazma işlemini yeniden denemiyordu. Böylece “yeni dil” yolu, kullanıcı tekrar senkronizasyon yapana kadar sessizce hiçbir şey yapmadan başarılı görünüyordu — tam olarak ikinci bir modelin yakaladığı türden bir kod yolu bug’ı.

Düzeltme küçüktü: sürüm oluşturulduktan sonra yazma işlemini yeniden dene, o dal için testler ekle. Ama ikinci geçiş olmadan gözden kaçacaktı.

Üç Oturum, Otonom Döngü

SEN  -- planlama
  |
  `--> [1] Planner Session
             Claude ---------> Codex (arka plan)
              |    <- bulgular  - |
              `---- yakınsama ----┘
                         |
                      Spec.md  <-- devam etmeden önce sen onaylarsın

SEN  -- iki oturumu da başlat, sonra uzaklaş
  |
  |--> [2] Generator Session
  |          Spec.md'ye göre uygular
  |          dönüm noktalarında commit atar
  |
  `--> [3] Evaluator Session
             Claude ---------> Codex (arka plan)
              |    <- bulgular  - |
              `---- yakınsama ----┘
                         |
                 FAIL -> Generator düzeltir -> döngü
                 PASS -> İnceleme Brifingi -> sen

Planner tek etkileşimli adım. Spec.md’yi onayladıktan sonra Generator ve Evaluator, ya düzeltilecek bir FAIL ya da inceleme brifingiyle bir PASS alana kadar kendi başlarına çalışıyor.

Claude ve Codex Nasıl Anlaşıyor

Buradaki bariz hamle puanlama: iki model de çalışmayı puanlar, puanları ortalar, eşiğin üstündeyse geçer. Ama puanlar başarısızlıkları gizler. 8/10, iki kritik kriterin tamamen başarısız olup geri kalanının iyi olduğu anlamına gelebilir.

Bu yüzden TandemKit kriter kriter değerlendiriyor. Her bulguya iki boyut ekleniyor:

• Anlaşma düzeyi: agreed, partially agreed veya disputed

• Önem düzeyi: HIGH, MEDIUM veya LOW

Claude ve Codex bağımsız araştırma yapıp bulgularını dosyalara yazıyor. Sonra Claude, Codex’in bulduklarını okuyor, birleştirilmiş bir değerlendirme oluşturuyor — hemfikir olduklarını koruyor, farklı düşündüğü yerleri açıklıyor — ve Codex o birleştirmeyi inceliyor. Herhangi bir anlaşmazlık, bellekten tartışma değil gerçek kaynak dosyaların yeniden okunması demek.

Yakınsama kuralı basit: HIGH veya MEDIUM bulgular partially agreed veya disputed kategorilerinde kalmadığı sürece döngü devam ediyor. Aynı anlaşmazlık üç tur boyunca hayatta kalırsa, TandemKit yinelemeyi durdurup her iki pozisyonu sana sunuyor.

Genellikle 2-4 tur.

Neden Agent Teams Değil

Merak edebilirsin: Claude Code’da tam olarak bunun için Agent Teams yok mu? Var, ama Agent Teams API faturalandırması gerektiriyor — Claude Max’e dahil değil — ve Codex ile entegre olmuyor.

Claude Max zaten aylık $100+ tutuyorsa, ChatGPT Plus için aylık $20 eklemek makul — bağımsız ikinci bir model elde ediyorsun, artı Claude’un üretmediği UI mockup’ları, ikonlar ve diğer görseller için görsel üretimi.

Her Şey Düz Metin

Her araştırma, her yakınsama alışverişi, her değerlendirme turu projende okunabilir dosyalar olarak saklanıyor:

TandemKit/001-ConnectAPIClient/
├── Spec.md
├── Planner-Discussion/
│   ├── Claude-01.md    ← Claude'un araştırması
│   ├── Codex-01.md     ← Codex'in bağımsız bulguları
│   └── Claude-02.md    ← yakınsamış plan
├── Generator/
│   └── Round-01.md
└── Evaluator/
    ├── Round-01.md     ← FAIL: versiyon oluşturuldu, yerelleştirme yazımı yeniden denenmedi
    └── Round-02.md     ← PASS

Dosyaları aç ve tüm akıl yürütme izini takip edebilirsin.

Başlarken

GitHub’daki README tam kurulum akışını ve oturumların birbirine nasıl devredildiğini gösteriyor. Eğer bu, elle bir araya getirdiğin iş akışına benziyorsa, başlayacağın yer orası: