- Kasava, ürün geliştirme sürecinin tamamını tek bir monorepo içinde yönetiyor; kodu, dokümantasyonu, pazarlamayı ve operasyon verilerini tek yerde birleştiriyor
- Tüm değişiklikler tek bir commit ile yansıtılıyor; böylece backend, frontend, web sitesi ve dokümantasyon aynı anda güncellenebiliyor
- Yapay zeka araçları, kodu, dokümantasyonu ve web sitesini doğrudan referans alarak tutarlılık doğrulama, otomatik doküman güncelleme ve içerik inceleme gibi işleri yapıyor
- CLAUDE.md, Selective CI/CD, bağımsız npm proje yapısı gibi yaklaşımlarla büyük depoların karmaşıklığı en aza indiriliyor
- Bu yaklaşım, AI-native geliştirme kültürünü güçlendirirken ürün, içerik ve operasyon arasındaki sınırları kaldırıyor; hızlı dağıtım ve iş birliğini mümkün kılıyor
AI-native geliştirme ve monorepo'nun anlamı
- Kasava, tüm platform bileşenlerini tek bir Git deposunda birleştiriyor; yalnızca kodu değil, dokümantasyonu, pazarlamayı, e-postaları ve yatırım materyallerini de buna dahil ediyor
- Örnek:
frontend/, backend/, website/, docs/, marketing/, external/ gibi dizinler dahil 5.470'ten fazla TypeScript dosyası
- Yapay zeka, kod ve dokümantasyona aynı anda erişerek bağlam tabanlı otomasyon gerçekleştiriyor
- Doküman düzeltmeleri, web sitesindeki fiyat değişiklikleri ve blog doğrulaması gibi işler yapay zeka ile tek bir konuşmada çözülebiliyor
- Tüm değişiklikler aynı Git iş akışı (
git push) ile dağıtılıyor
- Kod, içerik, dokümantasyon ve pazarlama aynı inceleme, CI/CD ve denetim süreçlerinden geçiyor
- Bu yöntem hızı ve tutarlılığı artırıyor ve “her şeyi kod olarak yönetme” kültürünü yerleştiriyor
Neden tek bir depoda birleştiriliyor?
- Sınırlar arası atomik değişiklikler (Atomic Changes)
- Backend API'sinde bir değişiklik yapıldığında frontend tip tanımları ve dokümantasyon aynı commit içinde güncelleniyor
- Örnek: Asana entegrasyonu eklendiğinde backend, frontend, dokümantasyon ve web sitesi tek bir PR ile birleştiriliyor
- Tek doğruluk kaynağı (Single Source of Truth)
- Ücret planı limitleri tek bir
billing-plans.json dosyasında tanımlanıyor ve tüm servisler bunu referans alıyor
- Yapay zeka; backend, frontend ve web sitesi arasındaki tutarlılığı otomatik olarak doğruluyor
- Projeler arası refactoring
- IDE içinde tüm kod, dokümantasyon ve hatta blog örnekleri aranıp düzenlenebiliyor
- Paylaşılan araçlar ve pipeline'lar
- Ortak CI/CD, bağımlılıklar ve arama ortamı sayesinde yönetim sadeleşiyor
Depo yapısı ve bileşenler
- Core Application:
frontend/, Next.js 16 + React 19 tabanlı; backend/ ise Cloudflare Workers + Hono + Mastra kullanıyor- API değişikliklerinde tip güvenliği ve test yardımcı araçları paylaşılıyor
- Marketing:
website/, marketing/blogs/, investor-deck/, email/ içeriyor- Bloglar, e-postalar ve yatırım materyalleri de kod olarak sürüm kontrolüne alınıyor;
git revert ile geri alınabiliyor
- Documentation:
docs/, Mintlify tabanlı herkese açık dokümantasyon; docs-internal/ ise iç mimari dokümanları içeriyor- Kodla birlikte aranabiliyor ve wiki yerine gerçek zamanlı güncel bilgi sağlıyor
- External Services:
- Chrome uzantısı, Google Docs Add-on ve GCP Functions gibi harici dağıtım servislerini kapsıyor
- API sözleşmeleri paylaşıldığı için değişiklikler eş zamanlı yansıtılabiliyor
- Development Infrastructure:
github-simulator/, infra-tester/, scripts/ gibi yerel geliştirme için sahte sunucular ve test araçları içeriyor
Çalışma biçimi ve geliştirme kültürü
- Workspace kullanılmıyor
- Her dizin bağımsız bir npm projesi olarak tutuluyor; böylece bağımlılık çakışmaları önleniyor
- Seçici CI/CD (Selective CI/CD)
- GitHub Actions, yol tabanlı olarak tetikleniyor ve yalnızca ilgili testler çalıştırılıyor
- CLAUDE.md kuralları
- Her ana dizinde teknoloji yığını, komutlar ve mimari kararlar dokümante ediliyor
- Yapay zeka yardımcıları bunu okuyarak projenin bağlamını anlıyor
- Tutarlı araç ayarları
.prettierrc, .eslintrc, tsconfig.json gibi ortak yapılandırmalar korunuyor
Zorluklar ve yanıtlar
- Depo boyutu: Şu anda klonlama süresi yaklaşık 20 saniye; Git performansında sorun yok
- Büyük varlıklar ileride R2/S3'e ayrılacak
- Build süreleri: Her proje bağımsız build alıyor; Turbopack, Wrangler ve WXT ile yeniden build süresi hızlı
- Yetki sınırları: Küçük ekiplerde herkes tümüne erişebiliyor; gerekirse CODEOWNERS ve branch protection uygulanabiliyor
- Bağlam değiştirme: Farklı diller (TypeScript, Apps Script, MJML) arasında geçiş, CLAUDE.md ve birleşik formatlarla hafifletiliyor
Sonuç
- Kasava'nın monorepo yaklaşımı, basit bir trend değil; bağlamı birleştirerek üretkenliği en üst düzeye çıkaran bir araç
- Backend, frontend, dokümantasyon ve pazarlama tek bir değişiklikle birlikte çalışıyor ve yapay zeka bunu gerçek zamanlı doğruluyor
- Sonuç olarak “monorepo, bir kısıt değil; bir çarpan etkisi yaratan hızlandırıcı (force multiplier) olarak işliyor”
1 yorum
Hacker News yorumları
Bu, şirketin tamamını yönetmekten çok sadece tek bir ürün (monorepo) gibi görünüyor
Finans, İK, sözleşmeler, ekip fotoğrafları gibi şeyler yok; sadece frontend+backend yapısına biraz sıra dışı şekilde eklenmiş bir pazarlama klasörü var gibi
Bu yüzden her şeyin tek bir repo içinde olması mümkün, ama böyle bir durumda buradan çıkarılacak “içgörü”nün değerini sorgulatıyor
Mesela şifrelenmiş artifact’ler bile dahil, “şifre anahtarı fiziksel olarak yalnızca CEO’da bulunuyor” gibi bir düzenle
GitHub private folder kavramı eklese güzel olurdu ama bu ACL meselesi olduğu için fazla büyük bir beklenti olabilir
Ben monorepo ve development branch olmaması yaklaşımını destekliyorum
Ama geliştirme ile release ayrılmalı
Kararlı release’ler kesilip cherry-pick yapılabilmeli ve frontend ile backend arasındaki API kararlılığı mutlaka korunmalı
Eğer doğrudan main branch üzerinde geliştirme yapılıyorsa, farklı büyüklükteki işlerin aynı anda nasıl yönetildiğini merak ettiklerini söylüyorlar
Kendilerinin 3’ten fazla ürünü monorepo ile yönettiğini ve kararlı release birimleri halinde dağıtılsa da sorun yaşamadıklarını söylüyorlar
git squash’tan hoşlanmıyor ve forking yaklaşımının geliştiricilere daha özgür bir ortam sunduğunu belirtiyor
“Tek bir değişiklikle her yer aynı anda güncellenir” sözü tehlikeli bir yanılsama
DB ya da API içeren sistemlerde her zaman geriye dönük uyumluluk düşünülmeli
Birden fazla ekibin olduğu organizasyonlarda, bir ekibin yükseltmeyi doğrulayamaması yüzünden herkesin önünün kesildiği durumlar yaşanır
Bu yüzden kademeli rollout şart
Monorepo’nun kendisi kötü değil ama “tek bir değişiklikle her şey anında deploy edilir” yaklaşımı mümkün değil
Çünkü DB şeması ve kod aynı anda değiştirilemez
Bu tür yazılar AI tarafından yazılmış blog gibi görünüyor ve muhtemelen gerçek müşteri sayısı da çok az
Organizasyon sorunlarını teknik sorun sanmamak, bunun yerine ekipler arası politika ve liderlikle uyum sağlamak gerektiği söylendi
Bunun küçük ekiplerde mümkün bir yaklaşım olduğunu da ekliyor
Eskiden monorepo’dan hoşlanmazdım ama Claude Code kullanınca fikrim değişti
Frontend ve backend aynı repo’da olunca senkronizasyon kolaylaşıyor
Bu yazı AI yazmış gibi hissettiriyor
İnsan eliyle yazılmış içerik bulmak zorlaştığı için yorucu geliyor
“This isn’t just for…”, “The Challenges (And How We Handle Them)” gibi cümleler tipik AI üslubu olarak görülüyor
Kusursuz olmasa da insan yazısından daha iyi değil mi, diye soruyorlar
“Claude’a pricing page’i güncellemesini söylemek” kısmı tuhaf geliyor
Pazarlama sayfasını aynı repo’da yönetirken, basitçe config dosyasındaki veriyi okumakla çözülecek bir işi LLM’ye bırakmak ikna edici bulunmuyor
AI var diye insanların artık kontrol etmediği anlamına gelmediği söyleniyor
“Frontend, backend, website”i tek repo’ya koymak kafa karıştırıcı
Commit düzeyinde birleşik olmak güzel görünebilir ama 3 repo ile de gayet yönetilebilir
Monorepo’yu düzgün işletmek için ciddi bir bakım maliyeti gerekiyor
Yazı AI tarafından yazılmış gibi duruyor ama IaC’nin aşırı genişletilmiş bir versiyonu olarak fikir yine de ilginç
O yüzden insanda karışık duygular uyandırıyor
İleride bu tür LLM tarzı halka daha tanıdık geldikçe, bugünün yazıları demode görünebilir deniyor
Şirket web sitesini aynı repo’da tutarsanız marka materyallerine ve tona kolayca ulaşabilirsiniz
Bu yüzden müşteri sunumları ya da demo videolarını otomatik üretmek daha kolay olur
Hatta dokümanlar, bug’lar ve issue’ları da tek yere koymak ilginç olabilir
Eski startup Pangea’da benzer bir yapı kurmuşlar
Genel olarak iyiydi ama kusursuz değildi
Yine de ARM’a geçerek hesaplama maliyetini %70 azaltmak gibi başarılar elde etmişler
Pangea bağlantısı
Bu tür araçlar olmadan CI ölçeklenebilirliğinin sınırına çarpıldığını söylüyorlar