AI Kodlama Araçları Nasıl Benimsenir: Pilottan Üretime

AI kodlama araçlarını mevcut bir mühendislik organizasyonuna yaymak, araçlar yüzünden değil ikincil maliyetler yüzünden tökezler. İnceleme kuyrukları uzar, insan eliyle yazılmış kod varsayımıyla kurulmuş güvenlik kontrolleri yeni yüzeyi kapsamaz ve verimlilik hikâyesi pilot sunumundaki gibi çıkmaz: METR’in randomize çalışması, deneyimli geliştiricilerin kendi depolarında AI yardımı kullanmalarına izin verildiğinde işleri %19 daha uzun sürede bitirdiğini ölçtü; üstelik geliştiriciler daha hızlı olacaklarını bekliyordu. METR o tahmini sonradan genişletti ve ters yöne işaret eden bir takip çalışması yayımladı. Verimlilik etkisinin büyüklüğünü tartışmalı kabul edin; planlayabileceğiniz kısım ikincil maliyetlerdir.

Platform veya mühendislik liderleri için işe yarayan varsayılan dar bir çerçevedir. Lisanslardan önce inceleme kapasitesini ve güvenlik kontrollerini fonlayın, kritik yolda olmayan tek bir takımla sekiz haftalık pilot yürütün ve production kod üretimi yerine dokümantasyon ile test üretiminden başlayın. Aşağıdaki hazırlık puanlaması, pilot kapsamı, inceleme yönlendirmesi, güvenlik kontrolleri ve metrikler bu varsayılanın etrafında kuruldu; bu varsayılanı değiştirmesi gereken koşullar da yazının sonunda.

Pilot Öncesi Hazırlık Değerlendirmesi#

Puanlanmaya Değer Üç Boyut#

Herhangi bir AI aracına dokunmadan önce, aşağıdaki değerlendirme çerçevesi hazırlık açıklarını ortaya çıkarır:

Boyut	Sinyal	Skor
Kod inceleme olgunluğu	48 saatlik inceleme süresi, 1:4 inceleyici-geliştirici oranı, kısmi CI/CD otomasyonu	6/10
Güvenlik duruşu	Gizli ve bağımlılık taraması aktif, SAST/DAST yok, 4 saatlik olay müdahale süresi	5/10
Takım dinamikleri	1:3 senior-junior oranı, değişime orta düzeyde açıklık, önceki araç benimsemeleri başarılı, zayıf dokümantasyon kültürü	4/10

Genel hazırlık: 5/10.

Genel skorun 6’nın altına düşmesi, lisans almadan önce inceleme kapasitesini düzeltme sinyalidir.

Faz 1: Pilot Program (Hafta 1-8)#

Öncü Takım Seçimi#

Pilotun bileşimi, boyutundan daha belirleyicidir. İşe yarayan bir şablon 6 ila 10 geliştiriciden oluşur: gerçek sorunları bulacak 2 senior şüpheci, çekirdek verimlilik katmanını oluşturan 4 orta seviye geliştirici ve coşku ile taze bakış açısı katan 2 junior. Takımın güçlü kod inceleme alışkanlıkları, güvenlik farkındalığı, metrik odaklılığı ve deneme isteği olmalı; ayrıca kritik yolun dışında durmalı ki geçici bir verimlilik düşüşünü karşılayabilsin.

Araç Seçim Stratejisi#

Başlangıç için bir değerlendirme matrisi; fiyatlar üreticilerin yayımladığı liste fiyatlarıdır:

Araç	Maliyet	Notlar	Karar
Continue.dev	Ücretsiz, açık kaynak	Tam kontrol; kendi model ucunuzu bağlarsınız	Keşif için buradan başlayın
GitHub Copilot	Kullanıcı başına aylık 19 dolar (Business) artı AI kredisi	Sınırlı kontrol; organizasyon genelinde politikayla yönetilir	Kurumsal standart, en geniş güvenlik yüzeyi
Amazon Q Developer	Kullanıcı başına aylık 19 dolar (Pro)	SOC/HIPAA/PCI uyumlu; doğal AWS entegrasyonu	AWS ağırlıklı şirketler için en iyi
Cursor	Kullanıcı başına aylık 40 dolar (Business)	Çoklu dosya düzenleme	Güçlü ama en pahalı lisans

Üçüncü bir katman daha dar ihtiyaçları kapsar: test otomasyonu için TestRigor (altyapı bazlı fiyatlandırma), dokümantasyon üretimi için Mintlify ve AI destekli kod incelemesi için SonarQube.

Bu lisans fiyatlarını toplam değil taban olarak okuyun. GitHub’ın faturalandırma dokümantasyonu Copilot Business’ı kullanıcı başına aylık 19 dolar ve dahil 1.900 AI kredisi, Copilot Enterprise’ı kullanıcı başına aylık 39 dolar ve dahil 3.900 kredi olarak listeliyor; krediler kurum düzeyinde havuzlanıyor ve havuzun ötesindeki kullanım kredi başına 0,01 dolardan faturalanıyor. Kod tamamlamaları ve sonraki düzenleme önerileri sınırsız ve krediden düşmüyor; yani faturanın değişken kısmı ajan ve sohbet kullanımından geliyor. Yalnızca lisans fiyatına göre sıralanmış bir kısa liste, pilota ajan tabanlı iş akışları girdiği anda yeniden sıralanır.

İlk Lisanstan Önce Kurulacak Güvenlik Kontrolleri#

CVE-2025-53773, GitHub Copilot üzerinden geliştirici makinesinde kod çalıştırmaya varan bir prompt injection yolu; bu kontroller o risk sınıfına göre boyutlandırılmıştır. Üretilen kodu etiketleyip daha sıkı incelemeye yönlendiren bir pipeline en ucuz başlangıç noktasıdır:

# .github/workflows/ai-guvenlik-tarama.yml
name: AI Guvenlik Kontrolleri

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  guvenlik_tarama:
    runs-on: ubuntu-latest
    steps:
      - name: Gizli Tespiti
        uses: trufflesecurity/trufflehog@latest
        with:
          fail_on_finding: true

      - name: AI Kod İsaretleri
        run: |
          # Ekstra inceleme icin AI uretilen kodu isaretle
          if git diff --name-only | xargs grep -l "ai-generated\|copilot\|cursor"; then
            echo "::warning::AI uretilen kod tespit edildi - senior inceleme gerekli"
            echo "AI_GENERATED=true" >> $GITHUB_ENV
          fi

      - name: Guvenlik Acigi Taramasi
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Gelistirilmis İnceleme Gereksinimleri
        if: env.AI_GENERATED == 'true'
        run: |
          gh pr edit ${{ github.event.pull_request.number }} \
            --add-label "senior-inceleme-gerekli,ai-uretilen"

Faz 2: Kod Kalitesi ve İnceleme Akışı#

İnceleme Darboğazı Çözümü#

Üretim hızı inceleme hızını geçtiğinde darboğaz kuyruğa kayar. GitHub’ın Accenture çalışması pull request sayısında %8, derleme başarısında %84 artış ölçtü; yani ek hacim mütevazı olsa da gerçek. Mühendis başına merge edilen pull request sayısını ikiye katlamayı yazılı hedef haline getirmiş bir şirkette yürütülen ve 802 geliştirici ile 196.212 pull request’i kapsayan boylamsal bir çalışma, bu hacmin nereye düştüğünü gösteriyor: kişi başına üretim hızı hedef öncesi taban çizgisinin 2,09 katına çıktı, inceleyici başına yük yaklaşık ikiye katlandı ve otomatik inceleme insan incelemesini geçti. Merge ve geri alma oranları sabit kaldı; yani ek hacmin bedeli hatayla değil inceleyici dikkatiyle ödendi. Riske göre yönlendirme, senior dikkatini gerçekten gereken değişikliklerde tutar:

İnceleme türü	Ne çalışır	Merge’i engeller mi	Süre
Otomatik	Linting, formatlama, tip kontrolü, unit testler	Evet	5 dakikanın altında
AI destekli	SonarQube, DeepCode, CodeGuru; güvenlik, performans ve en iyi uygulamalara odaklı	Hayır; orta güven seviyesi, insan doğrulaması gerekir	Yaklaşık 10 dakika
İnsan kritik	Mimari, iş mantığı, güvenlik hassas değişiklikler; senior ve alan uzmanı inceleyiciler	Evet	Günlük 2-4 saat

Bir pull request önce otomatik kontrollerden, sonra AI destekli bir analizden geçer. Ortaya çıkan risk skoru bir sonraki inceleyiciyi belirler: 30’un altında junior inceleme yeterlidir; 30 ile 70 arasında standart inceleme devreye girer; 70’in üzerinde senior inceleyici AI analiziyle birlikte devralır.

Taban Çizgisine Alınacak Kalite Metrikleri#

Bu ölçümleri pilot başlamadan önce bir kez, sekizinci haftada bir kez daha alın. AI öncesi taban çizgisi yoksa karşılaştıracak bir şey kalmaz ve “araçlar işe yaradı mı” tartışması kazanılamaz hale gelir:

• Hata kaçış oranı: değişen bin satır başına production hatası. En kullanışlı sinyal ve en yavaş kıpırdayanı. Yayımlanmış hiçbir çalışma AI’ya atfedilen bir kaçış oranı vermiyor; yani bu sayı ancak siz ölçerseniz var olur.
• Kod değişim oranı: kısa bir pencere içinde yeniden yazılan yeni merge kodunun payı. GitClear’ın 623 milyon değişen satırlık analizi, iki haftalık değişim oranını 2023 taban çizgisine göre %15 yukarıda; blok tekrarını da milyon değişen satır başına 40,3 tekrarlanan satırdan 73,0’a çıkmış gösteriyor. Bu %81’lik artış, serinin en yüksek değeri.
• Tekrar mı, yeniden düzenleme mi: aynı veri setinde taşınan kod, değişen satırların %21’inden son dönemde %3,8’ine düşerken kopyala-yapıştır %9,4’ten %15,7’ye çıkıyor ve fonksiyon bağlantılılığı %35 geriliyor: bin değişen satır başına 343 metot çağrısından 223’e; yani bir kod tabanı, parçaları birbirini çağırmayı bırakırken de büyüyebilir.
• PR başına güvenlik bulgusu: hem şiddete göre hem de değişikliğin üretilen-kod etiketi taşıyıp taşımadığına göre ayrılmış olarak. Apiiro’nun Fortune 50 depoları üzerindeki analizi, AI destekli kodda yetki yükseltme yollarında %322, mimari tasarım kusurlarında %153 artış bildiriyor; buna karşılık basit sözdizimi hataları %76, mantık hataları %60’ın üzerinde azalıyor. Bulgular şiddet ölçeğinde aşağı değil yukarı kayıyor.
• Test kapsamı ve testin içeriği: önce kapsam kıpırdar. Yeni vakaların mutlu yolun ötesinde bir şey doğrulayıp doğrulamadığına bakın.
• İnceleme gecikmesi: incelemeye hazır olmadan merge’e kadar geçen süre; etiketli ve etiketsiz değişiklikler için ayrı ayrı.

Burada iki kanıt kümesi zıt yönleri gösteriyor ve asıl işe yarayan şey bu uyuşmazlık. GitHub’ın kendi çalışması, beş yıl ve üzeri deneyime sahip 202 geliştiriciyle yürütülen sıfırdan bir görevde Copilot ile yazılan kodun on unit testin hepsini geçme olasılığını %53,2 daha yüksek buldu; okunabilirlik %3,62, bakım yapılabilirlik %2,47 arttı. GitClear ve Apiiro başka bir şeyi ölçüyor: tek bir kontrollü görevi değil, yıllara yayılan depo telemetrisini. İkisi aynı anda doğru olabilir. Hangisinin sizin kod tabanınızı anlattığına kendi taban çizginiz karar verir; ayrıca buradaki her yayıncının cevapta bir çıkarı var, çerçevelemesi bir rakip tarafından açıkça tartışmaya açılan Apiiro dahil.

DORA’nın 2024 araştırması, 2025 raporunda birebir yinelenmiş haliyle, AI benimsemesindeki her %25’lik artış için yazılım teslimat hızında %1,5 düşüş ve teslimat kararsızlığında %7,2 artış tahmin ediyor. 2025 raporu teslimat hızı ilişkisinin o zamandan beri pozitife döndüğünü, kararsızlıkla olan ilişkinin ise sürdüğünü buluyor. İki baskı, yanıtlayanları farklı iki ayrı kesit araştırması; yani bu dönüş, iki anket yılında raporlananın değişmesi demek. Hiçbir baskı bir takımı benimseme eğrisi boyunca izlemiyor ve hiçbiri hata kaçış oranını ya da kod değişim oranını ölçmüyor. Kendi kaçış oranınız ve kod değişim oranınız önce kötüleşip sonra toparlanır mı, bunu yalnızca zaman içinde kendi ölçtüğünüz seri söyler. Bunu sponsorlara baştan söylemek önemli, aksi halde ilk ayın verisi başarısızlık gibi okunur.

Üretilen Kod İçin SonarQube’u Sıkılaştırmak#

SonarQube’da AI’ya özel bir kural paketi yok. Olan şey quality gate; işe yarayan hamle de yeni koda daha sıkı bir gate uygulayıp üretilen değişikliklerin mevcut taban çizgisini seyreltmesini engellemek. Tarayıcı ayarları sıradan kalır:

# sonar-project.properties
sonar.projectKey=ai-ile-uygulama
sonar.sources=src
sonar.exclusions=**/*.test.js,**/node_modules/**

# Gate basarisiz olunca pipeline'i dusur
sonar.qualitygate.wait=true

Eşiklerin kendisi SonarQube quality gate’inde tanımlanır. Yeni kod üzerinde güvenilirlik ve güvenlik derecesi A, incelenmemiş güvenlik hotspot sayısı sıfır ve mevcut proje ortalamanızın üzerinde bir kapsam tabanı olan bir gate kurun, sonra bunu pilottaki depolara atayın. Halüsinasyonlu import’lar ve sabit kodlanmış değerler, gate onları geçirmeyi bıraktığı anda mevcut kural setiyle zaten yüzeye çıkar.

Faz 3: Test Üretimi ve Bakımı#

Doğal Dil Test Tanımları#

TestRigor gibi araçlar, tarayıcı testinin selector tesisatı yerine bir kullanıcı eylemi dizisi gibi okunmasını sağlar. Eleman çözümleme, bekleme durumları ve yeniden denemeler çalışma anında olur; selector tabanlı bir süitin bakım maliyetinin çoğu da tam burada birikir:

tikla "Giris"
gir "kullanici@ornek.com" "E-posta" alanina
gir "sifre123" "Sifre" alanina
tikla "Gonder"
sayfanin "Kontrol Paneli" icerdigini kontrol et
"kullanici@ornek.com" goruntuleniyor mu kontrol et

Bu bir takas; kırılganlık ortadan kalkmaz, yer değiştirir. Selector tabanlı süit, DOM değiştiğinde gürültüyle patlar. Doğal dil süiti ise çözümleyici yanlış elemanı seçene kadar geçmeye devam eder, sonra sebebi zor atfedilen bir şekilde düşer; pahalı olan da bu belirsiz düşüştür. Google’ın test ekibi, kendi ortamlarında tüm test koşumlarının yaklaşık %1,5’inin kararsız (flaky) sonuç verdiğini, testlerin neredeyse %16’sının bir miktar kararsızlık gösterdiğini ve post-submit CI’daki geçti-kaldı dönüşlerinin kabaca %84’ünün kararsız bir testi içerdiğini bildirdi. Bu rakamlar tek bir şirketin unit ve entegrasyon süitlerini anlatıyor ve burada adı geçen her araçtan eski. Doğal dil testini ölçmüyorlar; bir süitin neden düştüğünü söylemeden düştüğünde kestiği vergiyi ölçüyorlar. Bu takasın asıl konusu da o vergi.

Maliyet, kategorinin ima ettiğinden daha zor planlanır. testRigor yayımlanmış bir liste fiyatı sunmuyor: fiyatlandırma sayfası kalkmış, erişilebilir kalan şey eski bir SSS videosu ve sizin girdiğiniz rakamlardan bir sonuç üreten bir hesaplayıcı. Fiyatlandırma altyapı bazlı olduğu için mevcut bir framework ile karşılaştırma bir operasyon maliyeti sorusudur. Kendi sitesinden fiyatlandıramadığınız bir aracı pilot bütçesine koyamazsınız; bunu değerlendirme aşamasında öğrenmek tedarik aşamasından daha ucuzdur.

Promptun Atladığı Kapsam#

toplamHesapla için bir prompt tipik olarak tek bir mutlu-yol vakası döndürür:

it('toplam fiyati hesaplamali', () => {
  const sonuc = toplamHesapla([10, 20, 30]);
  expect(sonuc).toBe(60);
});

Yayına hazır bir versiyon, promptun hiç sormadığı vakaları ister: boş girdi, negatif sayılar, sayısal olmayan girdi, ondalık hassasiyet ve tam sayı tavanı.

describe('toplamHesapla', () => {
  it('gecerli pozitif sayilar icin toplami hesaplamali', () => {
    expect(toplamHesapla([10, 20, 30])).toBe(60);
  });

  it('bos diziyi ele almali', () => {
    expect(toplamHesapla([])).toBe(0);
  });

  it('negatif sayilari ele almali', () => {
    expect(toplamHesapla([-10, 20, -5])).toBe(5);
  });

  it('sayisal olmayan giriste hata firlatmali', () => {
    expect(() => toplamHesapla(['a', 'b'])).toThrow(TypeError);
  });

  it('ondalik hassasiyeti ele almali', () => {
    expect(toplamHesapla([0.1, 0.2])).toBeCloseTo(0.3);
  });

  it('maksimum guvenli tam sayiya saygi duymali', () => {
    expect(() => toplamHesapla([Number.MAX_SAFE_INTEGER, 1]))
      .toThrow(RangeError);
  });
});

Faz 4: DevOps ve İzleme Entegrasyonu#

AI Destekli Olay Müdahalesi#

Editörde işleyen kalıp uyarı yolunda da işler: hipotezi araç taslaklasın, doğrulamada insan kalsın. Bu şekilde kurulmuş bir yapılandırma:

Bileşen	Yapılandırma
Tespit	New Relic AI; 30 günlük tarihsel taban çizgisi; orta hassasiyet; mevsimsel ayrıştırma modeli; Slack, PagerDuty ve e-postaya uyarı
AI destekli özet	Kök neden hipotezi, etkilenen hizmetler ve benzer olayları içerir; başlangıç noktası olarak ele alınır; insan doğrulaması gerektirir
Önerilen düzeltmeler	Önceki olaylar ve dokümantasyondan türetilir; başarı oranı ve yakınlığa göre sıralanır; onay gerektirir

Altındaki uyarı kuralı standart bir New Relic yapılandırmasına yakın kalır: hata oranı taban çizgisi artı 3 standart sapmayı 5 dakika boyunca aştığında tetiklenir, ardından AI geliştirmesi olayı özetler, çözüm önerir, ilişkili sinyalleri otomatik ilişkilendirir ve yalnızca 0,8 güven eşiğinin üzerinde bildirim gönderir.

Bu iş bölümünü destekleyen ölçüm var. EuroSys 2024’te yayımlanan RCACopilot, Microsoft’un Transport servisinden bir yıllık 653 olayı kapsayan veri kümesinde bulut olaylarının kök neden kategorisini 0,766 Micro-F1 ve 0,533 Macro-F1 ile tahmin ediyor; çıkarım yükü de yaklaşık 4,2 saniye. Asıl öğretici kısım taban çizgileri: aynı görevde doğrudan GPT-4’e sorulduğunda skor 0,026 Micro-F1, gömme (embedding) aramasıyla 0,257. Sayıyı yukarı çeken şey arkadaki model değil, ekibin kendi olay geçmişi üzerinde yapılan geri getirme.

Doğrulamada insanın kalma sebebi ise artık kalan kısım. O 653 olayın 163’ünde, yani %25’in biraz altında, sistemin daha önce hiç görmediği bir kök neden kategorisi vardı. Sistem bir kategori tahmini yapıyor, serbest biçimli teşhis yapmıyor. Üstelik Microsoft’un sistemi Microsoft’un olay akışı üzerinde çalışıyor. Bunu “önce taslak, sonra doğrulama” düzeninin ilkece mümkün olduğunun kanıtı olarak okuyun; hiçbir gözlemlenebilirlik üreticisi bu sayıyı size tekrarlamayacak.

Taban çizgisini kendi tespit sürelerinizden kurun. New Relic’in 1.700 uygulayıcıyla yaptığı 2025 Observability Forecast anketi, tam yığın gözlemlenebilirliği olan ekiplerin bir olayı ortalama 28 dakikada tespit ettiğini ve bu ekiplerin diğerlerinden 7 dakika daha hızlı olduğunu; ayrıca bu ekiplerin %23’ünün haftada en az bir yüksek etkili kesinti yaşadığını, gözlemlenebilirliği olmayanlarda bu oranın %40 olduğunu bildiriyor. Bunlar gözlemlenebilirlik benimseme rakamları, AI özetleme rakamları değil. Yayımlanmış hiçbir kaynak, uyarı yolundaki bir asistana MTTR değişimi atfetmiyor; dolayısıyla böyle bir sonuç bildiren pilot, kaynağını gösteremeyeceği bir sayı bildiriyor demektir.

Asıl kontrol noktası güven eşiği. Çok düşük tutarsanız özet gürültüde tetiklenir ve nöbetçiler onu atlamayı öğrenir; çok yüksek tutarsanız birisi dashboard’u zaten açtıktan sonra gelir. Temkinli başlayın ve taslak hipotezin ne kadar hızlı üretildiğini değil, postmortem’den ne sıklıkla sağ çıktığını takip edin.

AI Yardımı ile Infrastructure as Code#

Bu araçlar en erken getiriyi altyapı kodunda verir; çünkü hedef, arkasında derleyici ve synth adımı olan bildirimsel bir construct ağacıdır, dolayısıyla yanlış cevap yayına çıkmadan build aşamasında düşer:

// Elle yazilan CDK: her construct tek tek
export class ManuelYigin extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Her construct'i manuel yazma...
    const vpc = new Vpc(this, 'VPC', { /* ... */ });
    const cluster = new Cluster(this, 'Cluster', { /* ... */ });
    // ... 200 satir daha
  }
}

// Amazon Q ile: dogal dilden CDK'ya, sonra synth ciktisini incele
export class AIDestekliYigin extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Amazon Q promptu: "Uretim-hazir ECS Fargate kurulumu olustur:
    // - 3 AZ'de public/private subnet'lerle VPC
    // - WAF'li ALB
    // - Auto-scaling'li ECS cluster
    // - Read replica'li RDS PostgreSQL
    // - ElastiCache Redis cluster
    // - Tum guvenlik en iyi uygulamalari"

    // Guvenlik kontrolleri dahil uretilen kod
    const vpc = new Vpc(this, 'VPC', {
      maxAzs: 3,
      natGateways: 3,
      flowLogs: {
        destination: FlowLogDestination.toCloudWatchLogs(),
        trafficType: FlowLogTrafficType.ALL
      }
    });

    // ... AI tam, uretim-hazir kurulum uretiyor
  }
}

Faz 5: Güncel Kalan Dokümantasyon#

Koddan ve Testlerden Dokümantasyon Üretmek#

Dokümantasyon en düşük riskli başlangıç noktasıdır; bu yüzden yayılım planında sonda değil başta durmalı. Dokümandaki yanlış bir cümle okunduğu anda düzeltilir, üretilen koddaki yanlış bir dal yayına çıkar. Geliştiriciler kendilerini zaten bu sıraya dizmiş durumda. Stack Overflow’un 49.000’den fazla katılımcıyla yaptığı 2025 anketinde, bir işi artık ağırlıklı olarak AI ile yaptığını söyleyenler arasında kodu belgelemek %30,8, dokümantasyon oluşturmak veya sürdürmek %24,8 pay alıyor; kod yazmak %16,9, commit ve inceleme %10,2’de kalıyor. İnsanların ilk devrettiği iş, hatanın ucuz yakalandığı iş. Git ile senkron üretim ayrıca dokümanı anlattığı kodla aynı inceleme yoluna sokar; böylece sürümler arasında kayması durur. Tipik bir kurulum git senkronunu açık tutar, dokümanı hem koddan hem yorumlardan üretir, OpenAPI spec’ini otomatik oluşturur, örnekleri testlerden çıkarır ve sonucu indekslenmiş, aranabilir bir llms.txt dosyası olarak yayımlar.

Üretilen metin kodun ne yaptığını anlatır, nedenini nadiren anlatır; dolayısıyla mimari karar kayıtları hâlâ elle yazılmak zorunda. llms.txt indeksi yayımlamak, iç dokümantasyonu sunucuya erişebilen her ajan için okunur hale getirir; bu açık bırakılacak bir varsayılan değil, bilerek alınacak bir karardır. DORA’nın 2025 raporu aynı yere ters yönden varıyor: AI’nın erişebildiği iç veriyi, AI’nın etkisini büyüten yetkinlikler arasında sayıyor ve iç dokümantasyonun yapılandırılmış, yönetişimi kurulmuş biçimde açılmasını öneriyor; bu da bir yayımlama işinden çok bir yönetişim işi.

Bir de bu kategorideki sonuç rakamlarına temkinli yaklaşın; neredeyse hepsi üretici tarafından yayımlanıyor. Mintlify’ın Anaconda müşteri hikâyesi, ayda yaklaşık 6.500 AI asistan sorgusunu “önlenen destek talebi” başlığı altında bildiriyor. Oysa bir dokümantasyon sorgusu önlenmiş bir talep değildir; ikisi ölçümle değil varsayımla eşitleniyor. Üretilen dokümana atfedilebilen bir dokümantasyon kapsamı, talep hacmi veya işe alıştırma süresi değişimini ortaya koyan bağımsız bir çalışma yok. Yani bunlar pilotunuzun kendi öncesi-sonrası verisiyle cevaplayacağı sorular listesine girer, devralınacak rakamlar listesine değil.

Araç Orkestrasyonu#

Birden Fazla Aracı Birlikte Çalıştırmak#

Her takım kendi yığınını seçmeye başladığında araç yayılması kaçınılmaz hale gelir. Her aşama için bir birincil araç ve yazılı bir yedek belirlemek, yüzeyi güvenlik ve denetim açısından yönetilebilir tutar:

Aşama	Birincil	Yedek / ayrıntı
Kodlama	Cursor	Yedek olarak Continue.dev; kod üretimi ve tamamlama
İnceleme	SonarQube (otomatik), Snyk (güvenlik), DeepCode (AI)	Çok katmanlı kod incelemesi
Test	Amazon Q (unit), TestRigor (entegrasyon), AI analizli K6 (performans)	Kapsamlı test kapsamı
Dokümantasyon	Mintlify (API), GitBook (kılavuzlar), GitHub Copilot (satır içi)	Canlı dokümantasyon
İzleme	New Relic (APM), Datadog (loglar), AI’lı PagerDuty (olaylar)	Gözlemlenebilirlik ve müdahale

Bir görev önce birincil kodlama aracından geçer. Ardından güvenlik, kalite ve test kontrolleri paralel çalışır, dokümantasyon ortaya çıkan koddan ve testlerden üretilir, son olarak deployment hazırlığı izlemeyi devreye sokar.

Güvenlik Kontrolleri: Ayrıntılar#

Tam Güvenlik Çerçevesi#

Önleyici kontroller commit öncesinde başlar: gitleaks ve trufflehog gizli bilgileri tarar, eslint ve prettier kod kalitesini kontrol eder, özel bir script AI kaynaklı kalıpları işaretler; hepsi başarısızlıkta engeller. IDE varsayılanları Copilot’un herkese açık kod önerilerini ve telemetriyi kapatır, kopya tespitini açık tutar, veri konumunu us-east-1’e sabitler ve trafiği kurumsal proxy üzerinden yönlendirir.

Tespit edici kontroller sürekli tarar: her pull request’te ve main’de saatte bir, Snyk ve GitHub Advanced Security üzerinden, AI kalıpları, eğitim verisi sızıntıları ve halüsinasyonlu import’lar için özel kurallarla. Denetim günlüğü AI araç kullanımını, kod üretimini ve kabul oranını şifrelenmiş, değiştirilemez S3 depolamasına kaydeder.

Müdahale kontrolleri döngüyü kapatır: 5 dakika içinde otomatik gizli anahtar rotasyonu, kod karantinası için otomatik dal koruması, güvenlik takımına, dev lead’e ve CTO’ya bildirim ve 48 saat içinde zorunlu olay sonrası analiz.

Araç Kaynaklı Bir CVE İçin Runbook#

CVE-2025-53773 üzerinde prova yapmaya değer, çünkü alışıldık bağımlılık açığı şeklini tersine çevirir: açığı taşıyan bileşen geliştiricinin editöründe oturan asistandır. Müdahalenin hem lisanslara hem iş istasyonlarına ulaşması gerekir ve durdurma kolunun, bildiri yayımlanmadan önce hazır olması gerekir.

Önceden bilinmesi gereken tek şey şu: GitHub, organizasyon genelinde Copilot politikasını çeviren bir API sunmuyor. Politika, organizasyon ayarları arayüzünde yaşıyor. REST API’nin sunduğu şey lisans yönetimi; dolayısıyla script’lenebilir sınırlama adımı lisansları geri almak:

#!/bin/bash
set -euo pipefail
ORG="ORGANIZASYONUMUZ"

# 1. Sinirlama: Copilot lisanslarini geri al. Politika anahtarlari
#    sadece arayuzde; script'lenebilir kol lisans kaldirma.
#    Lisanslar iptal beklemeye duser ve fatura donemi bitene kadar
#    kullanilabilir kalir; bu yuzden organizasyon politikasini da degistirin.
gh api -X DELETE "/orgs/$ORG/copilot/billing/selected_teams" \
  -f 'selected_teams[]=engineering'

# 2. Lisanslarin gercekten kalktigini dogrula
gh api "/orgs/$ORG/copilot/billing/seats" \
  --jq '.seats[] | select(.pending_cancellation_date == null) | .assignee.login'

# 3. Enjekte edilmis talimatlar icin workspace ayarlarini denetle
for repo in $(gh repo list "$ORG" --limit 1000 --json name -q '.[].name'); do
  gh api "/repos/$ORG/$repo/contents/.vscode/settings.json" 2>/dev/null \
    | jq -r '.content // empty' | base64 -d \
    | grep -qE '(chat\.tools|inject|eval|exec)' \
    && echo "INCELE: $repo"
done

Lisans listesini bireyler yerine takımlar üzerinden tanımlayın; böylece sınırlama tek bir çağrıya iner, bu alışkanlık işi ucuzlatır. Bir de .vscode/settings.json dosyasına, incelemeye tabi her dosyaya davrandığınız gibi davranın; çünkü pull request ile gelen bir workspace ayarı bir çalıştırma yüzeyidir.

Programın Ölçümü#

Gerçekten Önemli Olan Metrikler#

Kod satırı sayısı, kabul oranı ve PR sayısı ilerleme gibi görünür ama değildir. Kod satırı sayısı zaten yapısı gereği artar. Kabul oranı, bir önerinin kaç kez tab’lanarak alındığını kaydeder, incelemeden sağ çıkıp çıkmadığını asla ölçmez; PR sayısı da kuyruğa giren işi ölçer, ki zaten endişelendiğiniz şey odur.

Bunların yerine izlenecekler, hepsi pilot öncesi taban çizgisine karşı:

• Özellik teslimi: ayda production’a ulaşan özellik sayısı, başlatılan özellik değil. Beklenen etki büyüklüğünü de gözden kaçırmayın. 23 çalışmayı ve 27 etki büyüklüğünü birleştiren bir meta-analiz, verimlilik kazancını Hedges’ g = 0,33 (%95 güven aralığı 0,09 ile 0,58) olarak veriyor ve kazancın kontrollü deneylerde açık kaynak ile kurumsal ortamlardakinden daha büyük olduğunu buluyor. Ölçülü ve gerçek, dönüştürücü değil. Aynı analiz anlamlı bir öğrenme etkisi bulmuyor: g = 0,14 ve aralık -0,18 ile 0,47 arasında.
• Olay sayısı ve şiddeti, ayrı ayrı sayılmış olarak. Bir program birkaç büyük olayı birden fazla küçük olayla takas edip yine de önde olabilir. DORA’nın katsayıları, AI benimsemesiyle pozitif ilişkisi süren ölçütün teslimat hızı değil kararsızlık olduğunu gösteriyor; ağırlığı ona göre verin.
• İnceleyici başına inceleme yükü, inceleme gecikmesiyle birlikte ölçülmüş olarak. Yukarıda anılan boylamsal çalışmada inceleyici başına yük yaklaşık ikiye katlanırken merge ve geri alma oranları sabit kaldı; yer değiştirmiş bir darboğaz veride tam olarak böyle görünür.
• Geliştirici memnuniyeti değil, geliştirici güveni. Stack Overflow’un 2025 anketinde olumlu duygu deneyim bantları arasında neredeyse düz: kariyer başında %63,1, orta kariyerde %62,7, on yıl ve üzerinde %59,9. Asıl eğim güvende ve o da sığ: “kesinlikle güvenmiyorum” yanıtları aynı üç bantta %17,5, %19,7 ve %20,7. Genelde katılımcıların %46’sı AI çıktısının doğruluğuna güvenmiyor, %33’ü güveniyor ve toplam duygu bir yılda %70’in üzerinden %60’a düştü: memnuniyet skoru düz görünür ve bir şey söylemez, güven sorusu ise kıpırdar.
• Toplam program maliyeti: lisanslar artı lisans fiyatına dahil olmayan inceleme saatleri, güvenlik işi ve eğitim.

Yenilemelere karar veren maliyet satırıdır ve hiçbir üretici panosunun raporlamadığı satır da odur. İçindeki yalnızca en küçük bileşenin yayımlanmış bir rakamı var. Copilot Business’ta sekiz lisans aylık 8 × 19 = 152 dolar ve 8 × 1.900 = 15.200 havuzlanmış AI kredisi demek; havuzu %20 aşan bir ay buna 3.040 × 0,01 = 30,40 dolar ekler, toplam 182,40 dolar eder. Bunu yukarıdaki yönlendirmenin varsaydığı günlük iki ila dört saatlik senior inceleme yüküyle karşılaştırın: inceleme süresi lisans bedelinden daha pahalıya gelir.

Yayılım Sırası#

Öncelik Sırası#

1. Önce dokümantasyon ve test üretimi, sonra kod üretimi.
2. Kod çıktısını artırmadan önce inceleme kapasitesini büyütün.
3. Üretilen ilk kod satırından önce güvenlik kontrollerini yerleştirin.
4. İlk günden iş çıktılarını taban çizgisine alın; karşılaştırılacak bir “öncesi” hâlâ varken.
5. Kaçış yolunu kurun: lisans iptali ve politika geri alma; ihtiyaç duyulmadan önce bir kez prova edilmiş olarak.

Ertelenen ama ertelenmemesi gereken madde üçüncüsü. Apiiro’nun Fortune 50 depoları üzerindeki analizi, AI destekli geliştiricilerin üç ila dört kat daha fazla commit ürettiğini ve bunları daha az sayıda ama çok daha büyük pull request’lere paketlediğini; AI üretimi koddan gelen yeni güvenlik bulgularının altı ayda on katına çıkarak ayda 10.000’i aştığını; service principal ve depolama erişim anahtarı gibi bulut kimlik bilgilerinin ise yaklaşık iki katı sıklıkta açığa çıktığını buldu. Veracode’un 80 kodlama görevinde 100’den fazla modeli değerlendirmesi, üretilen kodun %45’inin bir güvenlik açığı içerdiğini, en kötü etkilenen dilin %72 başarısızlık oranıyla Java olduğunu gösterdi. İki yayıncı da güvenlik ürünü satıyor ve hiçbir kaynak belirli bir bütçe katsayısını desteklemiyor. Ortaya koydukları şey yön ve sıra: güvenlik yüzeyi lisans sayısından hızlı büyür.

Kazanımlar Önce Nerede Görünür#

Dokümantasyon ve altyapı kodu en erken getiriyi verir, çünkü ikisinin de bir doğrulayıcısı vardır. Doküman açıkta okunur ve düzeltilir. CDK derlenip synth edilir, yani halüsinasyonlu bir construct production’da değil build’de düşer. Uygulama mantığı bu yelpazenin öbür ucundadır: tek doğrulayıcı insan inceleyicidir.

Aynı asimetrinin kıdemde de geçerli olup olmadığı ise gerçekten tartışmalı ve bu anlaşmazlık taraflardan herhangi birinden daha öğretici. Mekanizmayı söylemek kolay: öneri çoğu zaman bir junior’ın ilk taslağından iyidir; kod tabanını derinden bilen geliştiricinin ilk taslağı ise zaten doğruydu, dolayısıyla makul görünen bir alternatifi incelemek cevabı yazmaktan pahalıya gelir. METR’in ölçtüğü yavaşlama tam bu ortamda, çalıştıkları depolarda yaklaşık beş yıllık geçmişi olan geliştiricilerde çıktı. Stack Overflow’un güven eğimi de aynı yöne gidiyor ama sığ: kariyer başında %17,5 olan “kesinlikle güvenmiyorum” yanıtı en deneyimlilerde %20,7’ye çıkıyor.

İki sonuç ise buna itiraz ediyor. 802 geliştiricilik boylamsal çalışma, üretim hızı kazancının junior’larda yoğunlaşmak yerine kıdemler arasında geniş biçimde paylaşıldığını buldu. Google’ın kurumsal ölçekte bir görevde 96 mühendisle yürüttüğü randomize deney ise görev süresinde geniş bir aralıkla birlikte yaklaşık %21 düşüş ölçtü ve günün daha çok saatini kodla ilgili işlere ayıran geliştiricilerin AI ile daha hızlı olanlar olduğunu gösterdi. METR de kendi çalışmasını revize etti: ilk sonuç artık %2 ile %39 daha uzun aralığını taşıyor ve bir takip çalışması geri dönen geliştiriciler için hızlanma tahmin ediyor. METR bu yeni tahmini kendisi de zayıf buluyor; çünkü katılımcılar kendi kendini seçiyor ve bir geliştirici aynı anda birden fazla ajan çalıştırdığında görev süresi güvenilir ölçülemiyor. Kendi güven ve memnuniyet verinizi kıdeme göre ayrıştırın ve bu ayrımı açık bir soru olarak ele alın.

Bu Varsayılan Ne Zaman Geçerli#

Bu varsayılan, çalışan bir kod incelemesi ve güvenilecek bir test süiti olan organizasyonlar için geçerlidir: araçlar var olanı büyütür ve kötü bir önerinin maliyeti, zaten kötü commit’leri yakalayan sürecin sınırları içinde kalır.

İnceleme kapasitesi sabitse üretim kapasitesi eklemek yalnızca kuyruğu uzatır ve pilot, araçları değil kuyruğu ölçmüş olur. Kod tabanının anlamlı bir test kapsamı yoksa araçların yanlışını yakalayacak hiçbir şey yoktur; bu yüzden test kapsamı ön koşuldur. Ve bir uyumluluk rejimi kaynak kodun üçüncü taraf bir uca gönderilmesini yasaklıyorsa, yukarıdaki iş akışı devreye girmeden önce kısa liste kendi çıkarım ucunuzun arkasındaki self-hosted modellere iner.

Bu Seride Gelecek Bölümler#

Bölüm 3 güvenlik, güven ve yönetişim yüzeyini ayrıntılı ele alıyor. Bölüm 4 ilk yıl maliyet modelini ve git/gitme çerçevesini kapsıyor.

Kaynaklar#

• Erken 2025 AI’sinin Deneyimli Açık Kaynak Geliştirici Verimliliğine Etkisinin Ölçümü (yeni sekmede açılır) - METR’in 16 geliştirici ve 246 issue üzerinde yürüttüğü randomize kontrollü çalışması: deneyimli bakımcılar kendi depolarında AI araçlarıyla işleri %19 daha uzun sürede bitirdi; oysa kendi öngörüleri %24 hızlanma yönündeydi.
• Geliştirici Verimliliği Deney Tasarımımızı Değiştiriyoruz (yeni sekmede açılır) - METR’in kendi sonucunu revize ettiği yazı: aralık %2 ile %39 daha uzun olarak yeniden ifade ediliyor, hızlanma tahmin eden bir takip çalışması ve bu yeni tahmini zayıf kılan çekinceler aktarılıyor.
• State of AI-assisted Software Development (yeni sekmede açılır) - DORA’nın yaklaşık 5.000 katılımcıya dayanan 2025 raporu; 2024 katsayılarını birebir yineliyor: AI benimsemesindeki her %25 artış için teslimat hızında %1,5 düşüş ve teslimat kararsızlığında %7,2 artış.
• The Maintainability Gap: AI Code Quality in 2026 (yeni sekmede açılır) - GitClear’ın 623 milyon değişen satırlık analizi; iki haftalık kod değişim oranını, blok tekrarını, taşınan koddan kopyala-yapıştıra kayışı ve fonksiyon bağlantılılığındaki düşüşü kapsıyor.
• 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks (yeni sekmede açılır) - Apiiro’nun Fortune 50 depoları üzerindeki kod analizi: daha büyük pull request’ler, güvenlik bulgularında on kat artış ve sözdizimi hatalarından yetki yükseltme ile tasarım kusurlarına kayış. Bir uygulama güvenliği üreticisi tarafından yayımlandı ve çerçevelemesi bir rakip tarafından açıkça tartışmaya açıldı.
• 2025 GenAI Code Security Report (yeni sekmede açılır) - Veracode’un Java, JavaScript, Python ve C# üzerinde 80 kodlama görevinde 100’den fazla modeli değerlendirmesi; üretilen kodun %45’i bir güvenlik açığı içeriyor, en kötü etkilenen dil Java.
• Does GitHub Copilot Improve Code Quality? Here’s What the Data Says (yeni sekmede açılır) - GitHub’ın sıfırdan tek bir görev üzerinde 202 deneyimli geliştiriciyle yaptığı kontrollü çalışma; yukarıdaki depo telemetrisinin karşı ağırlığı. Üretici finansmanlı ve kapsamı dar; ikisinin uyuşmamasının sebeplerinden biri de bu.
• Araştırma: Accenture ile GitHub Copilot’un Kurumsal Etkisini Nicelleştirme (yeni sekmede açılır) - Copilot ile pull request’lerde yüzde 8 artış ve derleme başarı oranlarında yüzde 84 artış gösteren kurumsal ölçekli araştırma.
• AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate (yeni sekmede açılır) - Mühendis başına merge edilen pull request sayısını ikiye katlama hedefi altında 802 geliştirici ve 196.212 pull request’lik panel; ek hacmin nereye düştüğünü ve bedelini kimin ödediğini gösteriyor.
• A Meta-Analysis of the Effect of Generative AI on Productivity and Learning in Programming (yeni sekmede açılır) - Biçimsel yanlılık değerlendirmesiyle birleştirilmiş 23 çalışma ve 27 etki büyüklüğü; ölçülü bir verimlilik etkisi ve anlamlı olmayan bir öğrenme etkisi veriyor.
• How Much Does AI Impact Development Speed? An Enterprise-Based Randomized Controlled Trial (yeni sekmede açılır) - Google’ın kurumsal ölçekte bir görevde 96 mühendisle yürüttüğü deney; METR sonucunun doğrudan karşı ağırlığı ve kıdem anlatısını karmaşıklaştıran sonuç.
• Stack Overflow 2025 Geliştirici Anketi: AI (yeni sekmede açılır) - 177 ülkeden 49.000’den fazla yanıt; deneyim bandına göre duygu ve güven ile geliştiricilerin işi ilk olarak AI’ya devrettiği görev dağılımı.
• Automatic Root Cause Analysis via Large Language Models for Cloud Incidents (yeni sekmede açılır) - EuroSys 2024 RCACopilot makalesi: 653 Microsoft olayı üzerinde kök neden kategorisi tahmini ve işi modelin değil geri getirmenin yaptığını gösteren taban çizgileri.
• 2025 Observability Forecast (yeni sekmede açılır) - New Relic’in 1.700 uygulayıcıyla yaptığı anket; tespit süresi ve kesinti sıklığı taban çizgilerinin kaynağı. AI yardımını değil gözlemlenebilirlik benimsemesini ölçüyor.
• Flaky Tests at Google and How We Mitigate Them (yeni sekmede açılır) - Google’ın kendi unit ve entegrasyon süitleri için yayımladığı kararsızlık oranları ve CI hatalarının ne kadarının kararsız testten geldiği.
• GitHub Copilot’ta Organizasyon ve Kurum Faturalandırması (yeni sekmede açılır) - Lisans fiyatları, dahil AI kredileri, havuzlama davranışı ve maliyet hesabında kullanılan kredi başına aşım ücreti.
• CVE-2025-53773 (yeni sekmede açılır) - GitHub Copilot ve Visual Studio üzerindeki komut enjeksiyonuna ait NVD kaydı; yetkisiz bir saldırganın geliştirici makinesinde yerel olarak kod çalıştırmasına izin veriyordu.
• Copilot Lisanslarını REST API ile Yönetmek (yeni sekmede açılır) - Sınırlama runbook’unda kullanılan takım ve kullanıcı kaldırma çağrıları dahil, lisans yönetimi uç noktalarının resmi referansı.
• SonarQube Quality Gate’leri (yeni sekmede açılır) - Quality gate’lerin analiz sonuçlarına nasıl bir sürüm politikası dayattığı ve eşiklerin neden tarayıcı ayarlarında değil sunucuda yaşadığı.
• testRigor Fiyatlandırma SSS (yeni sekmede açılır) - Hâlâ erişilebilen tek genel fiyatlandırma içeriği ve yayımlanmış bir liste fiyatı olmadığının kanıtı.
• Mintlify Müşteri Hikâyesi: Anaconda (yeni sekmede açılır) - Üretici tarafından yayımlanan bir vaka çalışması; burada dokümantasyon sorgu hacminin “önlenen destek talebi” olarak raporlanmasına örnek olarak anılıyor.