Orijinal Başlık: Karpathy'nin 4 CLAUDE.md Kuralı, Claude hatalarını %41'den %11'e düşürdü. 30 kod tabanı üzerinden işlem yaptıktan sonra 8 tane daha ekledim
Orijinal Yazar: @Mnilax
Çeviren: Peggy, BlockBeats

Editörün Notu: 2026 Ocak ayında, Andrej Karpathy'nin Claude'a yönelik kod yazma eleştirisi, görünüşte küçük ancak AI programlama çalışma akışında son derece kritik olan bir dosyayı ortaya çıkardı: CLAUDE.md. Forrest Chang daha sonra bu sorunları 4 davranış kuralına dönüştürdü, Claude'ı kodlarken sıkça yapılan hataları sınırlamayı amaçladı: Sessiz varsayımlar, aşırı mühendislik, ilgisiz kod üzerinde değişiklik yapma ve net başarı standartlarının eksikliği.

Ancak birkaç ay sonra, Claude Kodunun kullanım senaryosu artık sadece "bir modelin bir kod parçasını yazmasını" içermiyordu. Çok adımlı Ajanlar, tetikleyici zinciri, beceri yükleme ve çoklu kod havuzlarında işbirliği normal hale geldikçe, yeni başarısızlık modelleri de ortaya çıkmaya başladı: Modelin uzun görevler sırasında kontrolünü kaybetmesi, testlerin geçmesine rağmen gerçek mantığı doğrulamaması, taşınmanın tamamlanmasına rağmen sessizce hata atlaması, farklı kod stillerinin yanlışlıkla karıştırılması.

Yazar bu makalede, 30 kod tabanı üzerinde 6 hafta boyunca test yaptı ve Karpathy'nin orijinal 4 kuralına ek olarak 8 yeni kural ekledi, AI programlamada tek seferlik tamamlamadan Ajan tabanlı işbirliğe geçiş sonrası ortaya çıkan yeni sorunları ele almaya çalıştı.

Aşağıda orijinal metin yer almaktadır:

2026 Ocak sonlarında, Andrej Karpathy, Claude'ın kod yazma şekline dair bir dizi tweet attı. Üç tipik sorunu belirtti: açıklama olmadan yanlış varsayımlarda bulunmak, aşırı karmaşıklaştırma ve aslında değiştirilmemesi gereken kodlara gereksiz müdahalede bulunmak.

Forrest Chang bu tweet dizisini görünce, şikayetleri 4 davranış kuralına dönüştürdü, bunları ayrı bir CLAUDE.md dosyasına yazdı ve GitHub'da yayınladı. Bu proje, lansmanın ilk gününde 5,828 yıldıza ulaştı, iki hafta içinde 60,000 kez "favori"ye alındı ve şu anda 120,000 yıldıza sahip olarak 2026'nın en hızlı büyüyen tek dosyalı kod deposu haline geldi.

Daha sonra, ben de 6 hafta boyunca 30 farklı kod tabanında bu kural setini test ettim.

Bu 4 kural gerçekten etkiliydi. Bu kurallara uygun görevlerde, yaklaşık %40'lık bir hata olasılığı, %3'ün altına düştü. Ancak sorun şuydu ki, bu şablon aslen 1 Ocak'ta Claude'ün kod yazarken karşılaştığı hataları gidermek için oluşturulmuştu.

2026 Mayıs ayına gelindiğinde, Claude Code ekosistemiyle karşılaşılan sorunlar artık farklıydı: Ajanlar arasındaki çatışmalar, hook zincirli tetiklemeler, beceri yüklemesi çatışmaları ve oturumlar arası çok adımlı iş akışları kesintileri gibi.

Bu nedenle, 8 ek kural daha ekledim. İşte tam 12 kural CLAUDE.md versiyonu: Her birinin neden eklendiği ve orijinal Karpathy şablonunda hangi 4 noktada sessizce başarısız olduğu.

Açıklamaları atlayıp doğrudan kopyalamak isterseniz, tam dosya metni makalenin sonundadır.

Neden Bu Önemli

Claude Code'un CLAUDE.md dosyası, tüm yapay zeka programlama yığınının en az anlaşılan belgesidir. Çoğu geliştirici genellikle üç tür hata yapar:

İlk olarak, tercih çöp kutusu gibi davranır, tüm alışkanlıklarını içine döker ve sonunda 4000'den fazla token ile şişer, kural uyum oranı %30'a düşer.

İkinci olarak, hiç kullanmazlar, her seferinde yeniden başlatır. Bu, 5 kat daha fazla token israfına ve oturumlar arasında tutarsızlığa neden olur.

Üçüncüsü, bir şablonun kopyasını alır ve sonra asla ilgilenmez. Belki iki hafta etkili olabilir, ancak kod tabanı değiştikçe, hatalı hale gelir.

Anthropic'in resmi belgeleri açıkça belirtmiştir: CLAUDE.md temelde sadece tavsiyedir. Claude genellikle %80 zamanında uyar. 200 satırı aştığında, uyum oranı belirgin şekilde düşer, çünkü önemli kurallar gürültüye karışır.

Karpathy'nin şablonu bu sorunu çözdü: Bir dosya, 65 satır, 4 kural. Bu en düşük standarttır.

Ancak üst sınır daha da yüksek olabilir. Aşağıdaki ek 8 kuralı ekledikten sonra, kapsadığı sadece 2026 Ocak ayında Karpathy'nin şikayet ettiği kod yazma sorunları değil, aynı zamanda 2026 Mayıs ayında ortaya çıkan Ajan Sıralama sorunları da bulunmaktadır—bu sorunlar orijinal şablon oluşturulurken mevcut değildi.

Orijinal 4 Kural

Eğer daha önce Forrest Chang'in deposunu görmediyseniz, önce bu temel versiyona bakın:

Kural 1: Kodlamadan önce düşünün.

Sessizce varsayım yapmayın. Varsayımlarınızı açıklayın, denge noktalarını ortaya koyun. Tahmin yürütmek yerine sormaya başvurun. Daha basit bir çözüm mevcutken itirazı öne sürün.

Kural 2: Basitlik önceliği.
Problemı çözebilen en az kodu kullanın. Hayali özellikler eklemeyin. Tek seferlik bir kod için soyutlama katmanı oluşturmayın. Eğer deneyimli bir mühendis bunun fazla karmaşık olduğunu düşünecekse, basitleştirmelisiniz.

Kural 3: Cerrahi müdahale şeklinde düzenleme.
Değiştirmeniz gereken yeri sadece değiştirin. Bitişik kod, açıklamalar veya biçimlendirmeyi yanlışlıkla "optimize" etmeyin. Bozuk olmayan bir şeyi tekrardan yapılandırmayın. Mevcut tarzla uyumlu olun.

Kural 4: Hedefe odaklı yürütme.
Önce başarı kriterini tanımlayın, ardından döngüsel olarak teyit edene kadar iyileştirmeler yapın. Claude'a her adımı söylemeyin, ona nasıl yapıldığını değil başarılı sonucun nasıl olması gerektiğini söyleyin ve kendi kendine yinelemesine izin verin.

Bu 4 kural, Gözetimsiz Claude Code oturumlarında gördüğüm yaklaşık %40'lık başarısızlık modelini ele alabilir. Geriye kalan %60'lık sorunlar ise aşağıdaki boşluklarda saklıdır.

Eklediğim 8 Kural ve Nedenleri

Her kural, gerçek bir anıdan geliyor: Karpathy'nin orijinal 4 kuralı artık yeterli değildi. Şimdi o senaryoyu anlatacağım ve ardından ilgili kuralı vereceğim.

Kural 5: Modeli Doğal Dil Olmayan İşler İçin Kullanma

Claude ile yapılabilir: Sınıflandırma, taslak oluşturma, özetleme, yapılandırılmamış metinden bilgi çıkarma. Claude ile yapmayın: Yönlendirme, yeniden deneme, durum kodu işleme, belirlenmiş dönüşümler. Bir durum kodu zaten soruyu yanıtladıysa, o soruyu normal kodun yanıtlamasına izin verin.

Karpathy'nin kuralları bunu kapsamıyordu. Sonuç olarak model, belirli bir durumda yapılması gereken işleri kararlaştırmaya başladı: Bir API çağrısını yeniden denemeli mi, bir iletiyi nasıl yönlendirmeli, işlemenin ne zaman yükseltilmesi gerekti. Sonuç olarak, haftalık kararlar tutarlı değildi. Aldığınız şey, her token başına 0.003 dolar ücretlendirilen, istikrarsız bir if-else idi.

O an şöyleydi: Belirli bir kod parçası, Claude'ı çağırmak için kullanıldı ve "503 hatasıyla karşılaşıldığında yeniden denemeli mi?" kararını veriyordu. Başlangıçta iyi çalışıyordu, iki hafta boyunca devam etti, sonra aniden istikrarsızlaştı çünkü model şimdi isteği de bir karar bağlamı olarak algılamaya başladı. Yeniden deneme stratejisi rastgele hale geldi çünkü uyarlamak kendisi zaten rastgeleydi.

Kural 6: Katı Token Bütçesi Belirleyin, İstisna Yok

Tekil görev bütçesi: 4,000 token. Tek oturum bütçesi: 30,000 token. Bir görev bütçesi sınırına yaklaşıldığında, mevcut durumu özetleyin ve yeniden başlatın. Zorlamayı bırakın. Bütçe aşımını açıkça ortaya koyun, sessizce aşım yapmaktan daha iyidir.

Bütçe kısıtlaması olmayan CLAUDE.md, boş bir çek gibi. Her döngü kontrol dışına çıkabilir, 50,000 token'lık bir bağlam boşaltımına dönüşebilir. Model kendi kendine durmaz.

Şu anki durum şöyleydi: Bir hata ayıklama oturumu 90 dakika sürdü. Model sürekli olarak aynı 8KB'lık hata mesajı etrafında dönüp durarak ve daha önce denediği düzeltmeleri unutarak aşamalı olarak ilerledi. Sonunda, daha önce reddettiğim 40 fikri önermeye başladı. Token bütçesi olsaydı, bu süreç 12. dakikada sona erdirilmeliydi.

Kural 7: Çatışmayı Açığa Çıkarın, Ortalamaya Yanaşmayın

Eğer kod tabanındaki mevcut iki desen birbirini çeliyorsa, onları karıştırmayın. Bir deseni seçin, daha güncel veya daha fazla test edilmiş deseni tercih edin, nedeninizi belirtin ve diğer deseni temizlenmesi gereken bir işaretleyin. İki kural setini aynı anda karşılamaya çalışan 'ortalama kod', en kötü koddur.

Kod tabanındaki iki bölüm birbirine zıt olduğunda, Claude her iki tarafı da memnun etmeye çalışır, sonuç olarak yazılan tutarsız bir kod ortaya çıkar.

Şu anki durum şöyleydi: Bir kod tabanında iki farklı hata işleme deseni vardı, biri async/await ile açık try/catch, diğeri ise global hata sınırları. Claude tarafından yazılan yeni kod her ikisini de kullandı. Sonuç olarak hata işlemi iki kez yapıldı. Hatanın neden iki kez yutulduğunu anlamam 30 dakikamı aldı.

Kural 8: Önce Oku, Sonra Yaz

Bir dosyaya kod eklemeye başlamadan önce, bu dosyanın dışa aktarılan içeriğini, doğrudan çağırılanları ve belirgin bir şekilde ilgili paylaşılan yardımcı işlevleri okuyun. Var olan kodun neden bu şekilde düzenlendiğini anlamıyorsanız, önce sorun, doğrudan katkıda bulunmayın. "Bunun ilgili olmadığını düşünüyorum" cümlesi, bu kod tabanındaki en tehlikeli ifadedir.

Karpathy'nin "Cerrahi Müdahale Tarzı Değişiklik" yaklaşımı, Claude'e bitişik kodu değiştirmemesini söyledi. Ancak Claude'e bitişik kodu anlamadan önce değiştirmemesini söylemedi. Bu kural olmadan, Claude mevcut kodun 30 satır ötesiyle çakışan yeni kod yazabilir.

O an şöyleydi: Claude, mevcut bir işlevin yanına, işlevi okumadan tamamen aynı işlevselliğe sahip yeni bir işlev ekledi. İki işlev aynı şeyi yapıyor. Ancak, import sırasıyla ilgili olarak, yeni işlev eski işleve üstünden yazdı ve eski işlev zaten 6 aydır fiili olarak tek standart olarak varlığını sürdürüyordu.

Kural 9: Test Opsiyonel Değildir, Ancak Test Kendisi Hedef Değildir

Her bir test, "bu davranış neden önemlidir" şeklinde kodlanmalıdır, yalnızca "ne yaptığı" şeklinde değil. `expect(getUserName()).toBe('John')` gibi bir test, aslında sabit bir kimliği alması gereken bir işlev için değer taşımaz. İş mantığı değiştiğinde başarısız olacak bir test yazamıyorsanız, o zaman işleviniz yanlış demektir.

Karpathy'nin "Hedefe Odaklı Yürütme"si, testin başarı ölçütü olarak kullanılabileceğini ima eder. Ancak uygulamada, Claude, "testi geçmek"i tek amaç olarak görecek ve yüzeysel testleri geçen ama diğer şeyleri bozan kodlar yazar.

O an şöyleydi: Claude, kimlik doğrulama işlevi için 12 test yazdı, hepsi geçti. Ancak canlı ortamdaki kimlik doğrulama mantığı bozulmuştu. Bu testler, yalnızca işlevin "bir şey döndürüp dönmediğini" doğrulayan testlerdi, gerçekten doğru bir şey döndürüp döndürmediğini doğrulamıyorlardı. İşlev testleri geçebildi, çünkü dönüş değeri bir sabitti.

Kural 10: Uzun Süreli İşlemler İçin Kontrol Noktası Gerekli

Çok adımlı bir görevde, her adımı tamamladıktan sonra neler yapıldığını, neyin doğrulandığını ve geriye ne kaldığını özetleyin. Kendinize açıklayamayacağınız bir durumdan devam etmeyin. Kendinizi kaybettiğinizi fark ederseniz, durun, mevcut durumu yeniden ifade edin.

Karpathy'nin şablonu varsayılan olarak bir kezlik etkileşime dayanır. Ancak gerçek Claude Code çalışması genellikle çok adımlıdır: 20 dosya arasında yeniden yapılandırma, bir oturumda özellik geliştirme, birden fazla taahhüt üzerinde hata ayıklama. Kontrol noktaları olmadan, bir adım yanlış gitse, gerideki tüm ilerleme kaybedilebilir.

O an şöyleydi: Bir 6 adımlı yeniden yapılandırma görevinin 4. adımında hata oldu. Fark ettiğimde, Claude zaten yanlış durum üzerinde 5. ve 6. adımları tamamlamıştı. Hatanın giderilmesi ve geri alınması, tüm görevi tekrar yapmaktan daha uzun sürdü. Kontrol noktaları olsaydı, sorun 4. adımda keşfedilebilirdi.

Kural 11: Anlaşma Yenilikten Daha Önemlidir

Eğer kod deposu snake_case kullanıyorsa ama siz camelCase'i tercih ediyorsanız: snake_case'i kullanın. Eğer kod deposu class-tabanlı bileşenler kullanıyorsa ama siz hook'ları tercih ediyorsanız: class-tabanlı bileşenleri kullanın. Farklı görüşler ayrı bir tartışma konusudur. Kod deposu içinde, tutarlılık bireysel tercihlere göre önceliklidir. Eğer belirli bir anlaşmanın zararlı olduğunu gerçekten düşünüyorsanız, açıkça belirtin. Görünmeyen bir çatal yolunu sessizce açmayın.

Olgun bir deseni olan bir kod deposunda, Claude kendi yazımını tanıtmayı sever. Yazımı "daha iyi" olmasına rağmen, ek bir desen tanıtmak, herhangi bir tekil desenden daha kötüdür.

Şu anki durum şöyleydi: Claude, bir class bileşen tabanlı React kod deposuna hook'ları tanıttı. Bu çalıştı. Ancak aynı zamanda, o testlerin componentDidMount'e bağımlı olduğu kod deposunun mevcut test desenlerini bozdu. Sonunda, bunu silip yeniden yazmak için yarım gün harcadı.

Kural 12: Açıkça Başarısız Ol, Sessizce Başarısızlık Gösterme

Eğer bir şeyin başarılı olduğundan emin değilseniz, bunu açıkça belirtin. Eğer 30 kayıt sessizce atlandıysa, "göç tamamlandı" diyemezsiniz. Eğer herhangi bir testi atladıysanız, "testler geçti" diyemezsiniz. Eğer istediğim sınırların durumunu doğrulamadıysanız, "işlev kullanılabilir" diyemezsiniz. Belirsizliği varsayılan olarak açığa çıkarın, gizlemeyin.

Claude'ün en pahalı hataları genellikle başarılı gibi görünen hatalardır. Bir işlev "çalışabilir", ancak yanlış veri döndürür; bir göç işlemi "tamamlandı", ancak 30 kayıt atlandı; bir test "geçti", ancak bu yalnızca doğrulamanın yanlış olmasından kaynaklanır.

Şu anki durum şöyleydi: Claude bir veritabanı göç işleminin "başarılı bir şekilde tamamlandığını" söyledi. Ancak aslında, %14'lük yüzdeye denk gelen tetikleme kısıtlaması çakışması olan 30 kaydı sessizce atlattı. Atlama işlemi günlüğe kaydedildi, ancak açıkça sergilenmedi. 11 gün sonra, rapor verilerinde anormallikler görülmeye başlandığında sorunu fark ettik.

Veri Sonuçları

Aynı 50 temsilci görev grubunu 6 haftalık bir süre içinde takip ettim, 30 kod deposunu kapsayan ve üç farklı yapılandırmayı test eden.

Hata Oranı, bir görevin orijinal niyetle eşleşmesi için düzeltilmesi veya yeniden yazılması gereken durumları ifade eder. Dahil edilen hatalar şunları içerir: Sessiz Hata Varsayımı, Aşırı Mühendislik, İlgisiz Bozulma, Sessiz Başarısızlık, Sözleşme İhlali, Çatışma Teslimi, Kontrol Noktası Atlanması.

Uyum Oranı, bir kuralın uygulanması gerektiğinde Claude'un bu kuralı ne kadar açık bir şekilde uygulayacağını ifade eder.

Gerçekten ilginç olan sonuç, hata oranının %41'den %3'e düşmesi değil. Daha da önemlisi, 4 kuraldan 12 kurala genişlerken, neredeyse uyma yükünü artırmadan, uyum oranının sadece %78'den %76'ya düştüğü; ancak hata oranının 8 puan düştüğüdür. Yeni kuralar, önceki 4 kuralın ele almadığı başarısızlık kalıplarını kapsar ve bunlar aynı dikkat bütçesini talep etmez.

Karpathy Şablonunun Gizlice Başarısız Olduğu Noktalar

Yeni kurallar eklenmese bile, orijinal 4 kural şablonunun en az 4 noktada yetersiz olduğu görülmüştür.

Birinci, Uzun Süreli Çalışan Agent Görevi.
Karpathy'nin kuralları genellikle Claude'un kod yazdığı anda odaklanır. Ancak Claude bir çok adımlı iş akışını çalıştırdığında ne olur? Orijinal şablon, kural bütçesi, kontrol noktası kuralı ve "Yüksek Sesle Başarısız" kuralı olmadan bırakılabilir. Bu durumda iş akışı yavaş yavaş kayar.

İkinci, Çoklu Kod Deposu Uyumu.
"Mevcut stile uyum sağla" varsayılan olarak sadece bir stile işaret eder. Ancak 12 hizmet içeren bir monorepo'da, Claude hangi stile uyum sağlaması gerektiğine karar vermelidir. Orijinal kurallar ona nasıl seçim yapılacağını söylemez. Sonuç olarak, ya rastgele seçer ya da çeşitli stilleri eşit şekilde karıştırır.

Üçüncü, Test Kalitesi.
"Hedefe Odaklı Yürütme", "Test Başarılı" olarak görüldüğünde başarılı olarak kabul edilir, ancak testin kendisinin anlamlı olması gerektiği belirtilmez. Sonuç olarak, Claude anlamadan neredeyse hiçbir şeyi doğrulamayan bazı testler yazar, ancak bu testlerin kendisine oldukça emin olduğuna inanır.

Dördüncü, Üretim ve Prototip Aşaması Arasındaki Farklar.
Aynı 4 kural, üretim kodunun aşırı mühendislikten korunmasını sağlayabilir, ancak prototip gelişimini yavaşlatabilir. Çünkü prototip aşamasında bazen yönlendirmeyi anlamak için ilk etapta 100 satır keşif amaçlı bir şablon gerekebilir. Karpathy'nin "Basit Önce" kuralı erken aşamadaki koda aşırı müdahaleyi tetikleyebilir.

Bu 8 yeni kural, Karpathy'nin orijinal 4 kuralını değiştirmek için değil, onların boşluklarını tamir etmek içindir: Orijinal şablon, 2026 Ocak'ındaki otomatik tamamlama yöntemi odaklı kod yazma senaryosuna karşılık gelir; ancak 2026 Mayıs'ına gelindiğinde, Claude Code, Agent tarafından yönlendirilen, çok adımlı, çoklu kod havuzlu iş birliği ortamına geçiş yapmıştır ve bu iki senaryo karşı karşıya kaldığı sorunlar farklıdır.

Hangi Yöntemler İşe Yaramadı

12 kuralı kesinleştirmeden önce, bazı diğer çözümleri de denedim.

Reddit / X'de gördüğüm kurallara katılma.
Bunların çoğu, ya sadece Karpathy'nin orijinal 4 kuralını farklı ifadelerle tekrarlayanlar ya da genelleştirilemeyen alan özgü kurallardı, örneğin "Her zaman Tailwind sınıfı kullanın". Hepsi eninde sonunda çıkarıldı.

12 kuraldan fazlası.
En fazla 18 kurala kadar test ettim. 14'ten fazla kuraldan sonra, uyum oranı %76'dan %52'ye düştü. 200 satır sınırı gerçekten var. Bu uzunluğu aştıktan sonra, Claude gerçekten her kuralı okumak yerine "burada bir kural var" desen eşleştirmeye başlar.

Belirli araçlara bağımlı olan kurallar.
Örneğin, "Her zaman eslint kullan" ifadesi, projede eslint yüklü değilse bu kural geçersiz hale gelir ve sessizce geçersiz hale gelir. Sonradan bunu, örneğin "Projedeki zaten zorunlu kılınmış stile uyun" şeklinde, belirli bir araca bağımlı olmayan bir ifadeyle değiştirdim.

KLAVYE.md'de örneklerin değil kuralların bulunması.
Örnekler, kurallardan çok daha fazla bağlam tüketir. Üç örneğin tükettiği bağlam, yaklaşık olarak 10 kurala eşdeğerdir ve Claude örnekleri aşırı uyum sağlama eğilimindedir. Kurallar soyuttur, örnekler ise belirlidir. Bu nedenle, kuralların kullanılması gerekmektedir.

"Dikkatli olun", "Düşünceli olun", "Biraz odaklanın".
Bunlar hep gürültüdür. Bu tür talimatların uyumluluk oranı yaklaşık %30'a düşer çünkü bunlar denetlenebilir değildir. Sonradan bunları, "Varsayımları açıkça belirtin" gibi daha belirli kural niteliğinde ifadelerle değiştirdim.

Claude'a "Kıdemli Mühendis" gibi davranmasını söylemek.
Bu işe yaramadı. Claude zaten kendisini kıdemli mühendis gibi hissediyordu. Gerçek sorun, bunun ne düşündüğü değil, ne yaptığıyla ilgilidir. Kural niteliğinde ifadeler bu farkı azaltabilirken, kimlik ipuçları bunu yapamaz.

Tam 12 Kural Versiyonu CLAUDE.md

Doğrudan kopyalayarak kullanabileceğiniz tam sürüm aşağıda yer almaktadır.

Bu içeriği şu anda Lark belgesi dışında gösteremiyoruz

Bu içeriği, depo kök dizininize CLAUDE.md olarak kaydedin. Bu 12 kuralın altına, proje özel kurallarınızı ekleyin, örneğin teknoloji yığını, test komutları, hata modelleri vb. Genel uzunluğu 200 satırı geçmemeye dikkat edin. Bu sınırı aştıktan sonra, kural uyum oranı belirgin şekilde düşecektir.

Nasıl Kurulur

İki adımda yapabilirsiniz:

1. Karpathy'nin 4 Temel Kuralını CLAUDE.md dosyanıza ekleyin
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Bu belgedeki 5–12 arasındaki kuralları aşağıdaki gibi yapıştırın

Dosyayı depo kök dizinine kaydedin. Buradaki >> önemlidir, mevcut CLAUDE.md dosyasına eklenmesine olanak tanır, zaten yazdığınız proje özel kurallarınızı üzerine yazmaz.

Zihin Modeli

CLAUDE.md bir dilek listesi değil, gözlemlediğiniz belirli başarısızlık kalıplarını engellemek için bir eylem sözleşmesidir.

Her kural bir soruyu cevaplamalıdır: Hangi hatayı önler?

Karpathy'nin 4 kuralı, 2026 yılının Ocak ayında gözlemlediği başarısızlık modellerini önler: Sessiz Varsayım, Aşırı Mühendislik, İlgisiz Yıkım, Zayıf Başarı Standartları. Bunlar temeldir, atlanmamalıdır.

Benim eklediğim 8 kural, 2026 yılının Mayıs ayından sonra ortaya çıkan yeni başarısızlık modellerini engeller: Bütçe Kısıtı Olmayan Ajan Döngüsü, Adım Adım İşlemde Kontrol Noktası Olmaması, Anahtar Mantığı Test Etmek Gibi Görünüp Aslında Test Edilmeyen Testler ve Sessiz Başarısızlığı Sessiz Başarı gibi gösteren sorun. Bunlar artımlı yamalardır.

Elbette, etkileri kişiden kişiye değişir. Eğer çok adımlı bir iş akışı çalıştırmıyorsanız, Kural 10 sizin için o kadar önemli değildir. Kod tabanınızın zaten tek bir tutarlılık stiline sahip olduğu ve zaten lint tarafından zorunlu hale getirildiği durumda, Kural 11 gereksizdir. Bu 12 kuralı okuduktan sonra, asıl yaptığınız hatalara gerçekten uygun olan kuralları saklayın, geri kalanı silin.

Gerçek başarısızlık kalıplarına özgü olarak özel olarak tasarlanmış 6 kural içeren bir CLAUDE.md, her zaman kullanmadığınız 12 kural içeren bir sürümden daha iyidir.

Sonuç

Karpathy'nin 2026 yılı Ocak ayındaki o tweet'i aslında bir şikayetin ötesindeydi. Forrest Chang bunu 4 kurala dönüştürdü. Sonunda, 120.000 geliştirici bu sonuca yıldız verdi. Ve çoğu insan hala bugün sadece o 4 kuralı kullanıyor.

Model artık ilerledi, ekosistem değişti. Çok adımlı ajanlar, kancalarla zincirleme tetikleme, beceri yükleme, çoklu kod havuzu işbirliği — bunlar Karpathy'in o tweet'i attığı zaman henüz mevcut değildi. Orijinal 4 kural bu sorunları çözmedi. Yanlış değillerdi, sadece eksiktiler.

8 yeni kural ekleyin. 6 hafta süre, 30 kod havuzunu kapsayan testler. Hata oranı %41'den %3'e düştü.

Bu makaleyi bu akşam favorilere ekleyin ve bu 12 kuralı CLAUDE.md dosyanıza yapıştırın. Eğer size bir Claude serüveninden bir hafta tasarruf ettirecekse, lütfen paylaşın.

[Orijinal Tweet Linki]

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia