Birden fazla depo arasında çalışıyorsanız, o his tanıdıktır: bir yanda API, diğer yanda frontend, arada ortak tipler uçuşuyor… Claude Code tam gaz giderken bir anda sanki sizi ilk görüyormuş gibi davranmaya başlıyor. İşin aslı şu — sorun Claude’un “zekâsı” değil, context’in paramparça olması. Bunu ilk kez 2024 sonbaharında, İstanbul’daki küçük bir fintech projesinde yaşadım. API tarafında kuralları tek tek anlattım, frontend’e geçtim, iki dakika sonra aynı şeyleri yeniden yazarken buldum kendimi. Can sıkıcı mı? Evet. Ama çözümü var.
Bu yazıda meseleyi lafı gevelemeden anlatacağım: çoklu repo yapısında Claude Code’u nasıl daha az unutkan hale getirirsiniz, hangi dosyalar iş görür, hangi noktada işler biraz ham kalıyor ve nerede manuel kontrol şart oluyor. Açık konuşayım — yapay zekâ araçları ne kadar iyi olursa olsun, disiplinli bir çalışma düzeni yoksa insanı yarı yolda bırakabiliyor. Hele konu iki ayrı kod tabanıysa, yani backend’in kendi köşesi frontend’in kendi köşesi (ciddiyim). Bir de ortada duran shared tipler varsa… işler iyice karışıyor.
Durun, bir saniye.
Asıl problem: Tek pencere, dağılan hafıza
Claude Code’un temel derdi persistent memory olmaması. Yani oturum kapandı mı ya da başka repoya geçtiniz mi, önceki bağlamın büyük kısmı uçup gidiyor. Bazen çok bariz oluyor bu. Backend’de “Bearer token kullanıyoruz” diyorsunuz, frontend’de araç bunu unutmuş gibi davranıp fetch çağrılarında bambaşka bir akış öneriyor. Neden? Çünkü ona söylemediniz.
Şahsen, Geçen yıl Aralık 2024’te Kadıköy’deki bir ajans için hazırladığım küçük bir e-ticaret entegrasyonunda bunu net gördüm. Sipariş servisi ayrı repodaydı, admin paneli ayrıydı, ortak DTO’lar ise üçüncü bir klasörde duruyordu. Claude Code’a her geçişte “hayır bu endpoint böyle dönüyor” diye tekrar anlatmak zorunda kaldım. İnsan yoruluyor doğrusu.
Buradaki mesele sadece sinir bozucu olması değil. Yanlış varsayım üretmesi de ciddi risk — özellikle şema değişikliklerinde veya auth akışlarında model eski bilgiyi taşıyamayınca sizi ters köşeye yatırabiliyor; küçük bir startup için bu “idare eder” gibi görünebilir ama enterprise seviyede, hani onlarca servis. Ekip varsa, ufak unutkanlık bile zincirleme hata çıkarabiliyor. Farklı ölçekler, farklı acılar.
Çözüm 1: Her repoda CLAUDE.md ile yol çizmek
En pratik yöntemlerden biri her repoda kök dizine CLAUDE.md koymak. Bu dosya aslında model için mini kullanım kılavuzu gibi çalışıyor. Proje türü, auth biçimi, response standardı, hatta “fetch doğrudan kullanılmayacak” gibi spesifik kurallar bile burada duruyor. Gösterişli bir doküman değil — tutarlı bir sinyal.
Bunu ilk denediğimde — Şubat 2025’te İzmir merkezli bir SaaS ekibinde — bayağı işe yaradığını gördüm. Şaşırdım açıkçası. Frontend ve backend arasındaki ilişkiyi dosyanın içine gömünce Claude Code daha az saçmalamaya başladı; mesela API cevabı { data:..., error: null } formatındaysa bunu açıkça söyleyince araç artık rastgele obje döndürmeye kalkmıyor.
Hmm, bunu nasıl anlatsamdı…
Bi saniye — Karşı repo’ya referans vermek de iş görüyor, ama ölçülü olmak şartıyla. Mesela backend CLAUDE.md içinde frontend’in beklentilerini yazarsanız model çapraz bağı daha hızlı kuruyor. Yalnız burada aşırı ayrıntıya kaçınca dosya şişiyor… ve evet, bazen beklediğim kadar temiz sonuç vermediğini de söylemem lazım. Mükemmel değil bu yöntem. Siz ne dersiniz? Ama fena da değil.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| CLAUDE.md | Sürekli rehberlik verir | Düzenli güncelleme ister |
| Kontekst elle anlatma | Anında esneklik sağlar | Zaman kaybettirir |
| Kod yorumlarıyla yönlendirme | Dosya içinde görünür olur | Tutarlılık zayıflayabilir |
Küçük örnek yapı nasıl görünür?
# API Repo — CLAUDE.md
## This project
Node.js + Express + PostgreSQL REST API
## Paired with
../frontend
## Rules
- Response format must be { data:..., error: null }
- Dates are ISO 8601 strings
- Auth header uses Bearer access token
- Update shared-types before changing response shape
Bir bakıma, bi saniye — Buna benzer sade bir yapı çoğu zaman yetiyor. Modelin ihtiyacı olan şey gösterişli doküman değil, tutarlı sinyal — bunu bir kere kafaya yerleştirince gereksiz süsleme isteği de geçiyor zaten. EIE: Ollama’ya Rakip Yerel Yapay Zekâ Sunucusu yazımızda bu konuya da değinmiştik.
İşte tam da bu noktada devreye giriyor.
Çözüm 2: Geçici CONTEXT.md ile işi elde tutmak
İnanın, Gelelim ikinci yönteme. Workspace köküne geçici bir CONTEXT.md koymak. Bu özellikle aynı gün içinde üç-dört repo arasında gidip geliyorsanız hayat kurtarıyor. Ben bunu Mart (belki yanılıyorum ama) 2025’te Berlin’de uzaktan çalışan bir ekipte test ettim; ürün yöneticisi “avatar upload yetişsin” deyince hem backend hem frontend hem migration aynı hafta pat diye masaya geldi. Yetişecek, tamam. Ama nasıl? Bu konuyla ilgili Claude, mitmproxy ve Spor Uygulamasının Gizli API’si yazımıza da göz atmanızı tavsiye ederim.
Burada sihir yok aslında. Sadece aktif işi tek yerde topluyorsunuz: hangi endpoint yapılmış, hangisi sırada, limit neydi (mesela 5 MB), hangi klasöre bakılacak (en azından benim deneyimim böyle). hepsi orada duruyor. Claude Code yeni oturumda önce bu dosyayı görürse olayın neresinde olduğunu daha çabuk anlıyor. Fazladan açıklama yapmıyorsunuz. Zaman kazanıyorsunuz.
Kendi deneyimimden konuşuyorum, Aşağıdaki yapı basit ama etkili: Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
workspace/
CONTEXT.md
api/
frontend/
shared-types/Aslında, Tabi bu yöntemin de eksiği var. CONTEXT.md güncel tutulmazsa tam tersi etki yapar ve modeli yanlış yere sürükler. Ben bunu “geçici durum panosu” gibi kullanıyorum — iş bitince siliyorum ya da sıfırlıyorum (evet, doğru duydunuz). Kalıcı doküman değil bu; mutfaktaki post-it notu. Bu konuyla ilgili Klasörlerden Hafıza Kurmak: Claude Code ile İkinci Beyin yazımıza da göz atmanızı tavsiye ederim.
Aktif görev notu neden işe yarıyor?
Açık konuşayım, Dolapta ne eksikse ona bakarsınız ya… aynen aynı mantık. Model de projeyi tanırken en son neyin yapıldığını görmek istiyor; aksi halde sizi eski hedefe geri götürüyor. Çünkü ne düşüneceğini bilemez, tahmin eder — ve tahminler her zaman tutmaz.
- Kısa görev özeti: Ne yapılıyor?
- Status listesi: Neler tamamlandı?
- Kisitlar: Boyut limiti, format limiti, auth kuralı vb. (bence en önemlisi)
- Sıradaki adım: Bir sonraki somut iş ne?
Peki hangi senaryoda hangisi daha iyi?
Yani, Küçük ekiplerde genelde CLAUDE.md tek başına yetiyor. Kod tabanı sayısı az oluyor, iletişim zaten hızlı dönüyor, iki geliştiriciyle yürüyen projede fazladan katman eklemek bazen gereksiz geliyor. Hatta işleri ağırlaştırabiliyor. Orada duralım.
Ama mikroservis dünyasına girince tablo değişiyor. Backend ayrı repo, admin panel ayrı repo, mobil SDK ayrı repo derken context kopması kaçınılmaz oluyor — işte burada hem CLAUDE.md hem CONTEXT.md birlikte daha dengeli çalışıyor; biri kalıcı kural seti veriyor, diğeri aktif işi taşıyor. İkisi birbirinin yerini tutmuyor, ikisi birbirini tamamlıyor (bizzat test ettim)
Claude Code’u çoklu repoda iyi kullandıran şey yalnızca prompt değil; düzenli bilgi mimarisi.
Ne kadar iyi dokümante ederseniz o kadar az yeniden açıklama yaparsınız.
Ve inanın bana… yeniden açıklama yapmak insanın moralini düşürüyor.
Küçük startup vs enterprise farkı
Dürüst olmak gerekirse, Küçük startup’ta çoğu zaman hız öncelikli olur. Kısa CLAUDE.md artı gerektiğinde CONTEXT.md gayet yeterli. Enterprise tarafta durum farklı — güvenlik politikaları, release akışı. Tahmin eder misiniz? Ortak tipler daha karmaşık, daha kırılgan, daha fazla insanın elinden geçiyor. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Büyük yapılarda ben özellikle şunu öneriyorum: her repoda minimum standart doküman olsun. Ortak tipler merkezi depoda dursun. Yoksa bugün avatar alanını değiştirirsiniz, yarın başka servis kırılır… sonra kimse nedenini hatırlamaz bile. Kimse.
Şu ufak detaya bakın: pratik noktalar
Laf arasında şunu söyleyeyim — modelin unutmaması için siz de unutmamalısınız. Biraz sert ama doğruya yakın. En hayati konu güncellik.
- Aynı gerçeği iki yerde tutmayın: Response formatı hem README’de hem CLAUDE.md’de farklıysa sorun kaçınılmaz. (bu kritik)
- Kopyala-yapıştır tuzagina dikkat edin: Eski endpoint örnekleri yeni yapıyı bozabilir. Farkında bile olmadan.
- Sahiplik belirleyin: Shared types kimde? Migration kimde? Belli olsun — “herkesin işi” demek “kimsenin işi değil” demek.
- Kural yerine örnek verin: Model bazen düz cümleden çok somut örneğe daha iyi tepki veriyor. Defalarca gördüm bunu.
Editör masasında bu konuyu işlerken kendi kendime şunu düşündüm: yapay zekâ araçları aslında bize sistem kurmayı zorluyor olabilir mi? Bence evet. Çünkü düzensiz projede en gelişmiş araç bile çabuk tökezliyor. Araç değil, düzen kurtarıyor sizi (bizzat test ettim)
Sıkça Sorulan Sorular
Claude Code çoklu repoda neden context kaybediyor?
Cünkü her oturum sınırlı bağlamla çalışıyor ve reposlar arasında kalıcı hafıza taşımıyor gibi davranıyor diyebiliriz. Repo değişince önceki detayların çoğu otomatik aktarılmıyor. İlginç, değil mi? Bu yüzden kritik kuralları dosyaya yazmak gerekiyor.
CLAUDE.md ile CONTEXT.md arasındaki fark nedir?
CLAUDE.md kalıcı proje rehberi gibidir. CONTEXT.md ise o anki iş için geçici çalışma notudur. Biri düzeni korur, diğeri mevcut görevi taşır (şaşırtıcı ama gerçek).
Küçük ekip için iki dosya da gerekli mi?
Zorunlu değil. Küçük ekiplerde sadece CLAUDE.md çoğu zaman yeterli. Ama aynı anda birkaç repo üzerinde uğraşıyorsanız CONTEXT.md ciddi rahatlık sağlar.
Büyük projelerde bu yöntem gerçekten işe yarar mı?
Evet, özellikle ortak tipler ve paylaşılan sözleşmeler varsa bayağı fayda sağlar. Yalnız dosyaların güncel kalması şarttır ; aksi halde yanlış güven hissi verir.
Kaynaklar ve İleri Okuma
Anthropic Docs — Claude Kullanım Kılavuzu
Claude Code GitHub Sayfası (resmi)
Yapay Zekâ Kodlamada Neden Adım Adım Kazanıyor?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
