AI Yardım Spektrumu: Profesyonel Yazılım Geliştirmede Doğru Seviyeyi Seçmek

Profesyonel bir mühendislik workflow’una ne kadar AI yardımı girmeli? İşe yarayan cevap evet ya da hayır değil, bir seviye. Tamamen manuel bir baseline’ın üstünde altı seviye duruyor: sadece inceleme amaçlı sorgular, inline autocomplete, fonksiyon üretimi, çok dosyalı refactoring, otonom ajanlar ve kimsenin çıktıyı okumadığı “vibe coding”. Her basamak hız kazandırır, anlama payından harcar.

Production kodunun çoğu için savunulabilir varsayılan fonksiyon seviyesi generation’dır. Signature’ı ve niyeti siz yazarsınız, model gövdeyi yazar, siz de onu her diff gibi incelersiniz. Regulated veya güvenlik açısından kritik yollarda bu seviyeyi düşürün; ancak test coverage modelin kaçırdıklarını yakalayacak kadar güçlüyse yükseltin.

Temel Problem#

Mühendisler ve ekipler AI yardımı konusunda birkaç temel soruyla mücadele ediyor:

Belirsiz sınırlar: AI yardımı ne zaman işimize yarar, ne zaman zarar verir? Bir ekip autocomplete ile bir özelliği belirgin biçimde daha hızlı ship eder, sonra dikkatli manuel implementation’ın önleyeceği subtle bir race condition’ı kovalamakla günler harcar.

Ekip tutarsızlığı: Farklı ekip üyeleri AI’ı çok farklı seviyelerde kullanıyor. Bir developer her fonksiyonu manuel yazarken, meslektaşı full autonomous coding kullanıyor. Ortaya çıkan codebase dramatik kalite varyasyonları gösteriyor ve bu da code review ve maintenance’ı zorlaştırıyor.

Risk yönetimi: Kurduğumuz sistemleri anlamamızdan ödün vermeden AI hızından nasıl faydalanırız? Technical debt, AI önerilerini derin inceleme yapmadan kabul ettiğimizde sessizce birikir.

Kariyer endişeleri: Developer’lar AI’a aşırı güvenmekten kaynaklanan skill atrophy’den endişe duyarken, aynı zamanda yeterince kullanmayarak geride kalma korkusu yaşıyor. Bu endişe hem junior hem senior mühendisleri farklı şekilde etkiliyor.

Context switching maliyetleri: Her tool’un (Copilot, Cursor, Claude Code) farklı bir interaction modeli var. Yardım seviyeleri arasında gezinmenin kendi vergisi var; “şu anda hangi seviyedeyim” muhasebesi, çözmekte olduğunuz problemle yarışıyor.

ROI belirsizliği: İlk velocity kazançları etkileyici görünüyor. Bu kazançların yıllarla ölçülen bir maintenance ufkunda korunup korunmadığı ise ayrı bir soru; kazancı eriten kalemler (inceleme yükü, yeniden çalışma, yavaşlayan onboarding) geç ortaya çıkıyor.

Altı Seviye AI Yardım Spektrumu#

Aşağıdaki her seviyeyi iki şey tanımlıyor: modelin ürettiği birimin büyüklüğü ve o birime güvenmek için yapmanız gerekenler. Tool isimleri hızla değişiyor, seviyeler değişmiyor. Ekip el kitabınızdaki politikayı seviyelere göre yazın; bir sonraki ürün lansmanından sağ çıkar.

Level 0: Sıfır AI - Manuel Development#

Nedir: Compiler desteği, linter’lar ve static analysis ile geleneksel development - ama AI-powered code completion veya generation yok.

Ne zaman kullanılır:

• Yüksek düzeyde regulated ortamlar (healthcare sistemleri, finansal platformlar)
• Security-critical authentication ve authorization kodu
• Muscle memory oluşturmanız gereken yeni diller veya framework’ler öğrenirken
• Compliance için audit trail gerektiren kod

Tool’lar: TypeScript compiler, ESLint, language server’lı standart IDE’ler

Sahadaki durum: Artık çok az ekip bu seviyede çalışıyor. “AI yok” diyen ekipler bile AI-powered arama, AI tarafından oluşturulan Stack Overflow cevapları ve AI yardımıyla oluşturulan dokümantasyon kullanıyor. Gerçek Level 0 artık neredeyse yok.

Level 1: AI-Destekli Arama & Dokümantasyon#

Nedir: Kod örnekleri bulmak, hata mesajlarını anlamak, dokümantasyon sorgulamak ve yabancı API’ları araştırmak için AI kullanmak.

Ne zaman kullanılır:

• Yabancı kütüphaneler veya framework’leri keşfederken
• Şifreli hata mesajlarını debug ederken
• Yeni codebase’lere onboarding yaparken
• Legacy kod pattern’larını anlamaya çalışırken

Tool’lar: ChatGPT, Claude (tek seferlik sorgular için), GitHub Copilot Chat (contextual yardım için)

Produktivite etkisi: McKinsey’nin geliştirici verimliliği laboratuvarında dokümantasyon görevleri yarı sürede tamamlanıyor. DORA’nın 2024 raporu ise AI benimsemesindeki her %25’lik artışı dokümantasyon kalitesinde %7,5’lik bir yükselişle ilişkilendiriyor; bu, raporun herhangi bir süreç çıktısında ölçtüğü en büyük olumlu etki. Implementation hızı bu seviyede değişmiyor.

Risk seviyesi: Minimal - sadece bilgi alıyorsunuz, production kodu üretmiyorsunuz

Bu seviye özellikle regülatörü AI kod üretimini yasaklayan ekipler için değerlidir. Bir platform AI’ın yazdığı production kodunu yasaklayıp yine de pull request’lerde AI’ı inceleme desteği olarak çalıştırabilir. Audit trail bozulmaz, insan reviewer’lar ise gözle yakalaması yorucu olan hata sınıfları için bir ön filtre kazanır.

Level 2: Inline Autocomplete#

Nedir: Yazarken tek satırlık veya küçük blok completion, mevcut dosya context’ine reaktif.

Ne zaman kullanılır:

• Boilerplate kod yazarken (import’lar, type tanımları, standart pattern’lar)
• Yaygın pattern’leri implement ederken (hata işleme, validation)
• Variable isimleri ve fonksiyon signature’ları oluştururken
• Kurulu pattern’ları takip eden repetitive kod

Tool’lar: GitHub Copilot (base mode), TabNine, Amazon CodeWhisperer, Codeium

Produktivite etkisi: Google Research, 10.000’den fazla kurum içi geliştiricide üç ay boyunca kodlama iterasyon süresinde %6’lık bir azalma ölçtü ve bunu %90 güven seviyesiyle bildirdi. Öneri kabul oranı tek satırda %25, çok satırda %34 çıktı. Tasarıma ayrılan süre değişmiyor; Google, istatistiksel anlamlılığı doğrulanamadığı için aynı yazıdaki context switching iddiasını sonradan geri çekti.

Risk seviyesi: Düşük - önerileri kabul etmeden önce inceleyecek kadar küçük

Kod kalitesi etkisi: Developer dikkatini koruyup her öneriyi incelerse minimal

Level 2 hakkında kritik olan şu: önerileri kabul etmeden önce incelemek kolay. Tek satırlık bir öneriyi kontrol etmenin cognitive load’u yönetilebilir. Bu, kod okuma becerileri geliştirirken bir miktar produktivite kazancı elde etmesi gereken junior developer’lar için ideal.

// Level 2 örneği: Autocomplete implementation'ı öneriyor
function validateEmail(email: string): boolean {
  // "check if email is valid" yorumunu yazarken AI şunu öneriyor:
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

// Developer'ın işi: Regex'i gözden geçir, edge case'leri düşün
// Bu regex yeterli mi? Validation gereksinimlerinize uyuyor mu?
// validator.js gibi bir kütüphane kullanmalı mısınız?

Developer hala problemi düşünüyor ama implementation’da tuş vuruşu tasarrufu yapıyor.

Level 3: Fonksiyon Seviyesi Generation#

Nedir: Fonksiyon signature’ları veya neye ihtiyacınız olduğunu açıklayan yorumlar yazıyorsunuz, AI ise tam implementation’ları üretiyor.

Ne zaman kullanılır:

• Unit test’ler (test yapısı tahmin edilebilir)
• Veri dönüşümleri (input/output açıkça tanımlı)
• CRUD operasyonları (pattern’lar iyi kurulmuş)
• İyi tanımlanmış spesifikasyonlardan algoritma implementation’ları

Tool’lar: GitHub Copilot (multi-line), Cursor (tek dosya düzenlemeleri), AI chat interface’leri

Produktivite etkisi: GitHub’ın 95 geliştiriciyle yaptığı randomize deneyde sıfırdan yazılan bir HTTP sunucusunda %55,8 hızlanma; ancak bu rakamın %95 güven aralığı %21 ile %89 arasında geziniyor. Özgün tasarımda etki ihmal edilebilir.

Risk seviyesi: Orta - mantık, edge case’ler ve performans özelliklerinin dikkatli incelenmesini gerektirir

Yaygın tuzaklar: AI, codebase pattern’larınızla global olarak tutarsız, local olarak optimal kod üretiyor.

AI yardımının güçlü ama disiplin gerektirdiği yer burası. AI tüm fonksiyonları yazabilir ama dikkatle incelemeniz gerekir:

// Level 3 örneği: Fonksiyon seviyesi generation
// Developer signature ve yorumu yazıyor:

/**
 * Exponential backoff retry logic ile user verisi çeker
 * @param userId - User identifier
 * @param maxRetries - Maksimum retry denemeleri (varsayılan: 3)
 */
async function fetchUserWithRetry(
  userId: string,
  maxRetries: number = 3
): Promise<User> {
  // AI tam implementation'ı üretiyor:
  let attempt = 0;

  while (attempt < maxRetries) {
    try {
      const response = await fetch(`/api/users/${userId}`);

      if (!response.ok) {
        throw new Error(`HTTP ${response.status}`);
      }

      return await response.json();
    } catch (error) {
      attempt++;

      if (attempt >= maxRetries) {
        throw error;
      }

      // Exponential backoff: 1s, 2s, 4s
      await new Promise(resolve =>
        setTimeout(resolve, Math.pow(2, attempt) * 1000)
      );
    }
  }

  throw new Error('Max retries exceeded');
}

Developer’ın inceleme checklist’i:

• Exponential backoff mantığı gereksinimlerimize uyuyor mu?
• Thundering herd’ü önlemek için jitter eklemeli miyiz?
• İlgili tüm HTTP status code’larını işliyor muyuz?
• Bazı hatalar (404, 401) retry’ı atlamalı mı?
• Error handling monitoring setup’ımızla tutarlı mı?

Sürdürülebilir getirinin en iyi olduğu yer genelde Level 3’tür; yayımlanmış kanıtın bu seviyenin çizdiği sınırda en net ikiye ayrıldığı yer de burası. GitHub’ın deney grubu işi 1 saat 11 dakikada bitirdi, kontrol grubu 2 saat 41 dakikada. Ama görev, hiçbir mevcut koda uymak zorunda olmayan, kendi içine kapalı bir HTTP sunucusuydu. McKinsey ise geliştiricilerin karmaşık saydığı görevlerde zaman tasarrufunun %10’un altına indiğini buldu. METR aynı türden işi tam tersi ortamda ölçtü: 16 deneyimli maintainer, 246 gerçek issue, ortalama bir milyon satırın üzerinde repository. O grup işi %19 daha yavaş bitirdi.

Level 3’te çıktı birimi hâlâ düzgün incelenebilecek kadar küçüktür, dolayısıyla hız kalite vergisi ödemeden gelir. Bunun için iki şartın tutması gerekir: inceleme gerçekten yapılmalı ve iş, çalışmanın ölçtüğü işe benzer bir şekle sahip olmalı.

Level 4: Multi-File Refactoring & Editing#

Nedir: Birden fazla dosyadaki istenen değişiklikleri açıklıyorsunuz, AI ise tutarlılığı koruyarak düzenlemeleri koordine ediyor.

Ne zaman kullanılır:

• Dosyalar arasında fonksiyonları veya variable’ları yeniden adlandırırken
• API signature’larını ve tüm çağrı yerlerini güncellerken
• Module’ler arasında tutarlı pattern’lar uygularken
• Migration task’leri (örneğin, CommonJS’den ES module’lara geçiş)

Tool’lar: Cursor Composer, GitHub Copilot Workspace (beta), Claude Code (dosya context’i ile)

Produktivite etkisi: Google’ın kendi kurum içi migration’ları üzerine yayımladığı çalışmada toplam migration süresi tahminen %50 azalmış, merge edilen changelist’lerdeki kod değişikliklerinin %80’i tamamen AI tarafından yazılmış. McKinsey ise refactoring’in yaklaşık üçte iki sürede tamamlandığını ölçtü. İkisi de test coverage altındaki mekanik dönüşümü anlatıyor; yapısı belirsiz refactor’lar böyle davranmıyor.

Risk seviyesi: Orta-yüksek - AI implicit bağımlılıkları kaçırabilir, type safety’yi korurken runtime davranışını bozabilir

Kritik gereksinim: AI hatalarını yakalamak için kapsamlı test coverage

Planlamaya değer asıl hata modu, tip sisteminin göremediği referanstır. Onlarca dosyaya uygulanan bir yeniden adlandırma, compiler’ı sessiz ve test suite’ini yeşil bırakabilir; oysa reflection tabanlı bir arama eski adı hâlâ string olarak tutuyordur. Kırılma ancak runtime’da, hiçbir işe yaramayan bir stack trace ile görünür.

// Level 4 örneği: Multi-file refactoring challenge'ı

// Önce: Eski API signature
async function getUserData(id: string): Promise<UserData> {
  // implementation
}

// Sonra: AI getUser olarak yeniden adlandırıyor ve return type'ı değiştiriyor
async function getUser(id: string): Promise<User> {
  // implementation
}

// AI her direkt çağrı yerini doğru şekilde güncelliyor:
const user = await getUser(userId);

// Ama bu reflection-based kullanımı kaçırıyor:
const dynamicCall = {
  'getUserData': getUserData, // Hala eski adı referans alıyor
  'getOrderData': getOrderData
};

const result = await dynamicCall['getUserData'](id); // Runtime hatası!

Level 4 için güvenlik önlemleri:

• Değişikliklerden önce ve sonra tam test suite çalıştır
• AI’ın değişiklik planını execution’dan önce incele
• Easy rollback için version control kullan
• Değiştirilen fonksiyonelliğin manuel smoke test’i
• Yeniden adlandırılan identifier’lar için string referanslarını ara

Level 5: Agentic/Autonomous Development#

Nedir: Özellikleri veya problemleri yüksek seviyede açıklıyorsunuz, AI ise özerk olarak plan yapıyor, implement ediyor, test ediyor ve iterate ediyor.

Ne zaman kullanılır:

• Prototype’lar ve proof-of-concept’ler
• Kurulu pattern’ları takip eden iyi kapsam belirlenmiş özellikler
• Legacy constraint’leri olmayan greenfield projeler
• Öğrenmenin amaç olduğu keşifsel çalışma

Tool’lar: Claude Code (agentic mode), Cursor Composer (autonomous), GitHub Copilot Workspace, Windsurf

Produktivite etkisi: İlk implementation’da büyük, bir kısmı inceleme ve yeniden çalışmayla geri ödenir. Bu niteliksel bir iddia olarak kalıyor, çünkü bu seviyede birim emek başına çıktıyı ölçen yayımlanmış bir çalışma yok.

Benimseme: DORA’nın 2025 raporunda agentic mod, en az kullanılan etkileşim biçimi. Katılımcıların %61’i AI araçlarıyla hiçbir zaman agentic biçimde etkileşmediğini söylüyor. IDE içi sohbet ve tahmine dayalı metin hâlâ yaygın biçimler.

Risk seviyesi: Yüksek - AI genişletilmiş özerklikle çalışıyor, hataları birleştirebilir, insan gözetimi olmadan mimari kararlar alır

Sahadaki durum: Uzun süre özerk çalışabilmek, uzun süre iyi çıktı üretmekle aynı şey değil. Uzayan oturumlarda context drift artar ve karar kalitesi düşer.

Buradaki rakam boşluğu da kendi başına bir bilgi. Level 5, alt seviyeleri ölçen araştırma programlarının henüz yetişemeyeceği kadar yeni; benimseme verisi de nedenini gösteriyor. DORA 2025, kendi sahiplik verilerini yorumlarken bugünkü AI araçlarının otonom ajanlardan çok gelişmiş asistanlar gibi çalıştığı sonucuna varıyor. Tool pazarlamasının atladığı boşluk tam olarak bu: yetenek, etrafındaki çalışma pratiği oturmadan çok önce yayınlanıyor.

Level 5, prototyping ve keşif için iyi çalışır; buradaki amaç mühendislik zamanı ayırmadan önce bir ürün sorusunu cevaplamaktır. Tuzak, cevap geldikten sonra başlar. Bir yönü doğrulamış prototype, nadiren birinin üzerine ekleme yapabileceği bir codebase olur; içindeki mimari kararlar da hiçbir yere yazılmamıştır.

Level 5’in pratikte nasıl göründüğü:

// Level 5 örneği: Agentic development

// Developer yüksek seviye requirement sağlıyor:
/*
Şu özelliklere sahip bir notification sistemi oluştur:
- Email, SMS ve push notification gönderir
- Exponential backoff ile retry logic implement eder
- Veritabanında delivery status'ü takip eder
- Delivery event'leri için webhook callback'leri sağlar
- User başına rate limiting içerir
*/

// AI özerk olarak:
// 1. Data model'leri oluşturuyor (Notification, DeliveryStatus, RateLimit)
// 2. Birden fazla provider ile service layer implement ediyor
// 3. Redis ile retry queue ekliyor
// 4. Webhook delivery sistemi oluşturuyor
// 5. Kapsamlı test'ler ekliyor
// 6. Mimariyi belgeliyor

// Çıktının tipik hali:
// Good: Birbirine bağlanmış ve çalışan eksiksiz dosya seti
// Good: Implementation ile birlikte üretilmiş test suite
// WARN: Birbiriyle örtüşen birden fazla notification kütüphanesi (tutarsız)
// WARN: Rate limiting mantığında edge case bug'ları var
// WARN: Monitoring/observability hook'ları yok
// WARN: Mimari kararlar belgelenmemiş

Level 5 için kritik güvenlik önlemleri:

• Sadece sandbox ortamları
• Execution’dan önce insan AI’ın mimari planını inceler
• Tüm üretilen kodda güvenlik taraması
• Deployment’tan önce senior developer incelemesi
• Kodun önemli refactoring gerektirebileceği konusunda açık beklenti

Level 6: Vibe Coding - AI-First Development#

Nedir: AI’a tamamen güvenmek, üretilen kodu detaylı okumamak, development’ı yönlendirmek için “vibe’ları” ve test sonuçlarını takip etmek.

Ne zaman kullanılır:

• Anında öğrenme için hızlı prototyping
• Atılacak MVP development
• Problem space’lerini keşfetme
• Kısa ömürlü kritik olmayan uygulamalar

Tool’lar: Replit Agent, v0.dev, Bolt, Lovable, full agentic platformlar

Produktivite etkisi: Vendor’lar kat kat hızlanma vaat ediyor; iddialar yalnızca ilk build’i kapsıyor

Risk seviyesi: Çok yüksek - kod anlayışı yok, maintenance kabusları, güvenlik açıkları, hızlı technical debt birikimi

Kritik sınırlamalar:

• İlk context window dolduktan sonra bozulur
• Kodu anlamadan debug etmek imkansız
• Ekip devir teslimleri son derece zor
• Güvenlik ve performans sorunları fark edilmez

Level 6 konusunda net olalım: çoğu profesyonel context için production’a hazır değil. Karakteristik kusuru tutarsızlıktır. Authorization bazı endpoint’lere uygulanır, bazılarına uygulanmaz; çünkü döngüde kesişen bir invariant’ı izleyen kimse yoktur ve kodu fark edecek kadar yakından okuyan da olmamıştır. Test’ler geçer, çünkü test’ler de aynı yanlış anlamadan üretilmiştir.

Bunun produktivite tarafı ölçülmemiş olsa da güvenlik tarafı ölçüldü. Veracode’un 2025 raporu 100’den fazla büyük dil modelinin çıktısını test etti ve kod örneklerinin %45’inin OWASP Top 10 kapsamında bir açık getirerek güvenlik testlerinden kaldığını buldu: Java’da %72, C#‘ta %45, JavaScript’te %43, Python’da %38. En kötü kategori cross-site scripting oldu; modeller ilgili örneklerin %86’sında bu saldırıya karşı savunma üretemedi ve yeni modeller sözdizimsel olarak daha doğru kod yazarken güvenlik tarafını iyileştirmedi. Bunu, güvenlikle ilgili görevlerde üretilen çıktının bir özelliği olarak okuyun; sizin production kodunuzun %45’inin açık taşıdığı anlamına gelmiyor. Yine de kimsenin diff’i okumadığı bir workflow’da hayatta kalan hata sınıfını tam olarak tarif ediyor.

Level 6 için geçerli tek kullanım durumları:

• Açık “yeniden yazılacak” etiketli throwaway prototype’lar
• Amacın olasılıkları keşfetmek olduğu öğrenme deneyleri
• Hiçbir zaman production’a çıkması planlanmayan proof-of-concept’ler
• Tasarım doğrulaması için UI mockup’ları

Seviyenizi Seçmek İçin Framework#

İşte temel faktörleri yakalayan TypeScript tabanlı bir karar framework’ü:

interface ProjectContext {
  complexity: 'simple' | 'moderate' | 'complex';
  riskTolerance: 'low' | 'medium' | 'high';
  regulatoryConstraints: boolean;
  teamExperience: 'junior' | 'mixed' | 'senior';
  maintenanceHorizon: 'prototype' | 'months' | 'years';
  testCoverage: 'none' | 'partial' | 'comprehensive';
}

interface AILevelRecommendation {
  baseline: 0 | 1 | 2 | 3 | 4 | 5 | 6;
  adjustments: Array<{
    scope: string;
    level: number;
    reasoning: string;
  }>;
  safeguards: string[];
}

function recommendAILevel(context: ProjectContext): AILevelRecommendation {
  // Temel öneri ile başla
  let baseline = 3; // Varsayılan olarak fonksiyon seviyesi generation
  const adjustments = [];
  const safeguards = [];

  // Regulatory constraint'lere göre ayarla
  if (context.regulatoryConstraints) {
    baseline = Math.min(baseline, 1);
    safeguards.push('Tam audit trail gerekli');
    safeguards.push('Tüm kodlar için insan incelemesi zorunlu');
  }

  // Ekip deneyimine göre ayarla
  if (context.teamExperience === 'junior') {
    baseline = Math.min(baseline, 2);
    safeguards.push('Temelleri öğrenmeye odaklan');
    safeguards.push('Beceriler geliştikçe progressive unlock');
  }

  // Maintenance horizon'a göre ayarla
  if (context.maintenanceHorizon === 'years') {
    baseline = Math.min(baseline, 3);
    safeguards.push('Kod anlayışı gerekli');
    safeguards.push('Dokümantasyon zorunlu');
  } else if (context.maintenanceHorizon === 'prototype') {
    baseline = Math.min(baseline + 2, 6);
    adjustments.push({
      scope: 'Sadece prototype - yeniden yazma planla',
      level: 6,
      reasoning: 'Öğrenme amacı, production sistemi değil'
    });
  }

  // Test coverage daha yüksek seviyeleri etkinleştirir
  if (context.testCoverage === 'comprehensive') {
    adjustments.push({
      scope: 'Refactoring task\'leri',
      level: Math.min(baseline + 1, 5),
      reasoning: 'Test\'ler AI hatalarını yakalayacak'
    });
  } else if (baseline > 3) {
    safeguards.push('Daha yüksek AI seviyeleri kullanmadan önce test coverage oluştur');
  }

  // Risk tolerance modifier
  if (context.riskTolerance === 'low') {
    baseline = Math.min(baseline, 2);
  } else if (context.riskTolerance === 'high' &&
             context.maintenanceHorizon === 'prototype') {
    baseline = Math.min(baseline + 1, 5);
  }

  return { baseline, adjustments, safeguards };
}

// Örnek kullanım: Finansal sistem
const financialSystem = recommendAILevel({
  complexity: 'complex',
  riskTolerance: 'low',
  regulatoryConstraints: true,
  teamExperience: 'senior',
  maintenanceHorizon: 'years',
  testCoverage: 'comprehensive'
});

console.log(financialSystem);
// {
//  baseline: 1,
//  adjustments: [
//  {
//  scope: 'Refactoring task\'leri',
//  level: 2,
//  reasoning: 'Test\'ler AI hatalarını yakalayacak'
//  }
//  ],
//  safeguards: [
//  'Tam audit trail gerekli',
//  'Tüm kodlar için insan incelemesi zorunlu',
//  'Kod anlayışı gerekli',
//  'Dokümantasyon zorunlu'
//  ]
// }

// Örnek kullanım: Startup MVP
const startupMVP = recommendAILevel({
  complexity: 'moderate',
  riskTolerance: 'high',
  regulatoryConstraints: false,
  teamExperience: 'mixed',
  maintenanceHorizon: 'prototype',
  testCoverage: 'partial'
});

console.log(startupMVP);
// {
//  baseline: 5,
//  adjustments: [
//  {
//  scope: 'Sadece prototype - yeniden yazma planla',
//  level: 6,
//  reasoning: 'Öğrenme amacı, production sistemi değil'
//  }
//  ],
//  safeguards: [
//  'Daha yüksek AI seviyeleri kullanmadan önce test coverage oluştur'
//  ]
// }

Pratik Implementation Pattern’ları#

Pratikte iyi çalışan üç pattern:

Pattern 1: Kademeli Yaklaşım#

Bu özellikle AI yardımında yeni olan ekipler için iyi çalışıyor:

Hafta 1-2: Level 1-2 (arama ve autocomplete)
- Ekip AI önerilerini değerlendirmeyi öğrenir
- Baseline produktivite metrikleri oluşturulur
- "AI önerisi inceleme" muscle memory geliştirilir

Hafta 3-4: Level 3 (fonksiyon generation) sadece test'ler için
- Pratik yapmak için daha düşük riskli alan
- Test execution'dan anında feedback
- Üretilen kodu inceleme konusunda güven oluştur

Hafta 5-8: Feature kodu için Level 3
- Öğrenilen inceleme becerilerini production koduna uygula
- Kalite metriklerini yakından takip et
- Bulgulara göre politikaları ayarla

Hafta 9+: Refactoring için Level 4 (eğer test coverage güçlüyse)
- Multi-file yetenekleri etkinleştir
- Sıkı inceleme süreçlerini koru
- Uzun vadeli kalite etkisini ölç

Pattern 2: Risk Tabanlı Zonlar#

Codebase’inizin farklı kısımları farklı risk profillerine sahip:

// Kod zonuna göre AI seviye politikası tanımla
const aiLevelPolicy = {
  // Security-critical: minimal AI
  'src/auth/**': { maxLevel: 2, requireReview: true },
  'src/payments/**': { maxLevel: 2, requireReview: true },

  // Business logic: orta düzey AI
  'src/features/**': { maxLevel: 3, requireReview: true },
  'src/services/**': { maxLevel: 3, requireReview: true },

  // UI component'leri: daha yüksek AI'a izin veriliyor
  'src/components/**': { maxLevel: 4, requireReview: false },
  'src/pages/**': { maxLevel: 4, requireReview: false },

  // Test'ler: AI kullanımını teşvik et
  'src/**/*.test.ts': { maxLevel: 5, requireReview: false },

  // Prototype'lar: maksimum AI
  'prototypes/**': { maxLevel: 6, requireReview: false }
};

Pattern 3: Role Tabanlı Yetenekler#

Farklı ekip üyeleri deneyimlerine göre farklı AI seviyeleri kullanmalı:

type DeveloperLevel = 'junior' | 'mid' | 'senior' | 'principal';
type CodeZone = 'security' | 'business' | 'ui' | 'tests' | 'prototype';

function getAllowedAILevel(
  developerLevel: DeveloperLevel,
  codeZone: CodeZone
): number {
  const matrix: Record<DeveloperLevel, Record<CodeZone, number>> = {
    junior: {
      security: 1,  // Sadece arama
      business: 2,  // Sadece autocomplete
      ui: 2,  // Sadece autocomplete
      tests: 3,  // Fonksiyon generation tamam
      prototype: 3  // Fonksiyon generation tamam
    },
    mid: {
      security: 2,
      business: 3,
      ui: 4,
      tests: 5,
      prototype: 5
    },
    senior: {
      security: 2,
      business: 4,
      ui: 4,
      tests: 5,
      prototype: 6
    },
    principal: {
      security: 3,  // Derin inceleme ile fonksiyon generation kullanabilir
      business: 4,
      ui: 4,
      tests: 5,
      prototype: 6
    }
  };

  return matrix[developerLevel][codeZone];
}

// Örnek: Business logic üzerinde çalışan junior developer
const allowedLevel = getAllowedAILevel('junior', 'business');
// Döner: 2 (sadece autocomplete, öğrenmeye odaklan)

// Örnek: Prototype üzerinde çalışan senior developer
const seniorPrototype = getAllowedAILevel('senior', 'prototype');
// Döner: 6 (throwaway kod için vibe coding kabul edilebilir)

Karar Framework’ünü Görselleştirme#

Farklı faktörlerin AI seviye seçiminizi nasıl etkilediği:

Maliyet Analizi & Trade-off’lar#

Bu maliyet modelinde fiyatı yayımlanmış tam olarak tek bir kalem var. Geri kalanı ölçülemez değil, sadece fiyatlanmamış: yayımlanmış araştırma bu baskıların çoğunu adlandırıyor, birkaçına sayı da veriyor, ama hiçbirini dolara çevirmiyor.

Fiyatı Belli Olan Kalem#

Koltuk lisansları kişi sayısıyla doğrusal büyür ve aralığın en altında kalır. GitHub’ın plan dokümantasyonu Copilot Business’ı koltuk başına ayda $19, Copilot Enterprise’ı $39 olarak listeliyor. Cursor’ın fiyat sayfası ise iki ekip tier’ını da kullanıcı başına ayda $40 gösteriyor.

20 developer’lık bir ekip için hesap şöyle: ayda $19’dan 20 koltuk, 12 ay boyunca $4,560 eder; aynı 20 koltuk $40’tan $9,600 eder. Yani liste fiyatıyla yılda kabaca $4,600 ile $9,600 arası. Kullanım her iki üründe de koltuğun üstüne biniyor: Cursor tüm ücretli tier’lara kullanım bazlı faturalama uyguluyor, GitHub ise premium işleri tanesi $0.01 olan AI kredileriyle ölçüyor. İki vendor da bu tier’ları sık sık yeniden fiyatlandırıp yeniden adlandırıyor; hesabı buradaki rakamlardan değil güncel sayfalardan kurun.

Fiyatı Belli Olmayan Kalemler#

Abonelikler denklemin en küçük parçası:

Öğrenme eğrisi: DORA’nın 2025 raporunda medyan katılımcının AI araçlarıyla deneyimi 16 ay ve AI kullananların yalnızca %7’si bir problemle karşılaştığında refleks olarak araca uzanıyor. Cui ile arkadaşlarının Microsoft, Accenture ve adı açıklanmayan bir Fortune 100 şirketinde yürüttüğü üç saha deneyinde, dağıtımdan bir yıl sonra benimseme ortalama %60’ta kalmış. Aynı DORA çalışmasında yer alan Sabre’de asistan kullanımı geliştiricilerin %74’üne ulaşmış, ama agent modunu kullanan yalnızca %25 olmuş. Satın alınan lisans, kazanılmış yetkinlik demek değil.

İnceleme ve yeniden çalışma: DORA 2025 bulgularının kendi özetinde mekanizma açıkça yazıyor: üretimde kazanılan zaman sıklıkla denetime ve doğrulamaya kayıyor. Stack Overflow’un 2025 geliştirici anketinde soruyu yanıtlayan 31.476 geliştiricinin %66’sı en büyük sıkıntı olarak neredeyse doğru ama tam doğru olmayan AI çözümlerini işaretlemiş. DORA katılımcıları da son iş günlerinde AI ile etkileşime medyan iki saat ayırdıklarını söylüyor; sekiz saatlik bir günün yaklaşık dörtte biri.

Debugging zamanı: Yazmadığınız kodun debug edilmesi daha uzun sürer, çünkü pattern’lar kafanızda değildir. Stack Overflow katılımcılarının %45,2’si AI’ın ürettiği kodu debug etmenin kendi kodlarını debug etmekten daha çok vakit aldığını söylüyor.

Bakım yüzeyi: Yüksek seviyeler birim düşünce başına daha fazla kod üretir; daha fazla kod da bakımı yapılacak daha fazla yüzey demektir. GitClear’ın Ocak 2020 ile Aralık 2024 arasında değişen 211 milyon satır üzerinde yaptığı okumaya göre kopyala-yapıştır satırlar 2021’den 2024’e değişen satırların %8,3’ünden %12,3’üne çıkmış; refactor edilen satırlar ise yaklaşık %25’ten %10’un altına inmiş. Seride ilk kez kopyala-yapıştır, refactor’ü geçmiş. GitClear kod kalitesi analitiği satıyor; dolayısıyla ondalıklara değil yöne bakın.

Context switching overhead’i: Yardım seviyeleri ve tool arayüzleri arasında gezinmenin kendi maliyeti var. “Şu anda hangi AI seviyesini kullanıyorum?” muhasebesi, çözmekte olduğunuz problemle yarışıyor. Bu kalemi sayıya döken yayımlanmış bir ölçüm yok.

Bilgi transferi: Junior developer’lar konusunda iki güvenilir çalışma birbiriyle çelişiyor ve asıl bulgu da bu çelişki. McKinsey, bazı görevlerin junior developer’larda araçlarla, araçsız haline göre %7 ila %10 daha uzun sürdüğünü bildiriyor. Cui ile arkadaşları tam tersini söylüyor: junior’larda %27 ila %39, senior’larda %8 ila %13 kazanç. Tek bir rakam iki okumayla da tutarlı: Stack Overflow katılımcılarının %20’si kendi problem çözme becerilerine olan güvenlerinin azaldığını söylüyor. Bunların hiçbiri bir junior’ın sonradan araçsız ne yapabildiğini ölçmüyor; beceri maliyetini kanıtlanmış bir sonuç değil, kendi ekibinizde sınayacağınız bir hipotez olarak alın. Bir mühendisin kendi kodunu tasarım incelemesinde açıklayabilmesi ucuz bir kontroldür ve buradaki çalışmaların hiçbiri bu kontrolü yapmıyor.

Bunların tamamını kapsayan tek bir çarpan yok; vendor’ın verdiği çarpan da pazarlama olarak okunmalı. Ölçmeye değer sinyal bir oran: inceleme, yeniden çalışma ve debugging teslim edilen özelliklerden daha hızlı büyümeye başladığında seviye o codebase için fazla yüksektir.

Getirinin Şekli#

Yayımlanmış hiçbir kaynak AI araçları için bir geri ödeme ayı vermiyor. Kayıtların desteklediği şey getirinin şeklini tarif etmek; o tarif bile yıldan yıla yer değiştirdi.

DORA’nın 2024 raporu, bireysel AI benimsemesindeki her %25’lik artışın yanında bireysel verimlilikte %2,1, dokümantasyon kalitesinde %7,5, kod kalitesinde %3,4 ve kod inceleme hızında %3,1 artış tahmin etti. Aynı %25’lik artışın yanında yazılım teslim throughput’unda %1,5 düşüş ve teslim kararsızlığında %7,2 artış duruyor. DORA’nın kendi açıklaması batch büyüklüğü: AI aynı sürede daha fazla kod üretmeyi mümkün kılıyor, changelist’ler büyüyor, büyük changelist’leri güvenle teslim etmek de zorlaşıyor. 2025 raporu bu işaretlerden birini ters çevirdi. Throughput artık benimsemeyle birlikte iyileşiyor, kararsızlık ise hâlâ kötüleşiyor. İki yıl farklı istatistiksel birim kullanıyor (2025’te %89 güvenilirlik aralıklı standartlaştırılmış etki büyüklükleri, 2024’te yüzde tahminleri), dolayısıyla aralarına trend çizgisi çekilemez. Yöntem değişikliğinden sağ çıkan şey asimetri: fayda tarafı yer değiştirdi, kararlılık maliyeti değiştirmedi.

Bütün bunlarda en güvenilmez girdi kişinin kendi beyanı. METR’in randomize deneyi 16 deneyimli open-source maintainer’ı, ortalama bir milyon satırın üzerindeki repository’lerde 246 gerçek issue’nun başına oturttu. Geliştiriciler %24’lük bir hızlanma öngördü. İşi bitirdikten sonra bile AI’ın kendilerini %20 hızlandırdığına inanıyorlardı. Gerçekte %19 daha yavaştılar. METR bugün bu sonucu tarihsel olarak etiketliyor ve artık AI modellerinin open-source geliştirici verimliliği üzerindeki güncel etkisini yansıtmadığını söylüyor; bir geri ödeme hesabının kaldıramayacağı türden bir düzeltme. Kurumun 349 teknik çalışanla yaptığı 2026 takip anketinde medyan beyan 3 kat hızlanma yönünde çıktı, üstüne METR’in kendi notu ekleniyor: 2025 başında insanlar AI’ın kendi zamanlarına etkisini ortalama 40 puan fazla tahmin etmişti.

DORA’nın 2025 katılımcıları da aynı boşluğa oturuyor. %80’den fazlası AI’ın verimliliklerini artırdığına inanıyor, %40’tan fazlası ise artışı yalnızca hafif buluyor. İş vakasını inanca kurarsanız rakam büyük çıkar. Ölçüme kurarsanız daha küçük, daha gürültülü ve işin şekline özgü çıkar.

Yayımlanmış Kurumsal Sonuçlar#

Beş kurum, kendi kurulumları hakkında yukarıdaki seviyelerle karşılaştırılacak kadar ayrıntı yayımladı. Hepsinde tekrarlayan ve biraz rahatsız edici bir örüntü var: en büyük kazançlar en yapay görevlerden geliyor.

ANZ Bank, 5.000’i aşkın mühendisinden yaklaşık 100’üyle altı haftalık randomize bir deney yürüttü ve yarı yolda kontrol ile deney gruplarının rollerini değiştirdi. Copilot grubu görevleri %42,36 daha hızlı tamamladı: görev başına ortalama 17,86 dakika, kontrol grubunda ise 30,98 dakika. Ortalamada daha az code smell ve bug çıktı. Unit test başarı oranındaki %12,86’lık fark istatistiksel anlamlılığa ulaşmadı, güvenlik sonucu da belirsiz kaldı; yine de Copilot büyük bir güvenlik sorunu getirmedi. Banka sonrasında erişimi yaklaşık 1.000 mühendise açtı. Buradaki çekince taşıyıcı nitelikte: görevler production işi değil, algoritmik Python kodlama alıştırmalarıydı ve kata tarzı alıştırmalar production’ı yavaşlatan kısıtları taşımaz.

Google, Level 4 için mevcut en güçlü kanıtı yayımladı. int32’den int64’e geçen bir identifier migration’ında merge edilen changelist’lerdeki kod değişikliklerinin %80’i tamamen AI tarafından yazılmıştı ve migration’a harcanan toplam süre, model desteği olmayan benzer bir çalışmaya göre tahminen %50 azaldı. JUnit3’ten JUnit4’e geçişte AI’ın ürettiği kodun yaklaşık %87’si hiç değiştirilmeden commit edildi; üç ayda 5.359 dosya ve 149.000’den fazla satır taşındı. Joda-time’dan Java time’a geçişte küçük kümelerde insan zamanının yaklaşık %89’u kazanıldı. Üretilen kod, her kod gibi insan incelemesinden geçti. Bunların hepsi güçlü test coverage’a sahip bir codebase üzerinde mekanik, pattern’a oturan dönüşümler; yani Level 4’ün zaten şart koştuğu önkoşul.

Microsoft, Accenture ve adı açıklanmayan bir Fortune 100 şirketi, toplam 4.867 developer’ı kapsayan üç randomize saha deneyine ev sahipliği yaptı; havuzlanmış sonuç, tamamlanan görevlerde %26,08 artış ve %10,3 standart hata. Kıdem kırılımı McKinsey’ninkinin tersi yönde: junior developer’lar %27 ila %39, senior’lar %8 ila %13 kazandı. Benimseme bir yıl sonra ancak %60 civarındaydı. Yazarlar koda erişimlerinin olmadığını ve üretilen işin kalitesini değerlendiremediklerini açıkça belirtiyor; görev sayısına dayalı bir metriğin sınırı da tam burası.

Adidas, DORA’nın 2025 çalışmasında gevşek bağlı mimarilere ve hızlı geri bildirim döngülerine sahip ekiplerin commit, pull request ve özellik teslim hızındaki artışlarla ölçülen %20 ila %30 verimlilik kazancı gördüğünü bildirdi; buna idari işler yerine elle kod yazmaya ayrılan sürede %50 artış eşlik etti. ERP’ye sıkı bağlı, geri bildirim döngüsü yavaş ekipler aynı sonucu görmedi. Tavanı mimari belirledi; tool belirlemedi.

Sabre, aynı çalışmada asistan kullanımının farklı kıdemlerdeki geliştiricilerde %74’e fırladığını, buna karşılık kullanım analitiğinin bu kullanıcıların yalnızca %25’inin agent moduna dokunduğunu gösterdiğini aktardı. Bir ürünün benimsenmesi ile o ürünün en gelişmiş yeteneğinin benimsenmesi ayrı sayılardır ve ikincisi geriden gelir.

Bunların yanına karşı ağırlığı da koyun. METR’in ortalama bir milyon satırın üzerindeki repository’lerde çalışan 16 maintainer’ı işi %19 daha yavaş bitirdi. GitHub’ın %55,8’i ve ANZ’nin %42,36’sı sıfırdan yazılan, kendi içine kapalı görevlerden geldi. Google’ın %50’si istisna olmayı hak ediyor, çünkü test coverage altında yapılan mekanik bir dönüşümü anlatıyor; spektrumun zaten Level 4’e ayırdığı tek iş. Manşet yüzdeleri bağlamlar arasında taşınmıyor. Taşınan şey seviye ve işin şekli.

Takip Edilecek Metrikler#

Daha yüksek AI yardım seviyeleri uygularsanız, bu metrikleri birinci günden itibaren takip edin:

Development Metrikleri#

interface DevelopmentMetrics {
  // Velocity takibi
  featuresDeliveredPerSprint: number;
  timeToFirstPR: number; // Ticket'tan initial koda kadar saat
  codeReviewCycles: number; // Merge öncesi iterasyonlar

  // Kalite takibi
  bugIntroductionRate: number; // Her 1000 satır başına
  revisionRate: number; // Yeniden çalışma gerektiren AI kodunun %'si
  technicalDebtScore: number; // Complexity/coupling metrikleri
  testCoveragePercentage: number;

  // AI-özel metrikler
  aiGeneratedLinesPercentage: number;
  aiSuggestionAcceptanceRate: number;
  aiCodeRevisionTime: number; // AI kodunu incelemeye harcanan saat
}

Seviyeye Göre Kalite Güvenlik Önlemleri#

Farklı AI seviyeleri farklı güvenlik önlemleri gerektiriyor:

Level 2-3 Güvenlik Önlemleri:

• Tüm AI tarafından üretilen kod için zorunlu kod incelemesi
• Developer’lar PR açıklamalarında AI tarafından üretilen mantığı açıklar
• Kapsamlı linting kurallarıyla static analysis
• Unit test coverage gereksinimleri değişmez (tipik olarak %80+)

Level 4-5 Güvenlik Önlemleri:

• Değişiklik öncesi: Kapsamlı test suite (%80+ coverage)
• Sırasında: İnsan AI’ın execution planını çalıştırmadan önce inceler
• Değişiklik sonrası: Tam test suite + manuel smoke testing
• Dokümantasyon: AI mimari kararlarını belgeler
• Rollback: Multi-file değişiklikler için kolay geri alma mekanizması

Level 6 Güvenlik Önlemleri (Kritik):

• Sadece sandbox ortamları - asla production değil
• Tüm üretilen kodda güvenlik taraması
• Herhangi bir deployment öncesi senior developer mimari incelemesi
• Potansiyel tam yeniden yazmaların açık beklentisi
• Açık öğrenme hedefleriyle zaman sınırlı deneyler

Yaygın Tuzaklar & Dersler#

Planlamaya değecek kadar sık tekrarlayan altı hata modu var:

Tuzak 1: Tekdüze Adoption Beklentileri#

Ne olur: Tüm developer’lara aynı AI tool’ları verilir ve tekdüze kullanım beklenir. Junior developer’lar özellikleri hızla ship ederken temel becerileri oluşturmakta zorlanır; açık ise ancak kendi kodlarını ilk debug etmeleri gerektiğinde görünür.

Neden önemli: Junior developer’ları Level 2 ile sınırlamak, çıktı birimini okunabilecek kadar küçük tutar; temel yetkinlikleri kuran da bu okumadır. Senior developer’lar Level 4-5’i etkili bir şekilde kullanabilir. Rehberi role göre yazın, sonra kendi kod incelemelerinizin gösterdiğiyle karşılaştırın.

Çözüm: Role göre açık AI seviye politikaları, ekip el kitabında belgelenir, kod incelemede uygulanır.

Tuzak 2: Kalite Platosunu Görmezden Gelme#

Ne olur: Erken velocity artışı birkaç çeyrek boyunca heyecan yaratır. Ardından bug raporları tırmanır, özellik tamamlama yavaşlar ve developer’lar bıkkınlaşır. Eldeki ölçüm ne ise, technical debt’in arttığını ve velocity’nin balayı rakamının epey altına yerleştiğini gösterir.

Neden önemli: İlk velocity kazançları sürmez. Takip edilmezse kalite sessizce düşer.

Çözüm: Birinci günden itibaren revizyon oranlarını, technical debt metriklerini ve maintenance yükünü takip et. Problemler belirgin olana kadar bekleme.

Tuzak 3: Yetersiz Kod İncelemesi Adaptasyonu#

Ne olur: AI tarafından üretilen kod için standart kod inceleme checklist’i kullanılır. Pattern tutarsızlıkları, subtle bug’lar ve AI’ın yaygın olarak getirdiği performans sorunları gözden kaçar.

Neden önemli: AI kodu farklı inceleme odağı gerektiriyor: codebase ile pattern tutarlılığı, edge case işleme, performans özellikleri ve güvenlik etkileri.

Çözüm: Güncellenmiş inceleme checklist’leri, açık “AI-generated” PR etiketleri ve elle yazılmış koda ayrılandan bilinçli olarak daha geniş bir inceleme zamanı bütçesi.

Tuzak 4: Production için Vibe Coding#

Ne olur: İlk sonuçlar etkileyici göründüğü için customer-facing bir özellikte Level 6 kullanılır. Kod, kimse okumadan production’a çıkar; sonradan yüzeye çıkan kusurlar da hiçbir test’in aramadığı türden olur: tutarsız authorization, doğrulanmamış input yolları, özensiz taşınan secret’lar.

Neden önemli: Vibe coding, gizli güvenlik sorunlarıyla sürdürülemez kod üretir. Production sistemler için asla uygun değildir.

Çözüm: Sıkı sınırlar - Level 6 sadece repository’de açık “yeniden yazılacak” etiketleriyle throwaway prototype’lar için.

Tuzak 5: Junior Developer Beceri Erimesi#

Ne olur: Junior developer’ların Level 4-5 tool’ları kullanmasına “daha produktif oldukları” gerekçesiyle izin verilir. Birkaç çeyrek sonra bakılacak şey şu: debugging task’lerinde zorlanma ve kendi kodlarını açıklayamadıkları tasarım incelemeleri.

Neden önemli: Mühendislik muhakemesini kuran döngü şudur: bir şey yaz, patlamasını izle, nedenini çöz. Generation bu döngüyü atlatır. Risk, özellik ship eden ama debugging becerisi ve mimari anlayış geliştirmeyen bir junior.

Çözüm: Junior’lar için varsayılan Level 2 olsun; kod incelemeleri ve teknik tartışmalarla yetkinlik gösterildikçe progressive unlock.

Tuzak 6: Context Window İllüzyonları#

Ne olur: 200K token context, AI’ın tüm codebase’i “anladığı” şeklinde yorumlanır. Büyük context sağlanır ve tutarlı mimari kararlar beklenir. AI, sistemin farklı kısımlarında çelişkili seçimler yapar.

Neden önemli: Context büyüdükçe modelin dikkati dağılır. Token’ları “görür” ama sistem mimarisini gerçekten anlamaz.

Çözüm: Context çıkarımına güvenmek yerine açık mimari kararlar, pattern’lar ve constraint’ler sağla. Context’i ilgili dosyalarda odaklı tut.

Varsayılanın Geçerli Olduğu Alan#

Fonksiyon seviyesi generation, bakımını başkasının üstleneceği bir codebase’le temas ettiğinde ayakta kalan seviyedir. Çıktı birimi incelenebilecek kadar küçük kalır ve kaliteyi hıza bağlı tutan şey de o incelemedir. Bakım ufku yıllarla ölçülen production kodunda bu seviyede durun.

Sapmayı üç yönde yapın. Aşağı, arama ve autocomplete’e: regülatörün audit trail istediği yerde ya da junior bir mühendisin generation’ın atlatabileceği sezgileri hâlâ inşa ettiği yerde. Yukarı, multi-file ve agentic seviyelere: modelin kaçırdıklarını yakalayacak kadar güçlü test coverage’ın desteklediği mekanik dönüşümlerde. En tepeye, vibe coding’e: yalnızca atılacağı yazıyla kayıt altına alınmış kod için.

Sorumluluk seviyeyle birlikte yer değiştirmez. Kodu merge eden kişi, onu ister kendi yazmış ister onaylamış olsun, doğruluğundan, güvenliğinden ve bakımından sorumludur.

Kaynaklar#

• GitHub Copilot Planları (yeni sekmede açılır) - Copilot Free, Pro, Pro+, Business ve Enterprise için resmi koltuk fiyatları ve premium kullanımın AI kredileriyle nasıl ölçüldüğü.
• Cursor Fiyatlandırması (yeni sekmede açılır) - Cursor’ın resmi tier ve kullanıcı başı fiyatları; her ücretli planın üstüne binen kullanım bazlı faturalama dahil.
• DORA Accelerate DevOps Durum Raporu 2024 (yeni sekmede açılır) - Her %25’lik benimseme artışı için verimlilik, dokümantasyon kalitesi, kod kalitesi, inceleme hızı, teslim throughput’u ve teslim kararlılığı tahminleri ve DORA’nın teslim kaybını batch büyüklüğüyle açıklaması.
• 2025 DORA Raporu: AI Destekli Yazılım Geliştirmenin Durumu (yeni sekmede açılır) - Yaklaşık 5.000 katılımcılı takip anketi: benimseme ve güven verileri, medyan AI deneyimi, günlük AI etkileşim süresi, agentic kullanım ve yukarıda aktarılan Adidas ile Sabre örnekleri.
• Araştırma: GitHub Copilot’un Geliştirici Verimliliği ve Mutluluğu Üzerindeki Etkisini Nicelleştirme (yeni sekmede açılır) - GitHub’ın SPACE çerçeveli çalışması: HTTP sunucusu yazan 95 geliştirici, tamamlama süreleri ve %55,8 rakamının arkasındaki güven aralığı.
• Üretken AI ile Geliştirici Verimliliğini Serbest Bırakmak (yeni sekmede açılır) - McKinsey’nin görev türüne göre dokümantasyon, yeni kod ve refactoring kazançları dökümü; karmaşık işlerde tasarrufun nerede çöktüğü ve junior developer’ların nerede yavaşladığı dahil. McKinsey’nin kendi geliştiricileriyle yapıldığı için yön gösterici olarak okuyun.
• ML Destekli Kod Tamamlama Geliştirici Verimliliğini Artırıyor (yeni sekmede açılır) - Google’ın 10.000’den fazla kurum içi geliştiricide kontrollü inline completion ölçümü; kabul oranları ve istatistiksel anlamlılığı doğrulanamayan bir iddiayı kaldıran yayımlanmış düzeltme dahil.
• Google Kurum İçi Kod Migration’larında AI’ı Nasıl Kullanıyor? (yeni sekmede açılır) - Level 4 rakamlarının kaynağı olan migration çalışması: AI’ın yazdığı değişiklik oranları, tahmini zaman tasarrufu ve JUnit migration’ının dosya ile satır sayıları.
• ANZ Bank’ta AI Aracının Mühendisliğe Etkisi (yeni sekmede açılır) - Regulated bir bankada yaklaşık 100 mühendisle yürütülen altı haftalık randomize deney; görev tamamlama süresi, kod kalitesi ve belirsiz kalan güvenlik sonucu.
• Üretken AI Yüksek Nitelikli Çalışanları Nasıl Etkiliyor (yeni sekmede açılır) - MIT Sloan’ın 4.867 developer’ı kapsayan üç randomize saha deneyi özeti; kıdem kırılımı ve yazarların kod kalitesini hiç değerlendiremediklerine dair çekincesi.
• 2025 Başındaki AI’ın Deneyimli Open-Source Geliştirici Verimliliğine Etkisinin Ölçümü (yeni sekmede açılır) - METR’in olgun repository’ler içinde yürüttüğü randomize deney; öngörülen, algılanan ve ölçülen etkilerin keskin biçimde ayrıştığı yer. METR bugün sonucu tarihsel olarak etiketliyor.
• 2026 Başındaki AI’ın Teknik Çalışan Verimliliğine Etkisine Dair Beyan Ölçümü (yeni sekmede açılır) - METR’in 349 teknik çalışanla yaptığı takip anketi ve beyana dayalı zaman tasarrufunun ölçülenden ne kadar saptığına dair kendi tahmini.
• 2025 Stack Overflow Geliştirici Anketi: AI Bölümü (yeni sekmede açılır) - Geniş örneklemli sıkıntı ve güven verileri: neredeyse doğru ama tam doğru olmayan çıktı sorunu, üretilen kodun debug maliyeti ve kişinin kendi problem çözme becerisine güvenindeki düşüş.
• 2025 GenAI Kod Güvenliği Raporu (yeni sekmede açılır) - Veracode’un 100’den fazla modelin ürettiği güvenlikle ilgili kodu dile ve açık sınıfına göre kırdığı benchmark.
• AI Copilot Kod Kalitesi: 2025 Verileri Kod Klonlarında 4 Kat Artışa İşaret Ediyor (yeni sekmede açılır) - Değişen 211 milyon satır üzerinden kopyala-yapıştırın yükselişini ve refactoring’in düşüşünü gösteren uzunlamasına okuma. GitClear kod kalitesi analitiği satıyor; ticari çıkarı hesaba katın.