Jev Code Reviewer, GitHub diff’lerinin yanına öncelik koyuyor
Jev inceleme önceliğini belirlerken OpenAI değişiklik açıklamalarını yazıyor. Yerel GitHub eklentisinin yararlı triyaj fikrini; kapsam, gizlilik ve güven sınırlarıyla inceliyoruz.

Bu yazıda
Bir ajan onlarca dosyayı değiştiren bir pull request açtığında, bir duvar dolusu yeni inceleme metni asıl sorunu büyütebilir: İnsan önce nereye bakmalı? Jev Code Reviewer daha dar bir iş üstleniyor. Yerel komut satırı aracı pull request’i analiz ediyor; Chrome eklentisi de GitHub’ın mevcut dosya görünümüne öncelik rozetleri ve değişiklik özetleri yerleştiriyor. Proje 25 Eylül’de Hacker News’te tartışmaya açıldı; bu tartışma tarihi geliştirme veya ilk sürümün ne zaman başladığını göstermiyor.
Tasarım iki işi iki sağlayıcı arasında paylaştırıyor. TypeSafe’in Jev’i yapılandırılmış bir öncelik sinyali döndürüyor. Projenin politikası bunu P0 (insan incelemesi gerekli), P1 (önerilir) ya da P2 (mekanik veya iyi desteklenmiş) olarak eşliyor. OpenAI ise doğal dilde gösterilen alanları yazıyor: eski mantık, yeni mantık, nelerin değiştiği ve neden insanın dikkat etmesi gerekebileceği. Bu ayrım önemli. Jev’den inceleme paragrafı yazması istenmiyor; önceliği de açıklamayı üreten model belirlemiyor. Yine de iki çıktı da yanlış olabilir ve akıcı bir açıklama, hatalı sınıflandırmayı olduğundan inandırıcı gösterebilir. Mimari belgesi iki sağlayıcının rolünü ve eşleme politikasını açıklıyor.
İnceleme akışı nasıl işliyor?
| Aşama | Projenin yaptığı | Uygulamadaki sınır |
|---|---|---|
| Analiz | Yerel CLI, mevcut klon ve GitHub CLI ile PR’ı inceliyor; Jev değişiklik birimlerini sınıflandırıyor, OpenAI açıklamalarını hazırlıyor. | Varsayılan olarak yol sırasındaki ilk 12 diff hunki analiz ediliyor; --max-units sınırı 100’e çıkarabiliyor. Kalan değişiklikler GitHub kodu olarak duruyor. |
| Gösterim | Yerel sunucu raporu, elle yüklenen Chrome eklentisiyle eşleştiriyor; eklenti diff tablolarını eski/yeni mantık kartları ve öncelik rozetleriyle değiştiriyor. | GitHub’ın klasik Files changed sayfası destekleniyor; yeni /changes görünümü desteklenmiyor. P1 ve P2 başlangıçta kapalı; varsayılan açık olan yalnızca P0. |
| Kontrol | İnceleyen kişi tek anahtarla özgün koda dönebiliyor; rapor eskiyse veya erişilemiyorsa GitHub diff’i ekranda kalıyor. | Kartlar okumayı kolaylaştırıyor; doğruluk kontrolü veya birleştirme kararı vermiyor. |
Son sınırı akılda tutmak gerekir. Düşük öncelikli bir değişiklikte de güvenlik açığı olabilir; P0 rozeti yalnızca “buraya bak” anlamına gelir, hata bulunduğunu kanıtlamaz. Önceliklerin anlamı ayarlanabildiği için ekiplerin kategorileri tanımlaması ve sıralamanın kendi risklerine uyup uymadığını ölçmesi gerekir. Kaynak diff’ine tek anahtarla dönebilmek iyi bir güvence; yine de kodu okuma işini ortadan kaldırmıyor.
Yerel arayüz, sağlayıcılara giden analiz
“Yerel” ifadesi CLI’ı, rapor önbelleğini, sunucuyu ve tarayıcı bağlantısını tarif ediyor. Canlı analiz çevrimdışı çalışmıyor: README, değiştirilen kodun ve yakın bağlamın TypeSafe ile OpenAI’ye gönderildiğini açıkça belirtiyor. Mimari belgesi isteğe bağlı Graphify bağlamından da söz ediyor. Özel kaynak kod göndermeden önce iki sağlayıcının veri koşullarını değerlendirmek gerekir. Proje, kimlik bilgilerinin depo dışında ve yalnızca dosya sahibinin erişimine açık biçimde tutulduğunu, ancak diskte şifrelenmediğini söylüyor.
Birlikte gelen kayıt, küçük bir demo pull request’i üzerindeki inceleme arayüzünü gösteriyor. Öncelik sınıflandırmaları Jev’den alınmış; açıklama metinleri ise demo için önceden hazırlanmış. Kayıt sırasında yapılandırılmış OpenAI projesi credit_balance_exhausted hatası vermiş. Depodaki demo kaynak notu bu ayrımı belgeliyor. Dolayısıyla video, arayüzün tanıtımı; ekranda görülen açıklamaların canlı OpenAI çağrısıyla üretildiğine dair kanıt değil.
Küçük bir pilotla sınamak
İnceleme dikkati gerçekten sınırlı olduğunda, örneğin risk düzeyleri farklı çok sayıda üretim değişikliği bulunan bir PR’da bu fikir daha anlamlı. Pilot çalışmada öncelik sıralaması deneyimli bir insanın incelemesiyle karşılaştırılmalı; P1/P2 altında kalan yüksek önem dereceli hatalar, özetlerin davranış değişikliğini ne sıklıkta atladığı ölçülmeli. Mekanik değişiklikler, ince yetkilendirme farklılıkları ve yanıltıcı yorumlar da test kümesinde yer almalı. Böylece triyajın diff’i yalnızca daha kısa gösterip göstermediği değil, önemli davranışı bulmaya yardımcı olup olmadığı anlaşılır.
Karşılaştırma için bir başlangıç ölçütü de gerekli: ekibin bugünkü inceleme yöntemi, basit bir dosya yolu ya da kural filtresi ve öncelik belirlemeden yorum yazan bir model. Karışıklık matrisiyle takip için harcanan süre kaydedilmeli; sonuçlar değişiklik türlerine göre karşılaştırılmalı. Aksi hâlde sistem, biçimlendirme değişikliklerini öne çıkarırken daha seyrek görülen bir mantık hatasını kaçırarak başarılı görünebilir. Kullanım genişletilmeden önce bu puan kartı temsil gücü olan ve izinli bir örnek kümede oluşturulmalı.
Depo, sağlayıcı çağrısı yapmayan bir oynatma için npm run demo komutunu sunuyor. Gerçek bir pull request’i incelemek için yerel klon, GitHub CLI erişimi, TypeSafe ve OpenAI anahtarları ile elle yüklenen Chrome eklentisi gerekiyor. Bu yazı için iki yolu da çalıştırmadık; değerlendirme kaynaklara dayanıyor, uygulamalı test değil. Benimsemeden önce ilk kontrol basit: hangi dosya ve bağlamın makineden çıktığını netleştirin; sonra rozetlerin gerçek bir incelemeyi etkilemesine izin vermeden, öncelikleri insan incelemesinden geçmiş bir örnekle karşılaştırın.
Kaynaklar
- Jev Code Reviewer README ve hızlı başlangıç ↗Jev-Reviewer katkıcıları
- Jev Reviewer mimarisi ve veri sınırları ↗Jev-Reviewer katkıcıları
- Birlikte gelen demo kaydının kaynağı ↗Jev-Reviewer katkıcıları
- Jev Based Code Review — 25 Eylül 2026 Hacker News tartışması ↗Hacker News
- Depo MIT Lisansı ↗Jev-Reviewer katkıcıları
AI desteğiyle hazırlandı.
Düzeltme öner
Bir hata veya eksik kaynak mı fark ettin? Editöre özel bir öneri gönder. Önerin incelenir ve herkese açık bir yorum olarak yayımlanmaz. Ad, e-posta veya hesap gerekmez.



Bize mesaj gönder