Kod asistanı lisansı almak dönüşüm değildir: AI destekli SDLC'yi adım adım kurmak

Bahar aylarında kırk kişilik ekibe kod asistanı lisansı alınır. Sonbaharda yönetim toplantısında aynı soru gelir: verimlilik nereye gitti? Sürüm takvimi aynı, review kuyruğu daha uzun, test kapsamı yerinde sayıyor. Lisans panosu ise yeşil: herkes aracı açmış, öneriler kabul edilmiş, satırlar yazılmış.

Bizim pozisyonumuz şu: lisans, tek tek geliştiricilerin yazma hızını değiştirir. Ekibin nasıl teslim ettiğini değiştiren şey ise repoya giren dosyalar ve ekibin üzerinde anlaştığı kurallardır. Bu yazıda teslimat yaşam döngüsünün her adımı için AI'a neyi verdiğimizi, neyi insanda tuttuğumuzu ve bunu tekrarlanabilir yapan somut dosyayı anlatıyoruz. Örnek olarak iOS, Android ve küçük bir BFF servisi olan hayali bir perakende uygulaması reposu kullanacağız.

Lisans alındı, teslimat aynı kaldı

Lisanstan altı ay sonra büyük ekiplerde sık gördüğümüz repo aşağı yukarı böyle görünür:

retail-app/
├── CLAUDE.md                        # bir kişi ekledi, 600 satır, yarısı eskimiş
├── .github/
│   └── copilot-instructions.md      # başka biri ekledi, CLAUDE.md ile çelişiyor
├── README.md                        # kurulum adımları iki Xcode sürümü önce çalışıyordu
├── ios/
├── android/
└── bff/

PR #2147  "Sepet ekranı refactor"
  +1.840  −212   27 dosya
  Açıklama: "Sepet akışı yenilendi."
  Review: 1 onay, 4 dakika sonra

Tablonun parçaları tanıdıktır. Üç dört meraklı aracı gerçekten iyi kullanıyor, her birinin kendi makinesinde kendi prompt'ları var. Ekibin geri kalanı otomatik tamamlamayı açık bırakmış, gerisine dokunmamış. Talimat dosyaları kişisel inisiyatifle eklenmiş, kimse sahiplenmiyor. Review süreci, test stratejisi ve sürüm adımları lisanstan önceki hâliyle duruyor.

Sonuç tahmin edilebilir. Kod daha hızlı yazılıyor, PR'lar büyüyor, review yapan iki kıdemli kişi aynı iki kişi. Darboğaz yazmaktan okumaya taşınıyor ve teslimat süresi kıpırdamıyor. Yönetimin gördüğü tek metrik "kabul edilen öneri sayısı" olduğu için de kimse sorunun nerede olduğunu gösteremiyor.

Yaşam döngüsünün haritası: hangi adımda AI'a ne veriyoruz

Dönüşüm dediğimiz şey, aşağıdaki tablonun son sütunundaki dosyaların repoda var olması ve ekipçe kullanılmasıdır. İlk iki sütun bugünkü araçların makul biçimde üstlenebildiği işleri ve insanda kalması gerekenleri gösteriyor.

Sırayla hepsine girişmeyin. Biz kodlama, review ve test satırlarıyla başlıyoruz, çünkü üçünün de çıktısı PR'da görünür ve ölçülebilir. Gereksinim ve operasyon satırları daha fazla veri erişimi ister (ticket sistemi, crash raporları, loglar), bu da veri sınıflandırması ve yetki sorularını beraberinde getirir. O soruların cevabı yazılı değilse önce AI kullanım politikası yazısındaki işi yapın.

Tablonun her satırında aynı örüntü var: AI taslağı üretir, insan kararı verir, dosya da bunun kişiden kişiye değişmemesini sağlar. Dosya yoksa o adım "Ayşe iyi prompt yazıyor" seviyesinde kalır.

Çoğu ekibin atladığı temel: agent'ın okuyabildiği bir repo

Agent, ekibe bugün katılmış ve kimseye soru soramayan bir mühendis gibidir. Slack geçmişini bilmez, "o script'i çalıştırmadan önce şu ortam değişkenini ayarla" bilgisini duymamıştır. Repoda yazmayan şey onun için yoktur. Bulut tarafında çalışan agent'lar bunu daha da görünür kılar: her görev temiz bir sanal makinede, temiz bir checkout'la başlar. Örneğin GitHub'ın Copilot cloud agent'ı ortamını, içinde copilot-setup-steps adlı bir job bulunan .github/workflows/copilot-setup-steps.yml dosyasından hazırlar; build'iniz kimsenin yazmadığı adımlar gerektiriyorsa bunu o dosyayı yazarken öğrenirsiniz.

Agent'a yaptıramadığınız build'i, yeni başlayan mühendise de bir günde yaptıramazsınız.

İlk iş, tek komutla çalışan ve etkileşim istemeyen bir doğrulama script'idir:

#!/usr/bin/env bash
# scripts/verify.sh: temiz checkout'tan çalışır, hiçbir soru sormaz.
set -euo pipefail

target="${1:-all}"

case "$target" in
  ios)
    xcodebuild test \
      -workspace ios/Retail.xcworkspace \
      -scheme RetailApp \
      -destination 'platform=iOS Simulator,name=iPhone 17' \
      -quiet
    ;;
  android)
    (cd android && ./gradlew --no-daemon lint testDebugUnitTest)
    ;;
  bff)
    (cd bff && npm ci && npm test)
    ;;
  all)
    "$0" ios && "$0" android && "$0" bff
    ;;
  *)
    echo "kullanım: verify.sh [ios|android|bff|all]" >&2
    exit 2
    ;;
esac

Bu script'in değeri, agent'ın kendi işini kontrol edebilmesidir. Test çalıştıramayan agent, derlenip derlenmediğini bilmediği kodu size teslim eder; siz de bunu review'da ya da CI'da öğrenirsiniz. Sınaması basit: repoyu boş bir dizine klonlayın, README'ye bakmadan script'i çalıştırın. Geçmiyorsa agent için de geçmeyecek.

Gerisi yazılı hâle getirme işidir. Ekibin kafasındaki kuralları (hangi katman hangisini import edebilir, hata nasıl taşınır, test adı nasıl verilir) kısa maddeler olarak yazın. Mimari notu tek sayfada tutun: module'ler, bağımlılık yönü, dokunulmaması gereken yerler. Dördüncü madde en pahalısıdır: küçük module'ler. Agent da insan gibi, tek bir özelliği anlamak için on bin satır okumak zorunda kaldığında hata yapar; yalnız o bunu size söylemez, makul görünen bir tahmin yazar. Module sınırları net bir repoda görev "şu module'de, şu arayüzün arkasında" diye tarif edilebilir ve agent yalnızca o module'ün testlerini çalıştırarak kendini doğrular.

Aynı kurallar, her araçta: ortak talimat dosyaları

Bugünkü araçların hepsi repodaki bir talimat dosyasını her oturumun başında okuyor. Dosya adları farklı, fikir aynı. Biz kuralları araçtan bağımsız tek bir dosyada, AGENTS.md içinde tutuyoruz. AGENTS.md düz Markdown'dır, zorunlu alanı yoktur, repo köküne konur; monorepo'da alt dizinlere de konabilir ve en yakın dosya geçerli olur. Format bugün Linux Foundation çatısındaki Agentic AI Foundation tarafından yürütülüyor; Copilot ve Cursor dokümantasyonları da bu dosyayı okuduklarını belirtiyor.

# Retail App: agent talimatları

## Doğrulama
- Her değişiklikten sonra ilgili hedefi çalıştır: `./scripts/verify.sh ios|android|bff`
- Script geçmeden işi bitmiş sayma. Geçiremiyorsan nedenini yaz, testi silme ya da kapatma.

## Mimari
- Module haritası ve bağımlılık yönü: docs/architecture.md
- Feature module'leri birbirini import etmez. Ortak ihtiyaç `Core*` module'lerine gider.
- Ağ çağrısı yalnızca repository katmanında yapılır.

## Kurallar
- Yeni bağımlılık (SPM paketi, Gradle kütüphanesi, npm paketi) ekleme; gerekiyorsa PR açıklamasında öner.
- Public API'yi değiştiren her değişiklikte docs/ altındaki ilgili sayfayı güncelle.
- Görev tarifinde olmayan dosyalara dokunma. Gördüğün başka sorunları PR açıklamasında listele.

## Yasaklar
- `main` ve `release/*` branch'lerine push etme.
- `.env`, `secrets/` ve imzalama dosyalarını okuma; `.github/workflows/` altını değiştirme.
- Üretim ortamına istek atan komut çalıştırma.

Claude Code için ayrı bir kopyaya gerek yok. Dokümantasyona göre Claude Code, çalışma dizininde ya da üstünde CLAUDE.md yoksa AGENTS.md'yi doğrudan okuyor (v2.1.277 ve sonrası). Araca özel ek talimatınız varsa CLAUDE.md içinde import söz dizimiyle aynı dosyayı içeri alırsınız:

@AGENTS.md

## Claude Code
- `ios/Payments/` altındaki değişikliklerde önce plan çıkar, onay bekle.

Aynı dokümantasyon dosya başına 200 satırın altında kalmayı öneriyor; uzun dosyalar bağlamı tüketiyor ve kurallara uyumu düşürüyor. Yalnızca belirli dosyalarda geçerli kurallar için üç araç da yol bazlı kural dosyası sunuyor. Aynı kural üç araçta şöyle yazılır (her bölümün ilk satırı dosyanın yolunu gösteren etikettir, dosyaya girmez):

# .claude/rules/ios-tests.md  (Claude Code)
---
paths:
  - "ios/**/*Tests.swift"
---
- Yeni testleri Swift Testing ile yaz; mevcut XCTest dosyalarını çevirme.
- Ağ çağrısı yapan test yazma, `Fixtures/` altındaki JSON'ları kullan.

# .github/instructions/ios-tests.instructions.md  (GitHub Copilot)
---
applyTo: "ios/**/*Tests.swift"
---
- Yeni testleri Swift Testing ile yaz; mevcut XCTest dosyalarını çevirme.
- Ağ çağrısı yapan test yazma, `Fixtures/` altındaki JSON'ları kullan.

# .cursor/rules/ios-tests.mdc  (Cursor)
---
description: iOS test kuralları
globs: ios/**/*Tests.swift
alwaysApply: false
---
- Yeni testleri Swift Testing ile yaz; mevcut XCTest dosyalarını çevirme.
- Ağ çağrısı yapan test yazma, `Fixtures/` altındaki JSON'ları kullan.

Copilot tarafında repo geneli talimatlar .github/copilot-instructions.md dosyasında durur. Hangi Copilot özelliğinin hangi dosyayı okuduğu ürüne göre değişiyor (GitHub, yol bazlı talimatların GitHub.com'da yalnızca cloud agent ve code review tarafından kullanıldığını belirtiyor), bu yüzden kendi kullandığınız yüzeyi dokümantasyondaki destek tablosundan kontrol edin. Ekipte iki araç varsa kuralın kopyaları kaçınılmazdır; kopyaları kısa tutun ve hepsini aynı kişiye sahiplendirin.

Bu dosyaların ne olmadığını da bilin. Claude Code dokümantasyonu açık söylüyor: talimat dosyaları bağlamdır, zorlanan yapılandırma sayılmaz. AGENTS.md'ye "main'e push etme" yazmak bir ricadır. Zorlayan mekanizmalar bir sonraki bölümlerde.

Komut kütüphanesi repoda durur

Meraklıların makinesindeki iyi prompt'lar ekibin malı olmadıkça ölçeklenmez. Tekrarlanan işleri (PR hazırlama, ticket inceleme, sürüm notu) repoya adlandırılmış komut olarak koyuyoruz. Claude Code'da bunun yeri .claude/skills/<ad>/SKILL.md dosyasıdır; eski .claude/commands/*.md dosyaları da çalışmaya devam ediyor.

---
name: pr-hazirla
description: Mevcut branch için ekip şablonuna uygun PR açıklaması hazırlar.
disable-model-invocation: true
---

## Değişiklikler

!`git diff origin/main...HEAD --stat`

## Yapılacaklar

1. Değişen hedefler için `./scripts/verify.sh` çalıştır, sonucu not et.
2. `.github/pull_request_template.md` şablonunu doldur.
3. "AI kullanımı" bölümüne hangi dosyaların agent tarafından üretildiğini
   ve hangi adımların elle doğrulanması gerektiğini yaz.
4. Diff 400 satırı aşıyorsa mantıklı bir bölme öner, PR'ı açma.

disable-model-invocation: true komutun yalnızca biri /pr-hazirla yazdığında çalışmasını sağlar. Copilot'taki karşılığı .github/prompts/ altındaki *.prompt.md dosyalarıdır; GitHub bunları hâlâ public preview olarak işaretliyor ve yalnızca VS Code, Visual Studio ve JetBrains IDE'lerinde destekliyor. Hangi aracı kullanırsanız kullanın ilke aynı: komut repoda durur, PR ile değişir, review'dan geçer.

Çalışma anlaşmaları: hesap kimde, agent neye dokunamaz

Dosyalar ekibin neyi nasıl yaptığını tarif eder. Çalışma anlaşmaları ise kimin neden sorumlu olduğunu. Bunları bir sayfaya yazıp ekipçe kabul etmeden pilot başlatmıyoruz.

Kodu kim ya da ne yazmış olursa olsun, PR'ı açan kişi her satırın sahibidir.

"Bunu agent yazdı" bir review cevabı olarak kabul edilmez. PR'ı açan kişi diff'in tamamını okumuş, çalıştırmış ve açıklayabiliyor olmalıdır. Açıklayamadığı kod merge edilmez. AI çıktısına yeni başlamış bir mühendisin işine davrandığımız gibi davranıyoruz: hızlı, çoğu zaman işe yarar ve her zaman review'dan geçer.

İkinci anlaşma beyandır. Reviewer nereye daha dikkatli bakacağını bilmeli:

## Ne değişti ve neden

## Nasıl doğrulandı
- [ ] `./scripts/verify.sh` yerelde geçti (hedef: ...)
- [ ] Elle denendi: (cihaz, senaryo)

## AI kullanımı
- Agent'ın ürettiği kısımlar: (dosyalar ya da "yok")
- Satır satır okuduğum kısımlar:
- Emin olamadığım, reviewer'ın özellikle bakmasını istediğim yer:

## Risk
- [ ] Ödeme, kimlik doğrulama, kişisel veri ya da migration içeriyor

Bu şablon .github/pull_request_template.md olarak repoya girer. "AI kullanımı" bölümü reviewer'ın dikkatini yönlendirir ve üç ay sonra hangi tür işlerde agent'ın iyi sonuç verdiğini görmenizi sağlar. Buraya yazdığı şey yüzünden kimse suçlanmaz.

Üçüncü anlaşma agent'ın sınırlarıdır ve ricaya bırakılmaz. Claude Code'da izin kuralları repoya giren .claude/settings.json dosyasında durur:

{
  "permissions": {
    "allow": [
      "Bash(./scripts/verify.sh *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Edit(/.github/workflows/**)",
      "Bash(fastlane *)"
    ]
  }
}

Kurallar deny, ask, allow sırasıyla değerlendirilir ve ilk eşleşen kazanır. Yalnız dokümantasyonun kendi uyarısını ciddiye alın: Bash kuralları agent'ın yazdığı komut metniyle eşleşir, aynı programın başka biçimde çağrılmasını (sh -c içinden ya da tam yoluyla) yakalamaz ve bir güvenlik sınırı sayılmaz. Gerçek çit sunucu tarafındadır: main ve release/* için branch koruması, zorunlu status check'ler, CODEOWNERS onayı. Agent'ın kullandığı token'ın yetkisi de dar olmalıdır. İmzalama sertifikaları, mağaza anahtarları ve üretim kimlik bilgileri agent'ın çalıştığı ortamda hiç bulunmaz; bulunmayan şey sızmaz.

Dördüncü anlaşma review derinliğidir. Her PR'a aynı özeni göstermek mümkün olmadığı için risk sınıfı tanımlıyoruz: ödeme, kimlik doğrulama, kişisel veri ve migration içeren değişikliklerde iki insan onayı ve satır satır okuma; düşük riskli mekanik değişikliklerde AI ilk geçişi artı bir insan onayı. Review tarafının ayrıntısını AI ile kod review yazısında anlatıyoruz.

CI'da ilk geçiş review'u

Review darboğazını hafifletmenin yolu, insan reviewer'a gelen PR'ın bariz sorunlardan arınmış gelmesidir. Aşağıdaki workflow, Claude Code'un GitHub Action'ını dokümantasyondaki örneğe göre kurar: PR açıldığında ya da güncellendiğinde review plugin'ini çalıştırır ve bulguları PR üzerinde satır yorumu olarak bırakır.

name: AI ilk geçiş review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Üç ayrıntı önemli. contents: read olduğu için bu job kod değiştiremez, yalnızca yorum bırakır. Review, repodaki talimat dosyasını okuduğu için "feature module'leri birbirini import etmez" kuralı burada da geçerlidir; kuralı bir yere yazıp iki yerde kullanırsınız. Açık repolarda GitHub, fork'tan gelen PR'lara secret vermediği için job yalnızca aynı repodaki branch'lerde çalışır. Copilot kullanan ekiplerde karşılığı Copilot code review'dur ve o da .github/copilot-instructions.md ile yol bazlı talimat dosyalarını okur.

Bu job'ı zorunlu status check yapmayın. AI review'unun bulguları bir öneri listesidir; yanlış pozitif üretir ve atladığı şeyler olur. Zorunlu olan, verify.sh çalıştıran job ile insan onayıdır. Mimari kuralları lint ya da derleme zamanı kontrolleriyle zorlamak ayrı bir iştir ve AI review'undan daha güvenilirdir.

Aşamalı yaygınlaştırma: ne yapılır, ne ölçülür

Dört aşamada ilerliyoruz. Her aşamanın bir çıkış koşulu var; koşul sağlanmadan sonrakine geçmiyoruz.

Aşama 0: baz ölçüm

Hiçbir şeyi değiştirmeden önce mevcut durumu kaydedin, yoksa altı ay sonra "iyileşti mi" sorusuna yalnızca his ile cevap verirsiniz. Git ve CI geçmişinden çıkarabileceğiniz ölçüler yeterlidir: PR açılışından merge'e geçen süre, ilk review'a kadar bekleme süresi, PR başına değişen satır, revert edilen PR oranı, CI'ın ilk denemede geçme oranı. Teslimat tarafında DORA'nın beş ölçüsü (change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate) iyi bir çerçevedir. En az iki üç aylık geçmişi alın. Ayrıntısı AI verimliliğini ölçmek yazısında.

Aşama 1: tek ekip, bir ya da iki adım

Gönüllü bir ekip ve dar bir kapsam seçin. Bizim tercihimiz mevcut koda test yazımı ile CI'daki ilk geçiş review'u: ikisi de düşük riskli, çıktısı PR'da görünür. Bu aşamada verify.sh, AGENTS.md ve PR şablonu yazılır. Ölçtükleriniz: aynı baz metrikler yalnızca bu ekip için, AI review yorumlarından kaçının işe yaradığı (PR'da "çözüldü" ya da "geçersiz" olarak işaretlenenlerin sayımı yeter) ve ekibin haftalık kısa notu: agent nerede zaman kazandırdı, nerede yanlış yöne gitti. Çıkış koşulu: ekip dosyaları her gün kullanıyor ve talimat dosyası en az birkaç kez PR ile güncellenmiş.

Aşama 2: kurallar ve şablonlar

Pilotta öğrenilenler kalıcı hâle gelir: çalışma anlaşmaları yazılır, izin dosyası ve branch koruması devreye girer, komut kütüphanesi repoya taşınır, talimat dosyalarına bir sahip atanır. Kullanım oranı bu aşamada az şey söyler; kural ihlallerinin nerede yakalandığına bakın. Agent talimatta yazan bir kuralı çiğnediyse bunu AI review'u mu, insan reviewer mı, yoksa üretim mi yakaladı? Yakalama noktası sola kayıyorsa sistem çalışıyor demektir.

Aşama 3: genişleme

Diğer ekipler aynı dosyaları kendi repolarına uyarlar. Burada iki şeye bakıyoruz. Birincisi, baz metriklerin ekip bazında seyri: review bekleme süresi ve PR boyutu en erken bozulan iki göstergedir. İkincisi, kıdemli mühendislerin takvimi: review'a ayırdıkları süre artıyorsa darboğaz oraya taşınmıştır ve genişlemeyi yavaşlatıp ilk geçiş review'unu ve PR boyutu sınırını sıkılaştırmanız gerekir.

Sık gördüğümüz bozulma biçimleri

Araç bolluğu ilk sırada gelir. Dört ayrı asistan, her biri kendi talimat dosyasıyla, kimsenin güncellemediği dört kural kopyası demektir. En fazla iki araç seçin, kuralları AGENTS.md'de toplayın, araca özel dosyaları ince tutun.

İkincisi main'e doğru "vibe coding": geliştirici agent'a geniş bir görev verir, çıkan diff'i okumadan PR açar, reviewer büyük diff'i görüp onaylar. Belirtisi yazının başındaki PR'dır: 27 dosya, bir satır açıklama, dört dakikada onay. Çaresi PR boyutu sınırı, beyan bölümü ve "açıklayamadığın kodu merge etme" kuralıdır.

Üçüncüsü review darboğazının kıdemlilere taşınması. Kod üretimi hızlanır, okuma kapasitesi aynı kalır. Bunu review bekleme süresinden ve en çok review yapan iki üç kişinin payından görürsünüz.

Dördüncüsü güvenlik kör noktaları. Agent'ın okuduğu her dosya, prompt'la birlikte model sağlayıcısına gider. Hangi koşullarda saklandığı kullandığınız plana bağlıdır. Örnek olarak Claude Code dokümantasyonu, ticari planlarda (Team, Enterprise, API) kod ve prompt'ların varsayılan olarak model eğitiminde kullanılmadığını ve standart saklama süresinin 30 gün olduğunu, bireysel planlarda ise eğitim kullanımının kullanıcının ayarına bağlı olduğunu söylüyor; oturum dökümleri ayrıca geliştiricinin makinesinde düz metin olarak tutuluyor. Pratik sonucu: şirket kodunda kişisel hesap kullanılmaz ve .env gibi dosyalar okuma izninin dışında bırakılır. Kendi sağlayıcınızın koşullarını sözleşmeden okuyun. İkinci kör nokta uydurulmuş bağımlılıklardır: agent var olmayan ya da yanlış adlı bir paketi önerebilir. Yeni bağımlılığın insan kararı olması bu yüzden talimat dosyasında yazıyor.

Beşincisi satır saymak. Üretilen satır, kabul edilen öneri ya da "AI ile yazılan kod yüzdesi" çıktı ölçüsüdür ve agent'lar satır üretmekte çok cömerttir. Bu metrikleri hedef yaptığınızda daha büyük PR ve daha fazla review yükü alırsınız.

Nerede durmalı

Beş kişilik, tek repolu bir ekipte bu yapının tamamı fazladır: verify.sh, kısa bir AGENTS.md ve PR şablonundaki beyan bölümü yeter. CI'daki AI review'unu, yorumlarının büyük kısmı geçersiz çıkıyorsa kapatın ya da kapsamını daraltın; gürültü üreten bir bot, ekibi bütün bot yorumlarını yok saymaya alıştırır. Üretim erişimi olan agent'lar, otomatik merge ve mağaza gönderimi bizim bugün agent'a vermediğimiz işlerdir; bunları açmak için önce yukarıdaki dört aşamanın oturmuş olması gerekir.

Pazartesi için kontrol listesi

• Repoyu boş bir dizine klonladım; tek komutla (./scripts/verify.sh) build ve test çalışıyor.
• Repo kökünde 200 satırın altında bir AGENTS.md var; içinde doğrulama komutu, mimari özet, kurallar ve yasaklar yazıyor.
• Ekipte kullanılan her araç bu dosyayı okuyor (doğrudan ya da CLAUDE.md içinden import ile); araca özel kopyaların sahibi belli.
• .github/pull_request_template.md içinde "Nasıl doğrulandı" ve "AI kullanımı" bölümleri var.
• main ve sürüm branch'leri korumalı; agent'ın kullandığı token bu branch'lere push edemiyor.
• Secret'lar, imzalama dosyaları ve üretim kimlik bilgileri agent'ın çalıştığı ortamda bulunmuyor; izin dosyasında okuma yasağı tanımlı.
• Şirket kodunda kişisel hesap kullanılmadığı ve sağlayıcının veri saklama koşulları teyit edildi.
• Son iki üç ayın baz metrikleri (PR süresi, ilk review bekleme süresi, PR boyutu, revert oranı) bir yere yazıldı.
• Pilot ekip ve pilotun kapsadığı bir ya da iki adım belli; çıkış koşulu yazılı.
• "PR'ı açan kişi her satırın sahibidir" kuralı ekipçe konuşuldu ve yazıldı.
• Satır sayısı ve kabul edilen öneri sayısı hiçbir raporda hedef olarak geçmiyor.