Codex ile 15 projeyi incelerken manuel kontrolü nasıl elimde tutuyorum

Birkaç yıl önce 15 yazılım projesini aynı dönemde ciddi biçimde incelemek bana gerçekçi gelmezdi. Burada 15 repository açıp hızlıca göz atmaktan söz etmiyorum. Gerçek projeleri düzenli olarak bug, yanlış varsayım, SEO problemi, çeviri hatası, yerelleştirme tutarsızlığı, eksik test, regresyon ve sistemin geri kalanıyla artık uyuşmayan eski kod açısından kontrol etmekten söz ediyorum.

Asıl sınır hiçbir zaman yazma hızı değildi. Dikkatti. Her projenin kendi geçmişi, kuralları, edge case’leri ve yanlış göründüğü hâlde bilinçli olarak öyle bırakılmış kodları var. Dikkatli bir review; okumayı, aramayı, karşılaştırmayı, kontrolleri çalıştırmayı ve ancak ondan sonra neyin değişmesi gerektiğine karar vermeyi gerektiriyor.

Codex bu tekrar eden işin maliyetini benim için değiştirdi. Repository’de ilk taramayı yapabiliyor, referansları takip edebiliyor, ilişkili dosyaları inceleyebiliyor, şüpheli pattern’leri öne çıkarabiliyor, test fikirleri verebiliyor ve eskiden tek tek açacağım alanları araştırmama yardım edebiliyor. Bu son kararı otomatik yapmıyor. Karardan önceki pahalı araştırma bölümünü çok hızlandırıyor.

Öğrendiğim en önemli kural basit: Codex’i kendimi review döngüsünden çıkarmak için değil, o döngünün kapsadığı alanı genişletmek için kullanıyorum.

Gerçek darboğaz kod yazmak değil, tekrar

Tek projede şaşırtıcı miktarda context akılda tutulabilir. Proje sayısı artınca bu ölçeklenmiyor. Aynı işler tekrar tekrar geliyor:

• farklı component’lerde benzer bug’ları aramak;
• refactor sonrasında eski bir call site kalıp kalmadığını kontrol etmek;
• davranış değişikliklerinden sonra testleri incelemek;
• metadata, dil kuralları, heading ve internal link tutarsızlıklarını bulmak;
• localization key’lerini ve çevrilmiş içeriği karşılaştırmak;
• eksik error handling ve edge case aramak;
• “küçük” bir değişikliğin beklenenden fazla dosyaya dokunup dokunmadığını görmek;
• tek tek basit ama toplamda çok zaman alan diff’leri okumak.

Bunların hiçbiri gösterişli değil. Hepsi önemli. Aynı review tipini birçok codebase üzerinde tekrarlamak zorunda kalınca maliyet çok büyüyor.

AI coding agent benim için tam burada en değerli hâle geliyor. Arama alanının tekrar eden kısmını tüketip dikkati karar gerektiren yere bırakıyor.

Her şeyi yeniden yazma izni vermek yerine incelemeyle başlıyorum

Kötü sonuç almanın en kolay yollarından biri “tüm projeyi review et ve her şeyi düzelt” gibi dev bir görev vermek. Verimli görünür ama discovery, önceliklendirme, mimari, implementasyon ve validation’ı kontrolsüz tek görevde birleştirir.

Aşamaları ayırınca çok daha iyi sonuç alıyorum.

inspect → explain findings → prioritize → change → validate → review diff

Önce agent’ın ilgili alanı anlamasını ve ne bulduğunu açıklamasını istiyorum. Somut dosya yolları, etkilenen kod, neden şüpheli olduğu ve muhtemel etkisi lazım. Değişiklik ancak sonra geliyor.

Bu önemli çünkü AI çok emin biçimde yanılabilir. Gereksiz görünen kod eski bir browser, nadir bir ödeme edge case’i, migration yolu veya tek dosyadan anlaşılamayan business rule için var olabilir. İnceleme aşaması yanlış varsayımı dev bir diff’e dönüşmeden yakalamamı sağlıyor.

Bulguları karar değil, araştırma ipucu olarak görüyorum

İyi bir Codex review “17 problem buldum” diye bitmemeli. Sayının tek başına neredeyse anlamı yok. Ben kanıt istiyorum.

Gerçekten aksiyon alınabilir bir bulguda şunları bilmek isterim:

• problem nerede;
• neden problem;
• hangi davranış bozulabilir;
• sonuca ne kadar güvenmek gerekir;
• hangi kontrol bunu doğrular ya da reddeder;
• en küçük güvenli fix nedir.

Bu özellikle security, SEO ve business logic için önemli. Agent araştırılmaya değer bir noktayı gösterebilir ama security diliyle yazılmış açıklama otomatik olarak kanıtlanmış vulnerability değildir. SEO uyarısı otomatik olarak ranking problemi değildir. Garip bir koşul otomatik olarak dead code değildir.

AI aday bulma maliyetini düşürür. Neyin gerçek olduğunu hâlâ doğrulama belirler.

Workflow’u güvenilir yapan validation loop

Kod üretmek AI-assisted development’ın görünür kısmı. Production’da işe yarar hâle getiren kısım validation.

Bir değişiklikten sonra codebase’in cevap vermesini isterim. Projeye göre bu şunları içerebilir:

• TypeScript veya başka compiler/type checker;
• lint;
• unit ve integration testleri;
• build check;
• eski isim ve call site aramaları;
• final diff’in manuel review’u;
• kullanıcı davranışının manuel kontrolü.

Kesin komutlardan çok döngü önemli. Agent bir varsayım yapar, repository kanıt üretir ve sonraki karar o kanıta dayanır.

Bu yüzden güçlü tip kullanılan projeleri AI ile çalışırken özellikle seviyorum. Ayrı bir yazıda TypeScript’in gerçek yazılım geliştirmede Codex ile neden iyi çalıştığını anlattım: type sistemi birçok yanlış varsayımı hemen makine tarafından okunabilir feedback’e çeviriyor.

Bazı review kategorileri AI için özellikle uygun

Bug ve regresyon

Agent bir değeri dosyalar arasında takip edebilir, caller’ları inceleyebilir, benzer implementasyonları karşılaştırabilir ve uyumsuz branch’leri bulabilir. Bu, bir semptomun kaynağını daraltmak için faydalı. Sonuca güvenmeden önce davranışı yine de yeniden üretir veya başka şekilde doğrularım.

Testler

AI değişen ama karşılık gelen test coverage’a sahip olmayan davranışı bulmakta, edge case önermekte ve mevcut testin gerçekten neyi koruduğunu açıklamakta kullanışlı. Sadece implementasyon detayını test eden testleri de fark ettirebilir.

SEO

Technical SEO çok fazla tutarlılık işi içeriyor: metadata, language alternates, indexability kuralları, internal link’ler, template’ler, sitemap generation, redirect ve page-level convention’lar. Agent bunları büyük codebase’de benim her route’u elle açmamdan daha hızlı karşılaştırabilir. Ama teknik doğruluğu, içeriğin gerçekten rank etmeyi hak edip etmediği sorusundan ayrı tutarım.

Yerelleştirme ve çeviri

Çok dilli üründe en tekrar eden alanlardan biri. AI key’leri karşılaştırabilir, eksik değerleri bulabilir, yanlış dil karışımını fark edebilir, placeholder’ları kontrol edebilir ve locale’lerin yapısal olarak nerede ayrıştığını gösterebilir. Büyük translation object’lerini elle taramaktan çok daha hızlıdır; önemli copy yine insan yargısı ister.

Refactor sonrası tutarlılık

Büyük refactor’lar çoğu zaman sıkıcı şekilde bozulur: eski import kalır, tek bir route eski field adını kullanır, bir test fixture eski shape’te kalır. Repository-wide search ile değişikliğin amacını anlayan agent kombinasyonu burada çok güçlüdür.

Paralel çalışma yalnızca görevler bağımsızsa yardımcı olur

Birçok agent başlatıp hepsinin aynı anda her şeyi değiştirmesine izin vermek cazip. Throughput artabilir ama conflict ve tutarsız varsayımlar da aynı şekilde artabilir.

Parallelism’i bir koordinasyon problemi olarak görüyorum. Bağımsız audit’ler iyi adaydır: bir proje localization için kontrol edilirken diğeri test açısından review edilebilir veya ayrı repository’ler aynı anda incelenebilir. Ortak plan olmadan aynı mimariyi iki agent’ın yeniden yazması başka bir şeydir.

Paralellik arttıkça sınırlar daha önemli olur: net project, net task, net definition of done ve ayrı review edilebilir sonuç.

Amaç çalışan agent sayısını maksimize etmek değil. Yararlı ve doğrulanabilir ilerlemeyi maksimize etmek.

Körü körüne delege etmediğim şeyler

• Mimari kararlar: model seçenek sunabilir ama uzun vadeli trade-off’lar repo dışındaki context’e bağlı olabilir.
• Security sonuçları: bulgular doğrulama, threat context ve bazen özel araçlar ister.
• Business rule’lar: kod içsel olarak tutarlı olup yine de yanlış ürün davranışı uygulayabilir.
• Büyük yıkıcı refactor’lar: dev diff’i anlamak zordur ve dikkatsizce onaylamak kolaydır.
• Production deployment: geçen testler operasyonel riski ortadan kaldırmaz.
• Final review: değişikliğe adımı koymadan önce ne değiştiğini bilmek isterim.

AI bu alanlarda işe yaramadığı için değil; makul görünen yanlış cevabın burada pahalı olabileceği için.

AI review statik analizin yerine geçmez

Codex’i compiler, linter, test, scanner veya monitoring’in alternatifi olarak da görmüyorum. Bu araçların AI’da olmayan avantajı var: dar, deterministik ve tekrarlanabilir olmaları.

En güçlü workflow bunları birleştirir. Codex context üzerinde düşünüp nereye bakılması gerektiğini önerebilir. Statik araçlar kesin kuralları uygular. Testler davranışı doğrular. Log ve monitoring gerçekte ne olduğunu gösterir. İnsan review’u tüm bu sinyalleri ürün amacıyla birleştirir.

Bu feedback systems olmadan AI’a daha çok değil, daha az güvenirim.

En büyük verimlilik artışı dikkatin daha iyi dağıtılması

“Codex zaman kazandırıyor” demek kolay ama benim için değişimi tam anlatmıyor.

Yazılım geliştirmedeki kıt kaynak keystroke değil, kaliteli dikkattir. AI coding agent’lardan önce bunun büyük kısmı tekrar eden discovery işine gidiyordu: aynı pattern’leri aramak, benzer dosyaları okumak, reference takip etmek, değişikliğin her yere ulaşıp ulaşmadığını kontrol etmek ve aynı audit’i başka repository’de tekrarlamak.

Şimdi bu first-pass work’ün daha fazlasını delege edip kendi dikkatimi otomasyonu zor kararlara ayırabiliyorum: bulgu önemli mi, fix mimariye uyuyor mu, UX iyileşiyor mu, risk kabul edilebilir mi, bunu gerçekten ship etmek istiyor muyum?

Bu yüzden birçok projeyi korumak ve review etmek artık farklı hissettiriyor. Daha az review etmiyorum. Çoğu durumda mekanik kısım tüm bütçeyi tüketmediği için daha fazla review edebiliyorum.

Güvendiğim workflow

1. Dar bir review hedefi tanımla. Bug, test, SEO, localization, refactor veya başka net konu.
2. Agent’ın editten önce incelemesine izin ver. Önce kanıt ve etkilenen yerleri isterim.
3. Finding’leri önceliklendir. Her teorik sorun kod değişikliği gerektirmez.
4. Değişiklikleri sınırlı tut. Küçük ve tutarlı diff’ler daha kolay doğrulanır.
5. Machine check çalıştır. Typecheck, lint, test, build, search veya proje özel doğrulama.
6. Diff’i elle oku. Gereksiz rewrite, yanlış varsayım, eksik edge case ve scope dışı değişiklik ararım.
7. Önemli davranışı doğrula. Özellikle kullanıcı, para, security, SEO ve production infrastructure.
8. Sonra diğer projeye geç. Parallelism faydalı ama çözülmemiş belirsizlik yayılmamalı.

15 proje artık 15 kat review işi gibi hissettirmiyor

Codex 15 projeyi basit yapmadı ve sorumluluğumu ortadan kaldırmadı. Ölçek ile tekrar eden efor arasındaki ilişkiyi değiştirdi.

Daha derin first pass, daha geniş consistency check, daha çok test fikri ve daha sistemli audit yapabiliyorum; her dosyada her dakika kendim arama yapmak zorunda kalmıyorum. Kazandığım dikkati hâlâ geliştirici gerektiren kararlara ayırabiliyorum.

Değerli bulduğum AI-assisted development bu: autopilot değil, kör güven değil ve “bir şey geçene kadar kod üret” değil. Makine ölçeğinde inspection ile insan ölçeğinde judgment arasında daha sıkı bir loop.

Benim için Codex’in gerçek leverage’ı bu. Review’u ortadan kaldırmıyor. Önceden çok daha zor sürdürülebilen ölçekte ciddi review’u mümkün kılıyor.