M
Seviye 2 · Proje Ustalığı
Kimlik hedefi: "Reposunu ajana hazırlayan kişi." Seviye 1'de tek oturumu yönettiniz; şimdi projenin kendisini AI ile çalışmaya uygun hâle getiriyorsunuz: kurallar, sigortalar, kalite kapıları ve mimariyi okuma yetisi.
Bu seviyenin kavramları: repo · commit · branch · merge · build · test · CLAUDE.md · migration · ortam değişkeni/secret · frontend/backend · index · prod/preview
DERS 2.1 CLAUDE.md: projenin anayasası
KAZANIM Bu dersin sonunda: bir projeye, yapay zekânın her oturumda uyacağı bir anayasa yazabilirsin.
1 · TanımCLAUDE.md = proje klasörünün köküne koyduğunuz, AI'ın her oturumda otomatik okuduğu kurallar dosyası.
2 · İşlev ve amaçSeviye 1'de öğrendiniz: oturuma söylenen kural, compaction'da buharlaşabilir. Kalıcı kuralın yeri dosyadır. CLAUDE.md, her yeni oturuma "bu projenin görgü kurallarını" sıfır maliyetle taşır — siz tekrarlamazsınız, AI unutmaz.
3 · Nasıl yapılırDosyaya NE yazılır: (1) proje tek cümlede ne, (2) çalıştırma/test/build komutları, (3) dokunulmayacak yerler ve yasaklar ("X klasörüne dokunma", "paket ekleme, önce sor"), (4) proje kararları ("tarih formatı şu", "dil Türkçe"). NE YAZILMAZ: uzun tarihçe, genel nasihat ("temiz kod yaz"), her detay. Ölçü: kısa tutun (bir-iki ekran) — anayasa maddeleri, roman değil. İlk taslağı AI'a çıkartabilirsiniz:
Bu projeyi incele ve bir CLAUDE.md taslağı çıkar: proje özeti, komutlar, riskli
bölgeler, uyulması gereken kararlar. Kısa ve emir kipinde yaz. Ben düzelteceğim.
...ama son hâli SİZ onaylarsınız — anayasayı müteahhit yazmaz, mal sahibi onaylar.
4 · Ne ters gider + çözümüHata 1: dosya şişer, AI önemli kuralı gürültüde kaçırır. Çözüm: her yeni kural eklerken eskimiş bir satır silin. Hata 2: kural yazılır ama muğlaktır ("dikkatli ol") — uygulanamaz. Çözüm: kuralları denetlenebilir yazın ("build geçmeden commit yok" gibi evet/hayır'ı belli olan cümleler).
5 · AlternatiflerTek seferlik kısıt → istemin içine (ders 1.1). Sizin kişisel tercihiniz ama projeyle ilgisiz → memory (Seviye 3.5). Proje kuralı → CLAUDE.md. Bu üçlü yönlendirme, "nereye yazacağım" sorusunun tam cevabıdır.
6 · Denetim penceresiKontrol: yeni bir oturum açın ve sorun: "Bu projenin CLAUDE.md'sindeki kuralları listele ve her birine uyup uymadığını nasıl anlayacağımı söyle." AI kuralları eksik sayıyorsa dosya ya karışık ya şişkin. Kırmızı bayrak: AI'ın bir kuralı sistematik delmesi — kural muğlak yazılmış demektir; suç uygulayanda değil, maddede.
7 · Mini egzersiz (KENDİ-PROJEN)Üret: düşük riskli bir projenize yukarıdaki istemle CLAUDE.md taslağı çıkartın, elden geçirip 15-20 satıra indirin. Denetle: temiz oturumda 6. bölümdeki kontrolü koşturun.
8 · Kontrol soruları(1) CLAUDE.md'ye ne yazılır, ne yazılmaz? (2) "Dikkatli ol" neden kötü bir kuraldır? (3) Kural nereye yazılır: tek seferlik / kişisel / proje kuralı için üç ayrı adres nedir?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.1'in (CLAUDE.md yazımı) hocası ol. Bana kötü yazılmış 6 maddelik
örnek bir CLAUDE.md göster; hatalarını buldurup birlikte iyi versiyona çevirelim.
Sonunda 3 kontrol sorusunu sor ve değerlendir.
DERS 2.2 Git disiplini: commit = kayıt noktası
KAZANIM Bu dersin sonunda: her sağlam adımı kayıt altına alır, en kötü hatayı bile tek hamlede geri alırsın.
1 · TanımCommit = projenin açıklamalı fotoğrafı; branch = paralel taslak kopya; geri alma = önceki kayda dönme. Hepsini Git aracı sağlar — komutlarını AI yazar, kararlarını siz verirsiniz.
2 · İşlev ve amaçVibe coding'in ana sigortası. AI dakikada onlarca satır değiştirir; kayıt noktası yoksa "5 dakika önceki hâle dön" diyemezsiniz. Commit disiplini olan kullanıcı için AI'ın en kötü hatası bile "son kayda dön" kadar ucuzdur.
3 · Nasıl yapılırÜç kural: (1) Her sağlam adımda commit — özellik bitti + doğrulandı → kayıt. Komutu siz ezberlemeyin: "bu hâli commit'le, açıklamayı sen yaz" demek yeterli. (2) Riskli işe branch'te başla — "bu deneme için branch aç" → beğenirseniz merge, beğenmezseniz çöpe; ana kopya hiç etkilenmez. (3) Geri almanın iki modu: revert = hatalı değişikliği geri alan YENİ kayıt ekler (tarihçe korunur — güvenli, varsayılan tercih); reset = tarihçeyi geriye sarar (yıkıcı olabilir — paylaşılan projede tehlikeli). Şüphede hep revert.
4 · Ne ters gider + çözümüKlasik felaket: 4 saatlik seansta hiç commit yok, son değişiklik her şeyi bozdu, dönülecek kayıt yok. Çözüm sistemik: CLAUDE.md'ye "her doğrulanmış adımdan sonra commit öner" kuralı ekleyin — hatırlamayı kendinize bırakmayın. İkinci tuzak: anlamadan reset --hard onaylamak ve commit'lenmemiş işi kaybetmek. Çözüm: içinde hard, force geçen git komutları = ders 1.7 protokolü (açıklat, sonra karar ver).
5 · Alternatifler"Her adımda commit" yerine bazıları oturum sonunda tek büyük commit atar — geri dönüş noktalarınız seyrekleşir, riski size ait. Küçük kişisel projede kabul edilebilir; para/kullanıcı olan projede edilmez.
6 · Denetim penceresiKontrol soruları kendinize: "Şu an her şey bozulsa, en fazla kaç dakikalık işim yanar?" Cevap 30 dakikadan büyükse commit'lersiniz. AI'a: "son commit'ten bu yana neler değişti, listele" — liste sürpriz içeriyorsa önce inceleyin, sonra commit'leyin (çöp de kayda girmesin).
7 · Mini egzersiz (SANDBOX)Üret: sandbox'ta bir özellik ekletin, commit'leyin; sonra "bu özelliği bilerek boz" deyin. Denetle: bozulmayı revert ile geri aldırın ve uygulamanın eski hâline döndüğünü bizzat doğrulayın. (Geri dönüşü bir kez YAŞAMAK, on kez okumaktan değerlidir.)
8 · Kontrol soruları(1) Ne zaman commit atılır? (2) Revert ile reset farkı nedir, şüphede hangisi? (3) Riskli deneme neden branch'te yapılır?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.2'nin (git disiplini) hocası ol. Commit/branch/revert-reset'i
oyun kayıt noktası metaforuyla anlat. Bana 4 senaryo ver, her birinde hangi git
hamlesini seçeceğimi sor ve değerlendir. Sonunda 3 kontrol sorusu.
DERS 2.3 Kalite kapıları: build ve test
KAZANIM Bu dersin sonunda: commit ve yayın öncesi mekanik kalite kapılarını kurup işletirsin.
1 · TanımKapı = işin bir sonraki aşamaya geçmeden önce geçmek ZORUNDA olduğu mekanik kontrol: build (proje tutarlı mı derleniyor) ve testler (kurallar hâlâ sağlanıyor mu).
2 · İşlev ve amaçKapılar, denetimi kişisel gayretten çıkarıp mekanik zorunluluğa çevirir. Sizin gözünüz yorulur, kapı yorulmaz. "Geçti/geçmedi" cevabı tartışmasızdır — AI ile aranızdaki en objektif hakem.
3 · Nasıl yapılırSıralı kapı zinciri: değişiklik → build → (varsa) testler → kendi denemeniz → commit → yayın. Kural: commit'ten önce build; yayından önce hepsi. Kapıyı CLAUDE.md'ye yazın ("commit önerisinden önce build çalıştır ve sonucu göster"). Testleriniz yoksa: kritik akışlar için AI'a yazdırın — "bu projenin en kritik 3 davranışı için test yaz" iyi bir başlangıçtır.
4 · Ne ters gider + gerçek vaka
Gerçek vaka: Bir üründe hızlı kontrol aracı (tip denetimi) "her şey yolunda" dedi; ama tam build ancak yayın sırasında patladı — sorun, hızlı kontrolün hiç bakmadığı bir katmandaydı. Saatler kaybedildi. Ders: hızlı kontrol, tam build'in yerine geçmez. Yayına neyle çıkıyorsanız kapınız o olmalı.
Gerçek vaka (yayın doğrulaması): Bir yayında komut doğru çalıştı ama farkında olmadan YANLIŞ projeye yayın yapıldı — komut çıktısındaki "hangi projeye yayınlanıyor" satırı okunmamıştı. Ders: kapı sadece build değildir; yayın komutunun çıktısındaki hedef bilgisini okumak da bir kapıdır.
Çözüm kalıbı: kapılar atlanınca değil, atlanamaz yapılınca çalışır — kural dosyaya, alışkanlık zincire.
5 · AlternatiflerHer kaydetmede otomatik kapı koşturmak (hook — Seviye 3.2) manuel disiplinin gelişmişidir; oraya Seviye 3'te geleceksiniz.
6 · Denetim penceresiKırmızı bayraklar: "build'e gerek yok, küçük değişiklik" cümlesi (küçük değişiklikler de kırar) · test sayısının büyüyen projede hiç artmaması · "testleri geçti" beyanının çıktısız gelmesi. Kontrol istemi: "build ve test komutlarını çalıştır; çıktıları KISALTMADAN göster; geçmeyenleri tablo yap."
7 · Mini egzersiz (SANDBOX)Üret: sandbox'ta bir dosyayı bilerek bozdurun ("build'i kıracak küçük bir hata ekle"). Denetle: build'i çalıştırıp hatanın nasıl göründüğünü okuyun; sonra düzelttirin ve kapının yeşile dönüşünü izleyin. Kırmızı-ekranla ilk tanışma güvenli ortamda olsun.
8 · Kontrol soruları(1) Kapı zinciri hangi sırayla dizilir? (2) Hızlı kontrol neden tam build'in yerini tutmaz? (3) Yayın komutunda okunması şart olan satır hangisidir?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.3'ün (build/test kapıları) hocası ol. Kapı kavramını havaalanı
güvenlik kontrolü metaforuyla anlat. Bana örnek bir build hata çıktısı göster ve
panik yapmadan nasıl okuyacağımı öğret. Sonunda 3 kontrol sorusu.
DERS 2.4 Hata ayıklama döngüsü: kök neden vs yama
KAZANIM Bu dersin sonunda: hata karşısında yama değil, anladığın bir kök neden çözümü yaptırabilirsin.
1 · TanımHata ayıklama = belirtiden (hata mesajı, yanlış davranış) kök nedene inip onu düzeltme süreci. Karşıtı: yama — belirtiyi örtüp nedeni yerinde bırakmak.
2 · İşlev ve amaçAI hızlı yama üretmekte ustadır; yönetilmezse "çalışana kadar dene" moduna girer ve her yama yeni bir hata doğurur (Seviye 1.6'daki kısır döngünün kaynağı). Sizin işiniz süreci kök-neden yönüne itmek.
3 · Nasıl yapılırDört adımlı döngü: (1) Belirtiyi eksiksiz ver: hata mesajını KIRPMADAN yapıştırın + "ne yapınca oluyor" tarifi. (2) Kök neden isteyin: "düzeltmeden önce kök nedeni bul ve bana teknik olmayan dille açıkla." (3) Açıklamayı anlayın: anlamadıysanız düzeltme onayı yok — "daha basit anlat" hakkınız sınırsız. (4) Düzeltme + doğrulama: hatayı yeniden tetikleyerek gerçekten gittiğini görün (ders 1.5 merdiveni).
4 · Ne ters gider + çözümüTuzak 1: "hata alıyorum, düzelt" (mesajsız) → AI körlemesine tahmin eder. Çözüm: mesaj + adım tarifi olmadan düzeltme istemeyin. Tuzak 2: hata gitti ama neden gittiğini kimse bilmiyor → aynı hata başka kılıkla döner. Çözüm: "ne bozuktu, ne değişti, niye bir daha olmaz?" üçlüsünü her düzeltmeden sonra sorun; ikna edici cevap yoksa iş bitmemiştir. Tuzak 3: üçüncü yama — ders 1.6 kuralı: oturumu tazeleyin.
5 · AlternatiflerFrontend/backend ayrımıyla ön-teşhis: hata ekranda mı (salon) veride/kayıtta mı (mutfak)? Bu tek soru bile aramayı yarıya indirir ve AI'a daha iyi başlangıç noktası verir.
6 · Denetim penceresiKırmızı bayraklar: açıklaması yapılamayan düzeltme ("bir şeyler değiştirdim, geçti") · düzeltmenin dokunduğu dosyaların hatayla görünür ilgisinin olmaması · aynı belirtinin farklı yerlerde tekrarlaması. İkinci-ajan denetimi (temiz oturum): "Şu hata şöyle düzeltilmiş: [özet]. Bu düzeltme kök neden mi yama mı? Aynı hatanın başka yoldan tekrar etme riskini değerlendir."
7 · Mini egzersiz (SANDBOX)Üret: "uygulamaya bulması orta zorlukta bir hata sakla" deyin (AI saklasın), sonra hatayı kullanıcı gibi bulun. Denetle: dört adımlı döngüyü tam uygulayın; 3. adımdaki açıklamayı bir arkadaşınıza anlatabilecek kadar anlayın.
8 · Kontrol soruları(1) Kök neden ile yama farkı nedir? (2) Hata bildirirken iki zorunlu bileşen nedir? (3) Düzeltme sonrası üçlü soru nedir?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.4'ün (hata ayıklama döngüsü) hocası ol. Kök neden/yama farkını
"su sızıntısı + kova" metaforuyla anlat. Bana örnek bir hata senaryosu yaşat: ben
kullanıcıyım, sen AI'sın; dört adımı doğru işletip işletmediğimi değerlendir. 3 kontrol sorusu.
DERS 2.5 Geri alınamaz komutlar: kırmızı bölge
KAZANIM Bu dersin sonunda: geri alınamaz işlemleri dört adımlı protokolle (yedek→prova→ekle→son adım sende) yönetirsin.
1 · TanımKırmızı bölge = git'in sigortasının İŞLEMEDİĞİ işlemler: canlı veritabanı müdahaleleri (migration, silme, sıfırlama), dosya sisteminde kalıcı silme, dış dünyaya giden geri çağrılamaz eylemler (e-posta, ödeme).
2 · İşlev ve amaçDers 1.7'de sınırların haritasını çizdiniz; burada en tehlikeli bölgenin çalışma protokolünü öğreniyorsunuz. Fark şu: kod hatası tarihçeden döner, veri hatası dönmez — çünkü veri, git'in değil veritabanının içindedir.
3 · Nasıl yapılır — kırmızı bölge protokolü(1) Önce yedek: "bu işlemden önce veritabanının yedeğini nasıl alırım, komutunu hazırla" — yedeğin ALINDIĞINI görmeden devam yok. (2) Önce prova: işlem önce deneme kopyasında (preview/dev veritabanı, Neon'da dal kopyası) çalıştırılır, sonuç kontrol edilir. (3) Ekleyerek ilerle: yapı değişikliklerinde "ekle" güvenli, "sil/değiştir" tehlikelidir — sütun silmek yerine önce yeni sütunu ekle, veriyi taşı, eskiyi ancak her şey doğrulanınca kaldır. (4) Son adım elle: canlıdaki nihai komutu AI değil siz tetiklersiniz — bilerek, okuyarak.
4 · Ne ters gider + gerçek vaka
Gerçek vaka: Ders 1.7'deki veri kaybı vakasının perde arkası: şema uyuşmazlığında araç "sıfırlayıp yeniden kurayım mı?" diye sordu, hızlı onay verildi, canlı tablolar boşaldı. Üç koruma da atlanmıştı: yedek yok, prova yok, son adım elde değil. Tek bir protokol adımı bile faciayı önlerdi.
Çözüm sistemik: bu protokolü projenizin CLAUDE.md'sine yazın: "Veritabanı yapısını değiştiren hiçbir komutu doğrudan çalıştırma; önce yedek + prova planı sun."
5 · Alternatifler"Hiç dokunmayalım" da yanlış: ürün büyüdükçe şema değişecek. Alternatif yol, korkmak değil ritüelleştirmektir — protokol varsa kırmızı bölge rutin işe döner.
6 · Denetim penceresiOnay öncesi dört soru (ders 1.7'deki istemin veritabanı versiyonu): "Bu işlem hangi tablolara dokunuyor? Geri alınabilir mi? Yedek nerede? Provası yapıldı mı?" Dördünden biri cevapsızsa onay yok. Kırmızı bayrak kelimeleri: force, reset, drop, truncate, delete from (koşulsuz).
7 · Mini egzersiz (SANDBOX)Üret: sandbox için "örnek bir veritabanı şema değişikliği senaryosu yaz: bir sütunun adını değiştireceğiz; güvenli ve tehlikeli yolu karşılaştır" isteyin. Denetle: AI'ın güvenli yolunda 4 protokol adımının hepsi var mı? Eksik olanı SİZ yakalayın.
8 · Kontrol soruları(1) Kod hatası ile veri hatası neden farklı ligdedir? (2) Kırmızı bölge protokolünün 4 adımı nedir? (3) "Ekleyerek ilerle" ne demektir?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.5'in (geri alınamaz komutlar) hocası ol. Kırmızı bölge
protokolünü bana bir ameliyat kontrol listesi ciddiyetiyle anlat. Sonra 5 komut örneği
göster; hangileri kırmızı bölge, tek tek karar vereyim. Sonunda 3 kontrol sorusu.
DERS 2.6 Env ve secret: şifrelerin evi
KAZANIM Bu dersin sonunda: anahtar ve şifreleri sızdırmayacak düzeni kurar, sızıntıda doğru sırayla müdahale edersin.
1 · TanımOrtam değişkeni = ortama göre değişen ayar; secret = şifre değerindeki ayarlar (API anahtarları, veritabanı bağlantısı). Evleri: yerelde .env dosyası (repoya GİRMEZ), canlıda barındırma panelinin ortam-değişkenleri bölümü.
2 · İşlev ve amaçTek cümlelik yasa: koda yazılan şifre, çalınmış şifredir. Repo bir gün paylaşılır, yedeklenir, sızar — içindeki anahtar da onunla gezer. Anahtarın kod dışında yaşaması, sızıntıyı yapısal olarak önler.
3 · Nasıl yapılır(1) Proje kurulurken .env'nin repo-dışı listede (.gitignore) olduğunu doğrulatın: "'.env' dosyası git'e girmiyor, doğru mu? Kanıtla." (2) Yeni bir hizmet bağlanırken (Resend, ödeme...) anahtarı .env'ye siz yapıştırın — sohbete yapıştırmak zorunda değilsiniz; "anahtarı .env'ye NE adla koyacağımı söyle, ben koyarım" deyin. (3) Canlıya çıkarken aynı değişkenleri barındırma paneline girin — "canlı için hangi ortam değişkenlerini panele girmem gerekiyor, liste çıkar" isteyin ve listeyi tek oturuşta girin.
4 · Ne ters gider + çözümüKaza 1: anahtar yanlışlıkla koda/repoya girdi. Çözüm: sadece silmek YETMEZ (tarihçede durur) — anahtarı hizmet panelinden iptal edip (rotate) yenisini alın; sonra dosyadan temizleyin. Kaza 2: "yerelde çalışıyor, canlıda çalışmıyor" — klasik sebep: değişken panele girilmemiş. Çözüm: canlı hata + "environment variable" kelimesini görünce önce panel kontrolü. Kaza 3: boş değer — panel arayüzü bazen değeri sessizce boş kaydeder; girdikten sonra kaydedilen değerin gerçekten dolu olduğunu panelden teyit edin.
5 · AlternatiflerTakım büyüyünce secret yöneticisi araçlar devreye girer; tek kişilik üründe .env + panel ikilisi yeterli ve standarttır.
6 · Denetim penceresiPeriyodik tarama istemi: "Bu repoda koda gömülü anahtar/şifre/bağlantı adresi var mı tara; şüpheli her bulguyu dosya adıyla listele." Kırmızı bayraklar: kod içinde sk-, key=, uzun rastgele karakter dizileri · .env'nin repoda görünmesi. Bu tarama, mezuniyet görevinizin de parçası.
7 · Mini egzersiz (KENDİ-PROJEN)Denetle (bu ders üretmeden denetler): mevcut bir projenizde 6. bölümdeki tarama istemini çalıştırın. Bulgu çıkarsa: anahtarı panelden yenileyin, dosyayı temizletin, .gitignore'u doğrulatın — üç adımı sırasıyla.
8 · Kontrol soruları(1) "Koda yazılan şifre çalınmış şifredir" — neden? (2) Repoya sızan anahtarda ilk hamle silmek midir, değilse nedir? (3) "Yerelde çalışıyor canlıda çalışmıyor"un klasik sebebi?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.6'nın (env/secret) hocası ol. Secret kavramını "ev anahtarını
paspasın altına yazmak" metaforuyla anlat. Bana bir sızıntı senaryosu ver; doğru
kurtarma sırasını kurayım, değerlendir. Sonunda 3 kontrol sorusu.
DERS 2.7 Mimari okuma ve denetleme: projenin haritası
KAZANIM Bu dersin sonunda: kod bilmeden bir projenin mimari sağlığını beş işaretle puanlayabilirsin.
1 · TanımMimari = projenin yapısal düzeni: klasörler (odalar), katmanlar (ekran ↔ iş mantığı ↔ veri) ve veri akışı (tesisat). Mimari okumak = kod okumadan bu düzeni görebilmek.
2 · İşlev ve amaçMezun profilinin 2. yetkinliği tam olarak budur: "yapı doğru kurulmuş mu?" sorusuna yönlendirme almadan cevap verebilmek. Bina sahibi tuğla örmez ama kat planına bakıp "banyo neden mutfağın içinde?" diyebilir. Kötü mimari bugün çalışır — faturası, her yeni özelliğin gitgide zorlaşması olarak sonra gelir.
3 · Nasıl yapılırHarita çıkarma istemi (her projede işe yarar):
Bu projenin mimari haritasını teknik olmayan dille çıkar:
1) Klasör ağacı (2 seviye) — her klasör tek cümleyle ne işe yarıyor?
2) Bir kullanıcı işlemi örneğinde veri akışı: ekrandan veritabanına hangi duraklardan geçiyor?
3) Projenin "tek doğru yeri" olan şeyler nerede: ayarlar, veritabanı şeması, ortak bileşenler?
Sonra sağlık kontrol listesi — kod bilmeden bakılabilen 5 işaret: (1) Benzer şeyler bir arada mı? (ekran dosyaları bir yerde, veri işleri bir yerde — yoksa her yerde her şey?) (2) Dev dosya var mı? ("en büyük 5 dosyayı satır sayısıyla listele" — bir dosya diğerlerinin 5-10 katıysa, her iş oraya yığılıyor demektir.) (3) Aynı bilgi iki yerde mi? (aynı kural/metin/ayar kopyala-yapıştırla çoğalmışsa: birini değiştirince öbürü unutulur.) (4) Şema okunaklı mı? (veritabanı şema dosyasını açın — tablo adları işinizin dilini konuşuyor mu?) (5) Yeni özellik nereye? ("yarın X özelliği eklesek hangi dosyalar değişirdi?" — cevap "her yerden biraz" ise mimari kokuyor.)
4 · Ne ters gider + çözümüVibe coding'in doğal sürüklenmesi: her istem "çalışan en kısa yolu" ekler; on istem sonra yapı spagettiye döner. Çözüm: periyodik mimari bakımı — ayda bir harita çıkarıp 5 işareti kontrol edin; sorun görünce "davranışı DEĞİŞTİRMEDEN şu ikilemeyi tekle / şu dev dosyayı böl" diye hedefli iş isteyin (buna refactor denir: dışarıdan aynı, içeriden düzenli).
5 · AlternatiflerKendi kontrolünüzün ölçekli hâli: çok-boyutlu denetim kampanyası (Seviye 4.5) — birden çok ajanın projeyi farklı gözlüklerle taraması. Bu ders o kampanyanın el fenerli versiyonudur.
6 · Denetim penceresiİkinci-ajan mimari denetimi (temiz oturumda): "Bu projenin mimarisini bağımsız denetle: 5 sağlık işaretine göre puan ver (her biri 1-5), en riskli 3 bulguyu 'sorun → günlük hayattaki bedeli → önerilen düzeltme' formatında yaz. Hiçbir şeyi değiştirme." — Puanlamayı sizin yerinize düşünmesin diye kendi puanınızı ÖNCE verin, sonra karşılaştırın.
7 · Mini egzersiz (KENDİ-PROJEN)Üret: en aktif projenizin haritasını çıkartın. Denetle: 5 işareti kendiniz puanlayın, sonra ikinci-ajan denetimiyle karşılaştırın. En az bir bulguyu "hedefli düzeltme işi" olarak tarif edin (yapmasanız bile tarif edin — tarif etmek, denetim yetkinliğinin kendisidir).
8 · Kontrol soruları(1) Kod bilmeden bakılabilen 5 sağlık işareti nedir? (2) "Yeni özellik nereye eklenirdi?" sorusu neyi ölçer? (3) Refactor nedir ve nesi değişmez?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.7'nin (mimari okuma) hocası ol. Mimarlık metaforuyla katman
kavramını anlat. Bana uydurma bir proje klasör ağacı göster: içine 3 mimari koku sakla,
5 işaret listesiyle bulmamı iste. Sonunda 3 kontrol sorusu.
DERS 2.8 Sessiz katil: veritabanı index'i ve bulut maliyeti
KAZANIM Bu dersin sonunda: hiçbir hata vermeden faturanı katlayan eksik-index patolojisini kendi ellerinle teşhis eder, kalıcı biçimde düzelttirir ve bulut faturanı "compute-saat" diliyle okursun.
1 · TanımIndex = veritabanı tablosunun arka sayfasındaki dizin. Kitap analojisi birebirdir: "Atatürk hangi sayfalarda geçiyor?" sorusuna dizinli kitap 5 saniyede cevap verir; dizinsiz kitapta 400 sayfayı tek tek çevirirsiniz. Veritabanı da aynı iki yolu bilir: index scan (dizinden bak, doğru satıra atla) ve seq scan (sequential: tabloyu baştan sona tara). İkisi de aynı DOĞRU cevabı verir — farkları hız ve emektir. Kritik nokta: tabloyu oluşturunca yalnız kimlik kolonuna (primary key) otomatik dizin gelir; "bu ürünün yorumları" gibi İLİŞKİ kolonlarına (product_id tarzı foreign key'ler) dizini SİZİN eklemeniz gerekir.
2 · İşlev ve amaç — ve fatura bağlantısıBulut veritabanısı size sabit kira kesmez; motor gücü × çalışma saati faturalar (Neon örneği: CU "compute unit" × aktif-saat; motor trafiğe göre min–max arasında kendini büyütür [autoscaling], hiç iş yokken uyur [scale-to-zero]). Araba analojisi: eksik index, motoru her soruda boşa TAM GAZA bastırmaktır — yol aynı yol, varış aynı varış, ama 8 silindirin hepsi yanar. Bu yüzden eksik FK index'i belirtisiz bir patolojidir: küçük veride ve düşük trafikte tarama zaten milisaniyedir, hiçbir şey hissedilmez; veri ve trafik büyüdükçe her sorgu sessizce ağırlaşır. Uygulama ÇÖKMEZ, hata VERMEZ, kullanıcı belki fark etmez bile — tek belirti ay sonu faturasıdır. En tehlikeli bozulma sınıfı budur: sessiz ve kademeli.
3 · Nasıl yapılırTeşhis → tedavi → kalıcılaştırma:
Teşhis — Postgres'in kendi sayaçlarını okutun (çoğu bulutta ek kurulum istemeyen tablo):
SELECT relname AS tablo, seq_scan, seq_tup_read, idx_scan, n_live_tup AS satir
FROM pg_stat_user_tables ORDER BY seq_tup_read DESC LIMIT 10;
Okuma kılavuzu: seq_scan = kaç kez baştan sona tarandı · seq_tup_read = bu taramalarda TOPLAM kaç satır okundu · idx_scan = kaç kez dizin kullanıldı. Kırmızı kombinasyon: seq_tup_read, tablonun satır sayısının binlerce katı + idx_scan ~0 → o tablo her soruda baştan okunuyor. (Sorgu-bazlı ayrıntı veren pg_stat_statements çoğu ortamda kapalıdır — bu tablo neredeyse her yerde açıktır, önce bunu okuyun.)
Tedavi — eksik dizini ekletin; SQL'de tek satırdır: CREATE INDEX idx_reviews_product ON reviews (product_id);
Kalıcılaştırma — asıl disiplin burası. Kod ORM'le yazılıyorsa dizin, şemanın parçası olmalı: TypeORM'de ilişki kolonunun üstüne @Index(), Prisma'da modele @@index([productId]). Sonra migration (2.5 kuralları: additive, önce migration sonra kod) ile veritabanına işletin. Elle CREATE INDEX çekip şemaya yazmamak, yarın temiz kurulumda dizinin YOK olması demektir.
4 · Ne ters gider + çözümü
⚠ GERÇEK VAKA (Ağustos 2026, iki üründe aynı anda): Aylık bulut-veritabanı faturası $31'den $141'e sıçradı — 4,5 kat, hiçbir çökme/hata olmadan. Teşhis: iki ayrı üründe (biri TypeORM, biri Prisma) ilişki kolonlarında index yoktu; her katalog sorgusu tabloyu baştan sona tarıyordu. Bilanço akıl almazdı: 68 bin satırlık bir tablodan, sayaçlara göre 42 MİLYAR satır okunmuş, 3 günde 149 GB veri taşınmıştı. Kök neden bir "ORM halleder" varsayımıydı: TypeORM'in
@ManyToOne/@JoinColumn'u da Prisma'nın ilişki tanımı da FK kolonuna OTOMATİK index KOYMAZ — ikisi de belgelenmiş, ikisi de klasik tuzak. Düzeltme iki koldan geldi: index'ler migration'la eklendi (asıl tedavi) + motorun CU tavanı 8'den 1'e çekildi (hasar sınırlayıcı). Tavan kısmak yakıt deposuna kilit vurmaktır — faturayı sınırlar ama gaza basılı pedalı düzeltmez; ikisi birlikte yapılır.
Diğer tuzaklar: index'i yalnız lokalde eklemek → migration'a girmeyen şema değişikliği prod'da YOKTUR (2.5'in "entity var ≠ tablo var" dersiyle aynı aile); körlemesine her kolona index → her dizin yazma işlemini yavaşlatır ve yer yer; kural "her FK'ya evet, gerisi ölçüme göre"; faturayı görüp paniğe kapılıp motoru kapatmak → semptomu susturur, kullanıcı deneyimini öldürür, patoloji durur.
5 · AlternatiflerSemptom yönetimi araçları vardır ama hiçbiri index'in yerine geçmez: CU/instans tavanını kısmak (fatura sigortası — vaka bunu da yaptı), sık sorulan cevabı önbelleğe almak (cache), okuma yükünü kopyaya dağıtmak (read replica — ileri seviye). Sıralama hep aynıdır: önce index (kök neden), sonra sigortalar. Bir de proaktif alternatif var: bazı ORM/linter araçları FK-index taraması yapar — ama en taşınabilir yol, bu dersin denetim istemini periyodik koşturmaktır.
6 · Denetim penceresiKırmızı bayraklar: bulut faturası açıklamasız ay-üstü-ay %50+ arttı · panelde compute-saat/veri-transferi grafiği trafikle orantısız · pg_stat_user_tables'da seq_tup_read/satır oranı binleri aşıyor · şemada FK kolonu var, index'i yok. İkinci-ajan denetim istemi (temiz oturumda):
Bu projenin veritabanı şemasını denetle: 1) Tüm ilişki (foreign key) kolonlarını listele.
2) Her biri için index var mı — VAR/YOK tablosu çıkar. 3) YOK olanlar için migration
planı öner ama HİÇBİR ŞEYİ değiştirme. 4) pg_stat_user_tables sorgusunu çalıştırıp
en çok seq_tup_read biriktiren 5 tabloyu yorumla.
Ve kalıcı alışkanlık: bulut panelinde harcama alarmı kurun (ör. "aylık $X aşılırsa e-posta"). Bu vakada tek belirti faturaydı — alarm, faturayı ay sonundan güne çeker.
7 · Mini egzersiz (KENDİ-PROJEN)Üret: yukarıdaki denetim istemini veritabanı kullanan bir projenizde koşturun; YOK çıkan bir FK için ORM şemasına index ekletin + migration'la işletin. Denetle: migration'dan önce ve sonra pg_stat sorgusunu çalıştırıp idx_scan sayacının artmaya başladığını kendi gözünüzle görün (sayaç artıyorsa dizin gerçekten kullanılıyordur — "ekledim" ile "kullanılıyor" aynı şey değildir).
8 · Kontrol soruları(1) Seq scan ile index scan farkı nedir ve neden ikisi de "doğru" cevap verir? (2) Eksik FK index'i neden küçük projede görünmez? (3) ORM ilişki tanımı index'i otomatik koyar mı — bu varsayım neye mal oldu? (4) CU tavanını kısmak neden tek başına çözüm değildir?
9 · Mentor istemi
AI Maestro Seviye 2 Ders 2.8'in (index ve bulut maliyeti) hocası ol. Kitap dizini ve
tam-gaz motor analojileriyle başla. Bana uydurma bir pg_stat_user_tables çıktısı göster:
içine bir sessiz-katil tablo sakla, kırmızı kombinasyonu bulmamı iste. Sonra faturayı
CU×saat diliyle hesaplat. Sonunda 4 kontrol sorusu.
Seviye 2 Mezuniyeti
Görev (KENDİ-PROJEN): Düşük riskli bir gerçek projenizde uçtan uca teslim: CLAUDE.md yazın (2.1) → küçük bir gerçek görevi branch'te yaptırın (2.2) → kapılardan geçirin (2.3) → çıkan bir hatayı kök-neden döngüsüyle çözdürün (2.4) → secret taraması koşturun (2.6) → mimari haritayı çıkarıp 5 işareti puanlayın (2.7) → veritabanı varsa FK-index denetimini koşturun (2.8) → merge + commit. Zincir tamamsa mezunsunuz.
Seviye-sonu mentor istemi (kümülatif):
AI Maestro Seviye 2'nin bitirme sınavını yap. Sekiz dersin kontrol sorularından karışık 8
soru sor; ayrıca Seviye 1'in kontrol sorularından rastgele 3 soru ekle (kümülatif
tekrar). Cevaplarımı değerlendir, zayıf derslerimi söyle.
Sonraki seviye: seviye-3-sistem.md — tekrarı otomatiğe bağlamak.