AI Kod Asistanının Yaptığı Değişikliğe Ne Kadar Güvenebilirsiniz? İnsan Kontrolünün Hâlâ Gerekli Olduğu 10 Alan

Kısa özet: AI kod asistanları artık yalnızca birkaç satır kod tamamlayan araçlar değil. Repository okuyabiliyor, dosya değiştirebiliyor, test çalıştırabiliyor, pull request oluşturabiliyor ve kod incelemesi yapabiliyorlar. Buna rağmen AI tarafından oluşturulan veya incelenen kod otomatik olarak production’a güvenli kabul edilmemelidir. GitHub, Copilot code review’un bazı problemleri kaçırabileceğini, yanlış pozitif üretebileceğini ve önerdiği kodun hatalı veya güvensiz olabileceğini açıkça belirtiyor. OpenAI de Codex’in yaptığı değişikliklerin entegrasyon veya deployment öncesinde manuel olarak incelenip doğrulanmasını öneriyor.

Kısa doğrudan cevap

AI tarafından oluşturulan kod güvenilebilir mi? Evet, yazılım geliştirme sürecinde ciddi biçimde kullanılabilir; ancak “AI yaptı ve testler geçti” production güveni için tek başına yeterli değildir.

Daha doğru model:

AI üretir
 ↓
AI kendi değişikliğini test eder
 ↓
Statik analiz / CI çalışır
 ↓
İnsan diff'i inceler
 ↓
Kritik alanlar ayrıca doğrulanır
 ↓
Staging / kontrollü rollout
 ↓
Production

olmalıdır.

AI coding agent kod yazabilir, test üretebilir, build çalıştırabilir, potansiyel bug bulabilir, değişiklik açıklayabilir. İnsan reviewer ise özellikle:

• “Bu değişiklik gerçekten istediğimiz şeyi mi yapıyor?”
• “Güvenlik sınırını bozuyor mu?”
• “Veriyi kaybedebilir miyiz?”
• “Başka müşteriyi etkiler mi?”
• “Production’da geri dönüşü zor bir sonuç yaratır mı?”

sorularından sorumludur.

AI kod asistanları bugün ne kadar ilerledi?

Modern coding agent’lar artık yalnızca autocomplete sistemleri değildir. Örneğin GitHub Copilot agentic özellikleri repository üzerinde çalışabiliyor, dosya değiştirebiliyor, komut çalıştırabiliyor, test ve lint çalıştırabiliyor, pull request oluşturabiliyor, kod review yapabiliyor. GitHub aynı zamanda cloud agent üzerinde oluşturulan kod için CodeQL, secret scanning ve dependency analysis gibi otomatik kontroller kullandığını açıklıyor. OpenAI Codex de repository üzerinde görev gerçekleştirebiliyor, terminal komutlarını çalıştırabiliyor, test sonuçlarını gösterebiliyor, diff oluşturabiliyor, pull request hazırlayabiliyor, code review gerçekleştirebiliyor.

Bu gelişmeler “İnsan review artık gereksiz” sonucuna götürmüyor. Tam tersine agent’ın yapabileceği değişikliklerin kapsamı büyüdükçe review’un kapsamı da değişiyor.

GitHub neden Copilot review’u insan approval yerine koymuyor?

GitHub Copilot code review bir pull request’i inceleyebiliyor ve öneriler verebiliyor. Ancak GitHub’ın mevcut davranışında Copilot review `Comment` olarak bırakılıyor. `Approve` veya `Request changes` vermiyor. Bu nedenle Copilot review required approvals sayısına dahil edilmiyor ve merge’i tek başına engellemiyor. Bu ürün kararı önemli bir prensibi gösteriyor: AI review ek bir kontrol katmanıdır; kurumsal human approval mekanizmasının doğrudan yerine geçmez. GitHub’ın responsible use dokümantasyonu da Copilot code review’un insan review’unu desteklemek için kullanılması gerektiğini açıkça belirtiyor.

OpenAI Codex için yaklaşım farklı mı?

Temmel prensip benzerdir. OpenAI, Codex’in terminal loglarını, değiştirdiği dosyaları, test sonuçlarını kullanıcıya göstererek çıktının doğrulanabilir olmasını hedeflediğini belirtiyor. Ancak resmî Codex açıklamasında agent tarafından oluşturulan kodun entegrasyon ve execution öncesinde manuel olarak review edilip doğrulanmasının gerekli olduğu vurgulanıyor.

AI kod review neden tek başına yeterli değil?

GitHub’ın resmî limitation dokümantasyonu birkaç temel risk tanımlıyor. AI review:

• bazı kod kalitesi problemlerini kaçırabilir,
• büyük veya karmaşık değişikliklerde eksik kalabilir,
• olmayan bir problemi varmış gibi gösterebilir (false positive),
• geçerli görünen fakat yanlış kod önerebilir,
• güvenlik açığı içeren kod önerebilir,
• kullanıcının gerçek niyetini yanlış anlayabilir.

Dolayısıyla AI output’u için “Doğru görünüyor” ile “Doğrulandı” aynı şey değildir.

İnsan kontrolünün hâlâ gerekli olduğu 10 alan

1. İş gereksinimi ve gerçek kullanıcı niyeti

AI bir ticket’ı teknik olarak doğru uygulayabilir fakat işletmenin gerçek ihtiyacını yanlış yorumlayabilir. Örneğin “İptal edilen rezervasyonların tekrar kullanılmasını engelle” görevinde agent `if (reservation.status === 'cancelled') throw new Error(...)` yazabilir. Ancak gerçek kural müşterinin iptali ile admin veya ödeme hatası kaynaklı iptalleri farklı ele almayı gerektirebilir. İnsan reviewer: Ticket doğru anlaşılmış mı? Acceptance criteria karşılanıyor mu? Domain kuralları eksik mi?

2. Mimari ve sistem sınırları

Bir fonksiyonun çalışması, mimari olarak doğru yerde olduğu anlamına gelmez. AI frontend component içinde database query veya Server Action içinde doğrudan üçüncü taraf API çağrıları üretebilir. Human review: Kod doğru katmanda mı? Sistem tasarımı, gelecekteki ölçek ve mimari kurallar korunuyor mu?

3. Authentication, authorization ve güvenlik sınırları

AI syntactically correct kod üretebilir fakat örneğin `db.invoice.findUnique({ where: { id } })` yazarak tenant isolation kısıtını atlayabilir. İnsan reviewer: Auth, object ownership, tenant isolation, secret ve input sanitization kontrolleri doğru yapılmış mı?

4. Database migration ve veri bütünlüğü

AI `ALTER TABLE customers ADD COLUMN company_id UUID NOT NULL;` yazabilir. Milyonlarca kaydı olan production DB'de bu işlem deployment'ı kilitleyebilir. İnsan reviewer: Migration aşamalı mı? Production veri hacmi, lock süresi, backfill ve rollback stratejisi düşünüldü mü?

5. Dependency, lockfile ve yapılandırma değişiklikleri

GitHub Copilot code review varsayılan olarak `package-lock.json`, `tsconfig.json`, `next.config.js` gibi dosyaları review kapsamı dışında tutabilir. İnsan reviewer: Lockfile veya compiler options (`strict: false` gibi) beklenmeyen riskli değişiklikler içeriyor mu?

6. Testlerin gerçekten doğru şeyi ölçüp ölçmediği

Agent yeşil CI almak için `test.skip(...)` yapabilir veya assertion'ı `expect(result).toBeDefined` olarak zayıflatabilir. İnsan reviewer: Test silinmiş veya zayıflatılmış mı? Yeni edge case'ler gerçekten test ediliyor mu?

7. Edge case, hata yönetimi ve concurrency

AI happy path'i hızlı oluşturur. Fakat production race condition, duplicate request, idempotency ve partial failure senaryoları içerir. İnsan reviewer: Transaction, idempotency, timeout ve compensation mekanizmaları kurulmuş mu?

8. Performans, kaynak tüketimi ve gerçek maliyet

AI döngü içinde N+1 DB sorgusu veya gereksiz API/Token çağrıları yazabilir. Test ortamında çalışan kod production veri hacminde çökebilir. İnsan reviewer: N+1 query, unindexed search veya bellek sızıntısı riski var mı?

9. API sözleşmeleri ve geriye dönük uyumluluk

AI response payload yapısını değiştirdiğinde kendi repository'sindeki frontend'i güncelleyebilir ancak mobil uygulama veya dış API tüketicilerini kırabilir. İnsan reviewer: Breaking change var mı? Versioning veya backward compatibility korundu mu?

10. Production deployment ve geri döndürülemez işlemler

AI agent'a terminal yetkisi verildiğinde destructive command'lar (DB migration, secret rotation, production deploy) çalıştırabilir. İnsan reviewer: Yüksek riskli ve geri dönüşü zor işlemler için human approval sınırı korunuyor mu?

AI kodu için risk bazlı review matrisi

Bu tablo InoviqLab’ın risk bazlı önerisidir.

AI kod review kontrol listesi

• Ticket ve diff birbiriyle uyumlu; acceptance criteria karşılanıyor.
• Kod doğru katmanda, mimari sınırlar korundu.
• Auth, authorization, tenant isolation ve input validation kontrol edildi.
• Migration güvenli, veri kaybı riski değerlendirildi.
• Lockfile ve `tsconfig` / `next.config` değişiklikleri ayrıca incelendi.
• Failing test silinmedi, assertion zayıflatılmadı.
• Edge case, idempotency, retry ve timeout senaryoları mevcut.
• N+1 query yok, bellek ve API çağrı maliyeti kontrol edildi.
• API contract ve backward compatibility korundu.
• Production build ve staging doğrulaması yapıldı, rollback hazır.

InoviqLab teknik değerlendirmesi

Bu bölüm InoviqLab değerlendirmesidir; GitHub ve OpenAI’nin resmî açıklamalarından ayrıdır. AI coding agent’lar yazılım geliştirmede ciddi bir hız katmanı oluşturuyor. Anacak geliştirme ekiplerinin yapabileceği en büyük hata: AI’nın kod üretme hızını merge hızına çevirmektir. Daha doğru yaklaşım: “Kod üretimini hızlandır, doğrulama standardını düşürme” olmalıdır. İnsan review’un rolü syntax kontrolünden niyet, mimari, güvenlik sınırları ve operasyonel risk değerlendirmesine kaymaktadır. Merge eden ekip production sorumluluğunu taşır.

Sonuç

AI coding agent’lara güvenmek “koduna bakmadan merge etmek” anlamına gelmemelidir. En güçlü model: `AI kod üretir + AI review yapar + otomasyon doğrular + insan riski değerlendirir`.