İnsan ve Ajan Aynı Ekipte Çalışırken Kim Karar Veriyor?

Bir yazılım şirketinde üç kişilik bir mühendislik ekibi olduğunu düşünlim. Ekipte bir kıdemli geliştirici, bir yeni mezun ve bir kod review ajanı var. Kıdemli geliştirici mimariyi belirliyor, yeni mezun kodu yazıyor, ajan kodu inceler, hata buluyor ve düzeltme önerileri sunuyor.

Bu ekip düzgün çalışır gibi görünüyor. Ancak bir gün ajan bir hatayı yakalıyor, düzeltme önerisi sunuyor, ama geliştirici bu öneriyi uygulamıyor. Sonra müşteri bir şikayet geliyor. Kimin sorumluluğu bu?

Bu soru basit gibi görünüyor ama cevabı organizasyonun yapısına, kuralların nerede tanımlandığına ve kararların nasıl kaydedildiğine bağlı.

İş Bölümü: Kim Ne Yapıyor?

Karma ekiplerde iş bölümü ilk adım ama en kritik adım. İnsanlar ve ajanlar farklı yeteneklerle gelir. İnsanlar yaratıcı strateji belirler, duygusal bağ kurar, karmaşık belirsizlikte karar verir. Ajanlar tekrarlayan analizleri hızlı yapar, tutarlılık sağlar, büyük veri taraması yapar.

Bir mühendislik ekibinde bölüm şöyle olabilir:

Kıdemli geliştirici: Mimari kararları alır, kritik kod bölümlerini yazar, onayları yapar. Sorumluluk: teknik doğruluk ve proje takibi.

Yeni mezun: Kodu yazar, testleri çalıştırır, dokümantasyonu günceller. Sorumluluk: görev tamamlama ve raporlama.

Kod review ajanı: Kodu inceler, stil uyumunu kontrol eder, güvenlik açıklarını tarar, test kapsamını değerlendirir. Sorumluluk: kod kalitesi raporu ve öneriler.

Bu bölüm net değilse, her şey karışır. Mesela ajan bir hatayı bulduğunda, geliştirici “ben yazdım, ben karar veririm” diyebilir. Ama ajanın raporunu incelemek geliştiricinin görev değilse, hata geçer.

Onay Sorumluluğu: Her Kararın Sahibi Olmalı

Bu ekipte onay akışı şöyle çalışır:

Kod yazılır (mezun). Ajan inceler, rapor hazırlar. Geliştirici raporu gözden geçirir, kabul eder veya reddeder. Reddedilirse, mezun düzeltir, ajan tekrar inceler.

Bu basit görünüyor ama bir soru var: Ajanın raporunu reddeden kıdemli geliştirici, bu reddini neden yaptığını nasıl belirtiyor?

Eğer bu yanıt Slack’te, bir toplantıda veya sözlü bir şekilde yapılıyorsa, kaybolur. İşte bu nedenle onay sorumluluğu yalnızca kimin onay verdiğini değil, ne zaman ve neden verdiğini de kaydetmeli.

Git bu noktada devreye girer. Her onay, her karar ve her değişiklik commit mesajında görünmeli:

commit 4a2b3c1 - 2026-09-23 14:30 - Kod review ajanı raporu kabul edildi, güvenlik açığı yok
commit 3f8e2d1 - 2026-09-23 14:15 - Ajan raporu: SQL enjeksiyon riski tespit edildi
commit 2c7b1a9 - 2026-09-23 13:45 - Mezun, kullanıcı girişi kodunu tamamladı

Bu kayıt, ileride bir sorun çıktığında kimin ne zaman ne karar verdiğini gösterir. “Neden bu kod gönderildi?” sorusu cevapsız kalmaz.

Config-as-Code: Kurarlar Dosyada, İnsan Belleğinde Değil

Bu ekipte kurallar nerede tanımlı? Ekip başına ayrı bir dosya mı? Yoksa tüm şirket için tek bir politika mı?

Pratikte her ekibin kendi ihtiyacı farklıdır. Bir pazarlama ekibi, bir mühendislik ekibi ve bir destek ekibi aynı kuralları kullanamaz. Ama kuralların herkes tarafından erişilebilir, okunabilir ve versiyonlanabilir olması gerekir.

Config-as-code yaklaşımıyla, ekibin kuralları bir YAML veya JSON dosyasında tanımlı:

team: backend-engineering
version: 2.1
members:
  - role: senior-developer
    responsible_id: dev-001
    approval_authority: architecture, security
  - role: junior-developer
    responsible_id: dev-002
    approval_authority: none
  - role: code-review-agent
    responsible_id: agent-cr-001
    approval_authority: code_quality_report

policies:
  code_review_required: true
  agent_report_must_be_addressed: true
  merge_requires: senior_developer_approval

Bu dosya, hem insanlar hem ajanlar tarafından okunabilir. Ajan, raporunu oluştururken bu kuralları kontrol eder. Geliştirici, reddini bu dosyaya bakarak gerekçelendirir.

Ayrıca bu dosya Git’te tutulduğu için, kuralların değişmesi de kayıt altına alınır. “Kurallar ne zamandır böyleydi?” sorusu git log ile cevaplanır.

Git ve PR ile Organizasyonun Versiyonlanması

Bu ekipte her iş, bir pull request üzerinden yürür. PR, yalnızca kod değişikliği değil, tüm karar zincirinin kaydıdır.

Bir PR açıldığında:

Bu süreç sonunda, organizasyonun tarihi kayıt altında olur. Bir yıl sonra, “Bu projede neden bu karar verildi?” sorusu cevaplanabilir. Bu yalnızca kodun değil, organizasyonun öğrenme sürecinin de kaydıdır.

Gerçek Hayat Senaryosu: Bir Güvenlik Açığı Geçti

Bir şirkette bu süreç tam uygulanmamış. Mezun geliştirici kod yazıyor, ajan inceliyor ama raporlar cevapsız kalıyor. Kıdemli geliştirici “benim zamanım yok” diyerek raporları okumadan geçiyor. Bir güvenlik açığı üretim ortamına giriyor, müşteri verisi sızdırıyor.

Sorulması gereken soru: “Ajan raporunu kim okumadı?”

Eğer Git ve PR kayıtları varsa, bu soru cevaplanır. PR’da “ajan raporu görüldü, onaylandı” yoksa, süreç bozuktur. Ama bu bozukluğu görmek için önce sistemi kurmanız gerekir.

İnsan ve ajan ekipleri çalışırken, kimin ne yaptığı, kimin onay verdiği ve kuralların nerede tanımlandığı net olmadığında, hata kaçınılmaz olur. Çözüm, her şeyin kayıt altında olduğu, her kararın sahibi olan ve kurarların dosyada yaşadığı bir sistem kurmaktır.

Bu sistemi kurmak teknik bir değil, organizasyonel bir karar. Önce ekip üyelerinin rolleri tanımlanır. Sonra hangi kararların hangi onay gerektirdiği belirlenir. Kurallar dosyaya yazılır ve Git’e eklenir. Her iş bir PR üzerinden yürütülür ve her karar commit mesajında kayıt altına alınır.

Bu yaklaşımı uygulamak, başlangıçta fazladan iş gibi görünebilir. Ama bir sorun çıktığında, “Kim neden bu karar verdi?” sorusunu cevaplamak zaten çok daha fazla iş gücü ister. Kayıt almak, o günlük fazladan dakikaları değil, kriz anındaki haftaları kurtarır.

Bir organizasyon, ajanlarla çalışmaya başladığında bu sistemi kurmadan önce, ajanların tek başına yetenekli olduğunu ama sorumluluk zinciri olmadan çalışamayacaklarını unutmamalı. Ajan bir araçtır, bir hizmet değil. Ajanın çalıştığı ekip, onun sorumluluk sahibi olmalıdır. Bu, kurumsal bir yatırım gibi değil, işleyişin doğal bir parçası olmalıdır.