Claude Code ile Kod İncelemesi: Hataları Üretime Ulaşmadan Yakalayın

Claude Kod İncelemesi Nedir?

Claude Kod İncelemesi, bir PR’ı depo bağlamında inceleyen ve potansiyel hataları, güvenlik sorunlarını ve gerilemeleri raporlayan çok aracılı bir kod inceleme sistemidir. GitHub Code Review bu aracıları bir GitHub PR’ında çalıştırırken, yerel /code-review mevcut farkınızı doğrudan Claude Code’dan size sunar.

Buradaki önemli kelime bağlamdır. Geleneksel bir diff incelemesi, birinin değişen satırları incelemesini ister. Claude’un inceleme aracıları bu değişiklikleri deponun bağlamında değerlendirir. GitHub iş akışında paralel çalışan uzmanlaşmış birden çok aracı, ardından doğrulama, tekilleştirme ve önem derecesine göre sıralama yer alır.

Örneğin, bir pandas dönüşümündeki 10 satırlık bir değişiklik, yukarı akıştaki bir dbt modelinin oluşturduğu şemaya, bir Snowflake tablosunun tanecikliğine ve aşağı akıştaki bir panoya gömülü varsayımlara bağlı olabilir.

Claude ne bir PR’ı onaylar ne de engeller. GitHub Code Review nötr bir check sonucu raporlar; dolayısıyla mevcut dal koruma kurallarınız, kontrol çıktısı etrafında kendi CI mantığınızı kurmadığınız sürece değişmez.

Üç inceleme yüzeyi

Şu anda Claude Code ile kodu incelemenin 3 temel yolu var.

Yerel /code-review komutu dalınızdaki commit’leri inceler. Ayrıca belirli bir dosya, dal, PR numarası veya Git ref aralığı da verebilirsiniz.

GitHub Code Review PR’ın kendisi etrafında tasarlanmıştır. Depo yapılandırmasına bağlı olarak, PR oluşturulduktan sonra bir kez, her push’tan sonra veya yalnızca birisi @claude review ile inceleme istediğinde çalışabilir.

/code-review ultra daha ağır seçenektir. Anthropic bu özelliği ultrareview olarak adlandırır ve özellik hesabınızda açıksa /ultrareview bir takma ad olarak çalışır. Uzak bir kum havuzunda bir inceleme aracı filosu çalıştırır; bildirilen her hata, bulgulara eklenmeden önce yeniden üretilir ve doğrulanır. Şu anda bir araştırma ön izlemesidir ve tipik bir inceleme yaklaşık 5 ila 10 dakika sürer.

Claude’un işaretledikleri ve atladıkları

Claude Kod İncelemesi önce doğruluğa odaklanır. Anthropic’in dokümantasyonu, üretimi etkileyen hataları biçimlendirme tercihleri ve eksik test kapsamından özellikle ayırır.

Bulgular 3 önem derecesi kullanır:

Bu ayırtım yararlıdır; çünkü veri bilimciler, neyin inceleme zamanı hak ettiğine sıklıkla çok farklı bakar. revenue_df ile weekly_revenue arasındaki adlandırma önerisi, bir çoktan-çoğa join bir dönüşüme sızdığı için geliri 2 ile çarpmakla aynı kategoride değildir.

Claude Code’da Kod İncelemesini Nasıl Kurarsınız?

Claude Kod İncelemesini ayarlamak, yerel bir inceleme mi yoksa GitHub PR kod incelemesi mi istediğinize bağlı olarak farklı adımlar gerektirir. Yerel /code-review GitHub Uygulamasını gerektirmez ve PR açmadan önce yapılabilir. 

GitHub Code Review, bir kuruluşun Sahibi veya Birincil Sahibinin Claude GitHub Uygulamasını yapılandırmasını ve depoları seçmesini gerektirir. PR incelemeleri yaparken, yalnızca incelemeye özel kuralları tutan REVIEW.md adlı özel bir dosya oluşturmak isteyeceksiniz.

CLAUDE.md ve REVIEW.md

CLAUDE.md ve REVIEW.md farklı amaçlara hizmet eder ve bunları karıştırmak, gürültülü incelemeler oluşturmanın kolay bir yoludur.

CLAUDE.md, Claude’un görevler genelinde kullandığı genel proje yönergelerini içerir. Kod inceleme de bu yönergeleri okur ve yeni tanıtılan ihlaller, önemsiz olarak raporlanır.  Öte yandan REVIEW.md özellikle inceleme davranışı içindir ve inceleme araçlarına ekibinizin nelerin işaretlenmesini, atlanmasını veya Önemli olarak ele alınmasını istediğini söyler.

Bir Python veri deposu için, CLAUDE.md’yi depo yapısı, pytest’in nasıl çalıştırılacağı, dönüşümlerin pandas mı yoksa polars mı kullandığı ve SQL modellerinin nerede yaşadığı gibi konulara odaklı tutardım. 

İnceleme kurallarını ise REVIEW.md’ye koyardım. Olası kurallara birkaç örnek:

• “Her yeni dönüşüm için karşılık gelen bir test olup olmadığını kontrol edin.”
• “Kimlik bilgilerini asla log’lamayın."
• “Oluşturulan dosyaları atlayın.”

Küçük bir  REVIEW.md şöyle görünebilir:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

REVIEW.md’nizi odaklı tutmanızı öneririm; çünkü uzun yönergeler önemli kuralları sulandırabilir. Mevcut uygulama dosyayı düz yönerge olarak okur; bu nedenle kuralları içine doğrudan koymalı, @ kısayolunu kullanmamalısınız. 

Bu arada, yerelde geliştirme yaparken /code-review REVIEW.md’yi okumaz.  CLAUDE.md’yi takip eder; GitHub Code Review hattı ise incelemeye özel yönergeler için REVIEW.md’yi kullanır.

Aynı inceleme kurallarını yerelde ve GitHub’da istiyorsanız, genel kuralları CLAUDE.md’ye koyun ve gerekirse incelemeye özgü kuralları REVIEW.md’de tekrar edin.

Daha derine inmek için en iyi CLAUDE.md dosyasını yazma rehberimizi okumanızı öneririm.

GitHub Uygulaması ve tetik modu

GitHub Code Review, Claude’un yönetim ayarları üzerinden bir kuruluşun Sahibi veya Birincil Sahibi tarafından yapılandırılır. Yönetici Claude GitHub Uygulamasını kurmalı, depo erişimi vermeli, incelenecek depoları seçmeli ve sonra her depoya bir inceleme davranışı atamalıdır.

3 farklı tetik modu vardır:

Üçü için de bir istisna: Claude hiçbir zaman bir fork’tan gelen pull request’i otomatik incelemez. Birinin üzerine @claude review yazması gerekir.

Temmuz 2026 güncellemesi itibarıyla, manuel komutlar da değişti: 

• @claude review tek bir inceleme başlatır ve PR’ı gelecekteki push’lara abone etmez. 

• @claude review always bir inceleme başlatır ve PR’ı gelecekte push tetikli incelemelere abone eder.

• @claude review once çıplak komutla aynı şekilde davranır.

2026’nın başlarında Claude Kod İncelemesini öğrendiyseniz, eski eğitimler @claude review’un PR’ı gelecekteki incelemelere abone ettiğini söylemiş olabilir; ancak bu davranış Temmuz 2026’da değişti ve Eylül 2026 itibarıyla da geçerlidir.

Kuruluşun GitHub Code Review’una erişimi olmayan Pro ve Max kullanıcıları, Uygulamayı tamamen atlayıp yerelde /code-review ve daha derin bir inceleme için /code-review ultra kullanabilir.

/code-review ile Bir Farkı Yerelde Nasıl İncelersiniz?

Yerel /code-review komutu, PR açmadan önce mevcut dalınızı inceler. Ben daima bununla başlarım; çünkü hâlâ çalışırken sorunları yakalar ve başarısız CI’ı önleyebilir.

İncelenecek vaka

Bir e-ticaret depomuz olduğunu, sipariş tablosunda order_id, customer_id, order_date, status ve revenue bulunduğunu ve haftalık geliri hesaplamak için weekly_revenue.py yarattığımızı hayal edelim:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

İlk bakışta tuhaf görünen bir şey yok. merge() açık, grupla(n)dırma okunaklı ve gelir join’den sonra toplanıyor.

Sorun şu ki müşteri tablosu bazı müşteriler için birden çok tarihsel kayıt içeriyor. 2 kaydı olan bir müşteri, join sonrası 2 satır üretir ve o müşteriye bağlı geliri ikiye katlar. Bu, tablo tanecikliğini kontrol etmeden dönüşümü yerelde okurken gözden kaçması kolay bir hatanın tam karşılığıdır.

Farkın kapsamını belirleyin

Claude Code oturumunuzdan /code-review komutunu çalıştırın.

Komut, yukarı akış dalının önündeki mevcut dal commit’lerini ve commit’lenmemiş değişiklikleri inceler. Ayrıca belirli bir dosyayı, dalı, PR’ı veya main...feature/weekly-revenue gibi bir aralığı hedefleyebilirsiniz.

Örneğin:

/code-review weekly_revenue.py

ya da:

/code-review main...feature/weekly-revenue

Ayrıca /code-review high gibi bir efor düzeyi de verebilirsiniz. low ve medium seviyelerinde inceleme yalnızca en çok emin olduğu bulguları raporlar; high ile max arası ise kapsamı genişletir, ancak daha fazla yanlış pozitifle sonuçlanabilir. 

İncelemeyi yönlendirmek için bayrakları kullanın

İş akışına alıştıktan sonra iki bayrak işe yarar: 

• --fix bulguları incelemeden sonra çalışma ağacınıza uygular.

• --comment bulguları satır içi yorumlar olarak gönderir.

Claude incelemeyi arka planda bir alt aracı olarak çalıştırır; bu sırada siz değişiklik üzerinde çalışmaya devam edebilirsiniz. İnceleme bittiğinde bulgular oturumunuza döner.

İnceleme aşağıdakilere benzer bir şey raporlayabilir:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

İnceleme somut bir arıza biçimi buldu ve bana Claude’un yargısına güvenmek yerine gerçek şemaya karşı doğrulayabileceğim bir şey verdi.

Bulguları okuyun

/code-review --fix çalıştırmadan önce yine de her şeye elle bir göz atardım. Önce customers’ı oluşturan kodu arayın, eşsizlik kısıtlarını inceleyin ve weekly_revenue.py etrafındaki testlere bakın.

Eğer customers.customer_id gerçekten eşsizse, Claude’un bulgusu yanlış pozitif demektir. Tablo müşteri başına geçerli tarih başına bir satır içeriyorsa bulgu gerçektir ve dönüşümün değişmesi gerekir.

Buradaki kilit nokta, Claude’un inceleyicisinin kod davranışına baktığı; verinin neyi temsil ettiğini bilme sorumluluğunun ise hâlâ bende olduğudur.

İncelemeden sonra Claude’dan araştırmasını isteyebilirsiniz:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

Bu ikinci adım, Claude’dan yorumu körlemesine düzeltmesini istemekten genellikle daha faydalıdır. İncelemeyi bir kod üretme egzersizi yerine kısa bir araştırmaya çevirir.

Claude Kod İncelemesini Bir GitHub PR’ında Nasıl Çalıştırırsınız?

GitHub Code Review, Claude’un bulgularını doğrudan PR’a ekler; böylece inceleyenler sorunu değişen kodun yanında görebilir. 

Sıra önemlidir; çünkü inceleme, zaten var olan bir PR’a eklenir:

1. git push ile weekly-revenue dalını GitHub’a itin.

2. Pull request’i açın. Claude yalnızca açık bir PR’ı inceleyebilir; bu noktadan önce hiçbir şey olmaz.

3. Depo otomatik tetikleyiciye ayarlıysa inceleme otomatik başlar. Manuel’e ayarlıysa, başlatmak için üst düzey PR yorumu olarak @claude review gönderin.

Burada insanların tökezlediği üç gereklilik var. Komut bir üst düzey PR yorumu olmalı; satır içi bir inceleme yorumuna yanıt olmamalı ve depoda yazma, bakım veya yönetici izinlerine sahip olmanız gerekir. Komut ayrıca yorumu başlatmalı; once veya always eklenecekse aynı satırda olmalıdır.

İncelemeyi tetikleyin

Asıl maliyet oluşturan seçim, manuel ve otomatik arasındaki değil; iki manuel komut arasındadır.

@claude review bir inceleme çalıştırır ve PR’ı abone bırakır. @claude review always bir inceleme çalıştırır ve PR’a abone olur; böylece sonraki her push yeni bir inceleme başlatır.

Bu, Temmuz 2026 sonrası ve Eylül 2026 itibarıyla geçerli davranıştır. Bu güncellemeden önce, çıplak @claude review komutu PR’ı gelecekteki incelemelere abone ederdi; eski bir eğitim izliyorsanız önce bunu kontrol edin.

İnceleme genellikle yaklaşık 20 dakika sürer; ancak Anthropic, maliyet ve sürenin PR boyutu ve karmaşıklığına bağlı olduğunu söylüyor. Her inceleme ayrıca, Takım veya Kurumsal planın dahilî kullanımını tüketmek yerine kullanım kredileriyle ayrı ayrı faturalandırılır. Maliyet yapısı hakkında daha fazla bilgi isterseniz Claude Code kullanım sınırları rehberimizi okumanızı öneririm.

Satır içi yorumları ve check run’ı okuyun

İnceleme bittiğinde, Claude ilgili satırlara satır içi yorumlar gönderir. GitHub check run’ı ayrıca önem derecesi özetini içerir; bu, bir PR’ın weekly_revenue.py, SQL modelleri ve test dosyaları genelinde birden fazla bulguya sahip olduğu durumlarda kullanışlıdır.

Örneğin:

Satır içi yorumda gerçek sorunu araştırırım. Check run’da ise incelemenin genel resmini edinirim.

Not: 👍 ya da 👎 tıklamak yeni bir incelemeyi tetiklemez ve satır içi bir yoruma yanıt vermek Claude’un cevap vermesini sağlamaz. Yeni bir inceleme için kodu düzeltip push edin ya da yeni bir üst düzey PR yorumu olarak @claude review gönderin.

İnceleme kendi başına birleştirmeyi de engellemez. Check nötr bir sonuç sağlar; ancak çıktıda, ekiplerin isterse gh ve jq aracılığıyla kendi birleştirme kapılarını kurmak için kullanabileceği makinece okunabilir önem derecesi bilgisi bulunur.

Claude’un İnceleme Yorumlarını Nasıl Önceliklendirilirsiniz?

Tüm amaç, inceleme döngüsü sırasında insanı döngüde tutmaktır. Bu da her Claude incelemesinde, her bulgunun gerçek bir hata mı, engelleyici olmayan bir iyileştirme mi yoksa yanlış pozitif mi olduğuna karar verilmesi gerektiği anlamına gelir. Bunun nedeni, bir kod inceleyicisinin bir veri kümesi veya metrik arkasındaki her iş varsayımını bilmeden uygulama davranışını inceleyebilmesidir.

Basit bir üç yönlü karar kullanırım:

Bu son kategori önemlidir. 30 bulgu bildiren bir inceleyici, 5 bildiren birinden mutlaka daha iyi değildir. Bir pandas merge’ü hakkında yanlış pozitif bir yorum, asıl kod değişikliğinden daha fazla zaman kaybettirebilir.

Düzelt, atla veya geri it

Çoğaltılmış müşteri satırları hatası gerçekse, Claude’dan yukarı akış modelini incelemesini isteyebilir ve ardından şu düzeltmeyi talep edebilirim:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

Böylece Claude depoyu inceleyebilir, Python kodunu değiştirebilir, testi ekleyebilir ve test paketini çalıştırabilir.

GitHub inceleme yorumlarından çalışmak istiyorsanız, Claude Code depo ile GitHub CLI (gh) üzerinden de etkileşime geçebilir. Önemli ayrım şudur: “her şeyi düzelt” demek yerine, geçerli olduğunu düşündüğünüz belirli düzeltmeleri seçip uygulatırdım.

Bu, geliştiricileri inceleme döngüsünde tutar:

1. Claude olası bir sorun bulur.
2. Ben sorunu koda ve veri varsayımlarına göre doğrularım.
3. Claude istenen düzeltmeyi yapar.
4. Testler çalışır.
5. Claude ortaya çıkan farkı tekrar inceler.

Bu döngü, ilk inceleme çıktısını otomatik bir yeniden düzenleme kuyruğu gibi görmekten çok daha güvenlidir.

Bir veri PR’ı hâlâ insanı ne için gerektirir?

Claude’un kapsayamayacağı hata biçimi, kodun doğru çalışıp yine de yanlış şeyi yapmasıdır. Bunun üç sürümü tekrar tekrar karşımıza çıkar:

• Fark dışında yaşayan varsayımlar. Claude deponuzu okur; veri ambarınızı, yapılandırma servisinizi veya başka bir ekibin sahip olduğu sözleşmeyi değil. Bir join doğru anahtarları kullanıp yine de sonucun tanecikliğini değiştirebilir; çünkü anahtar başına satır sayısı, önünüzdeki kodun değil, yukarı akış tablosunun bir özelliğidir.

• Yalnızca ekibinizin bildiği tanımlar. Gelirin sipariş, müşteri veya hafta düzeyinde sayılması bir iş kararıdır. Claude, bir groupby()’nin kendisine verilen satırları memnuniyetle toplayacağını söyleyebilir. Finans ekibinizin hangi sayıya onay verdiğini söyleyemez.

• Zaman ve tür varsayımları. 2026-08-27 bir UTC günü mü, yerel iş günü mü, yoksa yukarı akış modelinin belirlediği bir raporlama tarihi mi? Sessiz zorlama da aynı görünümdedir: object, null olabilen tamsayı, saat dilimi bilgili datetime ve dize sütunları boyunca yapılan işlemler, karşılaştırmaların davranışını sessizce değiştirirken makul görünen bir şey döndürebilir.

Veri sızıntısı, ilk kategorinin en keskin örneğidir. Bir özellik dönüşümü, yalnızca tahmin tarihinden sonra var olan bilgileri içeren bir tabloyla bir eğitim setini birleştirebilir. Join geçerlidir, satır sayısı beklediğiniz gibidir ve model bozulmuştur.

Bu yüzden Claude’u uygulama davranışı inceleyicisi, tanımın sahibi değil, olarak ele alırım.

Kod İncelemesini Ne Zaman, Ultrareview’u Ne Zaman Kullanmalısınız?

Hızlı yerel geri bildirim için /code-review kullanın; daha derin bir birleştirme öncesi geçiş için /code-review ultra. İkisi de kodu inceler; ancak /code-review yineleme için tasarlanmıştır, ultra inceleme ise birden çok uzak aracı çalıştırır ve bildirilen hataları bağımsız olarak doğrular.

Anthropic, ultra incelemeyi hâlihazırda bir araştırma ön izlemesi olarak tanımlıyor. Pro ve Max aboneleri bir kereye mahsus 3 ücretsiz çalıştırma alır; sonrasında inceleme, değişiklik boyutuna bağlı olarak genelde 5$ ile 25$ arasına mâl olur. Takım ve Kurumsal kullanıcılar bu ücretsiz çalıştırmaları almaz ve özellik Amazon Bedrock, Google Cloud'un Agent Platformu, Microsoft Foundry üzerinde ve Zero Data Retention etkin olan kuruluşlarda kullanılamaz.

Önemli fark doğrulamadır. /code-review ultra, depo durumunu uzak bir kum havuzuna gönderir ve bir inceleme aracı filosu çalıştırır; bildirilen hatalar, bulgu olarak döndürülmeden önce bağımsız olarak yeniden üretilir.

Her commit’te çalıştırmazdım. Bir Python not defterinde bir değişken adını değiştiriyor ya da bir dbt modelinin biçimlendirmesini ayarlıyorsam yerel /code-review yeterlidir. Üretim modelinin özellik oluşturma mantığını değiştiriyorsam, bir gelir dönüşümünü yeniden yazıyorsam veya müşteri düzeyinde bir toplamayı değiştiriyorsam, ek inceleme turu daha mantıklı olur.

Doğru yapmak gereken bir adlandırma ayrıntısı da var. Belgelenen komut /code-review ultra’dır ve /ultrareview, ultrareview hesabınızda mevcutsa çalışan bir takma addır. Eski eğitimler sıklıkla /ultrareview’u birincil komut olarak sunar; ancak Anthropic’in dokümantasyonu artık derin bulut incelemesini /code-review komut ailesinin parçası olarak ele alır ve bulut özelliği kullanılamadığında /code-review ultra yerel incelemeye geri döner.

Aynı PR üzerinde ultra incelemeyi çalıştırın

Depodan şu komutu çalıştırın:

/code-review ultra

Bir GitHub PR’ını doğrudan incelemek için:

/code-review ultra <pr#>

Argümansız /code-review ultra, mevcut dalınızı varsayılan dal ile karşılaştırır ve commit’lenmemiş ve stage’lenmiş değişiklikleri içerir. Bir dal incelemesi varsayılan olarak yaklaşık 500 değişen dosya ve 8.000 değişen satırda sınırlandırılır; ancak Anthropic bu sayıların değişebileceğini not eder. Farkınız çok büyükse dalı push edin ve PR olarak inceleyin.

Bir PR numarasıyla, uzak ortam PR’ı GitHub’dan klonlar ve makinenizden hiçbir şey yüklenmez.

Başlamadan önce, Claude inceleme kapsamını, kalan ücretsiz çalıştırmaları ve tahmini maliyeti gösterir. Onaydan sonra inceleme arka planda çalışır; bu sırada uzak araçlar çalışırken Claude Code’u kullanmaya devam edebilirsiniz.

Bizim weekly_revenue.py örneğimiz için, daha derin incelemenin mutlaka doğru olduğunu varsaymak yerine bulguları karşılaştırırdım.

Eğer /code-review müşteri join’ini işaretler ve ultra inceleme aynı gelir çoğaltmasını bağımsız olarak yeniden üretirse bu bulguya güvenim artar. Ultra inceleme, yukarı akış tablosu eşsizlik garantisi verdiği için bunu yok sayarsa, kodu değiştirmeden önce her iki incelemenin kanıtlarını ve gerçek model tanımını incelerdim.

Birden çok inceleyicinin faydalı bir özelliği şudur: anlaşmazlık araştırmanız için size bir şey verir.

Bir de maliyet hususu var. GitHub Code Review şu anda inceleme başına ortalama 15$ ile 25$ arasında; ultra inceleme ise ücretsiz Pro ve Max çalıştırmalarından sonra genellikle 5$ ile 25$ arasında. GitHub Code Review maliyetleri, planlara dahil kullanımın dışındadır ve Anthropic kuruluşlar için harcama kontrolleri sağlar.

Tek başınıza çalışıyorsanız, yerel /code-review artı ara sıra /code-review ultra makul bir başlangıç iş akışıdır. Bir Takım veya Kurumsal plandaysanız ve her PR’ın otomatik bir inceleme taşımasını istiyorsanız, GitHub Code Review daha mantıklıdır.

Pratik Bir Claude Kod İnceleme İş Akışı

Faydalı iş akışı “her birleştirmeden önce Claude’u çalıştır” değildir. Her bir incelemenin geliştirme sürecinin farklı bir noktasında gerçekleştiği bir dizidir; çünkü her birinin maliyeti farklıdır ve farklı türde sorunları yakalar.

Üretimsel bir değişiklik için kullanacağım süreç şudur:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

Yerel inceleme, sorunları ucuzken yakalar. GitHub incelemesi, daha geniş ekibe bulguların paylaşılan bir kaydını sağlar; ultra inceleme ise önemli bir birleştirme öncesinde daha yüksek çabalı ikinci bir görüş sunar.

Veri bilimciler için ek kontroller

Veri işleri için, modelin tüm incelemeyi yapmasını beklemek yerine Claude’un etrafına 4 kontrol eklerdim:

• Önemli join’lerden önce ve sonra satır sayılarını ve veri kümesi tanecikliğini kontrol edin
• Dönüşümler ve özellik mantığı etrafında birim veya entegrasyon testleri çalıştırın.
• Makine öğrenimi özellikleri oluştururken sızıntıyı kontrol edin.
• İş metriklerini bilinen doğru bir sorgu veya panoya karşı doğrulayın.

Claude bu 4 faaliyetin hepsine katılabilir; ancak beklenen sonuç, Claude’un açıklamasından değil, koddan, testlerden veya veriden gelmelidir.

Son Düşünceler

Claude Kod İncelemesi en iyi, onu otomatik bir onay damgası değil, inceleme dizisindeki başka bir mühendis gibi ele aldığımda çalışır.

Yerel /code-review komutu, PR daha ortada yokken size hızlı bir inceleme sunar. GitHub Code Review, Takım ve Kurumsal kuruluşlar için çok aracılı bulguları PR’a getirir; /code-review ultra ise değişikliğin ikinci bir geçişi hak ettiği durumlarda daha derin bir uzak inceleme sunar.

Küçük başlayın derim. /code-review’u normal dal iş akışınıza alın, GitHub incelemeleriniz için kısa bir REVIEW.md yazın ve hatalı bir birleştirmenin size gerçekten bir maliyet çıkaracağı değişikliklerde /code-review ultrayı deneyin.

Temel model kavramları için Introduction to Claude Models kursumuz daha geniş bağlamı sağlar; GitHub Foundations ve Intermediate GitHub Concepts ise Kod İncelemesinin üzerinde çalıştığı Git ve GitHub iş akışını kapsar. Claude ile GitHub depolarını nasıl önceliklendireceğinize dair daha fazla ilham için Claude Code bağlayıcı eğitimimizi okumanızı da öneririm.