Kod tabanı oryantasyonu için Claude Code: uygulamanızı haritalayan istemler

Öğrenmeye çalıştığınız şey (ve neyi erteleyebileceğiniz)

Rasgele dosyalar okumak yavaş hissettirir çünkü çoğu kod tabanı bir hikâye gibi düzenli değildir. Bir klasör açarsınız, önemli görünen on isim görürsünüz, birine tıklarsınız ve yardımcılar, konfigürasyonlar ve kenar durumlarına saparsınız. Bir saat sonra birçok detaya sahipsiniz ama yine de uygulamanın nasıl çalıştığını açıklayamıyorsunuz.

Oryantasyon sırasında Claude Code için daha iyi hedef, basit bir zihinsel harita oluşturmaktır. Bu harita üç soruyu yanıtlamalıdır:

• Ana modüller neler?
• Kullanıcıların tetiklediği temel akışlar hangileri?
• Üretimi bozabilecek veya hatalara yol açabilecek riskli alanlar nerede?

Bir-iki günde "yeterince iyi" oryantasyon, "her sınıfı açıklayabilirim" demek değildir. Daha çok şuna benzer:

• 5–8 önemli modülü adlandırabilir ve her birinin neyi yönettiğini söyleyebilirsiniz.
• 2–3 gerçek kullanıcı akışını uçtan uca (UI veya API girişinden veritabanına ve geri) izleyebilirsiniz.
• En büyük riskleri (ödemeler, kimlik doğrulama, veri yazımları, arka plan işleri) ve nerede olduklarını bilirsiniz.
• Ne test edileceğini ve kime sorulacağını bildiğiniz için küçük bir değişikliği güvenle yapabilirsiniz.

Bazı şeyler bekleyebilir. Derin refaktörler, her soyutlamanın kusursuz anlaşılması ve kimsenin dokunmadığı eski kodu okumak nadiren hızlıca fayda getirir.

Oryantasyonu sokakları ezberlemek değil, bir harita oluşturmak olarak düşünün. İstemleriniz sizi sürekli şu sorulara geri çekmeli: "Sistemde nerede bulunuyorum, sonra ne oluyor ve burada ne ters gidebilir?" Bunları elde ettiğinizde detayları talep üzerine öğrenmek kolaylaşır.

Hazırlık: denizi kaynatmadan bağlam alın

Soru sormaya başlamadan önce, normalde ilk gün ihtiyaç duyduğunuz temel bilgileri toplayın. Claude Code gerçek dosyalara, gerçek konfigürasyona ve çoğaltabileceğiniz gerçek davranışa tepki verdiğinde en iyi şekilde çalışır.

Önce erişim ve çalışır bir kurulum sağlayın. Repoyu klonlayabildiğinizden, bağımlılıkları kurabildiğinizden ve uygulamayı (veya en azından küçük bir dilimi) yerelde çalıştırabildiğinizden emin olun. Yerel kurulum zorsa, staging ortamına ve logların bulunduğu yere erişim alın, böylece kodun gerçekte ne yaptığını doğrulayabilirsiniz.

Sonra “gerçeğin kaynağı” dokümanlarını bulun. Ekip değiştiğinde gerçekten güncelledikleri şeyleri arıyorsunuz: bir README, kısa bir mimari notu, ADR klasörü, runbook veya dağıtım notu. Dağınık olsalar bile modül ve akış isimleri verirler; bu da Soru&Cevap'ı çok daha hassas yapar.

Kapsamı erken belirleyin. Pek çok repo birden fazla uygulama, servis ve paylaşılan paket içerir. Sınırlar belirleyin: "sadece API ve fatura worker'ı" veya "sadece web uygulaması ve onun auth akışı" gibi. Net kapsam sonsuz sapmaları önler.

Asistanın tahmin etmesini istemediğiniz varsayımları yazın. Bu küçük görünür ama daha sonra saatler kaybettirebilecek yanlış zihinsel modelleri önler.

Basit bir hazırlık kontrol listesi:

• Repo erişimini, gerekli izinleri ve testleri nasıl çalıştıracağınızı doğrulayın.
• Ortam kurulum notlarını (env var'lar, seed'ler, feature flag'ler) ve loglar ile metriklerin nerede görüntülendiğini toplayın.
• Güncel gerçeği gösteren dosyaları belirleyin (README, mimari notları, ADR'ler, runbook'lar).
• Bu oryantasyon geçişi için kapsamın neler olduğunu ve nelerin açıkça dışarıda olduğunu tanımlayın.
• Güvenlik kurallarını belirleyin: sırları, API anahtarlarını, token'ları, özel müşteri verilerini veya hassas ayrıntılı üretim loglarını asla yapıştırmayın.

Eğer bir şey eksikse, bunu bir ekip arkadaşına sorulacak bir soru olarak kaydedin. Eksik bağlamı "çözmeye" çalışmayın.

Zihinsel harita: keşfederken neyi yakalamalısınız

Zihinsel harita, şu soruyu cevaplayan küçük bir not setidir: bu uygulamanın ana parçaları neler, nasıl birbirleriyle konuşuyorlar ve nerede işler ters gidebilir. İyi yapıldığında oryantasyon dosyaları gezmekten ziyade yeniden kullanılabilir bir resim oluşturmak olur.

Başlangıç olarak çıktılarınuzu tanımlayın. Pratik bir modül listesi isteyin, kusursuz değil ama işe yarar olsun. Her modül için ne yaptığı, kimin sahibi olduğu (biliniyorsa) ve ana bağımlılıkları (diğer modüller, servisler, veritabanları, dış API'ler) not edin. Ayrıca ana giriş noktalarını da belirtin: UI rotaları, API endpoint'leri, arka plan işleri ve zamanlanmış görevler.

Sonra birkaç kullanıcı yolculuğu seçin. Üç ila beş yeterlidir. Para, izinler veya veri değişiklikleri içeren akışları seçin. Örnekler: kayıt ve e-posta doğrulama, ücretli plan oluşturma veya satın alma, bir yöneticinin kullanıcı erişimini değiştiren işlemi ve çoğu kullanıcının günlük olarak güvendiği kritik bir akış.

Başlamadan önce riski nasıl etiketleyeceğinize karar verin. Tarama yaparken basit kategoriler tutun. Yararlı bir set: güvenlik, veri bütünlüğü, kullanılabilirlik ve maliyet. Bir şeyi riskli olarak işaretlediğinizde, nedenini bir cümleyle ve güvenli olduğunu kanıtlayacak şeyi (bir test, bir log, bir izin kontrolü) ekleyin.

Notları yeniden yazmadan oryantasyon dokümanına dönüştürebilmek için tutarlı bir format kullanın:

• Modüller: amaç, giriş noktaları, bağımlılıklar, sahibi
• Ana akışlar: tetikleyici, adımlar, yazılan veri, hata noktaları
• Veri: dokunulan tablolar veya koleksiyonlar, önemli alanlar, kısıtlar
• Riskler: kategori, en kötü etki, nasıl izlenir, nasıl geri alınır
• Açık sorular: hala bilmedikleriniz, kimi sormalısınız

Örnek: Checkout Billing'i çağırıp payments ve invoices'a yazıyorsa, bunu veri bütünlüğü ve maliyet olarak etiketleyin. Sonra retry'lerin nerede olduğunu ve çift ücretlendirmeyi neyin önlediğini not edin.

Kod tabanını keşfetmek için adım adım Soru&Cevap istemleri

Yeni bir repo'ya katıldığınızda, hızlı oryantasyon istersiniz, mükemmel anlayış değil. Bu istemler size küçük, güvenli adımlarla zihinsel harita oluşturmanızda yardımcı olur.

Asistana repo ağacını (veya yapıştırılmış alt kümesini) vererek bir tur isteyerek başlayın. Her turu odaklı tutun, sonra bir sonraki okunacak şeyi söyleyen bir soru ile bitirin.

1) Repo tour
"Here is the top-level folder list: <paste>. Explain what each folder likely contains and which ones matter for core product behavior."

2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."

3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."

4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."

5) Flow trace
"Trace this flow end-to-end: <flow>. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."

6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."

Somut bir örnek: "kullanıcı kaydolur ve ilk projesini oluşturur"u haritalıyorsanız, API route handler'ı, validasyon, DB yazımı ve e-posta gönderen veya kaynak sağlayan asenkron iş varsa onu isteyin. Sonra "kullanıcı proje siler" akışı için akış izini tekrar çalıştırın ve temizlik boşluklarını bulun.

Cevapları eyleme geçirilebilir kılmak için somut artefaktlar isteyin, sadece özet değil:

• Dosya yolları ve fonksiyon isimleri
• Açıkça belirtilmiş varsayımlar ve bilinmeyenler
• Bağımlılıkların "Eğer X'i değiştirirsem ne kırılır?" şeklinde ifade edilmesi
• 10 dakikada yapabileceğiniz küçük bir okuma görevi

Cevapları nasıl kaydedersiniz ki işe yarasınlar

En büyük oryantasyon kazancı, dağınık Soru&Cevap'leri başka bir geliştiricinin de kullanabileceği notlara dönüştürmektir. Notlar sadece size anlamlıysa aynı kazmayı tekrar yapmak zorunda kalırsınız.

Basit bir yapı uzun sayfalardan daha iyidir. Her keşif oturumundan sonra cevapları beş küçük artefakte (tek bir dosya veya doküman olabilir) kaydedin: bir modül tablosu, bir sözlük, ana akışlar, bilinmeyenler ve bir risk kaydı.

İşte yaparken yapıştırıp doldurabileceğiniz kompakt bir şablon:

Module table
- Module:
  Owns:
  Touches:
  Entry points:

Glossary
- Term:
  Meaning:
  Code name(s):

Key flow (name)
1.
2.
3.

Unknowns
- Question:
  Best person to ask:
  Where to look next:

Risk register
- Risk:
  Location:
  Why it matters:
  How to verify:

Ana akışları kasıtlı olarak kısa tutun. Örnek: 1) kullanıcı giriş yapar, 2) backend bir oturum oluşturur, 3) istemci panoyu yükler, 4) API veri çeker, 5) UI render eder ve hataları ele alır. Bir akışı beş adıma sığdıramıyorsanız, onu bölün (giriş vs pano yükleme gibi).

Claude Code kullanırken her cevaba bir satır ekleyin: "Bunu nasıl test ederim?" Bu satır pasif notları daha sonra çalıştırabileceğiniz bir kontrol listesine dönüştürür, özellikle bilinmeyenler ve riskler çakıştığında.

Koder.ai gibi vibe-coding platformlarında bu tür not tutma aynı zamanda oluşturulan değişikliklerin yan etkilerini görmenize yardımcı olur. Çok temas eden modüller genelde değişiklik mıknatısıdır.

Her dosyayı okumadan riskli alanları hızlı bulma

Kod tabanındaki risk nadiren rastgele dağılır. Kimlik doğrulama, veri değiştirme, diğer sistemlerle konuşma veya arka planda çalışma kararlarının yoğunlaştığı yerlerde kümelenir. Hedefli sorular ve birkaç odaklı aramayla çoğunu bulabilirsiniz.

Kimlikten başlayın. Kimlik doğrulamanın nerede gerçekleştiğini (login, oturum, token) ve yetkilendirme kararlarının nerede alındığını (rol kontrolleri, feature flag'ler, sahiplik kuralları) sorun. Yaygın bir sorun kontrollerin UI, API handler'ları ve veritabanı sorguları arasında dağınık olması ve tek bir güven kaynağı olmamasıdır.

Sonra yazım yollarını haritalayın. Kayıt oluşturan, güncelleyen veya silen endpoint'leri veya fonksiyonları ve zaman içinde veriyi yeniden şekillendiren migration'ları bulun. Arka plan işler de dahil edin. Birçok gizemli hata, isteğin bittikten sonra beklenmedik değerler yazan asenkron worker'lardan gelir.

Hızlıca riskleri ortaya çıkaracak istemler:

• "[kaynak X] için izinleri uygulayan her yeri listele. Nihai kapı hangisi?"
• "[tablo/varlık X] için tam yazma yolunu göster: API handler -> servis -> DB çağrısı. Validasyonlar nerede?"
• "Hangi dış entegrasyonlar var (ödemeler, e-posta, webhook'lar, üçüncü taraf API'ler)? Retry ve timeout nerede ayarlanmış?"
• "Hangi işler iki kez çalışabilir (kuyruklar, goroutine'ler, cron)? İdempotent yapan nedir?"
• "Sessizce ne kırılabilir ve bunu nasıl fark ederiz (loglar, metrikler, alarmlar, panolar)?"

Ardından konfigürasyon ve gizli bilgi yönetimini kontrol edin. Ortam değişkenleri, çalışma zamanı konfig dosyaları ve varsayılan geri dönüşler için arama yapın. Varsayılanlar faydalıdır ama eksik bir değer nedeniyle (örneğin prod'da dev anahtarın kullanılması gibi) yanlış yapılandırmaları gizlediklerinde risklidir.

Kısa bir örnek: PostgreSQL kullanan bir Go backend'de, başarısızlıkta tekrar deneyen bir "e-posta gönder" işi bulabilirsiniz. Eğer retry idempotency anahtarı olmadan yapılıyorsa kullanıcılar çift e-posta alabilir. Hatalar yalnızca uyarı olarak log'lanıp hiçbir alarm yoksa, bu sessizce bozulur. Bu tür bir alan belgelendirip erken test edilmelidir.

Örnek yürütme: tek bir gerçek kullanıcı akışını haritalama

İlk uçtan uca ipliği oluşturmak için bir gerçek akışı kullanın. Login başlamak için iyi bir akıştır çünkü routing, validasyon, oturum veya token ve veritabanı okumalarını kapsar.

Senaryo: React web uygulaması bir Go API'yi çağırıyor ve API PostgreSQL okuma/yazma yapıyor. Hedefiniz her dosyayı anlamak değil. Ama şu soruyu cevaplamaktır: "Kullanıcı Login'e tıkladığında sırada hangi kod çalışıyor, hangi veri hareket ediyor ve ne ters gidebilir?" Bu, oryantasyonun somut kalmasını sağlar.

Tarayıcıdan veritabanına akışı haritalayın

UI'dan başlayıp ileri doğru, bir adımda bir adım yürüyün. Spesifik dosya isimlerini, fonksiyonları ve istek/yanıt şekillerini isteyin.

• "Login ekranı için React rota veya sayfasını bulun. Hangi bileşen render ediyor ve submit'te hangi eylem tetikleniyor?"
• "API istemci çağrısı nerede yapılıyor (fetch/axios/vb.)? Tam URL yolu, method, header'lar ve gönderilen body nedir?"
• "Go tarafında, bu path için handler nerede kayıtlı? Router kurulumunu ve handler fonksiyonunu gösterin."
• "Handler içinde input validasyonu nerede gerçekleşiyor (frontend, backend, her ikisi)? Hangi kurallar var ve hatalar nerede formatlanıyor?"
• "Login için hangi veritabanı sorgusu çalışıyor? Repository/SQL dosyasını gösterin, dokunulan tablolar/sütunları listeleyin ve transaction veya lock var mı not edin."

Her cevaptan sonra zihinsel haritanıza kısa bir satır yazın: "UI component -> API endpoint -> handler -> servis -> DB query -> response." Sadece "bir fonksiyon" demeyin; isimleri dahil edin.

Hızlı bir çalıştırmayla doğrulayın

Yolu elde ettikten sonra küçük bir test çalıştırmasıyla doğrulayın. Haritaladığınız kod yolunun gerçekten kullanılan yol olup olmadığını kontrol ediyorsunuz.

Tarayıcı geliştirici araçlarında ağ isteklerini izleyin (path, status kodu, response body). Handler ve DB çağrısı çevresine sunucu log'ları ekleyin (varsa request ID ile). PostgreSQL'de beklenen değişiklikleri sorgulayın (login için last_login_at, session'lar veya audit satırları olabilir). Bir başarısızlığı zorlayın (yanlış parola, eksik alan) ve hata mesajının nerede oluşturulduğunu ve nerede gösterildiğini not edin. Başarı ve hata için beklenen yanıtları kaydedin (status kodları ve önemli alanlar) ki bir sonraki geliştirici hızlıca temel kontrolleri yapabilsin.

Bu tek akış genelde sahiplik sınırlarını ortaya çıkarır: UI'nın neye güvendiği, API'nin neyi zorladığı ve hataların nerede kaybolduğu veya çift ele alındığı gibi.

Zihinsel haritayı kısa bir oryantasyon dokümanına dönüştürme

İyi bir zihinsel haritaya sahip olduğunuzda, bunu 1–2 sayfalık bir notta sabitleyin. Amaç tamamlayıcı olmak değil. Bir sonraki geliştiricinin şu soruları cevaplayabilmesini sağlamaktır: bu uygulama nedir, nereden bakmalıyım ilk, ve en olası kırılma noktaları neler?

Claude Code kullanıyorsanız dokümanı Soru&Cevap çıktınız olarak düşünün: net, somut ve hızlı taranabilir.

Basit 1–2 sayfalık yapı

Dokümanı tahmin edilebilir tutun ki insanlar hızlıca aradıklarını bulabilsin:

• Amaç: uygulamanın ne yaptığı, kullanıcı kitlesi ve "bitti" ne demek
• Mimari özeti: ana servisler, veri depoları ve isteklerin sistemde nasıl aktığı
• Çalıştırma: önkoşullar, başlatmak için tek komut ve testleri çalıştırmak için tek komut
• Nerede bulunur: önemli klasörler ve giriş noktası olan 5–10 dosya
• Ana akışlar ve riskler: önemli yolculukların kısa izleri ve değişiklik sonrası neyi doğrulamalı

Eyleme dönük yapın, akademik değil

"Nerede bulunur" için şunlar gibi işaretler verin: "Auth X'de başlar, oturum mantığı Y'de, UI rotaları Z'de." Tam bir ağaç dökümü atmayın. Sadece insanların dokunacağı yerleri seçin.

"Ana akışlar" için her adımı 4–7 adımda tutun: tetik, controller/handler, ana modül, DB çağrısı ve dış etki (e-posta gönderildi, durum güncellendi, iş kuyruğa alındı). Her adımda dosya isimlerini ekleyin.

"Riskli alanlar" için başarısızlık modunu ve en hızlı güvenlik kontrolünü (belirli bir test, smoke run veya izlenecek log) yazın.

Sonunda yeni birinin güvenle katkıda bulunmasını sağlayacak küçük ilk görevler listesi ekleyin:

• Bir metin değişikliğini veya doğrulama kuralını tek bir ekran içinde güncelleyin
• Tespit ettiğiniz karmaşık yardımcı fonksiyon için küçük bir birim testi ekleyin
• Repro'su ve beklenen sonucu net olan düşük riskli bir hatayı düzeltin
• Bir koruyucu ekleyin: daha iyi hata mesajı, giriş kontrolü veya timeout
• Üretim dağıtımlarından kim sorumlu, alan soruları için kimi etiketlemeli bilmek

Yaygın hatalar ve nasıl kaçınılır

Asistanı boşa harcamanın en hızlı yolu "tüm repoyu tam açıklama" istemektir. Uzun ama muğlak bir özet alırsınız. Bunun yerine önemli bir dilim seçin (bir modül + bir kullanıcı akışı) ve sonra dışa doğru genişletin.

İkinci sık hata, hangi yolculukların önemli olduğunu belirtmemektir. Eğer "checkout", "login" veya "admin edit" demiyorsanız, cevaplar genel mimari konuşmasına kayar. Her oturuma somut bir hedefle başlayın: "Signup akışını uçtan uca anlamama yardım et, validasyon, hata durumları ve verinin nerede saklandığı dahil." gibi.

Bir diğer tuzak, asistanın tahmin yapmasına izin vermektir. Bir şey belirsizse, bunu etiketlemesini zorlayın. Koddaki kanıt ile çıkarımını ayırmasını isteyin.

Bilinmeyenleri görünür tutun (çözülsün diye)

Notlarınızda basit bir kural kullanın: her iddia şu etiketlerden biriyle işaretlensin:

• Koddaki kanıtla doğrulandı
• Uygulamayı çalıştırarak doğrulandı
• Varsayım (kontrol gerekli)
• Bilinmiyor (bağlam eksik)

Notlar yapısız toplandığında işe yaramaz hale gelir. Tutarlı bir şablon kullanın: ilgili modüller, giriş noktası, ana fonksiyonlar ve dosyalar, dokunan veri, yan etkiler, hata yolları ve çalıştırılacak testler.

Çıktıları gerçek bilgi gibi ele almayın

Claude Code olsa bile çıktıyı taslak gibi kabul edin. Önemli akışları çalıştırarak doğrulayın; özellikle prod'u kırabilecek kısımları: auth, ödemeler, izinler, arka plan işler ve migration'lar.

Pratik örnek: asistan "şifre sıfırlama X üzerinden e-posta gönderir" diyorsa, bunu bir dev ortamında tetikleyip logları veya e-posta sandbox'ını kontrol ederek doğrulayın. Bu gerçek kontrol sizi gerçeğe uymayan bir hikâyede oryante olmaktan korur.

"Oryante oldum" demeden önce kısa kontrol listesi

Repoyu ezberlemeniz gerekmez. Güvenli bir değişiklik yapacak, gerçek bir sorunu debug edecek ve sistemi bir sonraki kişiye açıklayacak kadar güveniniz olmalı.

Oryante olduğunuzu söylemeden önce şu soruları tahmin etmeden cevaplayabildiğinizden emin olun:

• Kodun en önemli beş bölümünü ve her birinin neyi yönettiğini açıklayabiliyor musunuz? (ör. UI, API katmanı, arka plan işleri, veri erişimi, entegrasyonlar)
• İki yüksek değerli kullanıcı yolculuğunu uçtan uca anlatabiliyor ve her akışı başlatan ilk dosya veya fonksiyonu gösterebiliyor musunuz?
• Kimlik doğrulamanın nerede uygulandığını ve rollerin/izinlerin nerede tanımlanıp kontrol edildiğini gösterebiliyor musunuz?
• En riskli veritabanı yazımlarını (para, izinler, silme, durum geçişleri) isimlendirebiliyor ve her değişikliği güvenle nasıl test edeceğinizi tanımlayabiliyor musunuz?
• Yeni bir geliştiriciye 10 dakikada okuyabileceği kısa bir oryantasyon notu verip nereden başlayacağını söyleyebiliyor musunuz?

Eğer bir madde eksikse, geniş bir arama yerine küçük, odaklı bir geçiş yapın. Bir akışı seçin, veritabanı sınırına kadar izleyin, durun ve öğrendiklerinizi yazın. Bir şey belirsizse onu bir soru olarak kaydedin, paragraf yerine. "Role X nerede oluşturulur?" sorusu "auth kafa karışık" demekten daha faydalıdır.

İyi bir son test: bir özellik flag'i arkasına küçük bir özellik eklemeniz istendiğini hayal edin. Dokunacağınız dosyaları, çalıştıracağınız testleri ve izleyeceğiniz hata modlarını sayabiliyorsanız, katkıda bulunmak için yeterince oryante olmuşsunuz demektir.

Sonraki adımlar: haritayı güncel tutun ve devralmaları kolaylaştırın

Zihinsel harita yalnızca gerçeğe uyduğu sürece işe yarar. Bunu tek seferlik bir görev olarak değil, yaşayan bir belge olarak görün. Haritayı gerçeğe yakın tutmanın en kolay yolu, davranışı etkileyen değişikliklerden hemen sonra güncellemektir.

Hafif bir rutin büyük yeniden yazmalardan daha etkilidir. Yaptığınız işlere bağlı olarak güncelleme yapın:

• Her özellikten sonra: modül listesini ve dokunduğu ana kullanıcı akışlarını güncelleyin
• Her olaydan (incident) sonra: tetikleyiciyi, etkiyi ve tam düzeltme yerini ekleyin
• Her riskli refaktörden sonra: ne değiştiğini ve neyin uyumlu kaldığını not edin
• Bir sürümden önce: en riskli 3 alanı ve test yollarını tekrar kontrol edin
• Ayda bir: eski notları silin ve ana modüllerin sahiplerini teyit edin

Oryantasyon dokümanını koda yakın tutun ve aynı disiplinle versionlayın. Küçük diff'ler okunur; büyük doküman yeniden yazımları genelde atlanır.

Dağıtımlar riskliyse, bir sonraki kişinin hızlıca kurtarmasına yardımcı olacak bilgileri yazın: ne değişti, ne izlenmeli ve nasıl geri alınır. Platformunuz snapshot ve rollback destekliyorsa, snapshot adını, sebebini ve düzeltmeden sonra "iyi" olanın ne göründüğünü ekleyin.

Eğer Koder.ai (koder.ai) ile geliştiriyorsanız, planlama modu Q&A'den tutarlı bir modül haritası ve oryantasyon notu çıkarmanıza yardımcı olabilir; kaynak kodu dışa aktarmak da inceleme için temiz bir yol sağlar.

Son olarak, bir sonraki geliştiricinin tahmin yürütmeden takip edebileceği bir devralma kontrol listesi tanımlayın:

• Önce okunacaklar (2–3 dosya veya doküman) ve nedenleri
• Yerelde çalıştırılacaklar (komutlar, env var'lar, seed verisi)
• Doğrulanacaklar (bir mutlu yol ve bir hata durumu)
• Keskin kenarlar (riskli modüller, flaky testler, karmaşık konfigürasyonlar)
• Kimi ne için sormalarını sağlayan sahip listesi

İyi yapıldığında, Claude Code kod tabanı oryantasyonu bir alışkanlık haline gelir: her değişiklik bir sonraki kişi için daha net bir harita bırakır.