Veri kaynakları: CodeRabbit 2025.12 / New Relic 2026 raporu, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms duyurusu, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Vaka örnekleri temsili senaryolardan derlenmiştir, belirli bir şirketi işaret etmez.

En Büyük Hatamız Araç Almamak Değil, CLAUDE.md Yazmamak

Bir anonim bankanın CIO’su bana yakındı: AI araçlarını aldılar, modelleri dağıttılar, insanları eğittiler; ama 2026 ilk yarısının tamamında teslim süreleri neredeyse hiç kısalmadı. Çekirdek sistem ekibinin başkanı daha da net konuştu: “AI’ın yazdığı kod çalışıyor, ama her seferinde baştan yazmak zorunda kalıyoruz — bizim bankanın kurallarını bilmiyor, regülasyon gerekliliklerini bilmiyor, o 30 yıllık eski sisteme nasıl entegre olacağını bilmiyor.”

Sorun yapay zekânın yeterince güçlü olmaması değil, kuralları yazıya dökmemiş olmanız. CodeRabbit’in Aralık 2025’te 470 açık kaynak PR üzerinde yaptığı analiz, sıkça atıf alan bir dizi rakam ortaya koydu: AI destekli PR’lar ortalama 10,83 sorun içerirken, tamamen insan eliyle yazılan PR’larda bu sayı 6,45 — 1,7 kat, yani insan emeğine kıyasla %70 daha fazla hata. 2026’ya gelindiğinde tablo değişmedi: New Relic’in 2026 State of AI Coding Report‘u, ekiplerin %78’inin AI kodunu devreye aldıktan sonra daha fazla arıza bildirdiğini, teknoloji liderlerinin %62’sinin ise ekiplerinin “satır satır incelemeden, kendinden emin bir şekilde” AI kodunu doğrudan gönderdiğini kabul ettiğini ortaya koydu (New Relic resmi raporu 2026, 0,866 skor, birincil kaynak). İki veri seti de aynı şeyi söylüyor: AI’nın eksik olan yetenek değil, bağlam.

Ağustos 2026 itibarıyla, “AI dönüşümünü hızlandırma” anlatısının tamamı şu karşılaştırma üzerinden okunmalı:

| Cep | İlerleme (2026 H1) | Karşı örnek (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot’u 150.000 çalışana yaydı; 2,5 milyon saat / 250 milyon dolar tasarruf sağladı; 400 bin küresel çalışana genişletiliyor | Aynı zamanda %95 hız artışı ve %37 finansal operasyon maliyet düşüşünün ön koşulunun “önce standartlaşma” olduğunu kabul ediyor |
| Atos | 54 ülkede / 56.000 çalışana dağıtıldı; aynı anda 19.000 AI ajanı çalışıyor; birleşik kimlik/güvenlik/uyum/yönetişim kontrol düzlemi | “Önce Agent 365’in yönetişim yeteneklerini devreye al, sonra ölçeklendir” ilkesine sıkı sıkıya bağlı |
| Microsoft (kendi bünyesi) | 2026 Work Trend Index: Liderlerin %82’si 12-18 ay içinde AI ajanlarıyla iş gücünü genişletmeyi planlıyor | Aynı dönemde “kurumsal dönüşümün hızının bireysel kullanımın gerisinde kaldığını” kabul ediyor — Frontier Firm kavramındaki temel çelişki de tam olarak bu |

Kaynak: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Bu iki karşılaştırma tek bir şeyi gösteriyor: ölçek büyütürken standardizasyon yoksa, riski N ile çarpmış olursunuz. EY/Atos/Microsoft’taki “hız” modelin hızı değil; “kurumun AI’ı nasıl kullanacağı sorusunu önce cevaplamış olması”dır. Spec-Driven Development’ın (SDD, spec güdümlü geliştirme) 2026 H1’de gerçek anlamda ana akım haline gelmesinin arka planı budur — mühendislerin dokümantasyonu sevmesinden değil, 19.000 ajanın olduğu bir ortamda spec yazmadan hayatta kalmanın imkânsız hale gelmesindendir.

Bu yazı üç şeyi netleştiriyor: 1) AI kodundaki hataların neden insan yazımından 1,7 kat daha ciddi olduğu; 2) GitHub, AWS, OpenAI, Anthropic ve Alibaba’nın 2026 H1’de nasıl aynı paradigmaya yöneldiği — dokümantasyonla AI davranışını sınırlamak; 3) spec güdümlü yaklaşımın neden bir araç seçimi değil, kurumsal bir yetkinlik olduğu ve 2026 H1’deki üç aşamalı uygulama süreci.

Çubuk uzunluğu = AI hatalarının insana katı; taban 1.0× = insan seviyesi

Taban 1.0×

Toplam sorun sayısı

1.7×
AI 10.83 vs insan 6.45 / PR

Mantık / doğruluk hataları

1.75×

Kod kalitesi / bakım kolaylığı

1.64×

Güvenlik bulguları (genel)

1.57×

Parola işleme hatası

1.88×

XSS açığı

2.74×
↑ En yüksek

Kural kısıtı olmayan AI kodu, her boyutta insandan yüksek
Finans/telekom = uyum mutabakatı, parola yönetimi, hassas alan şifreleme; AI hiçbirini görmüyor

I. AI Hata Oranı Bir Model Sorunu Değil, Bağlam Sorunu

CodeRabbit raporunda sürekli alıntılanan bir cümle var: “AI, yerel iş mantığından yoksundur: modeller kodu istatistiksel çıkarımla analiz eder, anlamsal olarak anlamaz. Katı kısıtlamalar olmadan, kıdemli mühendislerin içselleştirdiği sistem kurallarını gözden kaçırırlar.”

Bu cümle, CodeRabbit’in kendi AI kodlama platformunun (AI kod incelemesi konusunda uzmanlaşmış bir şirket) bu verileri neden diğerlerinden daha erken gördüğünü açıklıyor — her gün binlerce pull request inceliyorlar ve AI’ın yazdığı kodun neye benzediğini her gün görüyorlar. “En kritik” bulgu toplam sayı değil, dağılımdı:

Mantık/Doğruluk +%75: İş mantığı hataları, bağımlılık hataları, kontrol akışı hataları, yapılandırma hataları — bu tür sorunlar testlerde her zaman ortaya çıkmaz, ancak üretim ortamında ciddi arızalara yol açar.
Kod Kalitesi +%64: Tutarsız adlandırma, belirsiz yapı, proje kalıplarının ihlali — bu “en büyük fark kategorisi”. Kıdemli mühendisler ilk bakışta “bu bizim yazım tarzımız değil” der.
Güvenlik +%57 (XSS sınıfı en yüksek 2,74×): Yanlış parola işleme (1,88×), güvensiz nesne referansları (1,91×), hassas bilgi sızıntısı, güvensiz serileştirme (1,82×) — finans sektöründe bu “kullanılabilir mi” meselesi değil, “yayınlanabilir mi” meselesidir.

Sorun AI’ın yeterince güçlü olmaması değil. Sorun, AI’ın görememesi.

O CIO’nun gerçekte takıldığı noktaya dönersek, AI’ın finansal çekirdek sistemlerdeki üç somut arızası şöyle:

Birincisi, AI 30 yıllık mutabakat mantığını göremiyor. Bankanın risk kontrol kuralları, çekirdek sistemin saklı yordamlarında (stored procedure) yazılı — 30 yıl önce yazılmış, kimse tam olarak hatırlamıyor. AI’ın ürettiği kod mantıksal olarak doğru görünüyor, ancak üretim ortamında kimsenin hatırlamadığı o mutabakat kontrolü tetikleniyor ve tüm işlem grubu başarısız oluyor.

İkincisi, AI uyumluluk kısıtlarını göremiyor. Parolalar anahtar yönetim sisteminden geçmek zorunda, hassas alanlar şifreli saklanmak zorunda, loglara müşteri bilgisi yazılamaz — bunlar düzenleyici zorunluluklar ve iç politikalarda yazılı. AI bunları bilmiyor; yazdığı kod çalışıyor ama uyumluluk denetiminden geçemiyor.

Üçüncüsü, AI teknik borcunu göremiyor. O 30 yıllık ana sistem, kendine özgü bir arayüz protokolü kullanıyor ve dokümantasyonu yıllar önce kaybolmuş. AI genel RESTful standartlarına göre kod yazıyor; devreye alındığında arayüzlerin uyuşmadığı ortaya çıkıyor — iki hafta geri alım (rework).

New Relic’in diğer rakamlarına dönelim: Ekiplerin %62’si AI kodunu incelemeden “kendinden emin şekilde” yayınlıyor, %78’i ise devreye aldıktan sonra daha fazla olay raporluyor. Bu iki rakam bir araya geldiğinde şunu söylüyor — AI kodunun kusur oranı asıl sorun değil; “AI kodunun ne gibi kusurları olduğunu bilmiyorum” asıl sorun.

Tipik bir senaryo: Bir anonim şirket bankası, çekirdek sisteminin risk kontrol modülünü geliştirmek için AI destekli araçlar kullanmaya başladı. Üç ay içinde uyumluluk inceleme reddi oranı belirgin şekilde arttı. Temel sorun, şifre yönetimi, hassas alan şifreleme, log uyumluluğu gibi iç kurallardı. Bu kuralların tamamı iç dokümanlarda yazılıydı, ancak AI bunları göremiyordu. Ekip daha sonra temel kuralları CLAUDE.md dosyasına yazdı ve red oranı belirgin şekilde düştü.

İkinci Bölüm: Beş Büyük Platformun 2026 H1 Dönemi: Farklı Yollardan Aynı Sonuca — “Kural Odaklı” Yaklaşım

Temmuz 2025’te GitHub, Spec Kit’i yayınladı. 2026 başında AWS Kiro, OpenAI Codex ve Anthropic Claude Code’un tamamı bu yaklaşımı benimsedi. Mayıs 2026’da Alibaba Qoder, “Spec-Driven Workflow”u ürün konumlandırmasının merkezine koydu. Beş büyük platform, 2026 H1’de aynı paradigmaya ulaştı: dokümanlarla AI davranışını sınırlamak. Bu, tek bir şirketin icadı değil; sektörün “AI kod kalitesi krizine” verdiği kolektif bir yanıttır.

Her platformun 2026 H1’deki en güncel hamlelerine tek tek bakalım:

GitHub Spec Kit: Referans Uygulama, Beş Aşamalı Kapı Kontrolü. Eylül 2025’te açık kaynak olarak yayınlandı ve 2026’nın ilk yarısında sektörde referans uygulama hâline geldi. 5 temel komut + 2 ek komut: /speckit.constitution (tartışılmaz ilkeler), /speckit.specify (ne yapılacak, neden), /speckit.plan (nasıl değiştirilecek), /speckit.tasks (görevlere bölme), /speckit.implement (yürütme) ve ayrıca /clarify ile /analyze. Buradaki kritik tasarım kararı modelden bağımsız olması — aynı spec/plan/tasks dosyaları belirli bir yürütme aracısına bağlı değil; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code gibi araçların tümüyle uyumlu çalışıyor. Bu da onu GitHub’a özel bir üründen ziyade “kurumsal düzeyde bir SDD protokolü” hâline getiriyor (vibecoding.app değerlendirmesi, Haziran 2026, 0.816 puan, ikincil kaynak).

AWS Kiro: Spec-Driven Geliştirmeyi IDE’ye Gömmek. Temmuz 2025’te piyasaya sürülen Kiro, 2026’nın ilk yarısında tam teşekküllü bir Ajan IDE’sine dönüştü. Üç aşamalı iş akışı: Gereksinim → Tasarım → Görev. Spec Kit’ten farkı “hook”larda—Kiro’nun spec dosyaları, önceden tanımlanmış ajan eylemlerini tetikleyebiliyor; uyumluluk, denetim veya dağıtım gibi harici sistemler gerektiren adımları doğrudan iş akışının içine gömmek mümkün. Ekibinizi spec yazmaya zorlamak istiyorsanız Kiro’yu seçin—çünkü spec yazmazsanız Kiro çalışmaz (AWS Kiro resmi duyurusu, Temmuz 2025; Kiro.dev dokümantasyonu, 2026).

OpenAI Codex: AGENTS.md + Birleştirilebilir Skills. 2025-2026, AGENTS.md dosyasını ekosistemin merkezine taşıdı. Skills, 2026’nın ilk yarısındaki kritik genişleme oldu: “Excel tablosu okuma”, “SQL oluşturma”, “veri migrasyonu çalıştırma” gibi işlemleri önceden paketleyip, LEGO parçaları gibi birleştirilebilir hale getirdi. Codex’in haftalık aktif kullanıcı sayısı Haziran 2026’da 5 milyonu aştı ve bunların %20’si geliştirici değil — bu göz ardı edilen bir sinyal: kural odaklı yaklaşım artık sadece mühendislik ekiplerinin işi değil; ürün, operasyon ve risk ekipleri dahil herkesin işi. Herkes AGENTS.md yazıyor (OpenAI 2026.6.2 duyurusu; thebcms.com değerlendirmesi 2026, 0.801 puan).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic, proje talimatlarını CLAUDE.md (Şubat 2026’da resmi pazara girdi), .claude/rules/ (dizin bazında hiyerarşik kurallar) ve Skills (paylaşılabilir iş akışları) olarak adlandırıyor. Claude Code, 2026 ilk yarısının geliştirici memnuniyeti en yüksek aracı — JetBrains 2026.1 araştırması CSAT %91, NPS 54 olarak bildiriyor ve iki bağımsız araştırma (Pragmatic Engineer 2026.2) bu sonucu doğruluyor. Bu, sektördeki AI kodlama araçları arasında şu anki en yüksek skor (uvik.net 2026.5, 0.956 puan, birincil kaynak derlemesi). Claude Code, 9 ayda sıfırdan 2,5 milyar dolarlık yıllık gelire ulaştı (2026.2 Anthropic G serisi verisi) ve GitHub’da 112 bin yıldız (Skills deposu) topladı — geliştiricilerin oyu, kural odaklı yaklaşımın gerçek değerini açıkça gösteriyor.

Alibaba Qoder: Standartların Belirlediği Çin Pazarı. Ağustos 2025’te piyasaya sürülen Qoder, 15 Mayıs 2026’da 1.0 sürümüne yükseltilerek resmi olarak “AI IDE” kimliğinden “Otonom Ajan Geliştirme Çalışma Tezgahı”na (Autonomous Agent Development Workbench) dönüştü. Spec-Driven Workflow akışı; Quest Mode (bağımsız çok dosyalı görevler), Expert Mode (uzman ekip paralel çalışması) ve RepoWiki (depo bilgi grafiği) ile birlikte duyuruldu. 28 Mayıs 2026’da Cloud Agents (tamamen yönetilen ajan çalıştırma ortamı), 21 Temmuz’da ise uyumluluk ve güvenlik yetenekleri sunan Qoder Security devreye alındı. Aynı ay içinde Mobile sürümü (Android/iOS/HarmonyOS) yayınlandı. Mayıs 2026 itibarıyla küresel kullanıcı sayısı 5 milyonu aşan Qoder, DingTalk CLI tarafından desteklenen ajan yürütme ortamlarından biri olarak listeleniyor (Yahoo Finance 2025; Alibaba Cloud resmi 2026; Baidu Baike 2026.7).

Ortak Paradigma: “AI ile nasıl iş birliği yapacağımızı” açıkça bir doküman olarak yazıp depoya koymak ve herkesin — hem tüm insanların hem de tüm AI ajanlarının — aynı spesifikasyona göre çalışmasını sağlamak. Beş platformun uygulama detayları farklılık gösterse de (dosya adları / aşama sayıları / hook mekanizmaları), nihai hedef tamamen aynı.

Peki bu neden 2026’nın ilk yarısında bu kadar yoğun bir şekilde gündeme geldi? Çünkü AI yetenek eşiği artık aşıldı — Claude Code’un otonom ajanları, Codex’in çoklu ajan paralel çalışması, Cursor’ın çoklu dosya yeniden düzenleme yetenekleri derken, AI artık bir “tamamlama aracı” değil, bir “iş arkadaşı”. Yeni bir iş arkadaşına verebileceğiniz oryantasyon dokümanını, AI’a da verebilmelisiniz.

III. Spesifikasyon Odaklılık Bir Araç Seçimi Değil, Kurumsal Bir Yetenektir

Karar vericiler için en önemli madde bu. Spesifikasyon odaklılık araç seçmek değil, “kuruluşumuzun AI ile nasıl iş birliği yapacağını” tanımlamaktır. GitHub Spec Kit’i mi yoksa Claude Code’u mu seçtiğiniz önemli değil; önemli olan, spesifikasyonu bir dokümana yazıp depoya koymanız ve hem insanların hem de AI’ın bu spesifikasyona göre çalışmasını sağlamanızdır.

Bu olmadan, en iyi araç bile ekibinizin daha hızlı bir şekilde daha fazla teknik borç üretmesinden başka bir işe yaramaz.

Bu konuyu 2026 H1 ölçeğindeki yaygınlaştırma perspektifinden ele aldığımızda kanıtlar çok daha sağlam. Microsoft, Temmuz 2026’daki FY26 değerlendirmesinde EY ve Atos vakalarını “Frontier Firm” şablonu olarak yazdı — bunun nedeni modellerin yeni olması değil, her iki şirketin de “AI nasıl kullanılır” sorusunu önce yanıtlamış olması:

EY: Önce yönetişim, sonra ölçeklenen getiri. EY, 2024-2025’te Microsoft 365 Copilot’u 150 bin kişiye yaygınlaştırdı ve 2,5 milyon saat, yaklaşık 250 milyon dolar tasarruf sağladı. Bunun ön koşulu “AI yönetişim çerçevesinin önce kurulması”ydı: EY, Power Platform, Copilot Studio, Azure, Foundry ve Fabric ile birleşik bir araç zinciri oluşturdu; standartları, uyumluluğu ve denetimi aynı altyapıya yerleştirdi. Ardından %95 hız artışı, %37 finansal operasyon maliyet düşüşü ve %90’a varan manuel iş akışı azalması geldi. EY’nin başkan yardımcısı 2026 AI Tour’da çok net konuştu: “Biz önce AI’ı yayıp sonra yönetişimi eklemedik; önce yönetişimi kurduk, sonra AI’ı yaygınlaştırdık.”

Atos: 19.000 ajan için birleşik kontrol düzlemi. Atos, Microsoft 365 E7’yi (Frontier Suite) dağıtan dünyadaki ilk kuruluşlardan biri olarak Copilot’u 54 ülkede 56.000 çalışanına yaydı. Aynı anda 19.000 AI ajanı çalıştırıyor — dahili BT’den iş birimlerine ve müşteri projelerine kadar her yerde Foundry + Copilot Studio ile ajanlar oluşturuluyor. Atos’un bunu başarmasındaki kilit nokta “tek kontrol düzlemi”: Entra (kimlik) + Defender (güvenlik) + Intune (cihaz) + Purview (uyumluluk) + Agent 365 (ajan yönetişimi) — beş unsur birbirine bağlı. Bu bağlama biçimi, finans sektöründe “güvenlik denetimi + veri transferi değerlendirmesi + algoritma kaydı + denetim + model yönetişimi”ne karşılık gelir; yani salt bir AI aracı değil, bir yönetişim mimarisidir.

Microsoft’un kendi “organizasyonel değişim paradoksu.” 2026 Work Trend Index raporunda Microsoft, kendi itirafını yapıyor: “Organizasyonel değişimin hızı, bireysel kullanımın gerisinde kalıyor.” Araştırmaya katılan 20.000 AI kullanıcısından %82’si liderlerin 12-18 ay içinde AI ajanlarıyla iş gücünü genişletmeyi planladığını söylüyor; ancak yalnızca %24’ü bunu kurumsal düzeyde tamamlamış durumda. Liderlerin %81’i AI ajanlarının AI stratejilerine orta veya yüksek düzeyde entegre edileceğini öngörüyor — ama yine sadece %24’ü bunu başarmış. Bu, çoğu işletmenin “hazırlık” ile “uygulama” arasında hâlâ 12-18 aylık bir mesafe olduğunu gösteriyor. Bu mesafeyi kapatmanın ana yükü ise norm ve standart odaklı yaklaşımlara biniyor.

Kaynak: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, birincil PDF kaynağı); Futurum Group 2026.1.26 analizi (ikincil kaynak).

Çıkarım 1: Normlara yatırım yapmak yüksek ROI sağlar.

CodeRabbit’in verileri net bir ROI hesabı için sağlam bir temel sunuyor: AI kod sorun oranı yaklaşık 1,7 kat, güvenlik açıklarında ise 2,74 kat azalma. Bunun anlamı:

Daha az yeniden iş (finans sektöründe tek bir uyumluluk denetimi geri dönüşü 2-4 hafta sürer)
Daha az güvenlik olayı (tek bir veri sızıntısının düzenleyici cezası ve itibar kaybı)
Daha düşük bakım maliyeti (teknik borçta %40 azalma yaygın bir rakamdır)

Bir CLAUDE.md/AGENTS.md proje standardı yazmak, AI çağında en yüksek ROI’ye sahip mühendislik hamlesidir. EY’in örneği gerçek dünyadan somut bir karşılık sunuyor: 150 bin kişiye Copilot dağıtımı, 250 milyon dolar tasarruf. Dikkat edin, EY bu tasarrufu “araç güçlü olduğu için” değil, “standartlar aracın değerini gerçeğe dönüştürdüğü için” elde etti.

İkinci içgörü: Standartları organizasyonel süreçlere yazın, bireylere bağımlı kalmayın.

Standart yalnızca kıdemli bir mühendisin kafasında yaşıyorsa, kişi değiştiğinde kaybolur. Mutlaka şuraya sabitlenmeli:

Depo dokümantasyonu (AGENTS.md / CLAUDE.md / constitution.md)
CI kapıları (standartlara uyumu otomatik denetleme)
Ekip genelinde paylaşılan yapılandırma (Skills sistemiyle tüm ekibin kullanımına açma)

规范ları organizasyonun varlığı hâline getirmek, kişisel bir beceri olmaktan çıkarmak gerekir. Bu özellikle finans sektöründe kritik önem taşır — uyumluluk gereksinimleriniz, güvenlik kurallarınız ve iş kurallarınız organizasyon düzeyinde varlıklardır; herhangi bir mühendisin “tecrübesi” değildir. Atos’un 19.000 ajanı 54 ülkede çalışabiliyorsa, bunun nedeni yönetişimin “birinin bilmesi” değil, “sistemin zorunlu kılması”dır.

Üçüncü içgörü: Kapı kontrolü hızdan daha önemlidir.

GitHub Spec Kit’in beş aşamalı kapı kontrolü (constitution → specify → plan → tasks → implement), Claude Code’un “testler başarısız olmadan kod yazma” kuralı ve Kiro’nun “spec yazılmadan başlatılamaz” yaklaşımı — hepsi aynı şeyi yapıyor: AI ile nihai çıktı arasına bir “fren” koymak. Her adımda denetlenebilir çıktılar (spec.md, plan.md, tasks.md) üretiliyor ve bunlar kod üretilmeden önce reddedilebilir veya değiştirilebilir.

Özerkliği ne kadar yüksekse, kapı kontrolü o kadar gerekli. Finans sektöründeki değişiklik onay kurulları (Change Advisory Board — CAB), algoritma kayıt süreçleri (algorithm registration) ve güvenlik seviye tespiti (等保测评 — Chinese security level assessment, GDPR/NIS2 benzeri düzenleyici çerçevelere karşılık gelir), özünde üretim öncesine kapı kontrolü koymaktır. AI kodu da benzer bir kapı kontrolüne ihtiyaç duyar; yalnızca biçimi farklıdır. New Relic 2026 raporundaki, “güvenle incelemeden gönderen” %62’lik ekip, bu güvenin bedelini daha yüksek arıza oranıyla (%78) ödüyor.

İlk aşama en çok zaman alır, ancak ROI en yüksektir
Çoğu finans kuruluşunun kuralları doküman/e-posta/insan beynine dağılmıştır, ilk düzenleme 3-8 haftalık bir yatırımdır

Dört, 2026 H1 Gerçek Uygulama: Üç Aşamalı Model

Finans sektörü örneği üzerinden ilerleyen üç aşamalı yol haritası, diğer sıkı denetimli sektörler için de yol göstericidir. EY ve Atos’un 2026 ilk yarısındaki uygulamaları tam olarak bu üç aşamaya denk düşüyor.

Birinci Aşama: Kuralların Envanteri (2-4 hafta).

En çok zaman alan ama ROI’si en yüksek aşama budur. Dağınık haldeki tüm kuralları bir araya getirirsiniz:

Uyumluluk gereklilikleri: Finans sektöründe asgari taban çizgisi = 等保三级 (Çin’in çok katmanlı koruma standardı, Level 3) + veri yurtdışı transfer değerlendirmesi + algoritma kaydı (bunlardan biri eksikse AI yaygınlaştırmaya başlamayın). Bunun üzerinde ayrıca düzenleyici raporlama kuralları, müşteri bilgisi koruması, sınır ötesi veri akışı kısıtlamaları ve hangi verilerin AI’a gösterilebileceği gibi gereklilikler yer alır.
Güvenlik kuralları: Parola yönetimi, şifreleme standartları, hassas alan işleme, log gereklilikleri
İş kuralları: Risk kontrol eşikleri, hasar ödeme koşulları, işlem limitleri, faturalama mantığı
Teknik kısıtlar: Eski sistem arayüzleri, veritabanı adlandırma kuralları, framework sürüm sınırlamaları
Tedarikçi yönetimi: Tedarikçilerin sözleşmede bizim standartlarımıza uymasını nasıl şart koşacağımız, tedarikçilerin AI kullanımını nasıl denetleyeceğimiz

Tipik bir senaryo: Bir menkul kıymetler şirketi envanter aşamasında kuralların Word belgeleri, JIRA wiki sayfaları, kişisel e-postalar ve Excel tablolarına dağılmış olduğunu fark eder—ancak derleme sonrasında yapılandırılmış bir kural listesi ortaya çıkar. Atos’un yaklaşımı daha sistematiktir: kuralları doğrudan “uyum, güvenlik, iş, teknik, tedarikçi” olmak üzere beş kategoriye ayırır, her biri için ayrı bir yönetim iş akışı oluşturur ve hepsini Agent 365 kontrol düzlemine bağlar.

Bu teknik bir iş değil, organizasyonel bir iştir; uyum, güvenlik ve iş birimlerini bir araya getirip herkesin üzerinde mutabık kaldığı kuralları yazıya dökmeniz gerekir. İlk kez yapan bir finans kuruluşu için bu süreç genellikle 3-8 hafta sürer—ancak bu kalıcı bir kurumsal varlıktır.

İkinci Aşama: Depoya Aktarma (1-2 hafta).

İlk aşamada derlenen kuralları belge haline getirip depoya koyun. GitHub Spec Kit constitution.md, Claude Code CLAUDE.md, OpenAI Codex AGENTS.md, Alibaba Qoder ise Spec Workflow kullanır. Dosya adları farklıdır, ancak hedef aynıdır: AI’ın depoyu açtığı anda kuralları yüklemesini sağlamak.

Yapı Önerisi (2026 H1 Ana Akım Formu)

Proje Özeti: Bu sistem ne işe yarar, kime hizmet eder
Tartışılmaz İlkeler: Güvenlik kırmızı çizgileri, uyumluluk kırmızı çizgileri, iş kırmızı çizgileri
Teknoloji Yığını ve Kısıtlar: Hangi framework, hangi veritabanı, hangi API standartları
Kod Standartları: İsimlendirme kuralları, dizin yapısı, test minimum kapsam gereksinimleri (TDD ritmini zorunlu kılmaz—test kapsama oranını, zorunlu test edilecek yolları ve yasaklı yolları net biçimde yazmanız yeterli; TDD, kuruluşun tercihine bağlı bir ritimdir, standartların zorunlu kıldığı bir gereklilik değildir)
İş Kuralları: Risk kontrol mantığı, işlem kuralları, faturalama kuralları
Uyumluluk Gereksinimleri: Çin’in çok seviyeli koruma (等保) değerlendirmesi, veri yurt dışına çıkış değerlendirmesi, düzenleyici raporlama, AI tarafından üretilen algoritmaların kayıt zorunluluğu olup olmadığı
AI Kullanım Kuralları: Hangi senaryolarda AI kullanılabilir, hangi senaryolarda insan onayı zorunludur, veri yurt dışına çıkış kuralları
Tedarikçi Yönetimi: Sözleşme koşulları, denetim mekanizmaları, sorumluluk paylaşımı

Ek: CLAUDE.md Finans Sürümü İskeleti (yaklaşık 200 satır, doğrudan fork edip özelleştirebilirsiniz)

Aşağıda, bir anonim bankanın çekirdek sistem dönüşümü için hazırlanmış CLAUDE.md iskeleti yer almaktadır. “Tartışılmaz İlkeler → Uyumluluk Gereksinimleri → AI Kullanım Kuralları → İş Kuralları → Mühendislik Kısıtları” sırasıyla düzenlenmiştir. Şirketinizin sıfırdan başlamasına gerek yok—boş alanları kendi spesifik kurallarınızla doldurmanız yeterli.

# CLAUDE.md — <sistem adı> — AI İş Birliği Kuralları

> Kapsam: <sistem adı> v<sürüm>, bu depoda çalışan tüm AI ajanları (Claude Code / Cursor / Copilot / Codex)
> bu kurallara uymak zorundadır. Bu belge <yönetim kurulu> tarafından korunur, çeyreklik gözden geçirme.
> Son güncelleme: YYYY-MM-DD

## 1. Proje Genel Bakış
- **İş konumlandırması**: çekirdek sistem adı / hizmet verilen müşteri segmenti / ana işlem türleri
- **Kritik zincir**: işlem → risk kontrolü → takas → mutabakat → düzenleyici raporlama
- **Kullanılamaz pencere**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (bu pencerede hiçbir değişiklik yapılamaz)
- **Çekirdek bağımlılıklar**: yukarı yönde <sistem>, aşağı yönde <sistem>, düzenleyici raporlama platformu

## 2. Pazarlık Edilemez İlkeler (kırmızı çizgiler — ihlal = birleştirme reddi)

### 2.1 Güvenlik Kırmızı Çizgileri
- Parolalar, anahtarlar ve token'lar mutlaka KMS (Anahtar Yönetim Servisi) üzerinden geçmelidir; **hardcode yasak**, **log'a yazma yasak**
- Müşteriye ait hassas alanlar (kimlik numarası / kart numarası / CVV / telefon) **mutlaka şifreli saklanmalıdır**; düz metin veritabanına yazılamaz
- Log'larda şunlar yasaktır: tam kimlik numarası, tam kart numarası, düz metin parola, müşteri adı + telefon kombinasyonu
- Dış API çağrıları mutlaka API ağ geçidi üzerinden yapılmalıdır; doğrudan bağlantı yasaktır

### 2.2 Uyumluluk Kırmızı Çizgileri
- Müşteri verisine erişim içeren AI tarafından üretilen kod, PR açıklamasında "veri erişimi: <alan>" notunu taşımak zorundadır
- Sınır ötesi veri aktarımı yasaktır; **tüm veri çıkışı sınır ötesi veri aktarımı değerlendirmesi sürecinden geçmelidir** (uyum birimiyle iletişime geçin)
- Algoritmik kararlar (kredi / sigorta fiyatlandırması / dolandırıcılık önleme) insan incelemesi için bir kapı bulundurmak zorundadır
- Model değişiklikleri algoritma kaydından geçmelidir; kayıt numarası PR açıklamasında belirtilmelidir

### 2.3 İş Kırmızı Çizgileri
- Risk kontrolü eşik değişiklikleri risk sorumlusu + iş sorumlusu çift imzasını gerektirir
- Müşteri fonlarını ilgilendiren işlemler idempotent tasarım + başarısızlıkta geri alma (rollback) içermelidir
- İşlem limitleri, ücret tarifeleri ve ürün parametreleri parametre yönetim platformundan geçer; kodda hardcode edilemez

## 3. Teknoloji Yığını ve Kısıtlamalar
- **Dil**: Java 17 (çekirdek) / Kotlin (yeni modüller) / SQL (veritabanı)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Veritabanı**: OceanBase 4.x (MySQL uyumlu mod), **yabancı anahtar kullanımı yasaktır**
- **API standartları**: dahili her yerde gRPC; dış API'ler OpenAPI 3.0; RESTful yalnızca yönetim tipi arayüzler
- **Adlandırma kuralları**: Java sınıfları PascalCase, metotlar camelCase, sabitler UPPER_SNAKE; tablo adları `t_<iş alanı>_<varlık>`; indeksler `idx_<tablo>_<alan>_<sıra>`
- **Paket yapısı**: `com.<şirket>.<iş alanı>.<alt alan>.<katman>` (ör. `com.bank.pay.tx.core.service`)

## 4. Kod Standartları
- **Minimum test kapsamı**: çekirdek zincir ≥ %80, yardımcı sınıflar ≥ %60, yeni kod PR'larına testler eşlik etmelidir
- **Zorunlu test yolları**: tüm controller'lar için entegrasyon testi (başarısızlık yolları dahil); tüm enum dalları için birim testi
- **Yasak yollar**: `<tarihsel miras modülü>` dizininde değişiklik yasaktır — önce bir adaptör katmanı kurulmalıdır
- **Bağımlılık yönetimi**: yeni üçüncü taraf bağımlılıkları SCA taraması + güvenlik onayından geçmelidir

## 5. İş Kuralları (alana göre)
### 5.1 İşlem
- Tek işlem limiti: <tutar>; günlük limit: <tutar>; aşım için insan onayı gerekir
- İşlem zaman penceresi: <saat> ~ <saat>
- Yinelenen işlem tespiti: <zaman penceresi> içinde aynı <alan> = yinelenen işlem

### 5.2 Risk Kontrolü
- Kara liste eşleme önceliği: dahili kara liste → düzenleyici indirilmiş liste → adli dondurma
- Dolandırıcılık önleme modeli çıktı eşiği: <puan>; üzeri için ikinci insan incelemesi zorunludur

### 5.3 Faturalandırma
- Ücret değişikliklerinde versiyon numarası + yürürlük tarihi zorunludur
- Geçmiş siparişler yürürlük tarihindeki tarife üzerinden hesaplanır, geriye dönük uygulanmaz

## 6. Uyumluluk Gereksinimleri
- 等保三级 (MLPS Seviye 3): <değerlendirme kurumu>, <sonraki değerlendirme tarihi>
- Sınır ötesi veri aktarımı değerlendirmesi: kapsam (yalnızca sınır ötesi iş modülleri)
- Algoritma kaydı: kapsam (kredi / sigorta fiyatlandırması vb. kritik algoritmalar), kayıt no `<kayıt no>`
- Düzenleyici raporlama: <CBIRC / Çin Merkez Bankası> alan eşleme tablosu `<yol>` altında

## 7. AI Kullanım Kuralları
- **AI kullanılabilir senaryolar**: CRUD şablonları, birim testi üretimi, belge taslakları, SQL optimizasyon önerileri
- **İnsan incelemesi zorunlu senaryolar**: risk kontrolü mantığı, faturalandırma kuralları, yetki kontrolü, şifreleme / şifre çözme, sınır ötesi veri
- **AI'nın tek başına yapamayacağı senaryolar**: CAB (Değişiklik Danışma Kurulu) onay malzemeleri, üretim değişikliği yürütme, acil durum müdahalesi
- **Sınır ötesi veri kuralları**: eğitim verisi / prompt'lar / çıktı logları kesinlikle ülke dışına çıkmaz; yerelleştirilmiş dağıtım sürümü (<üretici>) önceliklidir
- **Denetim gereksinimleri**: AI tarafından üretilen tüm kodlar PR açıklamasında "AI destekli: <araç adı>" notunu taşımak zorundadır

## 8. Tedarikçi Yönetişimi
- **Tedarikçi kabulü**: SOC 2 / ISO 27001 raporu sağlanmalıdır; AI modelleri için model kartı (model card) sunulmalıdır
- **Sözleşme maddeleri**: veri mülkiyeti, model açıklanabilirliği, çıkış maddeleri, denetim hakkı
- **Denetim mekanizması**: tedarikçilerin AI kullanımı çeyreklik denetlenir; yüksek riskli tedarikçiler aylık denetlenir

## 9. Yönetişim ve Güncelleme
- **Sahibi**: <yönetim kurulu> (uyum + güvenlik + mimari + iş)
- **Güncelleme Sıklığı**: çeyreklik gözden geçirme; acil değişiklik için hızlı kanal (çift imza + 24 saat duyuru)
- **Değişiklik günlüğü**: bkz. `CLAUDE_CHANGELOG.md`
- **İhlal İşleme**: ilk ihlal = uyarı + zorunlu eğitim; ikinci ihlal = AI araç kullanımının askıya alınması; üçüncü = yetki iptali

Bu iskelet bir “standart cevap” değil, bir “doldurma şablonu”dur. Her boşluğa ne koyduğunuz, kaç kelime yazdığınızdan daha önemlidir—boşluklar, şirketinizin “henüz netleştiremediği” kısımları ortaya çıkarır.

Tipik bir senaryo: Bir anonim bankanın CLAUDE.md dosyası, şifre işleme kurallarını özel olarak tanımlar—AI tarafından üretilen kod şifre içerdiğinde, dahili anahtar yönetim API’sini çağırmak zorundadır; hardcoded (kod içine gömülü) şifre yazmak yasaktır. Bu tür kurallar, uyumluluk incelemesinden geri dönen nedenler arasında oldukça yüksek bir orana sahiptir.

2026 H1’de önemli bir yeni alan Skills/İş Akışı Tanımlarıdır—yalnızca dokümantasyon değil, AI tarafından çağrılabilen bir araç zinciridir. Claude Code’un Skills sistemi (Şubat 2026’da Anthropic’in resmi pazarına girdi, GitHub’da 112.000 yıldız), “Excel tablosu okuma”, “SQL üretme”, “veri migrasyonu çalıştırma” gibi işlemleri paylaşılabilir iş akışlarına dönüştürür. Bu, standartların 2026 H1’deki kritik evrimidir: standartlar yalnızca kısıtlama değil, çalıştırılabilir iş akışlarıdır.

Üçüncü Aşama: Kurumsallaşma (sürekli).

Standartları yazmak işin sonu değil, başlangıcıdır. Bunları organizasyonel sürecin bir parçası haline getirmeniz gerekir:

CI kapı kontrolü entegrasyonu: Kodun standarda uyup uymadığını otomatik olarak denetleyin (örneğin parolanın kod içine gömülmesi, hassas alanların şifrelenmemesi)
Ekip paylaşımlı yapılandırma: Skills sistemiyle tüm ekibin aynı standardı kullanabilmesini sağlayın
Düzenli güncelleme mekanizması: Kurallar değişirse, standartlar da değişir (çeyreklik değerlendirme)
Ölçüm ve geri bildirim: AI kodlarının hata oranı, uyumluluk incelemesinden geçme oranı ve yeniden işleme oranını takip edin
Ajan yönetişimi: İnsana yönelik yönetişimi AI ajanlarına da genişletin — Atos’un Agent 365 üzerinde yaptığı iş, bunu “bireysel” değil “sistem düzeyinde” hale getirmektir

EY ve Atos, 2026 H1’de üçüncü aşamayı “organizasyonel yetkinliğe” dönüştürdü. EY’nin 2,5 milyon saatlik tasarrufu, birinci ve üçüncü aşamaların doğru uygulanmasının sonucudur — ikinci aşama yalnızca kuralların AI’ın okuyabileceği belgelere dönüştürülmesidir.

Beş. Sıkı Denetimli Sektör Varyantı: Uyumluluğu Kod İçine Gömmenin Üç Mühendislik Yöntemi

Finans, telekom ve sağlık gibi sıkı denetimli sektörlerde, şartname odaklı uygulama genel sektörlerden bir katman daha zorludur — uyumluluk sürece sonradan eklenen bir adım değil, kodun içine gömülü bir bileşendir. Aşağıdaki üç yöntem, 2026 H1’de doğrulanmış uyumluluk gömme yaklaşımlarıdır; CIO’lar ve dijital dönüşüm liderleri organizasyon tasarımı yaparken doğrudan referans alabilir.

5.1 Uyum Temsilcisinin Akış Ekibine Gömülmesi: Uyumun “Onay” Değil “Sahada” Olması

Geleneksel yaklaşım: İş ekibi kodu yazar, uyum ekibi sonradan denetler—denetimde bir sorun tespit edildiğinde, kod zaten yarım aydır canlıda demektir ve düzeltme maliyeti 2-4 haftayı bulur. Sorunun özü, uyumun sürecin en sonunda yer almasıdır.

Yeni yaklaşım: Her akış ekibine (stream-aligned team) bir uyum temsilcisi gömmek. Bu, “asıl bağlılık uyum departmanına, operasyonel bağlılık iş ekibine” şeklinde çift yönlü raporlama hattıyla çalışır. Tasarımın detayları:

Kadro planlaması: Her 6-8 akış ekibi için 1 uyum temsilcisi. Temsilci, uyum departmanına bağlıdır ancak fiziksel olarak iş ekibiyle oturur—bu, geçici bir “görevlendirme” değildir
Operasyonel KPI: Uyum temsilcisinin performansının %50’si, iş ekibinin “uyum kusur oranı” ve “denetimde ilk seferde geçme oranı”na bağlanır; yalnızca uyum departmanının “denetim kapsamı”na bakılmaz
Önceden müdahale: Uyum temsilcisi günlük stand-up toplantılarına katılır (haftada 1 kez yeterlidir), PR incelemeleri yapar ve AI tarafından üretilen kod, birleştirilmeden önce uyum temsilcisinden geçmek zorundadır—birleştirme sonrası fark edilip sonradan düzeltilmez
Araç desteği: Uyum temsilcisi, uyum kontrol listelerini Skills çağrılarıyla kullanır; manuel olarak madde madde karşılaştırma yapmaz

Tipik bir senaryo: 2026 ilk yarısında ulusal ölçekte faaliyet gösteren bir anonim banka, 3 akış ekibine uyum temsilcisi yerleştirerek pilot uygulama başlattı ve AI kod uyum reddi oranını %35’ten %8’e düşürdü. Buradaki kritik nokta, uyumun “daha sıkı denetlemesi” değil, “daha erken görmesi”. Bu yaklaşımın anahtarı, uyum temsilcisinin dolaylı (dashed-line) performans hedeflerinin iş hedefleriyle hizalanmasıdır — eğer uyum temsilcisinin KPI’ları hâlâ yalnızca uyum departmanının verdiği görevlere bakıyorsa, bu yerleştirme başarısız olur.

5.2 Uyumu enabling team’e dönüştürmek: kısıtları affordance’a çevirmek

Geleneksel yaklaşım: Uyum ekibi bir “bekçi”dir, iş ekipleri uyumu “sorun çıkaran” olarak görür. İki taraf arasında sıfır toplamlı bir oyun vardır.

Yeni yaklaşım: Uyum ekibi, Team Topologies’taki enabling team modeline göre yeniden yapılandırılır — doğrudan kod yazmaz, doğrudan PR incelemez; ancak iş ekiplerinin “kendi kendine uyum sağlaması” için üç şey sunar:

CI pipeline’da uyumluluk kontrolleri: Parola hardcode’u, hassas alanların düz metin saklanması, sınır ötesi veri transferi ve algoritmik karar noktaları gibi yüksek frekanslı uyumluluk noktalarını GitHub Actions / GitLab CI üzerinde zorunlu gate’ler haline getirin. İş ekibinin PR’ı otomatik kontrol tetikler, uyumsuzluk durumunda doğrudan fail olur — uyumluluk temsilcisinin manuel kontrol yapmasına gerek kalmaz.
Regülasyon gereksinimlerini affordance (ortam kaynaklı kısıtlama) olarak tasarlayın: Örneğin, müşteri verisi içeren bir özellik geliştirilirken IDE eklentisi “bu alan için KMS çağrılması önerilir” uyarısı gösterir; log yazarken hassas bilgi içerip içermediğini otomatik tespit edip alarm verir. Uyumluluk gereksinimlerini “geliştirme sırasında doğal olarak gerçekleşen eylemler” haline getirin, “go-live öncesi hangi kuralı ihlal ettiğinizin bildirilmesi” değil.
Paylaşılan Skills kütüphanesi + uyumluluk eğitimi: Uyumluluk ekibi bir “uyumluluk Skills” koleksiyonu oluşturur; yeni işe başlayanlar / ekipler arası geçiş yapanlar doğrudan bunu kullanır — uyumluluk bilgisini “doküman” olmaktan çıkarıp “çalıştırılabilir araç” haline getirir.

Tipik senaryo: Bir bölgesel banka 2026 H1’de CI uyumluluk gate’i + IDE uyumluluk uyarılarını devreye alarak AI kod uyumluluk incelemesinde kişi başı süreyi 45 dakika/işlemden 8 dakika/işleme düşürdü. Buradaki asıl nokta uyumluluk “incelemesinin hızlanması” değil, AI’ın üretim aşamasında “hata yapmamasıdır”.

5.3 Çift hızlı uyumluluk: İş temposuna göre katmanlı yaklaşım

Son bir detay: uyumlulukta “herkese aynı ölçü” yaklaşımı yanlış olur. Kuralları risk seviyesine göre iki kademeye ayırın:

Yüksek riskli kurallar (müşteri fonları / algoritmik kararlar / sınır ötesi veri / kritik güvenlik çizgileri) sıkı kapı kontrolüne tabidir: zorunlu insan incelemesi + AI ikinci onayı + Change Advisory Board (CAB) kaydı
Düşük riskli kurallar (CRUD şablonları / araç tipi kodlar / doküman üretimi) self-servis kapı kontrolünden geçer: yalnızca CI otomatik kontrolü yeterlidir, insan incelemesi gerekmez

Atos’un Agent 365 kontrol düzlemi özünde bu katmanlı yapıyı kullanır — farklı seviyedeki ajanlar farklı yönetişim gereksinimlerine bağlanır. Uyumluluk kurallarını risk bazlı katmanlara ayırmak, iş birimlerinin “uyumluluk her yerde önümü kesiyor” hissini azaltır.

Bu üç unsuru bir arada değerlendirmek: Uyumluluğu sürece gömmek yeni bir prosedür eklemek değil, ekibin yapısını ve teşvik mekanizmasını yeniden tasarlamaktır. Eğer uyumluluk departmanınız hâlâ “sonradan denetim” modundaysa, kural odaklı dönüşüm en zor aşama olan “kurumsallaşma”da takılıp kalır — uyumluluk departmanının önce kendini dönüştürmesi gerekir ki iş birimlerinin kural odaklı çalışması sorunsuz ilerlesin.

Altı. Merak Edebilecekleriniz

“Zaten kodlama standartlarımız var, bunun farkı ne?”

Kodlama standartları “kodun nasıl yazılacağını” düzenler; kural odaklı çalışma ise “AI ile nasıl iş birliği yapılacağını” düzenler. Kodlama standartları şunları kapsamaz: iş kuralları, uyumluluk gereksinimleri, AI kullanım politikaları. Kural odaklı çalışma, “insan ve AI iş birliğinin tüm sürecini” açıkça ortaya koyar; bir kod stili kılavuzu değildir.

“Kod standartları yazmak geliştirme hızını düşürür mü?”

Kısa vadede evet, uzun vadede hayır. CodeRabbit’in verileri net bir cevap veriyor: kısıtsız AI kodunda hata riski yaklaşık 1,7 kat, güvenlik açığı riski ise 2,74 kat daha yüksek. Finans sektöründe tek bir uyumluluk denetimi geri dönüşü 2-4 hafta sürer — tek bir geri dönüşten kaçınmanız, bir aylık standart yazma süresine bedeldir. EY’ın 250 milyon dolarlık tasarrufu, bunu kurumsal bir yetkinliğe dönüştürmenin gerçek kanıtıdır.

“Ekibimizde standart yazmayı bilen kimse yoksa ne yapacağız?”

Sıfırdan başlamanıza gerek yok. GitHub Spec Kit, Claude Code Superpowers ve AWS Kiro hazır şablonlar sunuyor. Tek yapmanız gereken, kuruluşunuza özgü kuralları doldurmak — bunların çoğu uyumluluk ve güvenlik kurallarıdır ve uyumluluk ile güvenlik departmanlarınız bunları zaten yazmıştır; sadece AI’ın erişebileceği bir yere koymamışsınızdır.

“O kadar çok AI aracı var ki, hangisini seçmeliyiz?”

Önemli olan bu değil. Zaten kullandıklarınızı seçin. Kural odaklı yaklaşım araçtan bağımsızdır — CLAUDE.md, Claude Code, Cursor ve Codex’te çalışır; AGENTS.md, OpenAI ekosisteminde sorunsuz çalışır; constitution.md ise modelden bağımsızdır. Asıl mesele kural yazmak, araç değiştirmek değil. EY Microsoft ekosisteminde yaygınlaşıyor, Atos da Microsoft ekosisteminde yaygınlaşıyor — araç seçimindeki farklılıklar yalnızca yüzeyseldir; asıl önemli olan yönetişim mimarisinin tutarlılığıdır.

“Ağustos 2026’da AB Yapay Zeka Yasası (EU AI Act) tamamen yürürlüğe girecek — bu bizi etkiler mi?”

Evet. AB Yapay Zeka Yasası (EU AI Act), 2 Ağustos 2026’da tam uygulama aşamasına giriyor ve yüksek riskli yapay zeka sistemleri (kredi, sigorta fiyatlandırması, işe alım eleme, kritik altyapı dahil) için zorunlu uyumluluk gereklilikleri getiriyor: risk yönetimi (Madde 9), veri yönetimi (Madde 10), dokümantasyon ve şeffaflık (Madde 11-13), insan gözetimi (Madde 14), doğruluk/sağlamlık (Madde 15). İhlal cezaları 35 milyon avroya veya küresel cironun %7’sine kadar çıkabiliyor. Çin’den küresele açılan şirketler için AB pazarı kaçınılmaz bir sınav; yurt içinde faaliyet gösterenler için ise EU AI Act, dünya genelinde en çok referans alınan çerçeve olmayı sürdürüyor. Doğrudan kapsam altında olmasanız bile, bu düzenlemenin tedarikçilerinize, iş ortaklarınıza ve sınır ötesi operasyonlarınıza dolaylı etkisini görmezden gelmeniz çok zor (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Yurt İçi Karşılaştırma: AB Yapay Zekayı Düzenliyor, Biz Ne Yapıyoruz?”

Türkiye’de üretken yapay zeka yönetimi, “algoritma kaydı + veri seti denetimi + güvenlik değerlendirmesi” üçlüsü üzerinden yürüyor. Çin’de ise Ağustos 2023’te yürürlüğe giren Üretken Yapay Zeka Hizmetleri Yönetimine İlişkin Geçici Tedbirler (Generative AI Service Management Interim Measures) temel dayanak. İki yaklaşım arasındaki en büyük fark madde detaylarında değil, yasama felsefesinde yatıyor:

Boyut	AB Yapay Zeka Yasası	Çin’in Üretken Yapay Zeka Hizmet Yönetimi Önlemleri
Hukuki Nitelik	Yatay düzenleme (tüm yapay zeka sistemleri için geçerli)	Dikey kural (üretken yapay zeka hizmetlerine odaklı)
Risk Sınıflandırması	4 seviye (kabul edilemez / yüksek / sınırlı / minimal)	2 seviye (kamuoyu güvenliğini ilgilendiren / genel ticari kullanım)
Denetim Zamanlaması	Önceden (geliştirme aşamasında kayıt zorunluluğu)	Sonradan (hizmete alındıktan sonra kayıt + algoritma kaydı)
Şeffaflık	Yüksek (eğitim verisi kaynak özeti ve model kartı açıklaması zorunlu)	Orta (veri seti uyumluluğu şart, ancak kaynak açıklaması zorunlu değil)
Ceza Üst Sınırı	Küresel cironun %7’si veya 35 milyon Euro	Hizmetin durdurulması / para cezası (genellikle yasa dışı kazancın katları)
Kapsam	Küresel ciro eşiğini aşan tüm işletmeler	Çin topraklarında hizmet sunan tüm taraflar

Uygulamada, Çin’deki finans kurumlarının AI sistemleri genellikle aynı anda üç katmanlı bir düzenlemeye tabidir — 《Üretken Yapay Zeka Yönetim Önlemleri》(temel katman) + 《Ticari Bankaların İnternet Kredisi Yönetim Önlemleri》(iş katmanı) + 等保 (çok seviyeli koruma sistemi) + algoritma kaydı (uyum katmanı). Bu, Çin’de norm odaklı çalışırken EU AI Act çerçevesini birebir kopyalayamayacağınız anlamına gelir; Çin’e özgü “veri seti uyumu + algoritma kaydı + düzenleyici raporlama” üç hattının tamamını CLAUDE.md dosyanıza yazmanız gerekir.

Yurt dışına açılan şirketler için: EU AI Act’in “risk yönetimi + veri yönetimi + belge şeffaflığı + insan gözetimi” dörtlü paketi, Çin’in düzenleyici çerçevesinin de giderek hizalandığı yöndür — 2025’te Çin Siber Uzay İdaresi’nin (CAC) birkaç üretken AI kayıt geri bildirimi, AB’nin ayrıntı düzeyini açıkça örnek almıştır. Bugün EU AI Act uyumlu normlar yazarsanız, önümüzdeki 3 yıl içinde büyük olasılıkla Çin’in sıkılaşma trendiyle de uyumlu olacaktır (CAC kayıt duyuruları 2025-2026; eu-ai-act uyumluluğu 2026.6).

7. Karar Vericiler İçin Çıkarımlar

Çıkarım 1: Bir CLAUDE.md/AGENTS.md proje standardı yazmak, AI çağında ROI’si en yüksek mühendislik hamlesidir.

Yatırımı: 3-8 hafta düzenleme süresi + 1-2 hafta dokümantasyon süresi. Getirisi: hata riski üst sınırı yaklaşık 1,7 kat, güvenlik açıklarında 2,74 kat azalma, yeniden işleme oranında %40+ düşüş. Finans sektöründe, tek bir uyumluluk denetimi yeniden işlemesinden (2-4 hafta) kaçınmanız bile bu maliyeti karşılamaya yeter. EY’nin 150.000 çalışanına Copilot’u yaygınlaştırması 250 milyon dolar tasarruf sağladı; ancak bunun ön koşulu önce standartların oturmuş olmasıydı.

İkinci Ders: Standart odaklılık bir organizasyon yeteneğidir, araç seçimi değil.

GitHub Spec Kit mi yoksa Claude Code mu seçtiğiniz önemli değil. Önemli olan, “kuruluşumuzun AI ile nasıl iş birliği yapacağını” tanımlayıp tanımlamadığınız. Bu tanım yoksa, en iyi araç bile ekibinizin daha hızlı şekilde daha fazla teknik borç üretmesinden başka bir işe yaramaz.

Üçüncü Ders: Standartları organizasyonel süreçlere yazın, bireylere bağımlı kalmayın.

Standartlar yalnızca kıdemli bir mühendisin kafasında yaşıyorsa, personel değişiminde kaybolup gider. Bunları mutlaka repo dokümantasyonuna, CI kapılarına (gate), ekip paylaşımlı yapılandırmalarına ve ajan yönetim platformlarına işlemek gerekir. Standartları organizasyonel bir varlık hâline getirin; kişisel bir beceri olarak bırakmayın. Atos’un 19.000 ajanı 54 ülkede sorunsuz çalışabiliyor çünkü yönetişim “birinin bilmesi” değil, “sistemin zorunlu kılması”dır.

Dördüncü Ders: Kapılar (gate) hızdan daha önemlidir.

GitHub Spec Kit’in beş aşamalı kapı kontrolü, Superpowers’ın “testler başarısız olmadan kod yazma” kuralı, Kiro’nun “spec yazmadan başlatılamaz” yaklaşımı — hepsi de AI ile nihai çıktı arasına bir “fren” koyuyor. AI’ın yetenekleri arttıkça, yönetişim daha da önce devreye girmeli. New Relic 2026 raporundaki %78’lik arıza oranı, %62’lik ekibin “incelemeden gönderim” yapmasının bedeli. Finans sektöründeki CIO’lar bunu en iyi bilir: sizin değişiklik onay kurullarınız (Change Advisory Board), algoritma kayıt süreçleriniz, güvenlik denetimleriniz — hepsi üretime geçmeden önce birer kapı kontrolüdür. AI kodunun da benzer kapı kontrollerine ihtiyacı var, üstelik çok daha erken aşamada.

Tersine öz denetim (cevaplarken süslemeyin): AI’ın ürettiği kodların uyumluluk incelemeleri sık sık geri mi dönüyor? AI kodunun yol açtığı son sorun neydi? Teknik sorumluya “AI ile nasıl iş birliği yapıyoruz?” diye sorduğunuzda size bir doküman gösterebiliyor mu? Üç sorudan birine bile cevap veremiyorsanız, kural odaklı yaklaşım henüz oturmamış demektir — önce kuralları yazın, sonra araçları satın alın.

Karar vericiler için üç koçluk sorusu

Son olarak üç soru bırakıyorum — bunlar bir kontrol listesi değil, ekibinizle doğrudan kullanabileceğiniz tartışma başlıkları:

“Yarın tüm AI araçları kullanımdan kalksa, ekibinizin kod kalitesi ne kadar düşer?” — Bu soru, standart odaklı yaklaşımın gerçek değerini ortaya çıkarır: Cevap “ciddi şekilde düşer” ise, standartlarınız henüz oturmuş demektir; cevap “neredeyse hiç değişmez” ise, standart odaklı süreç zaten çalışıyor demektir.
“Uyum departmanınız, standart odaklı projenizde bir ‘bekçi’ mi yoksa bir ‘kolaylaştırıcı’ mı?” — Cevap “bekçi” ise, uygulama hızınız inceleme darboğazlarına takılır; cevap “kolaylaştırıcı” ise, Bölüm 5.2’deki yolu doğru izliyorsunuz demektir.
“12-18 ay sonra ekip büyüklüğünüz nasıl değişecek?” — Microsoft WTI 2026’nın cevabı şu: liderlerin %82’si AI ajanlarıyla iş gücünü “ölçeklendirecek”. Sizin cevabınız “değişmeyecek” ise, ya işiniz büyümüyor ya da organizasyon tasarımınız standart odaklı yaklaşımın getirdiği avantajı yakalayamıyor.

Bu üç sorunun standart bir cevabı yok. Ama cevaplarınızın yönü, cevapların kendisinden daha önemli.

Sıradaki Adım

Bu, “AI Çağında Yazılım Mühendisliği Dönüşümü” serisinin altıncı yazısı. Conway Yasası’ndan (organizasyon mimariyi belirler) Team Topologies’e (organizasyon nasıl tasarlanır), oradan darboğaz kaymasına (darboğaz kodlamada değil doğrulamada) ve bugün standart odaklı yaklaşıma (dokümantasyonla AI davranışını sınırlandırma) kadar geldik.

下一篇（第七篇）’de, tüm bunları ayakta tutan temel altyapıya bakıyoruz: MCP protokolü (Model Context Protocol). Anthropic’in açık kaynaklı bu protokolüne neden “AI’nın USB-C’si” deniyor, OpenAI, Google ve Microsoft’un tamamı neden bu protokole katıldı ve bu protokol çok araçlı, çok ajanlı birlikte çalışabilirliği nasıl mümkün kılıyor, bunları ele alıyoruz.

Bu yaklaşımı şirketinize uyarlamak mı istiyorsunuz?Kurumsal bağlamda kural odaklılığa geçişte genellikle birkaç somut sorunun çözülmesi gerekir: temel kurallar CLAUDE.md / AGENTS.md dosyalarında nasıl birikmeli, mevcut kod tabanına standartların geriye dönük olarak nasıl entegre edileceği, uyumluluk çalışmalarının nasıl yürütüleceği ve pilot uygulamanın başarısının hangi ölçütlerle değerlendirileceği gibi sorunlar öne çıkar. Şu anda üç tür iş birliği sunuyoruz:

Kurumsal eğitim: Şirketinizin gerçek projeleri üzerinden standart dokümantasyonunun hazırlanması, CI geçitlerinin tasarlanması, uyumluluk entegrasyonunun yol haritası ve yönetişim mekanizmalarının kurulmasına kadar uçtan uca destek verilir.
Özel danışmanlık hizmeti: Tek bir net karara odaklanırız; örneğin şirketinizin CLAUDE.md / AGENTS.md dosyalarını öncelikli olarak mı yazması gerektiği ya da mevcut kod tabanındaki uyumluluk iyileştirmelerinin önceliklendirilmesi gibi konuları ele alırız.
Yönetim kurulu sunumları ve sektör konuşmaları: AI kodlama araçları, kural odaklılık yaklaşımı, kurumsal yönetişim ve Frontier Firms üzerine içerikler sunarız.

Makale genel bir çerçeve sunabiliyor. Ancak somut uygulama, kurumun uyum gereklilikleri, düzenleyici sınırlar, mühendislik olgunluğu ve mevcut teslimat süreçleriyle yeniden tasarlanmayı gerektiriyor. İş birliği için coach@iaiuse.com adresinden iletişime geçebilirsiniz.

İleri okuma: Yavaşça Yapay Zekâ Öğren 187: “Yöntem Bilgisi v1.0” — kurumsal yapay zekâ dönüşümü için 7 adımlı çerçeveyi sistematik olarak tanıtır.

Bu Seri Hakkında

“Yapay Zekâ Çağında Yazılım Mühendisliği Dönüşümü”, telekom, finans, üretim ve e-ticaret sektörlerindeki CIO, CDO, CTO ve dijitalleşme liderlerine yönelik 18 bölümlük bir araştırma serisidir. Seri; yapay zekâ programlama araçlarının, standart odaklı yaklaşımların ve kurumsal yönetişimin yazılım teslimat süreçlerini, organizasyon yapılarını ve mühendislik olgunluğunu nasıl etkilediğine odaklanır.

Seri; akademik makaleleri, satıcı dokümanlarını ve sektör raporlarını sürekli takip eder. Araştırma veri tabanı 200’ün üzerinde kaynak içerir ve kritik değerlendirmelerde kanıt düzeyi belirtilerek doğrulanmış olgular, satıcı iddiaları, sektör gözlemleri ve yazar çıkarımları mümkün olduğunca ayrıştırılmaya çalışılır.

Yaklaşık 8 yıllık büyük ölçekli kurumsal danışmanlık ve iş analizi deneyimine sahibim; IBM’de görev aldım ve telekom, finans, sigorta ile üretim sektörlerindeki projelerde yer aldım. Sonrasında operatör ürünleri, internet ürünleri ve yapay zekâ uygulama geliştirme sahasında; gereksinim analizi, ürün tasarımı ve ekipler arası uygulama konularında çalışmaya devam ettim.

Bu serideki norm temelli, organizasyonel yönetişim ve mühendislikle ilgili değerlendirmeler; bu pratiklerden, kamuya açık araştırmalardan ve sektör vakalarından çapraz doğrulama yapılarak elde edilmiştir. Belirli projelere ilişkin içeriklerin tamamı anonimleştirilmiştir; bazı sektör senaryoları tipik problem senaryolarının türetilmesidir ve ilgili dayanaklar yazı sonundaki referans kaynaklarında belirtilmiştir.

Bu hesabın arkasında aslında küçük bir ekip var — ben ve 1-2 uzun süredir birlikte çalıştığımız arkadaşım. AI kodlama araçları araştırması, organizasyonel yönetişim vaka analizi ve koçluk diyalogları olmak üzere farklı alanlara ayrılıyoruz. Yazıda bahsettiğimiz “müşterilerle birlikte yürüdüğümüz” projelerin çoğu, birlikte teslim ettiğimiz işlerdir. Müşterilerin uyum sınırları ve kişi isimleri hâlâ açıklanmamaktadır; anonimlik, gelecekte birlikte çalışacağımız meslektaşlara da alan bırakmak için korunmaktadır.

Referans Kaynakları (tamamı doğrulanmıştır, her biri kanıt düzeyine göre işaretlenmiştir)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI tarafından üretilen kodlarda insan yazımına kıyasla 1,7 kat daha fazla sorun tespit edildi (PR başına 10,83’e karşı 6,45). Mantık/doğruluk hataları 1,75 kat, kod kalitesi sorunları 1,64 kat, güvenlik açıkları 1,57 kat, şifre işleme hataları 1,88 kat, XSS açıkları ise 2,74 kat daha fazla. Kanıt düzeyi: Birincil. Kaynak: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). CodeRabbit raporunun tamamını haberleştirdi: 470 açık kaynak PR analiz edildi; AI destekli PR’larda ortalama 10,83 sorun bulunurken, tamamen insan yazımı PR’larda bu sayı 6,45 olarak ölçüldü. Kanıt düzeyi: İkincil. Kaynak: Yukarıdaki URL ile aynı.
CodeRabbit / David Loker (2026.1). “2026 Tahminleri: Hız Tuzağı” — 2026 yılı, “kod üretim hızı”ndan ziyade “kod kalitesi ve yönetişim”e geçişin dönüm yılı olacak. Kanıt düzeyi: İkincil kaynaklar. Kaynak: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. Ekiplerin %78’i AI kodlarının üretime alınmasının ardından daha fazla aksaklık yaşadığını bildiriyor; teknik liderlerin %62’si ekiplerinin AI kodunu gözden geçirmeden gönderme konusunda rahat olduğunu kabul ediyor; %96’sı gözlemlenebilirliği bir zorunluluk olarak görüyor. Kanıt düzeyi: Birincil kaynaklar (satıcı raporu). Kaynak: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Yıllık Raporu (2026.5.5). 20.000 AI çalışanıyla yapılan anket, 10 ülkeyi kapsıyor; liderlerin %82’si 12-18 ay içinde AI ajanlarıyla iş gücünü genişletmeyi planlıyor; %81’i AI ajanlarının orta veya yüksek düzeyde entegre olacağını öngörüyor; %24’ü kurumsal düzeyde dağıtım yapmış durumda; Copilot görüşmelerinin %49’u bilişsel çalışmayı destekliyor; AI kullanıcılarının %58’i “bir yıl önce yapamayacakları işleri” yapabildiklerini belirtiyor ve bu oran Frontier Professionals grubunda %80’e çıkıyor. Kanıt düzeyi: Birinci seviye. Kaynak: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26 Retrospektifi: AI Deneylerinden Sınır Teknolojisine (2026.7.28). EY, Microsoft 365 Copilot’u 150.000 çalışanına yaygınlaştırdı; 2,5 milyon saat ve yaklaşık 250 milyon dolar tasarruf sağladı. Uygulama 400.000 küresel çalışana genişletildi; %95 hız artışı, %37 finans operasyon maliyeti düşüşü ve manuel iş akışlarında %90’a varan azalma elde edildi. Atos, Copilot’u 56 ülkede 56.000 çalışana ve 19.000 AI ajanına yaydı; kimlik, güvenlik, uyumluluk ve yönetişim için birleşik bir kontrol düzlemi oluşturdu. Kanıt düzeyi: Birinci seviye (Microsoft resmi retrospektifi). Kaynak: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Grubu ve Microsoft Stratejik İş Birliği (2026.6.9). Atos, Microsoft 365 E7 (Frontier Suite) çözümünü 56 ülkede 56.000 çalışanına ve 19.000 AI ajanına dağıtıyor; Entra/Defender/Intune/Purview/Agent 365 kontrol düzlemini tek çatıda birleştiriyor. Kanıt düzeyi: Birinci derece (iki tarafın ortak basın bülteni). Kaynak: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group- workforce-and-clients
GitHub Spec Kit (2025.9’da açık kaynak, 2026 H1’de gelişim). 5 aşamalı kapı /speckit.constitution → /specify → /plan → /tasks → /implement, artı /clarify /analyze; modelden bağımsız (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code — hepsiyle çalışır). Kanıt düzeyi: Birincil. Kaynak: https://github.com/github/spec-kit
AWS Kiro (2025.7’de yayınlandı, 2026 H1’de gelişim). Üç aşamalı iş akışı: gereksinim → tasarım → görev; spec, ön tanımlı aracı eylemlerini tetikler; spec yazmadan başlatılamaz. Kanıt düzeyi: Birincil. Kaynak: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex’in Haziran 2026 itibarıyla haftalık aktif kullanıcı sayısı 5 milyonu aştı; kullanıcıların %20’si geliştirici değil. AGENTS.md + Skills, birleştirilebilir komut setleri sunuyor. Kanıt düzeyi: Birincil (OpenAI resmi duyurusu). Kaynak: https://developers.openai.com/codex/skills
Claude Code (Anthropic, 2026 H1). CLAUDE.md + .claude/rules/ + Skills sistemi; Şubat 2026’da Anthropic resmi pazarına girdi; Skills deposu GitHub’da 112 bin yıldız aldı; Şubat 2026’daki G serisi turunda yıllık 2,5 milyar dolar gelir açıklandı. Kanıt düzeyi: Birincil. Kaynak: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Anketi (2026.1). 10.000’den fazla profesyonel geliştiriciyle yürütülen, 8 dile yerelleştirilmiş küresel bir araştırma; Claude Code CSAT skoru %91 / NPS 54 (sektörün en yükseği); Claude Code’un işyeri benimseme oranı %18 (9 ayda %3’ten 6 kat artış), Kuzey Amerika’da %24; Copilot işyeri benimseme oranı %29 ancak büyüme durmuş durumda; Cursor %18. Kanıt düzeyi: Birinci seviye. Kaynak: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Bülteni (2026.2). 15.000 geliştiriciyle yapılan anket; %46’sı Claude Code’u “en sevilen” araç olarak seçti, Cursor %19, Copilot %9. Kanıt düzeyi: Birinci seviye. Kaynak: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). Ağustos 2025’te Alibaba tarafından yayınlandı; 15 Mayıs 2026’da Qoder 1.0, Autonomous Agent Development Workbench’e yükseltildi; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 Mayıs 2026’da Cloud Agents (yönetilen ajan çalışma zamanı); 21 Temmuz 2026’da Qoder Security; Mayıs 2026 itibarıyla dünya genelinde 5 milyon+ kullanıcı; DingTalk CLI entegrasyonu; 20 Mayıs 2026’da Tongyi Lima, Qoder CN olarak yeniden adlandırıldı. Kanıt düzeyi: Birincil. Kaynak: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (2026 H1). Spec Kit beş aşamalı komutları, SDD araç karşılaştırma incelemeleri, EARS notasyon yöntemi. Kanıt düzeyi: İkinci seviye (üçüncü taraf incelemeleri). Kaynak: https://vibecoding.app/blog/spec-kit-review；https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (tam uygulama 2 Ağustos 2026). Yüksek riskli yapay zekâ sistemleri için uyumluluk son tarihi 2 Ağustos 2026; mevcut GPAI modelleri için 2 Ağustos 2027’ye ertelendi; azami ceza 35 milyon avro veya küresel cironun %7’si; Madde 9-15 risk yönetimi, veri yönetimi, dokümantasyon şeffaflığı, insan gözetimi, doğruluk ve sağlamlık. Kanıt düzeyi: Birincil (mevzuat + ikincil uyumluluk analizi). Kaynak: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). Sorunların %44’ünün kök nedeni eksik bağlam. Kanıt düzeyi: İkincil (satıcı raporu). Kaynak: https://www.qodo.ai/reports/state-of-ai-code-quality/