Gemini CLI mi, Claude Code mu: seçmeden önce kendi deponuzda deneyin

Gemini CLI, Google'ın terminal için geliştirdiği açık kaynaklı yapay zekâ ajanıdır. Claude Code da Anthropic'in yine terminalden kullanılan kodlama ajanıdır. İkisi de bir depoyu okur, dosya düzenler, komut çalıştırır ve dış araçlara bağlanır; ikisi de o kadar hızlı değişir ki özellik özellik yapılan her karşılaştırma birkaç hafta içinde eskir. Asıl yapılması gereken karşılaştırma, her birinin sizin kodunuzda, sizin kurallarınızla ve sizin inceleyicilerinizle nasıl davrandığıdır. Bu rehber birkaç günde yürütebileceğiniz bir deneme kuruyor ve onu dört soru etrafında topluyor: izin modeli, genişletilebilirlik, maliyet modeli ve inceleme akışı. Hâlâ terminal ajanı ile yapay zekâlı editör arasında karar veriyorsanız terminal ajanı mı, editör ajanı mı yazısıyla başlayın.

Adil bir deneme kurun

Oyuncak bir proje üzerinde yapılan gösterim size pek bir şey söylemez. Kendi deponuzu ve gerçek işleri kullanın:

1. Birikmiş işlerinizden beş ile sekiz arası görev seçin; farklı biçimleri kapsasınlar: yeniden üretimi bilinen bir hata, test yazılmamış bir modül için testler, küçük bir özellik, bir bağımlılık yükseltmesi, birkaç dosyaya yayılan bir yeniden düzenleme ve bir isteğin kodda nasıl aktığını açıklamak gibi düzenleme gerektirmeyen bir soru.
2. Hiçbir şey çalıştırmadan önce her görev için kabul ölçütlerini yazın: hangi testler geçmeli, ne değişmemeli, hangi dosyalar kapsam dışı. Kabul ölçütlerini önce yazmak notunda yeniden kullanabileceğiniz bir biçim var.
3. Her koşuyu aynı commit'ten, yeni bir dalda ya da çalışma ağacında başlatın; böylece hiçbir araç diğerinin bıraktıklarından yararlanmaz.
4. İki araca da eşdeğer proje talimatları verin. Her birinin talimat dosyaları için kendi düzeni var; aynı içeriği ikisine de koyun.
5. Her şeyi kaydedin: döküm, çalıştırılan her komut, her izin istemi, son fark, test sonuçları ve incelemeye harcadığınız dakikalar.
6. Mümkünse kör puanlayın. Bir ekip arkadaşınızdan farkları hangi aracın ürettiğini bilmeden incelemesini isteyin.

İzin modeli: sormadan ne yaptığını izleyin

Ayar sayfaları niyeti anlatır; deneme ise davranışı gösterir. Her araç için şunları gözlemleyin:

• Hiçbir ayarı değiştirmeden, yeni kurulmuş hâlde ne yaptığı.
• Onayların ne kadar ince ayarlı olduğu: komut başına, araç başına, oturum başına.
• Rutin komutları izin listesine alıp riskli olanları yasaklayıp yasaklayamadığınız; bu kuralların kullanıcı düzeyinde mi, depoya işlenmiş bir proje dosyasında mı, yoksa merkezi yönetim altında mı durduğu.
• Komutların bir korumalı alanda ya da konteynerde çalışıp çalışamadığı ve bunun ne kadar kurulum gerektirdiği.
• Her şeyi onaylayan bir mod olup olmadığı ve ekibinizin onu kapatıp kapatamayacağı.
• Proje dizini dışındaki dosyalara ve dizin içindeki gizli bilgilere nasıl davrandığı.

Ajanı politikanızın ötesine geçmeye özendiren bir görev de ekleyin; örneğin paket kurmanın onaya bağlı olduğu bir ortamda, yeni bir bağımlılıkla daha kolay çözülecek bir iş. Sorup sormadığına, kısıtlamanın etrafından dolaşıp dolaşmadığına ya da durup açıklama yapıp yapmadığına bakın. Test etmeye değer başlangıç politikasını ajanlara salt okuma ile başlayın notu anlatıyor.

Genişletilebilirlik: neyi ekleyebilirsiniz, kim denetler

İki araç da genişletilebilir. Her birinin MCP sunucularına nasıl bağlandığını, özel komutları ya da yeniden kullanılabilir talimatları destekleyip desteklemediğini, belirli noktalarda kendi betiklerinizi çalıştıran kancalar sunup sunmadığını ve bunların hepsinin depo üzerinden nasıl paylaşıldığını kontrol edin; her geliştirici aynı kurulumu almalı. Erişim kadar kapsam da önemlidir: genel olarak açılmış bir uzantı, olmaması gereken projeler dâhil her projede kullanılabilir.

Kaynak kodun erişilebilirliği de genişletilebilirliğin bir parçasıdır. Gemini CLI kodunu açık bir depoda yayımlıyor; hangi araç olursa olsun kaynağın erişilebilir olup olmadığını ve hangi lisansla sunulduğunu kontrol edin, çünkü kodu okumak makinenizde neyin çalıştığını bilmenin en doğrudan yoludur. Genişletme noktaları arasındaki genel ödünleşimler için MCP, beceri ya da CLI araçları yazısına bakın.

Maliyet modeli: bitmiş bir görevi fiyatlayın

Terminal ajanları farklı yollarla faturalanır: kişisel bir hesaba bağlı ücretsiz bir kullanım hakkı, bir abonelik, bir API anahtarı üzerinden ölçülen kullanım ya da bir kuruluşun bulut hesabı. Aynı deneme bir modelde ucuz, diğerinde pahalı görünebilir; bu yüzden fiyat sayfasından tahmin yürütmek yerine kullanımı kendiniz kaydedin. Yanıtlanması gereken sorular:

• Ekibiniz için hangi faturalama yolu geçerli ve hesabın sahibi kim?
• Bir sınıra ulaşıldığında ne oluyor: araç düzgünce duruyor mu, yavaşlıyor mu, başka bir modele mi geçiyor, yoksa bir düzenlemenin ortasında mı yarıda kalıyor?
• Oturum başına kullanımı görebiliyor ve kesin bir harcama sınırı koyabiliyor musunuz?
• Başarısız denemeler ve tekrarlar dâhil, tamamlanan her görev neye mal oldu?

Değere karşılık gelen rakam, kabul edilen değişiklik başına maliyettir. Tavan bir bütçe değil, bir güvenlik düzeneğidir; farkı ajan harcamasına tavan koymak notu açıklıyor.

İnceleme akışı: faturada görünmeyen saatler

Ajan destekli kodlamada en büyük maliyet çoğu zaman inceleyicinin dikkatidir. Deneme sırasında her aracın değişikliklerini nasıl sunduğunu, kendi düzenlemelerini geri alıp alamadığını, kendi başına commit atıp atmadığını, istenmeden test çalıştırıp çalıştırmadığını ve yarıda kalmış bir oturumu sürdürüp sürdüremediğinizi not edin. Sonra geriye ne kaldığına bakın: döküm dışa aktarılıp bir pull request'e eklenebiliyor mu, böylece sonraki inceleyici hangi komutların neden çalıştığını görebiliyor mu? Saklamaya değer asgari bilgiyi bir ajan denetim izi neleri kaydetmeli notu listeliyor.

Bir puanlama tablosu

Ağırlıklarda ilk koşudan önce anlaşın ve tabloyu hafızanızdan değil kayıtlarınızdan doldurun.

Seti farklı günlerde iki kez çalıştırın. Ajanlar belirlenimci değildir; tek bir koşu iki araçtan birini olduğundan iyi gösterebilir.

GoCux nerede durur

GoCux bir kodlama ajanı değildir ve kodlama ajanlarını sıralamaz. Değerlendirme sayfası bu rehberle aynı şeyi savunur: yalnızca yanıtı değil, işi değerlendirin. Ajan işinin tek bir geliştirici yerine bir ekip tarafından incelenebilir olması gerektiğinde, bir iş emri hedefi, kapsamı, kabul ölçütlerini ve çalışma süresi ile araç çağrısı sayısı gibi sınırları taşır; araç çağrısı sınırı sıfırsa hiç araç çağrısı yapılmaz. Her adım gerçekleştiği anda iş emrinin kaydına yazılır, harcama görünür krediler üzerinden günlük bir tavanla yürür ve kabul edilmiş bir iş emri, işin yapıldığının kanıtı sayılmaz: durumunu, ilerlemesini ve eklerini okursunuz.

Standart hâline getirmeden önce doğrulayın

• İki araç da aynı gerçek görevleri, aynı commit'ten ve eşdeğer talimatlarla çalıştırdı.
• Kabul ölçütleri ilk koşudan önce yazıldı.
• Yazılı izin politikanız her iki araçta da yapılandırılabiliyor ve depo üzerinden paylaşılabiliyor.
• Hiçbir araç yasak listenizdeki bir eylemi sormadan yapmadı.
• Faturalama yolunu, sınırdaki davranışı ve tamamlanan görev başına maliyeti biliyorsunuz.
• İnceleme süresi tahmin edilmedi, ölçüldü.
• Dökümler, ürettikleri değişikliklerle birlikte saklanabiliyor.
• Deneme birden fazla kez yapıldı ve farkları bir ekip arkadaşınız kör puanladı.