Big ball of mud (büyük çamur topu), uzun ömür için tasarlanmamış, kısa vadede çalışsın diye üst üste eklenerek büyümüş bir sistemdir. Nielsen Norman Group’un 2 Ekim 2026 tarihli araştırmasına göre yapay zeka inşa etmeyi neredeyse bedava hale getirdiği için, AI ajanlarıyla kurulan kişisel sistemler hızla bu çamur topuna dönüşüyor (NN/g).
Sorun sistemin çalışmaması değil. Tersine, şaşırtıcı derecede iyi çalışıyor — ta ki biriken karmaşa, ne neyi yapıyor sorusunu yalnızca yapay zekanın cevaplayabildiği noktaya gelene kadar. Bu yazıda NN/g’nin tarif ettiği beş örüntüyü, “yeniden kurmalı mıyım?” sorusunun tek soruluk testini ve bağlam dosyalarınızı çamurdan korumanın pratik adımlarını bulacaksınız.
Big ball of mud nedir, terim nereden geliyor?
Terim yazılım mühendisliğinden geliyor. Brian Foote ve Joseph Yoder, “Big Ball of Mud” makalesini Eylül 1997’de Illinois’teki dördüncü Pattern Languages of Programs (PLoP ’97) konferansında sundu; metin daha sonra 2000’de Pattern Languages of Program Design 4 kitabının 29. bölümü oldu (Foote ve Yoder, laputan.org).
Yazarların tespiti basitti: herkes şık mimari kalıplardan söz ederken, sahada fiilen en yaygın mimari kimsenin konuşmadığı bu dağınık yapıydı. Düzeni tasarımdan çok o günün aciliyeti belirliyordu.
NN/g’den Tanner Kohler, bu 29 yıllık kavramı bugünün AI ajan sistemlerine taşıyor ve tanımı şöyle veriyor: büyük çamur topu, “uzun vadeli dayanıklılık için tasarlanmamış, kısa vadeli işlevsellik için bir araya getirilmiş bir sistemdir” (NN/g).
Yapay zeka çamuru neden geri getirdi?
NN/g’nin açıklaması kıtlık ile bolluk arasındaki fark. Yazılımın ilk döneminde zaman, para ve uzmanlık kıttı; bu kıtlık insanları önceden düşünmeye, öncelik sırasına koymaya zorluyordu. Kodla-düzelt (code-and-fix) döneminin dağınıklığı planlı şelale (waterfall) modelini, o da Agile’ı doğurdu.
Bu bolluk özellikle teknik altyapısı olmayan kullanıcıları etkiliyor. NN/g bunlara vibe architect diyor: kodlama bilmeden, büyük bağlam kütüphanelerine dayanan karmaşık ajan sistemleri kuran kişiler. “Vibe coding” tartışmasının kod kalitesi tarafını daha önce Ilya Birman’ın görüşü üzerinden ele almıştık; NN/g’nin derdi ise kodun değil, sistemin bütününün anlaşılmaz hale gelmesi.
Vibe architect kimdir?
Terim NN/g’nin 19 Haziran 2026 tarihli ayrı bir çalışmasından geliyor. Kate Moran ve Sarah Gibbons, Claude Cowork ve Claude Code gibi açık uçlu ajan araçlarını kullanan 7 teknik olmayan katılımcıyla görüştü; aralarında bir operasyon uzmanı, bir finans kurumunda ürün tasarımcısı, bir girişim kurucusu ve bir ürün yöneticisi vardı (NN/g, Vibe Architects).
- Sezgiyle inşa: Katılımcılar özenli prompt yazmak yerine gevşek, bilinç akışı gibi talimatlar verip kararların çoğunu yapay zekaya bıraktı.
- Az denetim: Bir katılımcı izin isteklerini okumadan onaylıyordu.
- Opaklık: İleri düzey kullanıcılar bile sistemlerinin nasıl çalıştığını çoğu zaman açıklayamadı; biri, ayrıntısını onayladığını hatırlamadığı, AI’ın yazdığı bir yönetişim dosyası buldu.
- Çürüme: Bağlantıların süresi doldukça ve bağlam güncelliğini yitirdikçe sistemler zamanla bozuldu.
Büyük çamur topu makalesi, bu gözlemlerin bir adım ötesine geçiyor: çürümenin hangi sırayla ve hangi biçimlerde ortaya çıktığını adlandırıyor.
NN/g’nin 5 çamur topu örüntüsü
Örüntülerin adları doğrudan Foote ve Yoder’in 1997 makalesinden alınmış. NN/g bunların katı aşamalar olmadığını, ama kabaca bu sırayla ortaya çıkma eğiliminde olduğunu belirtiyor.
1. Atılacak kod (Throwaway Code)
Hızlı bir kavram kanıtı — örneğin bir rules.md dosyası — planlanmadan ve test edilmeden yazılır, ama zamanla iş akışları ona bağlanır. NN/g’nin bir katılımcısı e-postaları, görevleri ve toplantı notlarını özetleyen günlük bir otomasyon kurmuştu ve bir daha hiç dönüp bakmadığı yapıya mahkum hissediyordu.
2. Parça parça büyüme (Piecemeal Growth)
Yeni özellikler mevcut sisteme eklemlenir. Programcı olmayan bir katılımcının Asana için yaptığı küçük bir widget üç aşamada görselleştirme, tahmin algoritmaları ve zaman takibi içeren departmanlar arası bir panoya dönüştü. Bazı katılımcılar sistemlerinin dayandığı dosyaların yerini artık bulamıyordu.
3. Çalışır tut (Keep It Working)
Bozulan ya da bayatlayan sistem, insanlar ona güvendiği için terk edilmez, yamalanır. Bir katılımcı uygulama çöktükten sonra her oturuma İndirilenler klasöründen yeniden başlıyordu. NN/g’ye göre AI düzeltmenin maliyetini düşürürken kullanıcıyı bilgiyi bulma ve güncelleme işinde yapay zekaya bağımlı hale getiriyor.
4. Halının altına süpürmek (Sweeping It Under the Rug)
Dağınık malzeme tek bir “her şey” klasörüne doldurulur: to be synthesized adlı bir klasör ya da düzenlenmemiş bir Google Drive kökü. AI bu çekmeceyi çoğu zaman gezebiliyor, ama her zaman değil: bir katılımcı, yapay zeka yanlış makaleleri getirdiği için 45 dakika kaybetti.
5. Yeniden kurma (Reconstruction)
Sistemler üç nedenle yeniden kuruluyor ya da terk ediliyor:
İhtiyaca artık uymuyor: Kullanıcı sistemi aşmış ya da devraldığı sistem kendi çalışma biçimine uymuyor.- Kimse anlamıyor: Bir ürün lideri, ekibinin bağlam kütüphanesi aklında tutabileceğinin ötesine geçtiği için onu iki kez yeniden kurmak zorunda kaldı.
- Daha iyi bir yöntem çıktı: Kullanıcı yeni teknikler öğrenip iyileştirmeleri AI’a uygulatıyor.
İhtiyaca artık uymuyor: Kullanıcı sistemi aşmış ya da devraldığı sistem kendi çalışma biçimine uymuyor.Bağlam kütüphanesinin üç katmanı
NN/g çamurun büyük kısmını bağlam (context) türlerinin birbirine karışmasına bağlıyor. Ajan sistemlerinde üç tür bağlam var:
| Bağlam türü | Ne içerir | Örnek |
|---|---|---|
| Global | Sistemin tamamında geçerli talimat ve bilgiler | Her işte geçerli üslup ve kural dosyası (ör. kök dizindeki CLAUDE.md) |
| Yerel | Belirli bir görev, proje ya da iş akışına özgü bilgi | Tek bir müşteri projesinin brief’i, o projenin kuralları |
| Çevresel (ambient) | AI’ın erişebildiği ama kalıcı bağlam olarak bilinçli bakımı yapılmayan akışlar | E-posta, Slack mesajları, toplantı dökümleri |
Bu ayrım bilgi mimarisinin AI’daki karşılığı: hangi bilginin nerede durduğu belirsizleştikçe, model ne kadar iyi olursa olsun sonuç bozuluyor. Konuyu Model kusursuz çalışıyor, sorun bilgi mimarinizde yazısında ürün tarafından incelemiştik.
Sisteminizi yeniden kurmalı mısınız? Tek soruluk test
NN/g’nin teşhis testi tek bir soru: Sistemin çalışma biçimini değiştirmek isteseniz, bağlam kütüphanesinde neyi değiştireceğinizi bilir miydiniz?
Küçük tadilat yeter
Yeniden kurma zamanı
Dikkat: NN/g’ye göre amaç yeniden kurmaktan kaçınmak değil. “Amaç hiçbir zaman yeniden kurmaktan kaçınmak değildi; onu yönetebilecek konumda kalmaktı.”
Bağlam kütüphanesi nasıl denetlenir? 5 adım
NN/g’nin önerileri, Claude, ChatGPT ya da başka bir ajanla kendi iş akışını kuran herkesin bugün uygulayabileceği bir bakım rutinine dönüşüyor:
- Bağlam türlerini ayrı tutun. Global ve yerel talimatları aynı dosyaya yazmayın. Tek bir projeye ait kural global dosyaya sızdıysa onu proje klasörüne taşıyın.
- Değişiklik isterken bağlam türünü adlandırın. “Bunu nerede gerekiyorsa düzelt” yerine “global bağlamdaki şu kuralı güncelle” deyin. Böylece AI’ın değişikliği nereye yazdığını bilirsiniz.
- Global bağlamı düzenli denetleyin. Dosya tek oturuşta okunabilecek kadar kısa olmalı. Her yerde geçerli olmayan talimatları yerel bağlama taşıyın ya da silin.
- Çıktılar kötüleştiğinde yerel bağlamı tazeleyin. Sonuçlar bir projede bozulmaya başladıysa önce o projenin brief ve kural dosyalarına bakın.
- Periyodik olarak durup düşünün. Her parçanın ne yaptığını, hâlâ kullanıp kullanmadığınızı ve sıfırdan kursanız neyi farklı yapacağınızı sorun.
Bu rutin, yapay zeka çağında tasarımcının da sistem düşünmesi gerektiğini hatırlatıyor; temel kavramlar için NN/g’nin yapay zeka sözlüğü iyi bir başlangıç noktası.
Bizim açımız: atlanan örüntü “Shearing Layers”
Foote ve Yoder’in orijinal makalesinde yedi kalıp var: Big Ball of Mud’ın kendisi, NN/g’nin kullandığı beş örüntü ve bir de Shearing Layers (laputan.org). NN/g bu yedinci kalıbı listesine almıyor. Foote ve Yoder kalıbın sorununu “farklı yapıtlar farklı hızlarda değişir” diye koyuyor, çözümünü de benzer hızda değişen parçaları bir arada tutmak olarak tarif ediyor.
Bizim yorumumuz: NN/g’nin “bağlam türlerini ayrı tutun” tavsiyesi, aslında Shearing Layers’ın özü. Farklı hızlarda değişen parçaları — nadiren değişen global kuralları, proje bazında değişen yerel bağlamı ve her gün akan çevresel bilgiyi — ayrı katmanlarda tutmak, çamuru önlemenin en ucuz yolu. Kendi sistemini kuran tasarımcı için pratik karşılığı şu: dosyalarınızı konuya göre değil, ne sıklıkla değiştiklerine göre ayırın.
Bu yaklaşım, sistemleri sıfırdan kurmak yerine var olanı düzenli güncellemeyi savunan Victor Hwang’ın web tasarımı tezine de yakın duruyor.
Sıkça sorulan sorular
Big ball of mud ne demek?
Big ball of mud (“büyük çamur topu”), net bir mimarisi olmayan, düzeni tasarımdan çok o anki aciliyetle belirlenmiş dağınık bir sistemi anlatır. Terim Brian Foote ve Joseph Yoder’in 1997’de sunduğu aynı adlı makaleyle yaygınlaştı.
Vibe architect ne demek?
NN/g’nin kullandığı bu terim, teknik altyapısı az olduğu halde Claude Cowork veya Claude Code gibi araçlarla karmaşık AI ajan sistemleri kuran kişileri tanımlar. Bu kişiler genellikle sezgiyle çalışır ve kararların çoğunu yapay zekaya bırakır.
AI ajan sistemi neden zamanla bozulur?
NN/g’ye göre AI inşa etmeyi ucuzlattığı için sistemler planlanmadan büyür, bozuk parçalar yamalanır ve dağınık bilgi tek bir klasöre yığılır. Bağlantıların süresinin dolması ve bağlamın güncelliğini yitirmesi de bozulmayı hızlandırır.
CLAUDE.md gibi bağlam dosyası ne kadar uzun olmalı?
NN/g kesin bir satır sayısı vermiyor; ölçüt, global bağlamın tek oturuşta gözden geçirilebilecek kadar kısa olması. Her yerde geçerli olmayan talimatlar yerel bağlama taşınmalı ya da silinmeli.
Sistemi baştan kurmam gerektiğini nasıl anlarım?
Sistemin çalışma biçimini değiştirmek istediğinizde bağlam kütüphanesinde neyi değiştireceğinizi biliyorsanız küçük düzeltmeler yeter. Bilmiyorsanız ve yolu yalnızca AI bulabiliyorsa, yeniden kurma zamanı gelmiştir.
Kaynaklar
- Tanner Kohler, “The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile”, Nielsen Norman Group, 2 Ekim 2026
- Kate Moran ve Sarah Gibbons, “Vibe Architects”, Nielsen Norman Group, 19 Haziran 2026
- Brian Foote ve Joseph Yoder, “Big Ball of Mud”, PLoP ’97 (1997); Pattern Languages of Program Design 4 (2000)
Bir Yorum Yazın