🏗️ CI/CD & Ekipte AI

CI/CD & Ekipte AI: Bir ekibin paylaşılan prompt kütüphanesi, paylaşılan bir Java utility sınıfına (bir StringUtils veya DateUtils'e) benzer — mekanizma birebirdir: her geliştiric

Bir ekibin paylaşılan prompt kütüphanesi, paylaşılan bir Java utility sınıfına (bir StringUtils veya DateUtils'e) benzer — mekanizma birebirdir: her geliştiricinin "Claude'a sınır değer test verisi nasıl yazdırırım"ı her seferinde sıfırdan, her defasında hafifçe farklı bir kaliteyle icat etmesi yerine, ekip BİR KEZ iyi ayarlanmış bir prompt şablonu yazar ve herkes onu tekrar kullanır — tıpkı test edilmiş bir utility zaten varken kimsenin kendi leftPad()'ini yeniden yazmaması gibi. Üzerinde durulmaya değer soru şu: ekipteki her tester zaten tek başına çalışan prompt'lar yazabiliyorsa, paylaşılan bir kütüphaneyi sürdürmeye neden zahmet edilsin? Çünkü "çalışan" ile "tutarlı şekilde iyi" farklı çıtalardır — paylaşılan bir şablon olmadan beş tester beş farklı kalitede Gherkin senaryosu veya bug raporu üretir, kimi belirsizlik-önce adımını atlar, kimi PII temizlemeyi atlar; paylaşılan, incelenmiş bir şablon sadece en iyi prompt yazarının tavanını değil, TÜM EKİBİN TABANINI yükseltir. Java karşılaştırması: bu, tekrarlanan bir kod parçasını her gelecek çağıranın elle doğru kopyalamasına güvenmek yerine, bir pull request'te bir kez incelenmiş paylaşılan bir utility metoduna çıkarmakla aynı akıl yürütmedir. QA tarafındaki bedel: paylaşılan bir prompt kütüphanesi olmayan bir ekip, aynı dersleri (negatif senaryo istemeyi unutmak, temizlenmemiş log yapıştırmak) bağımsız ve tekrar tekrar yeniden öğrenir — paylaşılan bir Page Object Model'e sahip olmamakla aynı sınıftan kaçınılabilir bir israf.

PR Review Döngüsünde Claude

Claude'u (GitHub Actions üzerinden veya elle) bir PR'ın ilk-geçiş incelemesi için kullanmak — bir diff'i özetletmek, bir commit/PR açıklaması taslağı yazdırmak, açıkça riskli bir değişikliği işaretletmek — insan incelemesinin YERİNE değil, ONA EK olarak yapılır. Merge kararının sahibi hâlâ insan reviewer'dır.

Akıl yürütme: "Claude bu PR'ı onayladı" neden bir kategori hatasıdır? Onay, bir değişikliğin BU kod tabanı, BU ekibin standartları ve BU release zamanlaması için güvenli olup olmadığına dair bir yargıdır — Claude'un tek bir diff'ten bunların hiçbirine tam görünürlüğü yoktur. Gerçek değeri, yorgun bir insan reviewer'ın kaçırabileceğini yüzeye çıkarmaktır (ele alınmamış bir edge case, eksik bir test) — bir ilk geçiş, nihai söz değil.

Ekip için Test Raporlarını Özetletme

Büyük bir test koşumunun başarısızlık özetini yapıştırıp Claude'dan bir standup veya ekip güncellemesi için kısa, okunabilir bir özet istemek gerçekten kullanışlıdır — ama "bir sayıyı tekrarlamadan önce doğrula" disiplini burada da geçerlidir: Claude "12 başarısızlık, çoğunlukla checkout modülünde" derse, bunu bir toplantıda gerçek diye tekrarlamadan önce gerçek rapora karşı doğrula.

Ekip Prompt Kütüphanesi Kurma

Bir prompt, Prompt Mühendisliği sekmesindeki iterasyon disipliniyle kendini kanıtladıktan sonra, onu tüm ekibin tekrar kullanıp geliştirebileceği paylaşılan, versiyon kontrollü bir dosyaya yükselt — paylaşılan bir utility metodunun inceleneceği gibi incelenir, kişiden kişiye gelişigüzel kopyala-yapıştır edilmez.

prompt-templates/test-case-from-story.md

Adım Adım: Ekip Prompt Kütüphanesinin Yaşam Döngüsü

Bir prompt'u iterasyonla olgunlaştır

Bir tester, gerçek bir görev için (Prompt Mühendisliği sekmesindeki disiplinle) güvenilir sonuç verene kadar bir prompt'u iyileştirir.

Yer tutuculu şablona dönüştür

İşe yarayan prompt, özellik adı gibi sabit detaylar yerine {{yer_tutucu}} içeren tekrar kullanılabilir bir şablona çevrilir.