Ekipte AI: Politika, Etkiyi Ölçmek, Junior Gelişimi ve Ne Zaman Kullanmamalı

Sürüm notu: Bu yazıdaki dosyalar ve komutlar Bookstore repo'sunda .NET 10 ve Git 2.54 ile denenmiştir. Araştırma ve araç bilgileri 2026-11 itibarıyladır.

Önce Tahmin Et

Şirket yönetimi bir hedef koydu: üç ay içinde commit'lerin %80'i AI yardımıyla yazılmış olacak ve her ekibin oranı bir dashboard'da görünecek. Bookstore ekibinde Emre ve Ayşe bu hedefi tutturmak için ne yapar? Üç ay sonra dashboard'daki oran büyük ihtimalle yükselmiş olur. Peki aynı sürede değişikliklerin production'a çıkma süresi, geri alınan deploy sayısı ve review bekleyen pull request kuyruğu ne yöne gider?

Tahmin etmek için ilk yazıdaki iki bulguyu hatırla: DORA (DevOps Research and Assessment; Google'ın yazılım teslimatı araştırma programı) 2025'e göre AI kullanımı throughput'u artırırken instability'yi de artırıyor; METR'in (AI modellerinin etkisini ölçen bağımsız araştırma kuruluşu) ölçümünde geliştiriciler yavaşladıkları hâlde hızlandıklarını düşündü. Bu yazı, serinin son yazısı olarak bireysel kullanımdan ekibe geçiyor: politika, ölçüm, junior'ların gelişimi ve AI'ı kullanmamanın daha iyi olduğu yerler.

Ekip AI Politikası: Kısa, Yazılı ve Repo'da

Politikası olmayan bir ekipte herkes kendi kuralını uygular: biri müşteri verisini prompt'a yapıştırır, biri kişisel hesabıyla şirket kodunu bir web arayüzüne verir, biri de agent'ı tüm komutları onaysız çalıştıracak şekilde açar. Politika yazmak bunları yasaklamaktan çok, ekibin varsayılanını belirlemek. Bookstore'un politikası repo'da, kodun yanında duruyor:

# AI policy — Bookstore team

Last reviewed: 2026-11. Owner: tech lead. Reviewed every six months, or when a tool changes its data terms.

## Tools
- Company plans of the approved coding assistants only. No personal accounts or free plans for company code.
- Agents ask before running commands. Auto-approve only inside a container with no credentials.

## Data
- Never in a prompt or an agent's context: secrets, connection strings, production data, customer personal data.
- Example data comes from the seed (Ada, Alan, Grace; Dune, Emma, The Hobbit).

## Work
- The person who opens the pull request owns the code, whoever wrote it.
- Commits with substantial AI help carry the trailer `AI-Assisted: yes`; the PR template asks the same.
- A written plan (docs/plans/) first for work that touches the data model, more than one module, or security.
- AI review is a pre-filter. It never counts as a required approval.

## Extra care
- Authentication, authorization, payments, cryptography: two human approvals, one from someone who knows the area.
- Unclear requirement: clarify it with the Product Owner before asking an agent.

## Learning
- Learning tasks (new area, onboarding): try for 30 minutes first, write the tests yourself.
- Before accepting AI code, be able to explain every line to the reviewer.

## Measuring
- We watch change lead time, change fail rate, deployment rework rate and review time per pull request.
- We do not use lines generated, suggestion acceptance rate or "AI usage %" as targets.

Dosyada araç adı yok, bilerek. Araç listesi ayrı bir yerde değişebilir; politika "onaylı araçların şirket planları" der ve verinin nereye gidebileceğini tanımlar. Hukuki taraf da burada başlar: Bookstore'un müşteri verisi bir bulut sağlayıcısına gönderildiğinde bu, KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) açısından bir veri aktarımıdır ve sağlayıcı yurt dışındaysa kanunun 9. maddesindeki şartlara (1 Haziran 2024'te yürürlüğe giren değişiklikle standart sözleşme gibi güvenceler) bağlıdır. Bu bir hukuk tavsiyesi değil; politikanın veri bölümünü şirketin hukuk birimiyle birlikte yaz.

Dosyanın en üstündeki satır da önemli: "altı ayda bir gözden geçirilir". Araçlar her ay değişiyor, ama ekip pratiğini her ay değiştirmek, kimsenin kuralı hatırlamadığı bir ekip demek. Politikayı sabit tut, araç listesini ve ayarları ayrı güncelle.

DORA'nın Yedi Yeteneği Bookstore'da

DORA 2025 raporu, AI'ın kurum performansına olumlu etkisini büyüten yedi yetenekten oluşan bir model önerdi. Raporun bulgusu, AI'dan fayda görmenin araçtan çok bu çevreye bağlı olduğu. Yedi yeteneği ve Bookstore'daki karşılıklarını kendi cümlelerimle şöyle eşleştiriyorum:

Tabloya bakınca serinin önceki beş yazısının aslında bu yeteneklerin küçük parçaları olduğu görülüyor. AI politikası olmayan, küçük adımlarla çalışmayan ve testleri zayıf bir ekip, aynı araçlarla Bookstore ekibinden çok farklı sonuç alır. Raporun "amplifier" bulgusu tam olarak bu.

Pull Request'te AI Kullanımını Belirtmek

AI kullanımını belirtmenin amacı birini suçlamak değil, reviewer'a bilgi vermek: agent'ın yazdığı bir diff'te test değişikliklerine ve edge case'lere daha dikkatli bakılır. Bookstore'da bunun iki yeri var. Birincisi pull request şablonu:

## What and why


## How it was verified
- [ ] `dotnet test` (and `npm test` for web changes) is green locally
- [ ] Edge cases covered by tests:

## AI assistance
- [ ] No AI help
- [ ] AI helped with (code / tests / review / docs):
- [ ] I read every line of the diff and can explain it
- [ ] No test was deleted, skipped or loosened (or the reason is written above)

"Her satırı okudum ve açıklayabilirim" kutusu dördüncü yazıdaki sorumluluk kuralının pratik hâli. İkinci yer commit geçmişi. Git'in trailer'ları (commit mesajının sonundaki Key: value biçimindeki satırlar) bunun için uygun; AI-Assisted bizim seçtiğimiz bir ad, Git'in bildiği özel bir anahtar değil:

> git commit -m "06: team AI policy and PR template" -m "AI-Assisted: yes"

> git log --format='%h %(trailers:key=AI-Assisted,valueonly,separator=%x2C) %s'
e37343a yes 06: team AI policy and PR template
3d74070  05: package check script, secret hygiene rules
f32516c  04: move wishlist item to cart via ICartService; review instructions
5b4bb5f  03: wishlist module, migration AddWishlists
2137978  03 step 1: wishlist plan and failing tests
b7a95f6  02: context files
e92fbdb  01: isbn experiment
1031c70  main baseline

> git log --format='%(trailers:key=AI-Assisted,valueonly,separator=%x2C)' | sort | uniq -c
   7 
   1 yes

Kural yeni başladığı için sekiz commit'ten yalnız biri işaretli. Bu sayı bir hedef değil; ileride "AI'lı commit'lerden sonra gelen düzeltme commit'leri daha mı sık?" gibi soruları cevaplamak için bir veri. Sayıyı hedefe çevirdiğin anda, girişteki senaryodaki gibi herkes her commit'e trailer eklemeye başlar ve veri anlamını kaybeder.

Etkiyi Ölçmek: Neye Bakmalı, Neye Bakmamalı

AI'ın ekibe etkisini ölçmek için yeni metrik icat etmeye gerek yok; teslim performansını zaten ölçen metrikler en iyi göstergeler. DORA'nın güncel tanımlarıyla beş metrik var. Throughput tarafında change lead time (bir değişikliğin commit'ten production'a çıkma süresi), deployment frequency (deploy sıklığı) ve failed deployment recovery time (başarısız bir deploy'dan sonra toparlanma süresi). Instability tarafında change fail rate (acil müdahale gerektiren deploy oranı) ve deployment rework rate (production'daki bir sorun yüzünden yapılan plansız deploy oranı). Bunların nasıl ölçüldüğü CI/CD Temelleri serisinin 8. yazısında anlatılıyor.

AI için bunlara iki gösterge eklerim: pull request başına review süresi ve review'da istenen değişiklik sayısı. AI ile kod üretimi hızlanıp review süresi uzuyorsa darboğaz yer değiştirmiş demektir; üçüncü yazıda söylediğimiz gibi paralel agent sayısını review kapasitesi belirler.

Yanıltıcı metrikler ise kolay ölçülenler: üretilen satır sayısı, öneri kabul oranı, "AI kullanım yüzdesi" ve geliştiricinin kendi hız tahmini. İlk üçü daha çok kod üretildikçe iyi görünür; dördüncüsü METR'in gösterdiği gibi ölçümle ters yönde olabilir. Bunlar araç benimsenmesini takip etmek için işe yarar, verimlilik hedefi olarak kullanıldıklarında ise davranışı yanlış yöne iter.

Maliyeti de aynı tabloya koy. Agent oturumları ve AI review token ya da kredi harcıyor; dördüncü yazıda gördüğümüz gibi Copilot code review'un en yüksek effort seviyesinin pull request başına ortalaması yaklaşık 10 dolar. Ay sonunda "ne kadar harcadık" ile "lead time ve change fail rate ne oldu" sorularını birlikte sor. İkisinden yalnız birine bakmak yanlış karar verdirir.

Junior'lar ve Beceri Kaybı

Anthropic'in 29 Ocak 2026'da yayımladığı randomize deneyde 52 yazılımcı (çoğu junior), bilmedikleri bir Python async library'si olan Trio ile küçük bir görev yaptı; bir grup AI asistanı kullandı, diğeri kullanmadı. Görevden hemen sonra AI'sız bir quiz çözdüler. AI grubunun ortalaması %50, elle yazan grubun %67 oldu; fark en çok debugging sorularındaydı. AI grubu yaklaşık iki dakika daha hızlı bitirdi ama bu fark istatistiksel olarak anlamlı değildi. Yazarlar örneklemin küçük olduğunu ve quiz'in uzun vadeli öğrenmeyi değil görev sonrası anlamayı ölçtüğünü de belirtiyor.

Çalışmanın en işe yarar kısmı, AI'ı nasıl kullandıklarına göre sonuçların ayrışması. İşi tamamen AI'a devredenler ve hataları AI'a çözdürenler düşük puan aldı. Yalnız kavramsal soru soranlar, kodu açıklamasıyla birlikte isteyenler ya da kodu ürettikten sonra onu anlamak için soru soranlar yüksek puan aldı. Yani sorun AI'ın kendisi değil, düşünmeyi tamamen ona bırakmak.

Bookstore'da junior'lar için kurallar bu bulgudan çıkıyor. Öğrenme amaçlı bir görevde önce 30 dakika kendin dene ve testleri kendin yaz. AI'dan kod istediğinde, kabul etmeden önce her satırı reviewer'a anlatabilecek hâle gel; anlatamıyorsan sor. Hata ayıklarken hatayı modele yapıştırmadan önce stack trace'i kendin oku ve bir hipotez kur. Senior'un rolü de değişiyor: junior'un pull request'inde yalnız kodu değil, "bunu neden böyle yaptın" sorusunun cevabını da review etmek. Junior'un açıklayamadığı bir diff, AI'ın yazıp junior'un yalnız ilettiği bir diff'tir.

Ne Zaman Kullanmamalı

Bazı işlerde AI'ı kullanmamak ya da yalnız ek kontrolle kullanmak daha iyi sonuç veriyor:

• Güvenlik açısından kritik kod: authentication (kimlik doğrulama), authorization (yetkilendirme), ödeme ve kriptografi. Hatanın bedeli yüksek, makul görünen ama yanlış kod burada en tehlikeli hâlinde. Kullanılacaksa iki insan onayı, biri alanı bilen birinden.
• Net olmayan gereksinim: agent belirsizliği sessizce bir varsayımla kapatır; üçüncü yazıdaki Quantity alanı gibi. Önce Product Owner ile netleştir.
• Çok küçük değişiklik: tek satırlık bir düzeltmeyi agent'a tarif etmek, onu yazmaktan uzun sürer ve review maliyeti eklenir.
• Öğrenme amaçlı görev: amaç kodu değil beceriyi üretmekse, işi AI'a devretmek amacı ortadan kaldırır.
• Codebase'i en iyi bildiğin, kalite çıtası yüksek, uzun soluklu bir sistemdeki ince bir değişiklik: METR'in 2025 ortamı tam olarak buydu.

Liste "AI kötü" demiyor; AI'ın doğruluğu ucuz kontrol edilebilen işlerde en çok kazandırdığını, kontrolün pahalı ya da imkânsız olduğu işlerde ise riskin arttığını söylüyor.

Üretimde Dikkat

Politikanın teknik karşılıkları olmalı; yazılı ama uygulanmayan bir politika, hiç olmamasından daha kötü bir güven duygusu verir. Bookstore'da politikadaki her maddenin bir kontrolü var: secret'lar için secret scanning ve push protection, paketler için eng/check-packages.cs ve NuGetAudit, testler için CI, AI review için branch protection'da zorunlu insan onayı, agent'lar için onaylı komut ayarları. Bir maddenin kontrolü yoksa, ya kontrolünü ekle ya da maddenin yalnız bir öneri olduğunu açıkça yaz.

Ölçümü ekip düzeyinde tut. Kişi bazında "AI ile ne kadar hızlandın" dashboard'u, insanları ölçüme göre davranmaya iter ve dürüst geri bildirimi bitirir. Ekip retrospektiflerinde AI ile ilgili bir soru sormak (bu sprint AI nerede zaman kazandırdı, nerede kaybettirdi?) çoğu zaman daha güvenilir bilgi verir.

Sık Düşülen Tuzaklar

• AI kullanımını zorunlu metrik ya da hedef yapmak: oran yükselir, teslim performansı yerinde sayar ya da kötüleşir.
• Araç değişikliklerini her ay ekip pratiğine yansıtmak: kimse hangi kuralın geçerli olduğunu bilmez.
• Satır sayısı ve öneri kabul oranıyla verimlilik ölçmek.
• Politikayı yazıp teknik kontrollerini kurmamak.
• Junior'ların öğrenme görevlerini de agent'a devretmesine göz yummak.
• Maliyeti ve teslim metriklerini ayrı ayrı izlemek.

Küçük Bir Deneme

★☆☆ Ekibin için bu yazıdaki politikanın 15 satırı geçmeyen bir taslağını yaz ve her maddenin yanına onu hangi teknik kontrolün koruduğunu not et. Kontrolü olmayan maddeler hangileri?

★★☆ Son üç ayın pull request'lerinden change lead time'ı ve pull request başına review süresini çıkar (GitHub'ın pull request verisi ya da kullandığın platformun API'si yeterli). AI kullanımının yaygınlaştığı dönemden önce ve sonra ikisi nasıl değişmiş?

★★★ Ekipteki bir junior ile bir öğrenme görevi seç. Görevi önce AI olmadan yapsın, sonra aynı türden ikinci bir görevi yalnız kavramsal sorular sorarak AI ile yapsın. İki görevin sonunda debugging ağırlıklı kısa bir soru seti hazırla ve sonuçları birlikte konuşun.

Seri burada bitiyor. Altı yazıda araçtan bağımsız bir çerçeve kurduk: doğru beklenti, agent'a context, plan ile çalışmak, review, güvenlik ve ekip. Belirli bir aracın ayarlarını, permission mode'larını ve iş akışlarını ayrıntılı görmek istersen Claude Code ve OpenAI Codex serilerine, sohbet arayüzlerini günlük işte kullanmak için Claude ile Çalışmak ve ChatGPT ile Çalışmak serilerine, kendi agent'ını ve MCP server'ını yazmak için de AI Agent'ları ve MCP serisine geçebilirsin.