Giriş: AI Araçlarını Zaten Kullanıyordum

Yazıya Claude Code'un ne olduğunu ya da nasıl kurulduğunu anlatarak başlamayacağım. Bunu okuyorsanız büyük ihtimalle zaten bir AI aracı kullanıyorsunuz: Cursor, Copilot, Windsurf ya da bir tarayıcı sekmesinde ChatGPT. Nerede işe yaradıklarına, nerede ayağınıza dolandıklarına dair kendi fikriniz de oluşmuştur.

Ben de aynı yoldan geçtim. Yıllardır yazılım geliştiriyorum ve son dönemde AI araçlarına epey yaslandım. Önce Cursor'u kullandım; IDE içinde AI ile çalışmanın ne kadar rahat olabileceğini onunla gördüm. Sonra proje büyüdü ve cevaplar kötüleşti. IDE araçları asistan olarak tasarlanmış: siz yazarsınız, o tamamlar. Belli bir boyuta kadar bu gayet iyi gidiyor.

Claude Code ilk haftadan farklı geldi. Terminalde çalışıyor, dosyalarınızı okuyor, komut çalıştırıyor, git işlerini hallediyor, gerekirse paralel çalışsın diye başka Claude instance'ları başlatıyor. Bir asistandan çok bir geliştirme ortamı gibi davranıyor ve ondan ne alacağınız büyük ölçüde onu nasıl kurduğunuza bağlı.

Aylardır birkaç projede, farklı teknoloji yığınlarında üretimde kullanıyorum: .NET backend'ler, React Native uygulamalar, Go servisleri, Next.js frontend'ler. Bu yazı o süreçte öğrendiklerimi, yanlış yaptıklarım dahil, bir araya getiriyor.

Yazıyı basılacak düğmelerin listesi gibi değil, işe nasıl yaklaştığımın anlatımı olarak okuyun. Komutlar değişecek; arkalarındaki mantık ise çok daha uzun ömürlü çıktı.

Bölüm 1: Bir Zihniyet Değişimine İhtiyacınız Var

Junior Developer Gibi Değil, CTO Gibi Düşünün

En sık gördüğüm hata, AI'ı sizin yerinize kod yazan bir şey olarak görmek. "Şu fonksiyonu yaz", "şu bug'ı düzelt", "şu endpoint'i ekle" gayet makul istekler, ama bir projenin küçük bir kısmını kapsıyorlar.

Bir CTO projeye baştan sona bakar ve burada işe yarayan da bu bakış:

• Planlama: Ne inşa ediyoruz ve neden?
• Mimari: Nasıl yapılandıracağız?
• Geliştirme: Nasıl implement edeceğiz?
• Test: Doğru çalıştığını nasıl doğrulayacağız?
• Güvenlik: Güvenlik açıklarını nasıl tespit edeceğiz?
• Performans: Yeterince hızlı mı?
• Dağıtım: Nasıl yayına alacağız?

Claude Code bu aşamaların her birinde yardımcı olabilir; yazının büyük kısmı da bunun nasıl yapılacağını anlatıyor.

Listede eksik olana bakın: kodu yazmak. Bu çalışma biçiminde işinize yarayacak beceri, yazılımın nasıl davrandığını bilmek. Sistemlerin nerede kırıldığını ve bir testin gerçekte neyi kanıtladığını biliyorsanız, modelin yazdığı her satırı okumadan onu yönlendirebilirsiniz. En güçlü yanınız syntax ise, modelle onun en ucuza yaptığı işte yarışıyorsunuz.

Olasılıksal Düşünmeyi Öğrenin

AI deterministik değil. Aynı prompt iki çalıştırmada farklı sonuç verebilir. Bu modeller böyle çalışıyor, planınızı da buna göre yapın:

• Birkaç tur süreceğini baştan kabul edin. İlk çıktıyı inceleyin, neyin yanlış olduğunu söyleyin, tekrar çalıştırın.
• Doğrulama yolları kurun. Claude'un "bitti" demesi size pek bir şey söylemez. Build'in çalıştığını, testlerin geçtiğini, güvenlik taramalarının temiz döndüğünü kontrol edin.
• Deterministik katmanlar ekleyin. Hook'lar, linter'lar ve test suite'leri olasılıksal bir modelin üstüne kesinlik ekler.

Sonraki bölümlerin çoğu bunun üzerine kurulu.

Düşünce Hızında Çalışmayı Öğrenin

Model hızlandıkça döngünün yavaş kısmı siz oluyorsunuz. Bir bug görüyorsunuz, terminale geçiyorsunuz, anlatıyorsunuz, ekran görüntüsü alıp yapıştırıyorsunuz, geri dönüyorsunuz. Her geçiş biraz odak götürüyor ve sonunda ne diyecektiniz, yarısını unutmuş oluyorsunuz.

Bu yüzden aklıma geleni o anda modele iletebileceğim bir düzen kurdum. Konuşmayı metne çeviren araç bir kısayol tuşunda duruyor, çünkü konuşmak yazmaktan hızlı ve prompt'un dilbilgisi düzgün olmak zorunda değil. Bir pano yöneticisi son kopyaladığım her şeyi tutuyor. Görsel bug'ların ekran görüntüsü doğrudan konuşmaya gidiyor. Sonuçta yanınızda biriyle çalışıyormuş gibi oluyor: "bak, şurası bozuk, onu da düzelt, ha bir de şu var."

Bölüm 2: CLAUDE.md: Her Oturumun İlk Okuduğu Dosya

Nedir?

CLAUDE.md, Claude Code'un her konuşmanın başında okuduğu talimat dosyası. Claude önceki oturumlardan hiçbir şey hatırlamaz; her seferinde sıfırdan başladığında projenizi bu dosya sayesinde "tanır".

Claude Code'la günlük deneyiminizi hiçbir ayar bu dosya kadar belirlemiyor. İyi bir CLAUDE.md eksik mühendislik becerisini kapatmaz, ama kötüsü deneyimli bir geliştiriciyi bile canından bezdirir.

Az Çoktur: 100 Satır Kuralı

İlk CLAUDE.md'm 160 satırı geçiyordu. Her kuralı, her komutu ayrıntısıyla yazmıştım ve Claude önemli olanları kaçırmaya başladı. Dosya uzadıkça dikkati de dağılıyordu.

Artık CLAUDE.md'yi 100 satırın altında tutuyorum, ayrıntıları ayrı dosyalara taşıyorum. Claude ihtiyaç duyduğunda onları açıyor:

CLAUDE.md (70-100 lines)              - Always read
.claude/rules/architecture.md         - Referenced when needed
.claude/rules/security.md             - Referenced when needed
docs/claude/patterns.md               - Referenced when needed

Buna genelde "progressive disclosure" deniyor: model bilgiyi, ihtiyaç duydukça görüyor.

WHAT / WHY / HOW Yapısı

CLAUDE.md'yi üç parçaya ayırıyorum.

WHAT: Proje ne? Teknoloji yığını, mimari, temel kavramlar. Bir paragraf yeterli.

WHY: Bu kararları neden aldık? Çoğu kişinin atladığı, ama sınır durumlarında en çok işe yarayan kısım bu. "PaymentClient wrapper'ını kullan" yerine "PaymentClient wrapper'ını kullan, çünkü idempotency key ekliyor ve çıplak bir HTTP retry müşteriden iki kez para çekebilir" yazın. Claude o zaman kuralın, kimsenin bahsetmediği yeni iade endpoint'ini de kapsadığını anlar.

HOW: Nasıl çalışıyoruz? Komutlar, test pattern'leri, adlandırma kuralları. Burada örnek gösterin; iyi bir kod parçası bir convention'ı üç paragraf açıklamadan daha iyi anlatır.

"Yapma" Bölümü ve Kuralların Asıl Yeri

Claude'un bilinen eğilimleri var ve bunları yazmanın alışılmış yeri CLAUDE.md'deki "Yapma" bölümü:

• Aşırı mühendislik eğilimi (ekstra soyutlamalar, gereksiz interface'ler)
• Çok fazla dosya oluşturma eğilimi (tek dosyada çözülebilecek şeyleri böler)
• İmkansız senaryolar için hata yönetimi ekleme eğilimi
• Docstring ve yorum ekleme eğilimi (istenmediğinde bile)
• Stub dosya oluşturma eğilimi (dosya var ama return null, return {}, TODO, console.log yer tutucularıyla dolu; dosyanın var olması gerçek implementasyon anlamına gelmez)

Bunları yazın, ama listeyi kısa tutun ve her maddenin gerçekte nereye ait olduğunu düşünün. Güncel modeller talimatlara sıkı, neredeyse harfiyen uyuyor; yazdığınız her "asla" ve "her zaman" aklınızda olmayan yerler dahil her yerde uygulanıyor. Modele bir sayfa yasak verin, çekingen bir modelle karşılaşırsınız. Lafı dolandırır, ufak şeyler için izin ister ve tam fikir beklediğiniz işte riske girmez. Tasarımda, isimlendirmede, metin yazarken ya da yeni bir yaklaşım denerken uzun bir kural listesi çıktıyı çoğunlukla sadece sıkıcılaştırır.

O yüzden listeyi ayıklayın. Bir kural mekanik olarak kontrol edilebiliyorsa (stub dosyalar, unutulmuş console.log'lar, yasaklı bir import), onu prompt'tan çıkarıp bir hook'a ya da linter'a koyun (Bölüm 6); orada her seferinde çalışır ve context harcamaz. Zevk meselesiyse hedefi bir kez söyleyin, modele alan bırakın. Prompt'ta kural tutmanın anlamlı olduğu yer, hatanın pahalıya patladığı birkaç alan: migration'lar, para, güvenlik. Orada bile CLAUDE.md'deki satır sadece hatırlatma; asıl işi hook yapıyor.

3 Katmanlı Sınır Belirleme

Claude'a neyi kendi başına yapabileceğini, ne zaman sorması gerektiğini ve neyi asla yapmaması gerektiğini açıkça söyleyin:

• Her zaman yap: Test yaz, testleri çalıştır, adlandırma kurallarına uy
• Önce sor: Veritabanı migration'ları, yeni dependency ekleme, büyük refactoring
• Asla yapma: Secret'ları commit'leme, lock dosyalarını düzenleme, testleri silme

Bu üç katmanla Claude nerede rahat hareket edebileceğini, nerede durup size danışması gerektiğini bilir. "Asla" listesi aynı zamanda iyi bir ilk hook aday listesi; içindekilerin neredeyse hepsi doğrudan engellenebilir (Bölüm 6).

Global CLAUDE.md

~/.claude/CLAUDE.md bütün projeler için geçerli talimatları tutar. Benimkinde iletişim tercihlerim (özetler Türkçe, teknik terimler İngilizce), sık kullandığım CLI araçları ve birkaç genel çalışma ilkesi var; böylece bunları her projede tekrar yazmıyorum.

Yola Özel Kurallar: Doğru Kural, Doğru Dosya

Diyelim ki bütün test dosyalarınız için aynı kuralları istiyorsunuz ve bu dosyalar 50 farklı dizine dağılmış. Her dizine bir CLAUDE.md koymak saçma olur.

Bunun yerine .claude/rules/ altında dosya pattern'ine göre kural tanımlayın:

---
paths: ["**/*.test.tsx"]
---
Use AAA (Arrange-Act-Assert) pattern in test files.
Prefer real database connections over mocks.

**/*.test.tsx, kod tabanındaki bütün test dosyalarını, nerede olurlarsa olsunlar yakalar. API endpoint'leri için **/*.api.ts, Terraform dosyaları için terraform/**/* de aynı şekilde çalışır, her birinin kendi kuralı olur.

Bu kurallar context'ten de tasarruf sağlar, çünkü yalnızca Claude eşleşen bir dosyayı düzenlerken yüklenirler.

Bölüm 3: Context Window: İlk Anlaşılması Gereken Kavram

Nedir ve Neden Önemlidir

Context window, Claude'un çalışma belleği. Her mesaj, okuduğu her dosya, her komut çıktısı aynı ortak bütçeye yazılır. Claude Code'daki güncel Claude modellerinde bu bütçe varsayılan olarak bir milyon token. Epey geniş bir alan. Ama pencere büyüdü diye modelin bozulma biçimi değişmiyor; bozulmanın yayılacağı alan büyüyor, o kadar.

Çoğu geliştirici, context %100'e gelene kadar her şeyin sorunsuz gideceğini varsayar.

Oturum uzadıkça kalite gerçekten düşüyor, ama yeni modeller benim başladığım modellerden çok daha uzun dayanıyor. Belirtileri tanırsınız: Claude önceki talimatları unutur, yaptığı hataları tekrarlar, yanlış dosyaları düzenler. İlk kuralımı pencere 200k iken koymuştum: %40 civarında harekete geç, %60'ı asla bekleme. Bir milyon token'lık pencerede yüzde yanlış ölçü, çünkü %40 zaten 400k token'lık geçmiş demek ve güncel modeller çoğu zaman bunun epey ötesinde de stabil kalıyor. Modeli asıl bozan şey geçmişin ham büyüklüğü ve içinde ne kadar bayat ya da konu dışı içerik biriktiği. Artık ona bakıyorum. Biten alt görevler ve eski debug çıktıları context'in büyük kısmını kaplamaya başladıysa, çubuk ne gösterirse göstersin harekete geçiyorum.

Context doldukça bir de bozuluyor. Buna "context rot" deniyor.

Eski tool çıktıları, çoktan düzeltilmiş bug'lardan kalan debug izleri, sonradan refactor ettiğiniz dosyaların eski halleri; hepsi context'te kalır ve model güncel olanla eskiyi ayırt edemez. Yani bayat bilgi yer kaplamakla kalmaz. Model onu güncel sanıp üzerine karar kurar: adı değişmiş değişkenlere referans verir, değişmiş pattern'leri izler.

Pek çok multi-agent kurulumunun birkaç görevden sonra dağılmasının sebebi bu. Model kötüleşmedi. Kötüleşen onun context'i.

Haksızlık etmeyelim, bu tablo sürekli iyileşiyor. Her model sürümü uzun oturumlarda daha iyi dayanıyor, Claude Code da neyi compact edeceği, neyi özetleyeceği ve hafızaya neyi yazacağı konusunda giderek akıllanıyor. Bugünün terminal agent'ları bir yıl önce raydan çıkacakları durumlarda, bazen pencere neredeyse doluyken bile tutarlı kalabiliyor. O yüzden bu bölümdeki önerileri bir kanun listesi gibi değil, bir çalışma biçimi olarak okuyun. Oturumları gözle görülür şekilde iyileştiriyorlar, ama hiçbiri kesin bir sınır değil.

Bir Konuşma = Bir Görev

Pencere ne kadar büyük olursa olsun geçerli bir alışkanlık var: bir konuşma, bir görev. Auth sistemi, veritabanı şeması, UI bileşenleri, testler; hepsini tek konuşmada yapmaya çalışmayın. Her birine ayrı oturum açın.

"Her şeyi az önce anlattım, yeni oturumda baştan mı anlatacağım?" diyebilirsiniz. Gerek yok. CLAUDE.md projenizi biliyor, oturum hafızası da mevcut durumu tutuyor (nasıl olduğu bir sonraki alt bölümde). Yeni oturum sıfırdan başlamıyor.

Oturumlar Arası Hafıza

Claude stateless'tır; her konuşma sıfırdan başlar. Claude Code bunun bir kısmını artık kendisi karşılıyor. Auto memory ile Claude, düzeltmelerinizden ve tercihlerinizden çıkardığı notları repository'ye özel bir hafıza klasörüne yazıyor ve her oturumun başında bu klasörün dizini yükleniyor. Daha yapılandırılmış proje bilgisi için OMC (oh-my-claudecode) plugin'inin project-memory özelliğini de kullanıyorum. Bu, teknoloji yığınını, mimari kararları, convention'ları, notları ve direktifleri JSON olarak tutan projeye özel bir depo; her oturum onu otomatik okuyor.

Araçtan çok alışkanlık önemli: oturum biterken önemli olanı kaydedin, sonraki oturum başlarken okuyun.

Bu alışkanlığın kısa sürede karşılığını veren bir biçimi var. Bir oturum gerçekten uğraştıran bir şeyi çözdüğünde (bir build tuhaflığı, bir dependency çakışması, sonunda çalışan bir config), pencereyi kapatmadan önce modele çözümü yazdırın. Yoksa çözüm context'le birlikte kaybolur ve ileride bir oturum aynı bedeli baştan öder.

Pratik Context Yönetimi

Bir HUD (Heads-Up Display) Kullanın: Claude Code'un durum satırı script'lenebilir (/statusline), ben de içinde OMC plugin'inin HUD'unu çalıştırıyorum. Şunları gösterir:

• Aktif model
• Oturum süresi
• Harcanan token sayısı
• Mevcut maliyet ve saatlik maliyet oranı
• Cache hit oranı
• İzin modu; Shift+Tab ile modlar arasında dolaşılır

Context doluluk çubuğu: arada bir bakın, ama bir milyon token'lık pencerede yavaş yükselir ve tek başına pek bir şey söylemez. Yukarıdaki soruyla birlikte okuyun: içindekilerin ne kadarı hâlâ işe yarıyor?

/compact zamanlaması: Context biten işlerle dolmaya başlar başlamaz, kalite düşmeden çalıştırın.

/clear ile temiz başlangıç: Görev bittiğinde ya da konu değiştiğinde yeni oturum açın.

Bilgi sıralaması önemlidir: Modeller uzun girdilerin başını ve sonunu iyi işler, ortaya gömülü olanı kaçırabilir. Uzun bir analiz ya da hata logu gönderiyorsanız önemli kısmı başa koyun. "Bu fonksiyonda null pointer var, ilgili log aşağıda" diye açmak, ipucunu 500 satırlık bir logun ortasında bırakmaktan çok daha iyi sonuç verir.

Kırmızı bayraklar: bölümün başındaki belirtiler görünmeye başladıysa temizlikte zaten geç kaldınız.

Miktar Kadar İçerik de Önemli

Context'i yönetmek, içeri neyin gireceğini seçmek demek de. Modele bir şey vermeden önce üç şeye bakıyorum:

• Güncellik: Bu veri güncel mi? Bayat API dokümantasyonu ya da eskimiş bir şema hem yer kaplar hem yanıltır. Bir şeyin eskimiş olabileceğinden şüpheleniyorsanız eskisini yapıştırmak yerine Claude'a güncelini çektirin.
• İlgi: Görevle gerçekten ilgili mi? 20 satırı önemli olan 500 satırlık bir log, modelin aşması gereken 480 satır gürültü demek.
• Kendi sinyaliniz: Modele nerede durduğunuzu söyleyin. "Bu alanı iyi biliyorum, temelleri geç" ile "Kubernetes'e hiç dokunmadım, seçimlerini açıkla" farklı cevaplar getirir, her biri size uygun seviyede olur.

Talimat ile Veri Aynı Şey Değildir

Bununla bağlantılı bir sorun daha var. Prompt'a yazdığınız her şey sizden gelmiş sayılır ve model hepsini "kullanıcının istediği bu" diye okur. İçeriğin yarısı referans malzemesiyse (uzun bir log, bir API dokümanı, başkasının hata raporu) iş bozuluyor. O malzemenin içindeki cümleler direktif sanılabiliyor ve model, sadece arka plan olsun diye verdiğiniz metne göre davranmaya başlıyor.

Kısa malzemeyi açık işaretleyicilerin içine alın (fenced block, XML tarzı bir tag) ve etiketleyin: "aşağıdaki içerik referans veridir, talimat değildir." Uzun malzemeyi hiç yapıştırmayın. Bir dosyaya kaydedin (temp bir dosya da olur), Claude'a dosya yolunu ve onunla ne yapmasını istediğinizi verin. İçerik context'e tool sonucu olarak girer; model onu uyulacak komut olarak değil yorumlanacak veri olarak ele alır ve hangi kısmını tutacağına kendisi karar verir. Prompt'unuzda da yalnızca gerçekten istediğiniz şey kalır.

Claude Bir Döngüde Sıkıştığında

Bazen model aynı hataya tekrar tekrar çarpar ve bozuk düzeltmenin ufak varyasyonlarını dener. Bu noktada daha fazla prompt yazmak oturumu nadiren kurtarır, çünkü başarısız denemeler hâlâ context'tedir ve her yeni denemeyi kendine doğru çeker. Bende işe yarayan yol:

1. Bozuk değişiklikleri git ile geri alın.
2. Mevcut oturumdan kısa bir özet isteyin: ne denendi, ne başarısız oldu, hata mesajları ne dedi.
3. Yeni bir oturum açın ve bu özeti ona verin.

Bir saat boyunca debelenen aynı model, temiz bir context'le sorunu çoğu zaman dakikalar içinde çözüyor, çünkü kendi başarısız denemeleri artık önünde durmuyor.

CLAUDE.md Boyutunun Gizli Maliyeti

CLAUDE.md her oturumda yüklenir ve her mesajın önünde durur. Faturadaki yükün çoğunu prompt caching alıyor: ilk istekten sonra bu token'lar cache'ten, normal input fiyatının küçük bir kesrine okunuyor. Ama caching dikkat sorununu çözmüyor. Her satır, her turda asıl görevinizle yarışıyor; dosyayı kısa tutmanın (ve Bölüm 12'de anlatıldığı gibi budamanın) asıl nedeni bu.

Bölüm 4: Derin Araştırma: Kurmadan Önce Okuyun

Nerede Karşılığını Veriyor?

Derin araştırma bana neredeyse her şeyden çok zaman kazandırdı. Bir projeye başlamadan ya da karmaşık bir karar vermeden önce yapılan tek bir deep research turu, sizi epey deneme yanılmadan kurtarıyor.

İş Akışım

Derin araştırmayı tek bir araca bağlamıyorum. Claude.ai'da, ChatGPT'de ve Gemini'de derin araştırma ya da ona yakın bir mod var ve her biri farklı işlerde iyi. Hangisini seçtiğinizden çok süreç önemli:

Adım 1: Bir konuşmayla başlayın. Konu hakkında AI ile sohbet edin ve sadece siz sormayın, onun da size soru sormasını isteyin. Mesela: "Bu konu hakkında bana sorular sor, gereksinimlerimi birlikte netleştirelim." AI'ın hangi bilgiden yoksun olduğunu bu şekilde görürsünüz.

Adım 2: AI'ın sorularını yanıtlayın. Genelde 10-15 soru gelir. Cevap verirken kendi düşünceniz de netleşir, AI'ın elinde de çalışacak bol context olur.

Adım 3: Derin araştırma prompt'unu oluşturun. Sohbetin sonunda "şimdi bu konuşmaya dayanarak bana bir derin araştırma prompt'u yaz" deyin. Konuştuğunuz her şeyi içeren, ayrıntılı ve odaklı bir prompt çıkar.

Adım 4: Derin araştırmaya gönderin. Bu prompt'u Claude.ai'ın Research modunda, ChatGPT'nin deep research'ünde ya da Gemini Deep Research'te çalıştırın ve dönen sonuçları karşılaştırın.

Adım 5: Sonuçları Claude Code'a getirin. Kod yazmaya başlamadan bulguları Claude Code oturumunuza taşıyın.

Derin Araştırmayı Ne Zaman Kullanmalısınız?

• Yeni bir teknoloji veya framework seçerken
• Karmaşık mimari kararlar (monolit vs mikroservis, event-driven vs request-driven)
• Performans optimizasyon stratejileri
• Güvenlik yaklaşımı belirlerken
• Büyük bir refactoring öncesi strateji
• Aşina olmadığınız bir alandaki en iyi pratikler

Çıktıyla Ne Yapmalı?

AI büyük miktarda kaynağı bir araya getirip sizin durumunuza özel, kaynaklı ve ayrıntılı bir analiz yazar. Çıktıyı repo'da bir doküman olarak saklayın (örneğin docs/ altında) ve CLAUDE.md'ye yapıştırmak yerine oradan ona işaret edin. 100 satır kuralı bozulmaz, sonraki oturumlar da araştırmayı ihtiyaç duyduklarında okur.

Bölüm 5: İzin Modları ve Plan-Execute-Verify Döngüsü

İzin Modları

Claude Code'da altı izin modu var ve Shift+Tab günlük kullanılanlar arasında dolaşır:

Manual (varsayılan): Her dosya düzenlemesi ve komut çalıştırması için onay ister. En güvenli, en yavaş.

Accept Edits: Dosya düzenlemelerini otomatik onaylar; Claude'a "ne yaptığını biliyorsun, devam et" demenin karşılığı. Shell komutlarından önce yine sorar.

Auto: Her şeyi çalıştırır, ama her eylemi sizin yerinize ikinci bir model (bir sınıflandırıcı, classifier) inceler ve riskli olanları durdurur. Pro, Max ve Team planlarında artık yeni oturumların varsayılanı budur.

Bypass: Hiçbir incelemeden geçirmeden her şeyi onaylar. Güvendiğiniz, iyi tanımlanmış işleri hızlandırır, ama yalnızca hook güvenlik ağınız (Bölüm 6) kuruluysa anlamlıdır; o zaman izleme işini deterministik korkuluklar üstlenir. Hook'lar yoksa Bypass, emniyeti çıkarılmış Manual moddan ibarettir.

Bu modları bir güven merdiveni gibi görüyorum. Kurulumunuz varsayılan olarak Auto'da açılsa bile yeni bir projeye Manual ile başlayın. Modelin kod tabanınızda nasıl çalıştığını izleyip nerede tökezlediğini gördükten sonra Accept Edits'e, sonra Auto'ya geçin. Auto iyi bir ara basamak: sınıflandırıcı her yerde tehlikeli olan eylemleri, hook'larınız da sizin projenizde tehlikeli olanları yakalar. Bypass'ı yalnızca bunu hak etmiş görev türlerine açın, riskli noktaları hook'lar korusun. İlk günden tam otonomi verenler genelde silinmiş dosyalar ve force-push'lanmış branch'lerle karşılaşıyor.

Plan Mode: Ayrı Bir Çalışma Modu

Plan Mode da aynı Shift+Tab döngüsünde ama başka türlü çalışıyor. Claude hiçbir şeyi değiştiremez; analiz eder ve plan önerir. Ben her büyük değişiklikten önce kullanıyorum.

Plan Mode'dan önce ise hizalama geliyor. AI'a "bir auth sistemi kur" deyin, ilk 5 dakikada 30 karar verir: JWT mi session mı, e-posta doğrulaması olacak mı, OAuth mu sadece şifre mi, hata mesajları nasıl görünecek. Hangi yöne gittiğini ancak sonucu görünce öğrenirsiniz.

O yüzden planlamadan önce AI'a gri alanları buldurun ve bunlar hakkında size somut sorular sordurun. Mesela: "Bu özelliği planlamadan önce gri alanları ve birden fazla makul yaklaşımın olduğu noktaları belirle, sonra bana sor." Her belirsiz noktayı seçenekler halinde sunmasını isteyin: "Oturum yönetimi: A) JWT refresh rotation, B) Redis sunucu taraflı oturum, C) sizin tercihiniz."

10 dakikalık bir hizalama, implementasyonun ortasında yön değiştirmekten hem token hem zaman olarak çok daha ucuza gelir.

Plan -> Execute -> Verify Döngüsü

Denediklerim arasında en istikrarlı sonuç veren kalıp bu ve CTO zihniyeti pratikte böyle görünüyor:

1. Plan Mode'a geçin: Claude'un projeyi analiz etmesine ve ne yapacağını planlamasına izin verin
2. Planı inceleyin: Mantıklı mı? Eksik bir şey var mı? Gerekirse düzeltme isteyin
3. Accept Edits'e veya Auto'ya geçin: Claude'un planı uygulamasına izin verin
4. Doğrulayın: Build çalışıyor mu? Testler geçiyor mu? Beklenen davranış sağlanıyor mu? Mümkünse kodu yazan oturum değil, temiz bir oturum kontrol etsin (Bölüm 11).

"Tüm adımlar tamamlandı" demek doğrulama sayılmaz. Doğrulama sonucu gözlemlemekle olur ve sonucu üç seviyede düşünmek işe yarıyor:

• Davranışsal: "Kullanıcı giriş yapabiliyor mu?" Çalıştırıp gözlemlemeniz gerekir.
• Yapısal: "auth.ts gerçek bir implementasyon mu, yoksa TODO'lar ve return null ile dolu bir stub mı?" Dosyanın var olması yetmez; içeriğin gerçek olması gerekir.
• Bağlantısal: "Login handler, auth modülündeki fonksiyonu gerçekten import edip kullanıyor mu?" Dosyaların hepsi yerinde olup birbirine hiç bağlanmamış olabilir.

Bunun adı "goal-backward verification" (hedeften geriye doğru doğrulama). "Ne yaptım?" yerine "ne olması gerekiyordu, oluyor mu?" diye sorarsınız. AI'ın yazdığı kodda bu çok önemli, çünkü en sık böyle bozuluyor: dosyalar yerinde, build geçiyor, ama parçalar birbirine bağlanmamış.

Bu döngüyü çoğunlukla birden fazla dosyaya dokunan değişikliklerde kullanıyorum. Claude'un ne yapacağını onaylamadan önce görmek hem zaman kazandırıyor hem hataları erken yakalatıyor.

Bölüm 6: Hook'lar: Deterministik Güvenlik Ağları

Felsefe

Claude bir olasılık makinesi ve olasılıklar bazen ıskalıyor. Hook ise mekanik bir kilit: model ne karar verirse versin, yasakladığınız eylem gerçekleşemiyor.

Olasılıksal bir sisteme deterministik güvence böyle eklenir. Bu yazıdaki güvenlik önlemlerinin çoğu da bunun üzerine kurulu.

Çizgiyi nereye çekmeli? Tek bir hata para kaybettirebiliyor ya da güvenlik açığı yaratabiliyorsa deterministik garanti gerekir. Gerisini prompt'larla idare edebilirsiniz. Günlük sürtünmeyi azaltan ucuz hook'lar da işe yarar, ama güvenlik hook'ları kadar şart değil.

Hook Türleri

Claude Code, oturum başlangıcından compaction'a, bir subagent'ın bitmesine kadar otuzdan fazla hook olayı sunar. İhtiyacınızın çoğunu bunlardan beşi karşılar:

• PreToolUse: Bir tool çağrılmadan önce (engelleme yeteneği)
• PostToolUse: Bir tool çağrıldıktan sonra (doğrulama yeteneği)
• SessionStart: Bir oturum başladığında (ortam kurulumu)
• UserPromptSubmit: Kullanıcı mesaj gönderdiğinde (girdi kontrolü)
• Stop: Agent durduğunda (temizlik)

Bunlarla başlayın, diğerlerini ancak belirli bir hata gerektirdiğinde ekleyin.

Başlangıç İçin 3 Hook

Bütün bir hook ekosistemini tek seferde kurmaya kalkmayın. Başlamak için şu üçü yeterli:

1. Tehlikeli Git Koruması (PreToolUse:Bash): git push --force, git reset --hard, git checkout . gibi yıkıcı git komutlarını engeller. Bu tek hook beni kaç kez kurtardı, saymayı bıraktım. Auto modun sınıflandırıcısı artık bunların çoğunu kendisi durduruyor; hook bunu garantiye alıyor.

2. Conventional Commits (PreToolUse:Bash): Commit mesajlarını feat(scope): description formatına uydurur. Bu hook olmadan Claude arada bir "fix stuff" gibi bir şey yazıp geçiyor.

3. Convention Guard (PostToolUse:Edit|Write): Her dosya yazımında projenize özel kuralları kontrol eder. Bir TypeScript projesinde bu any tipleri, unutulmuş console.log'lar ya da @ts-ignore olabilir. İş bölümünü aklınızda tutun. Linter'ınız genel stil kurallarını zaten mekanik olarak yakalıyor; Biome'un ya da ESLint'in bedavaya uyguladığı şeyi Claude'a öğretmek için context harcamayın. Bu hook yalnızca sizin projenizin bildiği kurallar için.

İleri Düzey: Architecture Guard

Backend projemde tek bir hook tutabilseydim bunu tutardım. Her dosya değişikliğinde Clean Architecture katman ihlallerine bakıyor. Domain katmanında bir EF Core import'u ya da Application katmanında bir Infrastructure referansı yakalanıp engelleniyor.

Bölüm 7: Custom Agent'lar: Bir Kez Tanımlanan Uzmanlar

Agent Nedir?

Agent, tek bir iş türü için ayarlanmış bir Claude instance'ı. .claude/agents/ dizininde markdown dosyaları olarak dururlar; her birinin bir system prompt'u, izin verilen tool'ları ve bir modeli vardır.

Custom Agent'ları Neden Kullanmalısınız?

Çoğu kişi emeği persona'ya harcıyor, güncel modellerde bunun getirisi az. "Sen dünya çapında bir güvenlik uzmanısın" diye açılan bir system prompt çıktıyı pek değiştirmiyor. Agent dosyasının size kazandırdığı şey daha çok mekanik:

• İzolasyon: kendi context'inde çalışır, okuduğu dosyalar ve girdiği çıkmaz sokaklar ana oturumunuza hiç ulaşmaz
• Tool sınırları: yalnızca Read ve Grep'i olan bir reviewer, bulduğunu "yardımseverce" düzeltemez
• Sabitlenmiş model: agent, ana oturum hangi modeli kullanıyorsa onunla değil, o iş için seçtiğiniz katmanla çalışır

Prompt yine önemli, ama oynanacak bir rol olarak değil. Bu projede neyin güvenlik sorunu sayıldığını sıralayan kısa bir kontrol listesi, iyi bir güvenlik reviewer'ının nasıl olması gerektiğini anlatan üç paragraftan daha çok iş görür. Agent prompt'larını CLAUDE.md'yi yazar gibi yazın: kısa, net, projenize dair.

Temel Agent Stratejisi

Her projede en az şu ikisini kurardım:

Code-reviewer agent: Kod kalitesine, pattern uyumuna, adlandırma kurallarına ve projenizin kontrol listesinde ne varsa ona bakar. Salt okunur tool'lar ve Opus verin. Review muhakeme işi ve güçlü modelin parasını hak ettiği yer tam da burası (Bölüm 9).

Debugger agent: Hata analizi, kök neden tespiti ve log incelemesi yapar. Read ve Bash tool'larıyla sınırlayın, düzeltmeyi kendiniz onaylayın.

Bölüm 8: Multi-Agent Çalışma: Ana Hattı Temiz Tutmak

Subagent'lar ve Context Avantajı

Subagent'lar, kısa ve odaklı işler için açılan bağımsız Claude instance'ları. Her birinin sizinkinden ayrı, kendine ait bir context'i var.

Yani ana oturumunuzun context'i kalabalık olsa bile subagent temiz başlar. Araştırmayı, bir kod incelemesini ya da dosya aramasını devrettiğinizde okunan dosyalar ve ara çıktılar subagent'ın içinde kalır. Size yalnızca özeti döner, ana context'iniz de şişmez.

Ana Hattı Ana Görevde Tutun

Genelde "paralel kaç subagent çalıştırabilirim?" diye soruluyor. Ben daha çok, yoldan sapan her işin nereye gönderileceğine kafa yoruyorum.

Görevin ortasında planla hiç ilgisi olmayan sorular çıkar. Bu kütüphane retry'ı nasıl ele alıyor? Alakasız o test neden kırılmaya başladı? Bunun için daha iyi bir pattern var mı? Bunları ana oturumda cevaplarsanız okunan dosyalar ve çıkmaz sokaklar asıl iş için ihtiyaç duyduğunuz context'e dolar, modelin dikkati de onlarla birlikte kayar.

Ben planı ve ana işi ana oturumda tutuyorum, plan dışı her şeyi başka bir yere gönderiyorum:

• Hemen cevabına ihtiyacınız olan bir yan soru, size özet getiren bir subagent'a gider.
• Mevcut oturumla ilgili hızlı bir soru /btw'ye gider; cevabı konuşma geçmişine eklemeden verir.
• Daha sonra lazım olacak bir şey arka plandaki bir agent'a gider ve o çalışırken siz işinize devam edersiniz.
• Riskli bir deney, kendi git worktree'sindeki bir agent'a gider; sonuç beğenilmezse komple çöpe atılır.

Doğru gidip gitmediğinizi her an anlayabilirsiniz. Ana oturumun context'i büyük ölçüde onu açtığınız görevle ilgili olmalı. Yarısı bir sapmadan ibaretse, o sapmayı devretmeniz gerekirdi.

Team'ler: Kalıcı Koordinasyon

Agent Team'ler, birden fazla Claude Code instance'ını bir ekip olarak çalıştırmanızı sağlıyor. Ekip üyelerini subagent'lardan ayıran üç şey var: kalıcılar, birbirlerine mesaj atabiliyorlar ve ortak bir görev listesini paylaşıyorlar.

Subagent'ları ne zaman kullanmalı?

• Tek seferlik görevler: dosya arama, hızlı kod incelemesi, format kontrolü
• Devam etmeden önce sonucu beklemeniz gereken görevler

Team'leri ne zaman kullanmalı?

• Kapsamlı PR incelemesi (güvenlik + kalite + performans + test kapsamı paralel olarak)
• Büyük feature geliştirme (backend + frontend + test paralel olarak)
• Karmaşık refactoring (yalnızca modüller gerçekten bağımsızsa; bkz. Bölüm 14)

Pratik Senaryo: Kapsamlı Kod İncelemesi

Diyelim bir PR incelemeniz gerekiyor. "Kod güzel mi?" sorusu fazla dar kalır. Ben birkaç açıdan bakıyorum:

Team Lead (you): Coordination
Teammate 1: Security review (OWASP, input validation, auth)
Teammate 2: Code quality (patterns, SOLID, cleanliness)
Teammate 3: Performance analysis (N+1 queries, memory leaks, caching)
Teammate 4: Test coverage (missing tests, edge cases)

4 agent paralel çalışıyor, her birinin kendi kontrol listesi ve kendi temiz context'i var; sonuçları tek bir inceleme raporunda birleşiyor. Bulgu toplama kısmı bir öğleden sonra yerine birkaç dakika sürüyor.

İşin bir de öbür yüzü var: dört agent dört rapor üretiyor ve birinin bunları uzlaştırması gerekiyor. Paralellik keşfi hızlandırırken inceleme çıktısını da katlıyor. Bir sentez adımı planlayın, daha iyisi bulgular size gelmeden bir agent'a birleştirip tekrarları ayıklatın. Verimliliğinizi neden bu uzlaştırmanın maliyetinin sınırladığını Bölüm 11 anlatıyor.

Bölüm 9: Model Routing: Doğru İş İçin Doğru Model

Dört Katman, İki Ayar

Haiku: Hızlı ve Sonnet'in yaklaşık yirmide biri fiyatıyla neredeyse bedava. Aramalarda, dosya bulmada, format kontrollerinde ve hızlı sorularda iyi. Salt okunur işlerde tutun.

Sonnet: Dengeli. Standart implementasyon, debugging ve günlük işlerin çoğu.

Opus: Derin akıl yürütme. Karmaşık mimari kararlar, zor bug'lar, büyük refactoring, güvenlik denetimleri, code review. Sonnet'in kabaca iki katı fiyatında ve çalıştırmadan çalıştırmaya daha tutarlı.

Fable: En pahalı katman, Opus'un iki buçuk katı; ama o fiyat en yüksek skorları getirmiyor. Anthropic'in kendi lansman tablosunda Opus 5.5, yayımlanan her benchmark'ta Fable 5.1'in önünde, bağımsız endeksler de ikisini birbirine yakın gösteriyor. Fable'ı bir yükseltme gibi görmüyorum. Opus'un yetersiz kaldığı uzun soluklu problemlerde ikinci görüş olarak elimde tutuyorum.

İkinci ayar effort, yani modelin cevap vermeden önce ne kadar düşündüğü; low'dan max'e kadar gidiyor. Maliyeti neredeyse model seçimi kadar oynatıyor ve kaliteyi her zaman artırmıyor. Zor ve belirsiz bir problemde fazla effort işe yarar. Net, iyi tanımlanmış bir işte ise çoğunlukla aynı cevabın daha yavaş ve daha pahalı bir kopyasını alırsınız. İyi bir görev tanımı fazladan effort'tan daha çok iş görüyor: modele dosya yollarını, kabul kriterlerini ve çıktı formatını verin, low effort genelde max ile aynı sonucu çıkarır. Derlediğim uygulamalı bir karşılaştırmada Sonnet, bir grup günlük görevde low effort ile 1,60 dolara tam puan aldı; max effort ile aynı puan 10 dolara mal oldu.

Strateji

Bugün yönlendirmeyi şöyle yapıyorum. Oturumu Sonnet yürütüyor, Opus yanında advisor olarak duruyor, salt okunur aramaları Haiku yapıyor. Advisor bir Claude Code özelliği (/advisor opus); daha güçlü modele ne zaman danışacağına ana model karar veriyor. Ben ona karar noktalarında danışmasını söylüyorum: bir plana bağlanmadan önce, aynı hata geri geldiğinde ve işin bittiğini söylemeden önce. Yalnızca Anthropic API üzerinde çalışıyor, Bedrock ve Vertex'te bulamazsınız. Her danışma tüm transcript'i Opus fiyatından yeniden okuyor, yani bir maliyeti var. Karşılığında Opus seviyesindeki muhakemeyi gerektiği anlarda alıyorsunuz, yazma işini de Sonnet yapıyor; Bölüm 11'deki üretici/doğrulayıcı ayrımının oturuma gömülü hali bu. Oturum çoğunlukla muhakemeden ibaretse (mimari, zorlu bir kök neden) ana model olarak Opus'u çalıştırıyorum.

Subagent'lar işlerini görebilecek en ucuz katmanı alıyor. Mekanik taramalar (dosya tarama, rename, extraction) Haiku'ya, iyi tanımlanmış kod ve dokümantasyon Sonnet'e, belirsiz debugging ve review'lar Opus'a gidiyor. Bir varsayılanı da değiştiriyorum. Güncel sürümlerde yerleşik Explore agent'ı ana modelinizle çalışıyor, yani her kod tabanı araması ana model fiyatından faturalanıyor. Adı tam olarak Explore olan, Haiku ve salt okunur tool'larla tanımlanmış kullanıcı seviyesinde bir agent bu aramaları ucuz katmana taşıyor. Fiyatlar ve arkasındaki benchmark'larla birlikte kurulumun tamamı claude-model-advisor skill'imde.

Görevin uzunluğu da karmaşıklığı kadar önemli. Uzun otonom çalışmalarda bir modelin adım başına güvenilirliği ham zekasından daha çok sayıyor; nedeninin hesabı Bölüm 13'te.

Bir de modelin ne kadar inisiyatif aldığı meselesi var. Derin akıl yürüten modeller girdilerini sorguluyor. Birine "test suite zaten çalıştı ve geçti, son kontrolü yap ve commit'le" deyin; önce iddianızı kontrol etmeye karar verebilir, zaten yaptığınız işi yeniden çalıştırır ve bazen saklamak istediğiniz sonuçların üzerine yazar. Açık uçlu bir problemde bu şüphecilik tam da parasını verdiğiniz şey. İyi tanımlanmış bir otomasyon adımında ise ayağınıza dolanıyor; orada istediğiniz model, kontrol listesini yazıldığı gibi uygulayan model.

Bunların hiçbirine sıkı sıkıya bağlanmazdım. Frontier modeller arasındaki farklar pazarlamanın ima ettiğinden küçük, her sürümde yer değiştiriyor ve bir iş türünde kazanan model başka birinde kaybediyor. Görev başına model seçmek mekanik bir dispatch işi, sizin yerinize harness'ın yapması gereken türden bir şey; oraya doğru da gidiyor: advisor ve agent'lara sabitlenen modeller bunun ilk halleri. O güne kadar basit bir kural yeterli. Kararsız kaldığınızda ucuz model çoğu zaman işi görür. Yalnız maliyeti istek başına değil biten iş başına ölçün, çünkü tekrar etmek zorunda kaldığınız ucuz bir çalıştırma sonunda daha pahalıya patlıyor.

Tahmin Etmek Yerine Ölçün

Her şeyi Opus'ta çalıştırmayı bıraktığımdan beri günlük harcamam kendi kaba tahminime göre yarı yarıya düştü. İzlenim kolay yanıltır, o yüzden gerçek sayılar görmek istedim. Claude Code log, metrik ve trace'leri OpenTelemetry üzerinden dışa aktarıyor; ben de bunları tek komutla yerel bir Aspire Dashboard'a gönderen bir gist yazdım. Gist'i Claude Code'a verip kurulumu ona yaptırabilirsiniz. Her istek için token sayılarını ve tahmini maliyeti, modele ve ana agent/subagent ayrımına göre görürsünüz. Her mesajın bir trace'i de oluyor: her API çağrısının ve tool'un ne kadar sürdüğü, Claude'un bir onay için sizi ne kadar beklediği. Bu son sayı, Bölüm 5'teki güven merdivenini kontrol etmek için iyi bir ölçü. Maliyet rakamları API liste fiyatlarıyla hesaplanıyor; abonelikte faturanızı değil kullanımınızı gösteriyor.

Bölüm 10: Çapraz Model Orkestrasyonu: Farklı AI'ları Birlikte Kullanmak

Tek Bir Model Yetmez

Farklı sağlayıcıların modellerini birlikte kullanmak beklediğimden çok daha fazla işe yaradı.

Claude: Ana üssüm. Günlük işi Sonnet yapar; muhakemeyi Opus getirir, advisor olarak ya da zor oturumlarda ana model olarak (Bölüm 9).

OpenAI Codex/GPT: Kod analizi, planları kontrol etme, itiraz etme. Bana en çok farklı bir bakış açısı olarak faydalı.

Google Gemini: Üçüncü bir model ailesi; çok dosyaya yayılan büyük geçişlerde ikinci okuyucu olarak kullanışlı. Claude'da da artık bir milyon token var, yani Gemini'yi artık farklı kör noktaları için seçiyorum. Bir model kendi kör noktalarını göremez, başka bir aileden gelen model ise çoğu zaman onlara hemen takılır. (Bölüm 3'teki seçim kuralları iki tarafta da geçerli.)

Bölüm 11: Doğrulama Darboğazdır

Üretmek Ucuz, Kontrol Etmek Değil

AI'ı orkestre etmeye başladığımda kimse bana kod üretmenin darboğaz olmaktan çıkacağını söylememişti. Claude, bir günümü alan işi bir saatte çıkarıyor. Ama o bir saatlik çıktıyı düzgünce doğrulamak (diff'i okumak, akışları çalıştırmak, uç durumlara bakmak) dikkatimin birkaç saatini yiyebiliyor.

Dikkat, agent'lar gibi ölçeklenmiyor. İnceleme üretimden pahalı hale geldiği anda göz gezdirmeye başlıyorsunuz, göz gezdirmek de zamanla güvenmeye dönüşüyor. Er geç bozuk bir şey production'a çıkıyor ve "bitti" denen işin hiç doğrulanmadığı anlaşılıyor.

Bu açıdan bakınca önceki bölümlerin hepsi aslında doğrulamayla ilgili. Hook'lar (Bölüm 6) kendiliğinden çalışan doğrulama. Testler, dikkatiniz başka yerdeyken çalışan doğrulama. Bölüm 5'teki Plan-Execute-Verify döngüsü, Verify adımı bir rutin olduğu için işliyor; kimsenin kahramanlık yapması gerekmiyor. Sınır çoktandır üretim değil; tükenmeden ne kadarını doğrulayabildiğiniz.

Önce Sorulacak Soru: Oracle'ım Nerede?

Bazı projeler bu darboğazı diğerlerinden çok daha az hissediyor. Neyin doğru olduğuna karar veren mekanik bir referans varsa (bir test suite, bir referans implementasyon, bir formal spec), doğrulama artık dikkatinizi yemiyor. Test literatüründe buna oracle deniyor. Oracle olduğunda talimatın kendisi değişiyor: çıktıyı incelemek yerine "kontrol geçene kadar iterasyona devam et" deyip başından kalkıyorsunuz.

Migration ve port projelerinde agent'ların neredeyse sihirli görünmesinin sebebi bu. Eski sistem doğru davranışı son edge case'ine kadar tanımlıyor, agent da her denemesini bir insana notlandırtmadan sabit bir hedefe doğru ilerleyebiliyor. Rewrite'lar için buradan bir taktik ödünç alırdım: agent'ı eski sistemin kaynak koduna değil davranışına yönlendirin. Böylece kodun ne yaptığını, nasıl yaptığını miras almadan yeniden üretir.

O yüzden büyükçe bir işe girmeden önce kendime oracle'ımın nerede olduğunu soruyorum. Bazen zaten var. Bazen ucuza kısmi bir tane kurulabiliyor: mevcut davranışın etrafına characterization testleri, golden file'lar, API için bir contract. Her parça insan doğrulamasını makine doğrulamasına çeviriyor. Kodun dışında da böyle: makine araması, aday cevapların ucuza kontrol edilebildiği alanlarda en hızlı ilerliyor ve proof checker bulunabilecek en saf oracle'a yakın. Otomatikleştirdiğiniz her kontrol, kendi projenizi de o uca biraz daha yaklaştırıyor.

Üretici Kendi İşini Asla Notlandırmamalı

Doğrulamada en önemli alışkanlığım şu: kodu yazan oturuma o kodu değerlendirtmeyin.

Deneyin. Claude'a gerçekten karmaşık bir şey yazdırın, aynı anda birkaç alana dokunan bir değişiklik. Başarıyı ilan ettiğinde yeni bir oturum açın, aynı diff'i gösterin ve şunu söyleyin: "Bu değişikliği inceliyorsun. Görevin sorunları bulmak." Az önce her şeyin çalıştığını söyleyen model size gerçek sorunlardan oluşan bir liste verecek.

Şirketlerin geliştiriciyle test uzmanını ayırmasının sebebi de aynı. Yazarın context'i işi bitirme niyetiyle dolu; temiz bir context'le başlayan reviewer'ın ise tek bir derdi var, yanlış olanı bulmak.

Titizliği riske göre ölçeklendirin:

• Kullan-at iş: hiç inceleme yok. İşini görmüş tek seferlik bir script, önemli olan tek testi zaten geçmiştir
• Rutin değişiklik: temiz context'te tek bir inceleme geçişi
• Önemli değişiklik: Bölüm 10'daki kör nokta nedenleriyle, farklı bir modelle ikinci bir geçiş
• Para veya güvenlik söz konusuysa: art arda birkaç geçiş temiz dönene kadar tekrarlayın

Bunun da sınırları var. Reviewer agent'lar yüzeydeki sinyallere kanabiliyor: kendinden emin isimlendirme, derli toplu yorumlar, "test edildi, hazır" yazan bir açıklama. Bunların hiçbiri kanıt değil ama model hepsini kanıtmış gibi okuyor. Tek bir karara güvenmek yerine birden fazla geçiş ve birden fazla model kullanmak için bildiğim en sağlam gerekçe de bu zayıflık.

Öbür sınır sorumluluk; onu kimseye devredemezsiniz. Bir değişiklik sizin adınızla yayına çıkıyorsa ve siz onu kontrol edebilecek konumda hiç olmadıysanız, adı ne konursa konsun, kontrol edilmemiş bir çıktının altına imzanızı atmışsınız demektir. Düşük riskli işlerde titizliği istediğiniz kadar azaltın, ama doğrulayamadığınız şeyin altına imza atmayın.

Bölüm 12: Her Tekrarlanan Hatayı Bir Sisteme Dönüştürün

Claude'un stateless olmasının, çoğu kişinin hesaba katmadığı bir sonucu var. Model bir hatayı bir kez yaptıysa tekrar yapacak, çünkü o hatayı doğuran koşullar değişmedi.

Kuralım basit: aynı hatayı ikinci kez gördüğümde onu kalıcı bir şeye çeviriyorum. Kabaca tercih sırasıyla:

1. Bir hook, mekanik olarak kontrol edilebiliyorsa (engellenen bir komut, yasak bir pattern)
2. Bir test, regresyona uğrayabilecek bir davranışsa
3. Bir CLAUDE.md notu veya skill, modelin sürekli kaçırdığı bir convention veya iş akışıysa

Kendinizi iki kez anlatırken yakaladığınız her şey için de aynısı geçerli. Projeyi ayağa kaldırmak bir sıra gerektiriyorsa (önce bir container, sonra seed data, sonra watch modunda bir servis) ve ikinci bir oturum aynı anlatımı istiyorsa, henüz kimsenin yazmadığı bir skill bulmuşsunuz demektir. Onu sizin yazmanız da gerekmiyor. Sıranın işe yaradığı oturumun sonunda "az önce yaptığımızı bir skill'e dönüştür" deyin. Model, az önce uyguladığı bir prosedürü sizin hafızadan toparlayacağınızdan daha iyi belgeler; size maliyeti tek bir cümle.

Bedeli bir kez ödüyorsunuz: ilk düzeltme ve kalıcı hale getirmek için on dakika kadar. Sonrasında o hata size hiçbir şeye mal olmuyor.

Bunu atlarsanız tablo tersine döner. Kod tabanınızda her gün çalışan bir modelin onlarca tekrarlayan hata modu var. Her biri ara sıra bile geri gelse gününüz zaten düzelttiğiniz hataları yeniden düzeltmekle geçer ve durum hiç iyileşmez, çünkü o düzeltmelerin hiçbiri bir yere kaydedilmedi.

Model oturumlar arasında öğrenmiyor. Hook'larınız, testleriniz ve CLAUDE.md'niz ise birikip keskinleşiyor; altı ay sonra kurulum neredeyse tanınmaz halde oluyor. Kendi kendine öğrenen sistemden pratikte kastedilen bu.

Bu birikimi dengelemek de gerekiyor, çünkü prompt kuralları bayatlıyor. İki model sürümü önceki bir hatayı durdurmak için yazılmış bir CLAUDE.md satırı artık gürültü olabilir, ya da güncel modelin fazla harfiyen uyguladığı bir kısıta dönüşmüş olabilir. Birkaç ayda bir kurallarınızı baştan okuyun ve her biri için, yakın zamanda gördüğünüz bir şeyi hâlâ önleyip önlemediğini sorun. Önlemiyorsa silin ve hatanın geri gelip gelmediğine bakın. Hook'lar ve testler kalabilir, tetiklenmedikleri sürece maliyetleri yok; prompt kuralları ise her mesajda dikkat harcıyor.

Bütün bunun bir sınırı var: kurallar sizin kendi hatalarınızdan çıkmalı. Aynı faydayı hazır paket olarak vadeden bir sürü kural seti ve workflow koleksiyonu var ve işe yarayıp yaramadıklarını bilmenin bir yolu yok. Nadiren kanıtla geliyorlar; kendiniz dikkatle test etseniz bile sonuç net çıkmıyor, çünkü alttaki modeller ve araçlar sürekli değişiyor. Birini kurduktan sonra fark ettiğiniz iyileşme geçen haftaki model güncellemesiyle gelmiş olabilir. Bizzat izlediğiniz bir hatadan sonra yazdığınız kural ise kanıtını yanında getiriyor.

Bölüm 13: Uzun Süren Görevler: Hatalar Katlanarak Birikir

%99,9 ile %99,99 Arasındaki Fark Neden Büyük

Bir agent'ın bir görevin her adımını %99,9 oranında doğru yaptığını varsayalım. Harika bir sayı gibi duruyor. Şimdi ona gece boyu sürecek türden uzun, otonom bir görev verin: bin adım okuma, düzenleme, çalıştırma ve kontrol.

0,999'un 1000. kuvveti yaklaşık 0,37 ediyor; yani "mükemmel" agent'ınız temiz bir çalıştırmayı ancak %37 ihtimalle tamamlıyor.

Adım başına %99,99 tutturan bir agent aynı bin adımda yaklaşık %90 temiz çalıştırma çıkarıyor. Yuvarlama hatası gibi görünen bu aralık, gece boyu başına bırakabileceğiniz agent'ı bırakamayacağınızdan ayırıyor.

Bunun pratikte iki sonucu var.

Model seçimi görev uzunluğuyla değişir. 20 dakikalık bir iş için en akıllı modeli seçin. 10 saatlik bir çalıştırma için en tutarlı olanı, kendi adımlarını iki kez kontrol edeni seçin. Model-advisor skill'imin dayandığı karşılaştırmalarda Opus çalıştırmadan çalıştırmaya Sonnet'ten daha az oynuyor; Sonnet ise yüksek effort'ta ya çok iyi ya da başarısız bir sonuç verebiliyor.

Checkpoint'ler bu birikimi keser. Yukarıdaki hesap, tek bir hatanın bütün çalıştırmayı mahvettiğini varsayıyor; o yüzden hataları geri alınabilir hale getirin:

• Kilometre taşlarında commit'i zorunlu kılın. Agent'a biten her parçadan sonra commit atmasını söyleyin. Bir hata o zaman size bütün çalıştırmayı değil, bir rollback'i kaybettirir.
• Bir çalıştırma günlüğü tutun. Agent'a bir dosya tutturun: ne bitti, ne kaldı, ne ters gitti ve nasıl ele alındı. Çalıştırma yarıda kesilirse yeni bir agent sıfırdan başlamak yerine bu dosyadan devam edebilir.
• Önceden bütçe belirleyin. Zaman, token, kapsam. "Aynı sorunda üç denemeden sonra testler hâlâ kırmızıysa dur ve bildiklerini yaz" gibi bir talimat, agent'ın çıkmaz bir yolda bütün gece debelenmesinden çok daha iyi.

Uzun görevleri, yarı yolda bir şeylerin ters gideceğini varsayarak planlayın.

Bölüm 14: Doğru Yapılan Paralellik

Agent Sayısı Bir Çarpan Değildir

10 agent = 10x hız diye düşünmek cazip geliyor. 10 agent'ı kod tabanının aynı kısmına salın, olan başka. Her agent doğru bir değişiklik yapabilmek için kodun tutarlı bir resmine ihtiyaç duyuyor; o resmi kurarken başka bir agent kodu altından değiştiriyor. Birbirlerinin işinin üzerine yazıyor, birbirlerinin varsayımlarını bozuyorlar, siz de akşamı bu düğümü çözmekle geçiriyorsunuz. On agent'la tek agent'tan daha yavaş kalıyorsunuz.

Paralellik, işin bağımlılık grafiğini izlediğinde işe yarıyor:

• Gerçekten bağımsız alanlara göre bölün. Frontend ve backend ya da kod paylaşmayan iki servis; her biri kendi git worktree'sinde, sonunda merge edilir. Parçalar ne kadar bağımsızsa hızlanma da o kadar gerçek.
• Bir yazar, çok okuyucu. Değişiklikleri tek bir agent yaparken paralel subagent'lar ona araştırma taşır: dosya keşfi, doküman arama, pattern arama. Yazmalar sırayla, okumalar paralel ilerler ve hiçbir şey çakışmaz.

En Güvenli Paralellik: Keşif

Okumanın yan etkisi yok, o yüzden araştırma hiçbir hazırlık gerektirmeden paralelleştirebileceğiniz tek yer. Sürekli döndüğüm bir pattern var: aynı soruyu iki ya da üç agent'a ayrı ayrı verin, sonra başka bir agent'a raporlarını karşılaştırtın.

Asıl öğrendiklerimin çoğu bu karşılaştırmadan çıkıyor. Raporlar çelişiyorsa orada muhtemelen belirsiz ya da bozuk bir şey var ve gidip kendim bakıyorum. Uyuşuyorlarsa bunu kesin kanıt değil, orta güçte bir işaret sayıyorum; benzer verilerle eğitilmiş modeller kör noktalarını paylaşıyor ve aynı şekilde, aynı kendinden emin tavırla yanılabiliyor.

Bir de şu var: tek agent'lı döngü çalışmadan paralelleştirmeyin. Yön yanlışsa daha fazla agent sizi yanlış yere sadece daha erken götürür. Önce sistemi oturtun (context, doğrulama, checkpoint'ler); paralellik ancak ondan sonra zaten çalışan bir şeyi çoğaltır.

Çıktının Çoğunu Çöpe Atmak Ne Zaman Normaldir

Paralelliğin bir türü daha var ve Bölüm 11'deki soruya iyi bir cevabınız olduğunda açılıyor. Mekanik bir kontrol varsa üretilen kodu kıymetli bir şey gibi görmeyi bırakabilirsiniz: aynı probleme birkaç deneme başlatın, kontrolü geçeni tutun, gerisini silin. Çıktının çoğunu çöpe atmak bilinçli bir tercih: token artık ucuz, dikkatiniz değil.

Her şey o kontrolün otomatik olmasına bağlı. Aynı yöntemi her denemeyi bir insanın incelediği bir düzende uygularsanız okuma yükünüzü deneme sayısıyla çarpmış olursunuz; bu da Bölüm 11'deki darboğazın başka bir kılıkta geri gelmesi.

Bölüm 15: Test, Güvenlik ve Performans: CTO Kontrol Listesi

AI Destekli Geliştirmede Test

AI ile kod yazarken en kolay düşülen tuzak "şunu hızlıca bitireyim, testleri sonra yazarım" demek. Test yoksa AI'ın ürettiği kodu doğrulamanın bir yolu da yok.

O yüzden AI'a bir feature yazdırırken testleri aynı prompt'ta isteyin: "Bu feature'ı implement et ve testlerini yaz, sonra testleri çalıştır." Doğrulama kriteri eklemek size bir cümleye mal oluyor, dönen sonuç ise gözle görülür şekilde değişiyor.

Güvenlik Taraması

Her PR'dan önce şu güvenlik kontrollerini yapın:

1. Hardcoded secret taraması: API key'leri, şifreleri, token'ları arama
2. Input validation kontrolü: Kullanıcı girdileri doğrulanıyor mu?
3. OWASP Top 10 incelemesi: SQL injection, XSS, CSRF riskleri var mı?
4. Dependency güvenliği: Bilinen güvenlik açıklarına sahip paketler var mı?

Performans: Optimize Etmeden Önce Ölçün

AI ile performans çalışmasının kendine has bir tuzağı var. Model, gösterdiğiniz yeri sorun orada olsun olmasın seve seve optimize eder. Önce ölçün, sonra devredin. N+1 query'lere, eksik bir index'e, tek parça yüklenmek yerine stream edilmesi gereken bir payload'a bakmasını isteyin. Kontrol edebileceğiniz bir şey isteyin, örneğin "bu endpoint'i profille ve zamanın nereye gittiğini göster". "Daha hızlı yap" çoğunlukla tahmin getirir.

Bölüm 16: Yapın ve Yapmayın

Yapın

1. Her proje için iyi bir CLAUDE.md yazın. Bu dosya olmadan Claude projenizi bilmez.
2. Context'i aktif olarak yönetin. Sadece çubuğa değil, context'in içinde ne olduğuna bakın. Biten iş birikince compact edin, /clear ile temiz başlayın.
3. Plan Mode'u alışkanlık haline getirin. Büyük değişikliklerden önce ne yapılacağını görün, sonra onaylayın.
4. Doğrulama kriterleri belirleyin. "Test yaz" yerine "edge case'leri kapsayan testler yaz ve npm test ile çalıştır" deyin.
5. Hook'larla güvenlik ağı örün. En az 3 temel hook ile başlayın.
6. Ana hattı ana görevde tutun. Araştırma, inceleme, arama ve plan dışı her şey subagent'lara gider (Bölüm 8).
7. Derin araştırma ile başlayın. Karmaşık görevlerde önce araştırın, sonra implement edin.
8. Model routing uygulayın. Her subagent işine yeten en ucuz katmanı alsın; üst katmanları ve yüksek effort'u gerçekten ihtiyaç duyan işlere saklayın.
9. Örnekle öğretin. Üç paragraf açıklama yazmak yerine bir kod parçası gösterin.
10. Oturumları kısa tutun. Bir konuşma = bir görev. Context şiştikçe kalite de düşüyor.
11. Tekrarlanan hataları sisteme dönüştürün. Bir hata ikinci kez görüldüğünde ona bir hook, bir test ya da bir CLAUDE.md notu yazılır (Bölüm 12).
12. Üreteni doğrulayandan ayırın. Temiz context'teki bir inceleme, yazan oturumun göremediğini görür (Bölüm 11).

Yapmayın

1. Claude'u linter olarak kullanmayın. ESLint, Biome ve Prettier zaten var. "İki boşluk kullan" gibi kurallar context'i boşa harcar.
2. CLAUDE.md'yi romana çevirmeyin. 100 satırın altında tutun. Progressive disclosure kullanın.
3. Doğrulamadan güvenmeyin. Claude'un "bitti" demesi yetmez. Build'i, testleri ve güvenliği kendiniz kontrol edin.
4. Aşırı mühendislik yapmasına izin vermeyin. CLAUDE.md'de bir kez söyleyin ("ekstra soyutlama yok, gereksiz interface yok") ve gerisini review'da yakalayın. Aynı kuralın on farklı versiyonu işe yaramaz.
5. Test yazmayı ertelemeyin. Testi olmayan AI çıktısını kimse doğrulamamış demektir.
6. Sistem çalışmadan paralelleştirmeyin. Bozuk bir döngüdeki on agent on kat hızlı başarısız olur (Bölüm 14).
7. Hazır kural paketleri kurup iyileşme beklemeyin. Ödünç alınmış bir kural kanıtla gelmez; kendi tekrarlanan hatalarınızdan damıttığınız kural ise kanıtıyla gelir (Bölüm 12).
8. Yaratıcı işi daha fazla kuralla düzeltmeye çalışmayın. Açık uçlu görevlerde net bir hedef ve hareket alanı, uzun bir yasak listesinden daha iyi sonuç verir (Bölüm 2).

Sonuç: Şimdilik Vardığım Yer

Claude Code benim için "terminalde AI" olarak başladı, sonra geliştirme işimin çoğunu yaptığım yere dönüştü. CLAUDE.md stratejisi, context yönetimi, hook pipeline'ları, custom agent'lar, multi-agent orkestrasyon, birden fazla modeli birlikte kullanmak, kendi hatalarından öğrenen sistemler; bunların hepsini aylar içinde, yavaş yavaş öğrendim.

Çoğu Bölüm 1'deki fikre, CTO gibi düşünmeye dayanıyor: işi sadece yazmıyor, planlıyor, test ediyor, güvenliğini sağlıyor ve ölçüyorsunuz; hem de her seferinde aynı şekilde.

Bunların hiçbiri oturmuş bir metodoloji değil. Yazılımın bu şekilde nasıl geliştirilmesi gerektiğini sektörde henüz kimse bilmiyor. Okuduklarınız, aylarca süren günlük kullanımımdan sağ çıkan pratikler ve bir kısmı bir yıl içinde naif görünecek. İşin tuhafı, bu bana cesaret veriyor. Yirmi yıllık deneyim burada hiç olmadığı kadar küçük bir avantaj sağlıyor, çünkü herkes bu çalışma biçimini aşağı yukarı aynı başlangıç çizgisinden öğreniyor.

Haklı olarak şunu sorabilirsiniz: daha akıllı modeller bütün bu kurulumu gereksiz kılmayacak mı? Bence tam tersi olacak. Daha akıllı modeller devredebileceğiniz işin tavanını yükseltiyor ve bu makaledeki her şey (doğrulama, context disiplini, checkpoint'ler) o işi gerçekten devredebilmenizi sağlayan şey. Bu yüzden sistem kuranlarla sadece prompt yazanlar arasındaki farkın açılmaya devam edeceğini düşünüyorum.

Yine de modeller geliştikçe sistemin şekli değişiyor. Daha akıllı modeller daha az talimata ihtiyaç duyuyor: daha az kural, daha kısa prompt'lar, yaratıcı işte daha fazla alan. Doğrulamaya ise aynı ölçüde ihtiyaç duyuyorlar, çünkü daha çok devretmek, henüz kimsenin kontrol etmediği daha çok çıktı demek. Bunu ilk yazdığımdan beri kendi kurulumumun nasıl değiştiğini tek cümleyle özetlemem gerekirse: prompt katmanı küçülüyor, doğrulama katmanı büyüyor.

Başlamak için:

1. İyi bir CLAUDE.md yazın
2. Context yönetimini öğrenin (oturum başına tek görev, belirtilerden önce aksiyon)
3. 3 temel hook'u kurun
4. Plan Mode'u alışkanlık haline getirin
5. Üreteni doğrulayandan ayırın

Yol boyunca bahsettiğim araçlardan ikisi herkese açık: model-advisor skill'i ve telemetri kurulumu. Kullanın, değiştirin ve kendi hatalarınız karşısında ayakta kalanı tutun.