AI Coding Agent Kullanırken Kod İncelemesi Nasıl Yapılmalı? Review Rehberi

AI coding agent kullanırken en tehlikeli varsayımlardan biri, agentın görevi tamamlamasının kodun merge edilmeye hazır olduğu anlamına geldiğini düşünmektir. Bir agent dosyaları değiştirebilir, test çalıştırabilir ve görevin bittiğini söyleyebilir; ancak yanlış gereksinimi doğru uygulamış, mevcut bir davranışı bozmuş, edge case atlamış veya yalnız kendi yazdığı testleri geçirecek dar bir çözüm üretmiş olabilir.

15 Temmuz 2026 itibarıyla OpenAI Codex, Claude Code ve GitHub Copilot gibi güncel coding agent sistemleri code review iş akışlarını doğrudan destekliyor. OpenAI Codex GitHub entegrasyonu pull request review, otomatik review ve repository’ye özel review guidelines özellikleri sunuyor OpenAI Codex GitHub Code Review. Anthropic’in Claude Code Review sistemi pull requestleri codebase bağlamında inceleyip inline bulgular üretebiliyor Claude Code Review. GitHub ise Copilot code review’un amacını insan code review’unu desteklemek olarak tanımlıyor GitHub Copilot Agents – Responsible Use. Bu araçların ortak mesajı şudur: AI review değerli olabilir, fakat güvenilir süreç yalnız tek bir agentın “looks good” demesiyle kurulmaz.

AI coding agent kodu neden ayrıca incelenmeli?

Coding agent, yazılım geliştirme döngüsünde gerçek eylemler yapar. Repository’yi araştırabilir, birden fazla dosyayı değiştirebilir, komut çalıştırabilir ve pull request oluşturabilir. Bu yetenek üretim hızını artırırken hata yüzeyini de büyütür. Tek bir yanlış varsayım, bir satırlık öneriden çok daha geniş bir diff’e dönüşebilir.

Üstelik agentın kendi ürettiği değişikliği değerlendirmesi ile bağımsız bir reviewerın değerlendirmesi aynı şey değildir. İlk agent görev sırasında belirli bir çözüm yoluna bağlanmış olabilir. Kendi varsayımlarını yeniden kullanarak self-review yaptığında, çözümün dışından bakması zorlaşabilir.

Bu nedenle sağlıklı süreçte en az üç farklı kontrol türü bulunur:

• Üreten agentın self-review’u: Bariz hata, eksik test ve gereksiz değişiklikleri temizlemek.
• Bağımsız review: Farklı context veya reviewer ile varsayımları yeniden sorgulamak.
• İnsan onayı: İş amacı, risk ve sorumluluk açısından son kararı vermek.

İlk review sorusu: Kod istenen şeyi gerçekten yapıyor mu?

Kod incelemesi yalnız syntax, stil veya “bu fonksiyon daha temiz yazılabilir miydi?” sorusuyla başlamamalıdır. İlk kontrol, pull requestin niyeti ile gerçek diff’in aynı şeyi yapıp yapmadığıdır.

OpenAI, Codex code review yaklaşımını yalnız static analysis olarak değil; pull requestin ifade edilen amacı ile gerçek değişikliği karşılaştıran, codebase ve dependencies üzerinde reasoning yapan bir inceleme biçimi olarak tanımlar OpenAI – Introducing Upgrades to Codex. Bu yaklaşım insan review’u için de güçlü bir ilkedir.

Reviewer şu sorulara cevap aramalıdır:

• Görevin kabul kriterleri açık mı?
• Diff yalnız bu hedef için gerekli alanlara mı dokunuyor?
• Agent problemi gerçekten çözüyor mu, yoksa semptomu mu gizliyor?
• Mevcut davranışlardan hangileri bilinçli olarak değişiyor?
• Görev dışında kalan değişiklikler var mı?

Özellikle büyük yazılım geliştirme projelerinde “kod çalışıyor” ile “ürün gereksinimini doğru uyguluyor” aynı şey değildir. Review önce niyeti doğrulamalıdır.

Diff’i dosya dosya değil, risk üzerinden okumak neden daha iyi?

Büyük agent değişikliklerinde yüzlerce satırı sırayla okumak reviewerı yorabilir. Daha iyi yaklaşım, değişiklikleri risk katmanlarına ayırmaktır. Authentication, authorization, para hareketi, veri silme, migration, concurrency ve public API değişiklikleri; metin, dokümantasyon veya düşük riskli refactor ile aynı öncelikte incelenmemelidir.

Bu tablo evrensel bir güvenlik sınıflandırması değildir; review sırasını belirlemek için kullanılabilecek pratik bir risk çerçevesidir. Her projenin yüksek etkili alanları farklı olabilir.

Agent önce kendi kodunu nasıl review etmeli?

Self-review, bağımsız review’un yerine geçmez; fakat gereksiz hataları reviewer kuyruğuna taşımamak için önemlidir. OpenAI’ın agent-first geliştirme deneyimini anlattığı harness engineering yazısında, bir pull requesti tamamlamak için Codex’in kendi değişikliklerini yerel olarak review etmesi ve ardından ek, daha spesifik agent review’ları istemesi kullanılan çalışma adımları arasında anlatılır OpenAI – Harness Engineering.

Üreten agente yalnız “kodunu kontrol et” demek yerine açık kontrol listesi verilmelidir:

1. Görev hedefini ve kabul kriterlerini yeniden oku.
2. Git diff’i baştan sona incele.
3. Görev dışı dosya ve değişiklikleri belirle.
4. Hata yollarını ve edge case’leri ara.
5. Eklenen testlerin yalnız implementasyona özel olup olmadığını kontrol et.
6. İlgili test, lint, type-check ve build komutlarını çalıştır.
7. Kalan riskleri ve doğrulanamayan varsayımları açıkça yaz.

Self-review’un amacı “kendi kodunu onayla” değil, teslim öncesi kusur avcılığıdır.

Bağımsız AI review neden ayrı bir adım olmalı?

Üreten agent ile reviewer agentın aynı conversation context’ini paylaşması, review bağımsızlığını azaltabilir. Reviewer, implementasyonu yapan agentın gerekçelerini önceden kabul ederek aynı kör noktaları taşıyabilir.

Daha güçlü yaklaşım, reviewerı mümkün olduğunca bulgu odaklı ve bağımsız başlatmaktır. Reviewer’a görev amacı, base branch, diff, ilgili proje kuralları ve gerekli codebase erişimi verilir; ancak implementasyonu yapan agentın bütün iç açıklama akışı zorunlu olarak taşınmaz.

OpenAI’ın 2026 Codex prompting rehberi, kullanıcı review istediğinde önceliğin bug, risk, davranışsal regresyon ve eksik test bulmaya verilmesini; bulguların severity sırasıyla ve dosya/satır referanslarıyla sunulmasını önerir OpenAI Codex Prompting Guide. Bu format, AI review’un genel özet yerine eyleme dönük bulgu üretmesini sağlar.

AI reviewer hangi konuları kontrol etmeli?

Tek bir “review this code” talimatı geniş değişikliklerde yetersiz kalabilir. İncelemeyi belirli risk kategorilerine bölmek daha yüksek sinyal üretebilir.

• Correctness: Kod beklenen davranışı gerçekten sağlıyor mu?
• Regression: Mevcut davranışlardan biri yanlışlıkla bozuluyor mu?
• Edge case: Null, boş veri, sınır değer, hata cevabı veya eşzamanlılık senaryosu atlanmış mı?
• Security: Yetki kontrolü, input validation, secret veya veri sızıntısı riski var mı?
• Data integrity: Veri kaybı, duplicate işlem veya kısmi başarısızlık riski bulunuyor mu?
• Tests: Değişen davranışı gerçekten kanıtlayan testler var mı?
• Operability: Hata oluştuğunda log, metric veya geri dönüş yolu yeterli mi?

Büyük bir özel yazılım projesinde her kategori için aynı reviewer kullanılmak zorunda değildir. Kritik değişikliklerde güvenlik, veri veya performans için ayrı uzman review adımları oluşturulabilir.

Bulgular nasıl sıralanmalı?

AI review’un en büyük sorunlarından biri çok fazla düşük değerli yorum üretmesidir. Stil tercihleri ve küçük iyileştirmeler gerçek bug’ları görünmez hale getirebilir. Bu nedenle bulguların severity ve gerçek etki üzerinden sıralanması gerekir.

OpenAI Codex review dokümantasyonu, review sonuçlarının prioritized findings olarak raporlanabildiğini belirtir OpenAI Codex Code Review. Claude Code Review da bulguları inline yorumlar halinde ilgili kod satırlarına bağlar Claude Code Review.

Severity yalnız kodun “kötü görünmesine” göre değil, olası kullanıcı ve sistem etkisine göre verilmelidir. AI reviewerın severity tahmini de insan tarafından sorgulanmalıdır.

Testler review’un hangi aşamasında çalıştırılmalı?

Test yalnız kod yazıldıktan sonra bir kez çalıştırılan final kontrol değildir. İdeal süreçte agent implementasyon sırasında ilgili testleri kullanır, self-review sonrasında tekrar çalıştırır ve reviewer gerekli görürse farklı test veya doğrulama yolları önerir.

OpenAI, Codex code review yeteneklerini anlatırken codebase ve dependencies üzerinde reasoning yapmanın yanında kod ve test çalıştırarak davranışı doğrulamayı vurgular OpenAI – Introducing Upgrades to Codex. Bununla birlikte testlerin geçmesi tek başına doğruluk kanıtı değildir. Eksik test suite yanlış değişikliği de yeşil gösterebilir.

Review sırasında şu ayrım yapılmalıdır:

• Mevcut testler hâlâ geçiyor mu?
• Yeni davranış için yeni test gerekiyor mu?
• Agent yalnız happy path mi test etmiş?
• Test, implementasyon ayrıntısını mı yoksa gerçek davranışı mı doğruluyor?
• Değişiklik entegrasyon veya end-to-end seviyesinde ayrıca kontrol edilmeli mi?

Agentın yazdığı testlere neden tek başına güvenilmemeli?

Aynı agent hem kodu hem testi yazdığında aynı yanlış varsayım iki tarafa da taşınabilir. Agent, yanlış anladığı gereksinime uygun kod ve yine aynı yanlış gereksinimi doğrulayan test üretebilir.

Bu nedenle yüksek riskli değişikliklerde reviewer mevcut davranış ve gereksinimden bağımsız olarak test senaryolarını sorgulamalıdır. Gerekirse test case listesi önce insan veya bağımsız reviewer tarafından oluşturulabilir; sonra implementation bu senaryolara karşı değerlendirilir.

Bu, agentın test yazmaması gerektiği anlamına gelmez. Tam tersine agent test üretiminde çok faydalı olabilir. Ancak testin kaynağı ile doğruluğun kaynağı aynı şey değildir.

Code review sırasında yalnız diff’e bakmak yeterli mi?

Hayır. Diff temel artefacttır ancak bazı hatalar yalnız çevre kodu, veri akışı veya repository genelindeki sözleşmeler incelendiğinde görülür. Bir fonksiyon lokal olarak doğru olabilir fakat başka bir caller’ın varsayımını bozabilir.

Codebase-aware AI review araçlarının değer iddiası da burada ortaya çıkar. OpenAI, Codex code review’un pull request amacını gerçek diff ile karşılaştırabildiğini ve bütün codebase ile dependencies üzerinde reasoning yapabildiğini belirtir OpenAI – Introducing Upgrades to Codex. Anthropic’in Code Review ürünü de incelemeyi repository bağlamında yürüttüğünü açıklar Claude Code Review.

İnsan reviewer için de aynı ilke geçerlidir: Kritik bir değişiklik yalnız değişen satırlardan değil, etkilenen çağrı zinciri ve sözleşmelerden değerlendirilmelidir.

AI review ile static analysis aynı şey mi?

Hayır. Linter, type checker, SAST, dependency scanner ve test suite gibi deterministik veya özel amaçlı araçlar ile AI reviewer farklı sinyal üretir. AI reviewer niyet, davranış ve geniş codebase ilişkileri üzerinde reasoning yapabilir; ancak özel güvenlik veya tip araçlarının yerine geçmez.

En sağlıklı pipeline araçları birbirinin alternatifi değil tamamlayıcısı olarak kullanır:

1. Formatter ve linter.
2. Type-check ve compile kontrolleri.
3. Unit, integration ve gerekli end-to-end testler.
4. Güvenlik ve dependency kontrolleri.
5. AI code review.
6. İnsan review ve merge kararı.

Bu sıralama her proje için zorunlu değildir, fakat otomatik ve uzmanlaşmış kontrolleri yalnız AI review ile değiştirmemek temel ilkedir.

Review talimatları nasıl özelleştirilmeli?

Genel bir AI reviewer, projenin özel risklerini bilmeyebilir. Örneğin bir sistemde backward compatibility kritik olabilir; başka bir sistemde tenant isolation veya kişisel veri sınırları daha önemli olabilir.

OpenAI Codex GitHub code review entegrasyonu review guidelines özelleştirmesini destekler OpenAI Codex GitHub Code Review. GitHub Copilot da custom instructions ile code review deneyiminin takımın kurallarına göre özelleştirilebildiğini açıklar GitHub – Customize Code Review.

İyi review talimatları şunları içerebilir:

• Merge’i bloke eden hata türleri.
• Projeye özel güvenlik ve veri sınırları.
• Backward compatibility beklentileri.
• Zorunlu test seviyeleri.
• Generated veya review dışı dosyalar.
• Bulguların severity ve dosya/satır formatı.

Ancak talimatları yüzlerce genel stil kuralıyla doldurmak AI review’un sinyalini düşürebilir. Stil kontrolleri mümkün olduğunda formatter ve linter gibi deterministik araçlara bırakılmalıdır.

AI review insan code review’unun yerini almalı mı?

Genel olarak hayır. GitHub’ın Copilot Agents responsible use dokümantasyonu Copilot code review’u insan code review’unu supplementing, yani destekleyen bir kullanım olarak tanımlar GitHub Copilot Agents – Responsible Use.

İnsan reviewerın benzersiz değeri yalnız bug bulmak değildir. Ürün amacı, kullanıcı etkisi, organizasyonel risk, mimari yön ve “bu değişiklik gerçekten yapılmalı mı?” sorusu çoğu zaman repository kodundan tamamen çıkarılamaz.

Bununla birlikte AI review insanın zamanını daha yüksek değerli alanlara kaydırabilir. Tekrarlanan bug kalıpları, eksik testler ve bazı regresyonlar otomatik olarak daha erken yakalanırsa insan reviewer tasarım ve iş etkisine daha fazla odaklanabilir.

AI agent değişiklikleri için önerilen review akışı

1. Görev ve kabul kriteri kilitlenir: Review başlamadan neyin doğru sonuç olduğu açık olmalıdır.
2. Üreten agent self-review yapar: Diff, testler ve görev dışı değişiklikler temizlenir.
3. Otomatik kontroller çalışır: Lint, type-check, test, build ve gerekli güvenlik kontrolleri.
4. Bağımsız AI review yapılır: Bulgular bug, regresyon, güvenlik ve eksik test odağıyla aranır.
5. Bulgu triage yapılır: False positive ve severity insan tarafından değerlendirilir.
6. Gerekli düzeltmeler uygulanır: Düzeltmeler yeni regression oluşturmaması için yeniden test edilir.
7. İnsan reviewer son kararı verir: İş amacı, mimari ve risk kontrol edilir.
8. Merge sonrası gözlem yapılır: Yüksek riskli değişikliklerde log ve metric sinyalleri izlenir.

Bu süreç küçük her değişiklikte aynı ağırlıkta uygulanmak zorunda değildir. Risk tabanlı review, düşük etkili değişiklikleri hızlı geçirirken kritik alanlarda daha fazla kontrol sağlar.

Review sürecinde en sık yapılan hatalar

• Üreten agentın “tamamlandı” mesajını review yerine kabul etmek.
• Aynı agenta yalnız “kendini kontrol et” deyip bağımsız review yapmamak.
• AI reviewerın bütün yorumlarını doğru kabul etmek.
• Stil yorumlarını kritik bug’larla aynı öncelikte göstermek.
• Test geçmesini iş gereksiniminin kanıtı saymak.
• Diff dışındaki etkilenen çağrı zincirlerini incelememek.
• AI review kullandığı için linter, SAST veya insan review’u kaldırmak.
• Merge sonrası yüksek riskli değişiklikleri gözlemlememek.

Kod inceleme kontrol listesi

• PR amacı ve acceptance criteria açık mı?
• Diff görev kapsamının dışına taşıyor mu?
• Kritik iş kuralı doğru uygulanmış mı?
• Backward compatibility veya API sözleşmesi bozuluyor mu?
• Yetki, veri ve güvenlik sınırları korunuyor mu?
• Happy path dışında hata ve edge case’ler değerlendirildi mi?
• Testler gerçek davranışı doğruluyor mu?
• Agentın yazdığı testlerden bağımsız bir kontrol var mı?
• AI review bulguları severity ve gerçek etki açısından triage edildi mi?
• İnsan reviewer merge kararının sorumluluğunu gerçekten aldı mı?

Sonuç: AI review bir onay düğmesi değil, ek bir kusur bulma katmanıdır

AI coding agent kullanırken kod incelemesinin amacı, agentın yaptığı işi ikinci kez özetletmek değildir. İyi review; görev niyetini gerçek diff ile karşılaştırır, riskli alanları önceliklendirir, test ve regresyon sinyallerini inceler, bağımsız bulgular üretir ve son kararı insan sorumluluğunda bırakır.

Üreten agentın self-review yapması değerlidir ancak yeterli değildir. Bağımsız AI reviewer yeni kör noktalar bulabilir; deterministik araçlar farklı hata sınıflarını yakalayabilir; insan reviewer ise ürün ve sistem bağlamını değerlendirir. En güvenilir süreç bu katmanları birbirinin alternatifi değil, tamamlayıcısı olarak kullanır.

AI coding agentların üretim hızını artırması, review kalitesini düşürmek için değil daha sistematik hale getirmek için fırsattır. Hedef daha fazla kodu daha hızlı merge etmek değil; değişiklikleri daha erken, daha ölçülebilir ve daha yüksek sinyalle doğrulamaktır.