Prompt-to-PR İş Akışı ile Claude Code: Küçük Diff'ler
Claude Code'u yerelde kullanarak Prompt-to-PR iş akışı: küçük promptlar yazın, küçük diff'ler gönderin, kontrolleri çalıştırın, hatalarda yeniden promptlayın ve merge'e hazır PR'lara ulaşın.
Prompt-to-PR İş Akışı ile Claude Code: Küçük Diff'ler | Koder.ai
Neden Prompt-to-PR tek seferlik büyük promptlardan daha iyi\n\nTek seferlik büyük promptlar genellikle büyük, dağınık değişikliklere yol açar: onlarca dosya dokunulur, alakasız refaktörler yapılır ve anlamaya zamanınız olmayan kod çıkar. Çıktı teknik olarak doğru olsa bile, ne değiştiğini ve nedenini anlamak zor olduğu için inceleme riskli gelir.\n\nKüçük diff'ler bunu engeller. Her değişiklik sınırlı ve odaklı olduğunda, birkaç dakika içinde okuyabilir, hataları erken yakalayabilir ve istemeden dokunulan şeyleri bozmayı önleyebilirsiniz. İnceleyiciler küçük PR'lara daha çok güvenir, bu yüzden onaylar daha hızlı ve az geri dönüşle gelir.\n\nPrompt-to-PR basit bir döngüdür:\n\n- Bir kerede net sınırları olan küçük bir değişiklik isteyin.\n- Diff'i kontrol edin ve niyete uyduğunu doğrulayın.\n- Olağan kontrollerinizi çalıştırın (testler, lint, build).\n- Bir şey başarısız olursa, eksik hata ve bağlamla yeniden promptlayın.\n- Merge'e hazır olana kadar tekrarlayın.\n\nBu kadans, hataları son anda sürpriz yerine hızlı geri bildirime çevirir. Claude Code'dan bir doğrulama kuralını ayarlamasını istiyorsanız, yalnızca o kurala bağlı kalın. Bir test başarısız olursa, başarısız olan çıktıyı yapıştırın ve testi geçen en küçük düzeltmeyi isteyin; tüm modülü yeniden yazmasını istemeyin.\n\nDeğişmeyen bir şey var: nihai koddaki sorumluluk sizde. Modeli hızlı yazan yerel bir eş programcı gibi davranın, bir oto pilot gibi değil. Ne gireceğine, neyin kalacağına ve PR'yi açmanın ne zaman güvenli olduğuna siz karar verirsiniz.\n\n## Depo ve yerel eş programlama kurulumunuzu hazırlayın\n\nTemiz bir tabandan başlayın. Eğer dalınız gerideyse veya testler zaten başarısızsa, her öneri tahmine dönüşür. En son değişiklikleri çekin, rebase veya merge yapın (ekibinizin tercihi neyse) ve ilk isteği yapmadan önce mevcut durumun sağlıklı olduğundan emin olun.\n\n"Yerel eş programcı" kurulumunda Claude Code depo dosyalarınızı düzenlerken hedefin, korunacak sınırların ve her diff'in kontrolü sizde kalır. Model kod tabanınızı bilmiyorsa, ona dosyaları, kısıtları ve beklenen davranışı açıkça gösterin.\n\nİlk prompttan önce hangi kontrollerin nerede çalışacağını kararlaştırın. Testleri yerel çalıştırabiliyorsanız, dakikalar içinde geri bildirim alırsınız ve yinelemeler küçük kalır. Bazı kontroller yalnızca CI'de çalışıyorsa (belirli lint kuralları, uzun testler, build adımları), her küçük değişiklikten sonra beklememek için CI'ye ne zaman güveneceğinizi belirleyin.\n\nBasit bir ön uçuş kontrol listesi:\n\n- Dalınızı güncelleyin ve uygulamanın derlendiğini veya başladığını doğrulayın.\n- Hızlı kontrolleri yerelde çalıştırın (lint, unit testler, type check).\n- Hangi kontrollerin sadece CI'de olduğunu ve ne kadar sürdüğünü not edin.\n- Sorunu yeniden üretebildiğinizi veya eksik özelliği açıkça görebildiğinizi doğrulayın.\n- Değişiklikleri kolay geri alabileceğinizden emin olun (temiz statü, küçük commitler).\n\nÇalışırken küçük bir not defteri açık tutun. "API değişikliği yok", "davranış geriye dönük uyumlu kalsın", "sadece X modülü dokunulsun" gibi kısıtları ve aldığınız kararları yazın. Bir test başarısız olduğunda, tam hata mesajını oraya da yapıştırın. Bu not defteri sonraki promptunuz için en iyi girdiye dönüşür ve oturumun sapmasını engeller.\n\n## Küçük diff'lara doğal olarak götüren promptlar yazın\n\nKüçük diff'ler kasıtlı olarak dar olan bir promptla başlar. Merge edilebilir koda giden en hızlı yol, bir saatte anlamanız gereken bir refaktör değil, bir dakikada inceleyebileceğiniz tek bir değişikliktir.\n\nİyi bir prompt, bir hedefi, kod tabanının bir alanını ve beklenen çıktıyı adlandırır. Değişikliğin nereye düşeceğini (dosya, klasör veya modül) gösteremiyorsanız, model tahminde bulunur ve diff yayılır.\n\nDeğişiklikleri sıkı tutan bir prompt şekli:\n\n- Hedef: değiştirmek istediğiniz tek davranış.\n- Konum: dokunulmasını istediğiniz dosya(lar) veya bileşen.\n- Kısıtlar: ne değişmemeli.\n- Kabul: "bitti" ne demek.\n- Diff boyutu: işe yarayan en küçük değişikliği açıkça isteyin.\n\nSınırlar gizli silahtır. "Giriş hatasını düzelt" yerine neyin sabit kalması gerektiğini belirtin: "API şekli değişmesin", "public fonksiyonlar yeniden adlandırılmasın", "sadece formatlama değişikliği yapma", "yeni bağımlılık ekleme". Bu, eşinizin nerede zekice davranmaması gerektiğini söyler.\n\nDeğişiklik hâlâ belirsizse, kod yerine önce bir plan isteyin. Kısa bir plan işi adımlara böler ve küçük bir ilk hamleyi onaylama şansı verir.\n\n```text
Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.
SSS
Prompt-to-PR iş akışında "küçük diff" ne sayılır?
Varsayılan: Bir cümlede açıklayabileceğiniz, küçük ve incelenebilir bir değişiklik hedefleyin.
İyi bir kural: hangi dosyanın/dosyaların değişeceğini öngörebiliyor ve tek bir hızlı kontrolle doğrulayabiliyor olmalısınız (hedeflenmiş bir test, lint veya hızlı bir çalıştırma). Yapamıyorsanız, görev hâlâ çok büyük—"çoğaltan bir test ekle" ve "bugı düzelt" gibi ayrı döngülere bölün.
Kodu istemeden önce bir plan istemeli miyim?
Evet—hedef belirsizse önce kısa bir plan isteyin.
Basit bir kapı mekanizması kullanın:
3 adımlık bir plan isteyin.
Sadece 1. adımı onaylayın.
Ardından sadece o adım için kod isteyin.
Bu, modelin tahminde bulunup ekstra dosyalara dokunmasını engeller.
Değişiklikleri odaklı tutmak için prompta ne eklemeliyim?
Model benden daha fazla dosyaya dokunursa ne yapmalıyım?
Hemen durun ve kapsamı küçültün.
Pratik adımlar:
Değişiklikleri geri alın.
Yeniden promptlayın: “Sadece X dosyasına dokun. Refaktör yok. İlgisiz formatlama yok.”
Gerekirse önce sadece başarısız eden testi eklemesini isteyin.
Çok geniş bir diff'i "testle çözmeye" çalışmak genellikle daha fazla zaman kaybettirir.
Döngü sırasında testleri ve diğer kontrolleri ne zaman çalıştırmalıyım?
Önce diff'i okuyun, sonra kontrolleri çalıştırın.
Basit bir sıralama:
Diff taraması (dokunulan dosyalar, kapsam kayması, yeni bağımlılıklar).
Hızlıca başarısız olabilecek en hızlı kontrol (lint/format veya hedeflenmiş bir unit test).
Typecheck/build gerekiyorsa.
(integration/e2e) temel kontroller geçtikten sonra.
Bir kontrol başarısız olduğunda en iyi yeniden-prompt yöntemi nedir?
Hatayı olduğu gibi yapıştırın ve en küçük düzeltmeyi isteyin.
Dahil edin:
Çalıştırdığınız tam komut.
Tam hata çıktısı / stack trace.
Bahsedilen dosya ve satır numarası.
Son diff'te neyi değiştirdiğiniz.
Kısıtlar (örneğin: “public API'leri değiştirme”).
"Hâlâ çalışmıyor" gibi belirsiz tekrarlar yerine bu detaylar kesin yama üretmeyi sağlar.
Prompt-to-PR'de son kodun sorumlusu kimdir?
Modeli hızlı bir yazıcı gibi değil, bir autopilot gibi değil sayın — son koddan siz sorumlusunuz.
Sorumluluklarınız:
Planı ve sınırları onaylamak.
Her diff'i incelemek.
Kontrolleri çalıştırmak.
Neresi güvenliyse onu merge etmek.
İyi bir alışkanlık: ne değişti, ne değişmedi ve neden diye kısa bir düz dil özeti istemek.
Refaktörleri ve bug düzeltmelerini aynı PR'da karıştırmalı mıyım?
Varsayılan olarak ayrı tutun.
Davranış değişikliği: bir commit.
Başarısız testi düzeltme / kapsama ekleme: sonraki commit.
İsteğe bağlı refaktör: ayrı PR veya daha sonra.
Refaktörleri davranış değişiklikleriyle karıştırmak gürültü oluşturur ve incelemeyi yavaşlatır.
İnceleyicilerin hızlı onaylayacağı bir PR açıklaması nasıl yazılır?
Kısa ve somut tutun:
Ne değişti (1–2 cümle).
Neden değişti (bug veya gereksinim).
Nasıl test edileceği (tam komutlar/adımlar).
Ne değiştirilmedi (beklentileri ayarlamak için).
Risk/geri alma notu.
PR'iniz "bir fikir, bir kontrolle kanıtlanmış" şeklinde okunursa genellikle hızlıca onaylanır.
Bu iş akışı Koder.ai içinde nasıl uygulanır?
Koder.ai aynı disiplini destekler ve birkaç faydalı özellik sunar:
Planlama modu: koddan önce girdileri, çıktıları ve kabul kriterlerini tanımlamak için.
Anlık görüntüler ve geri alma: kapsam kaydında deneyleri temizce geri almak için.
Kaynak kodu dışa aktarma: normal yerel araçlarınızı ve CI'ınızı çalıştırmak için.
Dağıtım/barındırma ve özel alan adları: uçtan uca doğrulama gerektiğinde.
Bunları küçük ve geri alınabilir yinelemeler yapmak için kullanın, sonra standart inceleme sürecinizle birleştirin.
- Değiştirdiğiniz alan için hedeflenmiş unit testler.
- Her şeyin uyduğunu doğrulamak için build veya typecheck.
- Temel geçtikten sonra daha yavaş testler (integration, e2e).\n\nBir şey başarısız olduğunda, düzeltmeye başlamadan önce iki şeyi kaydedin: çalıştırdığınız tam komut ve tam hata çıktısı (birebir kopyalayın). Bu kayıt bir sonraki promptu spesifik tutar ve "hala çalışmıyor" döngülerini önler.\n\nKapsamı sıkı tutun. Lint de hata veriyor ve testler de başarısız oluyorsa önce lint'i düzeltin, yeniden çalıştırın, sonra testleri ele alın. "Hızlı temizlikler" ile bir çöküş düzeltmesini aynı geçişte karıştırmayın.\n\n## Kontroller yeşil olana kadar hatalarla yeniden promptlayın\n\nKontroller başarısız olduğunda, hata çıktısını bir sonraki promptunuz olarak kullanın. En hızlı döngü: hatayı yapıştırın, teşhis alın, en küçük yamayı uygulayın, yeniden çalıştırın.\n\nHataları birebir yapıştırın; komut ve tam stack trace dahil. Claude Code en iyi performansı tam satır numaraları ve mesajlar üzerinden veriyor, tahmin etmek yerine bunun üzerine sabitlenince daha iyi çalışır.\n\nDaha önce denediklerinizi tek cümleyle ekleyin ki sizi tekrar aynı döngüye sokmasın. Önemli kısıtları tekrar edin ("Public API'leri değiştirme", "sadece çöküşü düzelt, davranışı değiştirme"). Ardından kontrolleri geçiren en küçük yama isteyin.\n\nÖnerilen düzeltme davranışı değiştiriyorsa, yeni davranışın doğru olduğunu kanıtlayan bir test isteyin. Bir handler artık 500 yerine 400 döndürüyorsa, eski kodda başarısız olan ve düzeltmeyle geçen tek odaklı bir test isteyin. Bu işi dürüst tutar ve PR'ın güvenilirliğini artırır.\n\nKontroller yeşil ve diff hâlâ tek bir fikir içeriyorsa durun. Model alakasız kodu geliştirmeye başlarsa yeniden promptlayın: "Sadece başarısız testi ele al. Temizlik yok."\n\n## PR'ı incelemeye ve merge'e hazır hale getirin\n\nBir PR, ne değiştiğinin, neden değiştiğinin ve nasıl doğrulanacağının açık olduğu zaman en hızlı şekilde merge edilir. Bu iş akışıyla PR kısa bir hikâye gibi olmalı: küçük adımlar, net sebepler.\n\nCommit'leri yinelemelerinizle hizalayın. Bir davranış değişikliği istedinizse, onu tek commit yapın. Sonra başarısız testi düzelttiyseniz bunu bir sonraki commit yapın. İnceleyiciler yolu takip edebilir ve ekstra değişiklikleri gizlemediğinize güvenebilir.\n\nCommit mesajlarını dosya adlarından ziyade niyet için yazın. "Oturum süresi dolduğunda giriş yönlendirmesini düzelt", "auth middleware güncellendi" yazmaktan daha iyidir. Mesaj kullanıcıya yönelik sonucu adlandırdığında, inceleyiciler daha az tahminde bulunur.\n\nRefaktörleri davranış değişiklikleriyle aynı committe karıştırmayın. İsim değiştirme veya yardımcı taşıma gerekiyorsa ayrı yapın (veya şimdilik atlayın). Gürültü incelemeyi yavaşlatır.\n\nPR açıklamasında kısa ve somut olun:\n\n- Ne değişti (1–2 cümle).
- Neden değişti (bug veya gereksinim).
- Nasıl test edilir (tam adımlar, varsa bayraklar veya veriler).
- Ne değiştirilmedi (beklentileri belirlemek için).
- Risk veya geri alma notu.\n\nÖrnek: bir faturalama sayfası çöküşü null müşteri kaydı yüzünden. Commit 1 bir guard ve net bir hata durumu ekler. Commit 2 null durum için bir test ekler. PR açıklaması: "Billing sayfasını açın, profili olmayan bir müşteri yükleyin, sayfanın yeni boş durumu gösterdiğini doğrulayın." Bu tür PR'lar genellikle hızlı onaylanır.\n\n## Sizi yavaşlatan yaygın tuzaklar\n\nBu kadans, kapsam sessizce genişlediğinde bozulur. "Bu başarısız testi düzelt" diye başlayan bir prompt "modül genelinde hata işleme iyileştir"e dönüşürse, aniden niyeti belirsiz büyük bir diff incelemek zorunda kalırsınız. Tek hedef, tek değişiklik seti, tek kontrol kuralını koruyun.\n\nBir diğer yavaşlatıcı, güzel görünen refaktörleri olduğu için kabul etmektir. Yeniden adlandırmalar, dosya taşımaları ve stil değişiklikleri incelemede gürültü oluşturur ve gerçek davranış değişikliğini fark etmeyi zorlaştırır.\n\nYaygın tuzaklar:\n\n- Modelin "buradayken" diyerek alakasız dosyalara dokunmasına izin vermek.
- Semptomları düzeltmek (fazla null kontrolleri) yerine testin işaret ettiği kök nedeni ele almamak.
- Sadece logların son satırlarını yapıştırıp ilk hatayı gizlemek.
- Kontrolleri çalıştırmadan önce hızlı bir diff taramasını atlamak.
- Tam komut ve çıktı yerine "hala çalışmıyor" diye yeniden promptlamak.\n\nSomut bir örnek: bir test "expected 400, got 500" diye başarısız oluyorsa, sadece stack trace'in sonunu yapıştırırsanız genelde genel try/catch önerileri alırsınız. Tam test çıktısını yapıştırırsanız gerçek sorunu görebilirsiniz: eksik bir doğrulama dalı. Bu küçük, odaklı bir diff'e götürür.\n\nCommit etmeden önce diff'i bir inceleyici gibi okuyun. Her satır isteğe hizmet ediyor mu ve bir cümleyle açıklayabiliyor muyum diye sorun. Değilse, ekstra değişiklikleri geri alın ve daha dar bir istekle yeniden promptlayın.\n\n## Örnek: birkaç döngüde merge edilebilir bir bug fix\n\nKullanıcı bildiriyor: "Ayarlar sayfası kaydedildikten sonra bazen varsayılanlara sıfırlanıyor." Siz main'i çekersiniz, testleri çalıştırırsınız ve bir başarısızlık görürsünüz. Ya da test yoksa, açık bir repro vardır.\n\nBunu bir döngü olarak ele alın: bir küçük istek, bir küçük diff, sonra kontroller.\n\nÖnce Claude Code'a en küçük faydalı bağlamı verin: başarısız test çıktısı (veya tekrar üretme adımları), şüphelendiğiniz dosya yolu ve hedef ("sıfırlamayı düzelt, davranışı aynı tut"). Teşhis ve minimal bir yama isteyin, refaktör değil.\n\nSonra kısa döngülerde çalışın:\n\n1) **Döngü 1 (minimal yama):** Sorunu makul şekilde düzeltebilecek en küçük değişikliği uygulayın. Sıkı tutun: bir guard, eksik bir null kontrolü, yanlış bir varsayılan veya hatalı bir bağımlılık listesi olabilir.\n\nDiff'i inceledikten sonra kontrolleri çalıştırın.\n\n2) **Döngü 2 (tam hatayı geri besleme):** Testler başarısız olursa, başarısız çıkan tam çıktıyı Claude Code'a yapıştırın. Dosya adı, satır numarası ve assertion mesajını dahil edin. Sorun: "Bu hatayı mevcut kapsamı genişletmeden en küçük nasıl düzeltiriz?" diye sorun.\n\nEğer kontroller geçerse ama regresyonlardan endişe ediyorsanız, kapsama ekleyin.\n\n3) **Döngü 3 (test ekleme veya düzeltme):** Yamadan önce başarısız olan ve yamayla geçen bir test ekleyin. Hedef sadece o bug olmalı. Kontrolleri tekrar çalıştırın.\n\nİşinizi küçük bir PR açıklamasıyla paketleyin: bug neydi, neden oldu ve ne değişti. "Sadece X dosyasına dokunuyor" veya "sıfırlama vakası için bir test ekledim" gibi bir inceleyici notu ekleyin ki inceleme güvenli hissetsin.\n\n## PR'ı açmadan önce hızlı kontrol listesi\n\nPR açmadan hemen önce işi kolay incelenir ve güvenle merge edilir hale getirmek için son bir geçiş yapın.\n\n- Diff orijinal hedefle eşleşiyor ve birkaç dakikada anlaşılabilecek kadar küçük.\n- İlgili kontrolleri (testler, lint, typecheck, build) çalıştırdınız ve geçti. Ekip CI kullanıyorsa, aynı setin orada çalışacağını doğrulayın.\n- İşin uygun güvenlik ağı var: mümkünse bug veya özellik için bir test eklendi ya da test eklememenin açık bir nedeni belirtildi.\n- PR açıklaması spesifik: ne değişti, neden değişti ve doğrulama adımları.\n- Hızlı geçiş düzenlemeleri veya alakasız refaktörler yok.\n\nHangi öğe başarısız olursa, bir küçük döngü daha yapın: küçük bir diff oluşturun, kontrolleri tekrar çalıştırın ve PR notlarını güncelleyin. O son döngü genelde saatler süren karşılıklı yazışmaları kurtarır.\n\n## Sonraki adımlar: Bu kadansı alışkanlık haline getirin\n\nTutarlılık iyi bir oturumu güvenilir bir iş akışına çevirir. Varsayılan bir döngü seçin ve her seferinde aynı şekilde uygulayın. Bir hafta sonra promptlarınız kısalacak ve diff'lerinizin incelenmesi kolaylaşacaktır.\n\nBasit bir rutin:\n\n- Tek bir küçük hedef seçin (bir bug, bir kenar durumu, bir fonksiyon).
- Bir küçük diff ve kısa bir açıklama isteyin.
- İnceleyici gibi diff'i okuyun, sonra yerel kontrolleri çalıştırın.
- Tam hata çıktısı ve dosya adlarıyla yeniden promptlayın.
- Kontroller yeşil ve değişiklik net olunca durun.\n\nKişisel bir prompt şablonu sizi disiplinli tutar: "Sadece gerektiği kadar değiştir. En fazla 2 dosyaya dokun. Kamu davranışı aynı kalsın, aksi belirtilmedikçe. Çalıştırılacak komutu ve başarı kriterini belirt."\n\nEğer Koder.ai içinde geliştiriyorsanız, aynı döngüyü sohbet arayüzünde kullanabilirsiniz. Planlama modu en küçük mergeable dilimi (girdiler, çıktılar ve kabul kontrolleri) belirlemek için uygundur; anlık görüntüler ve geri alma deneyleri tersine almayı kolaylaştırır.\n\nDeğişiklik stabil olduğunda kaynak kodunu dışa aktarın, normal yerel araçlarınızı, CI'ınızı ve ekip incelemenizi çalıştırın. Gerçek dünya doğrulaması gerektiğinde dağıtımı yapın.\n\nDöngüyü varsayılanınız yapın. Küçük promptlar, küçük diff'ler, sık kontroller ve hızlı düzeltmeler birleşince sıkıcı ama güvenilir PR'lar ortaya çıkar.
Diff kısıtı: “minimal diff, refaktör yok, yalnızca formatlama düzenlemeleri yok.”
Bu yapı doğal olarak kapsamı sınırlar ve incelemeyi hızlandırır.
Yavaş suite'ler
Bu, döngüyü sıkı tutar ve hataları yorumlamayı kolaylaştırır.
