13 Ekim 2026'dan bu yana genel kullanıma açık olan Gemini 4 Argon, Google'ın çıktı üst sınırını 64 bin token'dan yaklaşık 1 milyona çıkararak modelin "tek bir yörüngede yüz binlerce token üretmesine" olanak tanıyor. Bunun nasıl yapılacağı Google’ın geliştirici kılavuzunda açıklanıyor. Standart bir istek, varsayılan olarak yine 65.536 çıktı token'ında duruyor. Interactions API üzerinde background: true ile max_output_tokens değerini daha yüksek ayarladığınızda sunucu, girdiniz düşüldükten sonra 1.048.576 token'a varan sınıra ulaşana kadar 64 bine varan adımlarla üretim yapmaya devam ediyor. Google, zorlu prompt'ların dakikalar sürebileceği konusunda uyarıyor.
Duyuru yazısında iki kez okunmaya değer satır bu sınır değil; Google'ın bu büyüklükteki bir çıktıyla neler yaptığı. Google, Argon'u dahili olarak C/C++'tan Rust'a geçiş süreçlerinde kullandığını belirtiyor. Bu geçişler "re2, libgav1 gibi çekirdek kütüphanelerdeki on binlerce satırdan, Fuchsia Zircon çekirdeğindeki 800 bini aşkın satıra kadar" uzanıyor ve yapılan bu yeniden yazımların "canlı ortama alınmadan önce titiz otomatik ve manuel denetimlerden, emülasyon testlerinden ve incelemelerden geçtiği" ifade ediliyor. Modeli eğiten laboratuvar bile üretime almadan önce inceleme yapıyor. Artık on altı kat daha yüksek bir tavan altında sonuç döndürebilen ajanlara sahip bir ekibin, modele ihtiyaç duymadan önce bir inceleme planına ihtiyacı var.
Özetle
Bir milyon token'lık çıktı sınırı, darboğazı kod üretme aşamasından kodu onaylama aşamasına taşıyor. Tek bir çalıştırma artık bu kadar çok sonuç döndürebildiğine göre; işi, bir insanın tek oturuşta inceleyebileceği Görevlere bölün, her birine yazılı bir tamamlanma tanımı ve Görev başına zaman aşımı belirleyin, her Görev için kanıt talep edin ve işe önce inceleme kapasitesi matematiğini yaparak başlayın. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar ise yönü belirler, yetki verir ve sonucu onaylar.
Tek bir çalıştırma bu kadar çok sonuç verebildiğinde neler değişir?
İnceleme kapasitesi, bir ekibin bir günde okuyabileceği, değerlendirebileceği ve onaylayabileceği tamamlanmış ajan çıktısı sayısıdır ve bu kapasiteyi model değil, insanlar belirler. Daha yüksek bir çıktı sınırı, yalnızca tek seferde ne kadar işin gelebileceğini artırır.
Eski tavan sınır, farkında olmadan bir kapsam kontrolü işlevi görüyordu: Bir yanıt yalnızca belirli bir uzunlukta olabiliyordu, bu nedenle işler aralarında duraklama noktaları bulunan parçalar halinde geliyordu. Google'ın yeni sınır için öne sürdüğü gerekçe ise tam tersi bir yönü işaret ediyor: "zorlu problemleri tek seferde çözebilmek" için alan açmak. Ancak incelemeyi yapan kişi için "tek seferde" demek; tek bir sonuç, tek bir karar ve bir insanın "yanlış yöndesiniz" diyebileceği hiçbir kontrol noktasının olmaması anlamına gelir.
Ayrıca bu tavan sınır paylaşımlıdır. Argon'un 1.048.576 token'lık penceresi girdi, düşünme (thinking) ve çıktı süreçlerini birlikte kapsar; bu nedenle 300 bin token'lık kod okuyan bir çalıştırmanın düşünme ve yazma için geriye yaklaşık 748 bin token'ı kalır. Bu da hâlâ bir insanın tek oturuşta satır satır okuyabileceğinden çok daha fazlasıdır.
Bir de kalite meselesi var. Duyuru sırasında Bloomberg, kimliği belirsiz Google çalışanlarının Argon'un kıyaslama testlerine kıyasla bazı kodlama ve ön yüz çalışmalarında beklentilerin altında kaldığını söylediğini aktardı; Google ise bunun gerçeği yansıtmadığını belirtti. Google'ın kendi tablosunda bile Argon, dört otonom kodlama kategorisinden ikisinde geride kalıyor (karşılaştırmamızda bunların detaylarını ele alıyoruz). Bir benchmark testi, yalnızca belirli bir test kümesine dair bir iddiadır. Kod farkınız (diff) ise doğrudan kendi kod tabanınıza dair bir iddiadır ve hangi model yazmış olursa olsun ancak kanıta dayalı olarak kabul edilir.
Token bütçesini değil, Görevin kapsamını belirleyin
Kontrol ettiğiniz birim token sayısı değil, Görev'dir. İşin boyutunu modelin tavan sınırının belirlemesine izin verirseniz, üretebileceği en büyük sonucu alırsınız. Sınırı siz belirlerseniz, bir insanın onaylayabileceği sonuçlar elde edersiniz. Google'ın kendi rehberi de bunu doğrulamaktadır: Standart görevler için 65.536 varsayılan sınırını koruyun; karmaşık akıl yürütme ve kodlama için maksimumu değil, 131.072 veya 262.144 token ile arka plan modunu kullanın.
Google'ın kendi açıklaması bile işi kütüphanelere ve çekirdeğe bölmektedir. Bir taşıma işlemini siz de aynı şekilde bölün: Bir incelemecinin tek oturuşta bitirebileceği, modül başına bir Görev. Sharkly'de bu, her modül için bir alt görevi olan bir ana Görev ve bir modülün diğerinden önce tamamlanması gereken durumlar için "engeller / engellenir" bağlantıları anlamına gelir. Hedef, kapsam ve kabul kriterleri, hem Ajan hem de incelemeci için Görev açıklamasında yer alır:
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
İki Ajan ayarı bu yaklaşımı destekler. Görev başına zaman aşımı, modele göre değil Göreve göre belirlenir: Bir modül için makul en uzun çalışma süresinin üzerinde, ancak faturasını ödemekten pişman olacağınız sürenin altında olmalıdır. Maksimum eşzamanlılık (atanan görevler), aynı anda işlenen modül sayısını sınırlar; çünkü aynı anda çalışan kırk alt görev, aynı incelemeciyi bekleyen kırk farklı sonuç üretir.
Karar mekanizması basittir: Bir derleyici ve eksiksiz bir test paketiyle desteklenen mekanik bir yeniden adlandırma gibi otomatik kontrollerin tüm sonucu kapsayabildiği durumlarda, tüm işi tek bir çalıştırmaya verin. Bir insanın herhangi bir kısmı değerlendirmesi gerektiğinde ise işi bölün ki bir dil geçişinde işin büyük kısmı tam olarak budur. Mesainizden daha uzun süren çalıştırmalar da aynı ön koşullara ihtiyaç duyar: bir durma koşulu, bir bekleme durumu ve ertesi sabah işi devralacak bir kişi.
Kanıtı Görevin içine ekleyin
Kanıt içermeyen büyük bir sonuç, bir inceleme değildir. Bir insan tarafından yavaşça gerçekleştirilen bir yeniden çalıştırmadır.
libgav1 örneği iyi bir kanıtın nasıl göründüğünü ortaya koyuyor. Google, Argon'un mevcut bir Rust taşımasındaki 32 bin satırlık SIMD kodunu yenilediğini ve elde edilen sonucun "birebir aynı video çıktısıyla Rust sürümünden 2,7 kat daha hızlı çalıştığını" söylüyor. Bu cümlenin ikinci yarısı, 32 bin satırı incelenebilir kılan asıl noktadır: Aynı girdiler hem eski hem de yeni koddan geçti ve çıktılar birebir eşleşti. Bu, diferansiyel testtir ve incelemeciyi salt bir karşılaştırmanın ulaşamayacağı alanlara odaklar: güvenli olmayan (unsafe) kodlar, hata yolları ve performans artışının gerçek iş yüklerinde geçerli olup olmadığı.
Her çalıştırma, Göreve şu dört çıktıyı döndürmelidir:
| Görevdeki kanıt | İncelemecinin yanıt bulduğu soru |
|---|---|
| Değişiklik özeti | Ne değişti, nerede ve neden? |
| Test, tip denetimi ve derleme çıktıları | Hâlihazırda güvendiğimiz kontrollerden hâlâ geçiyor mu? |
| Neler, nasıl doğrulandı? | Davranış aynı kaldı mı ve hangi girdilerde? |
| Bilinen sınırlar | Bizzat neye bakmalıyım? |
Sharkly'nin kendi iş akışının tanımladığı yapı tam olarak budur: Ajan; tip denetimini, testleri ve derlemeyi çalıştırır, ardından değişiklik özetini, doğrulama sonuçlarını ve bilinen sınırları ekler; bir insan ise sonucu onaylar, değişiklik talep eder veya birleştirme (merge) ve sürüm adımına karar verir. Ajanın nihai yanıtı Görevde saklanır ve çalıştırma günlüğü Executions sekmesinde yer alır; böylece kanıtlar bir terminal yerine doğrudan Göreve döner. Görev düzeyinde kanıtlarla inceleme okuma sırasını ele alır ve devir şablonları rapora sabit bir biçim kazandırır.
Kontrollerden geçmek onaylandığı anlamına gelmez; birleştirme yapmak da öyle: Sharkly'de bağlantılı bir pull request'i birleştirmek Görev durumunu değiştirmez. Otomatik kontroller doğrulayabilecekleri kısımları doğrular; yapay zekâ inceleme ajanları ise bunun nerede bittiğini gösterir. Değişikliğin Görevde istenen şeyi yerine getirip getirmediğine bir insan karar verir.
Çalıştırmadan önce inceleme kapasitesi matematiğini yapın
İnceleme bir kuyruktur: Sonuçlar gelir, bir insan bunları tamamlar ve gelen iş miktarı tamamlananı aşarsa kuyruk büyür. Daha büyük bir çıktı sınırı yalnızca geliş tarafını değiştirir. Gerçek bir projeden ziyade varsayımsal girdilerle hazırlanmış örnek bir senaryo:
| Örnek girdi (varsayımsal) | Değer |
|---|---|
| Taşımadaki modül sayısı | 40 |
| Modül başına inceleme süresi (yalnızca diff) | 2 saat |
| Modül başına inceleme süresi (diferansiyel kanıt ve değişiklik özeti ile) | 30 dakika |
| Bir incelemecinin günde titiz incelemeye ayırabileceği süre (saat) | 3 |
Yalnızca diff üzerinden incelendiğinde bu geçiş 80 incelemeci saatine, yani yaklaşık 27 iş gününe mal olur. Her Görevde kanıt bulunduğunda ise 20 saate, yani yaklaşık yedi güne mal olur. İster devasa tek bir çalıştırma ister kırk küçük çalıştırma olsun, incelemecinin hanesindeki yük aynı kalır.
Değişen şey verilen karardır. Kırk Görev kontrol ettiğiniz bir hızda gelir ve her biri kendi bağımsız değerlendirmesini alır. Kırk modülün tamamını kapsayan tek bir sonuç ise tek bir karara bağlanır; bu nedenle 31. modüldeki bir sorun diğer 39'unun da yanmasına yol açar. Alt görevler sayesinde, sorunlu olan modüle yazılacak bir yorum yalnızca o Görev üzerinde bir takip çalıştırması başlatabilirken geri kalanlar ilerlemeye devam eder.
Ardından maliyet hesabını yapın. Üst sınıra ulaşan bir çalıştırma yaklaşık 1 milyon çıktı token'ı yazar: Bu da 30 Kasım'a kadar milyon başına 10 dolarlık tarifeyle kabaca 10 dolar, 1 Aralık'tan itibaren ise yaklaşık 20 dolardır. 1. Seviye (Tier 1) bir projede Google'ın harcama tabanlı sınırı, 10 dakikalık kayan pencere başına 10 dolardır; dolayısıyla üst sınıra ulaşan tek bir çalıştırma, mevcut tarifeyle tüm pencere limitini, 1 Aralık'tan itibaren ise bu limitin iki katını tüketir. Bu kadar uzun çalışmasına izin verilen tüm Ajanlarda Maksimum eşzamanlılığı düşük tutun.
Kuyruk oluştuktan sonra değil, ilk büyük çalıştırmadan önce kendi hesaplamalarınızı yapın. İnceleme kapasitesi matematiği aynı aritmetiği ekip düzeyinde ele alırken, insan incelemesi darboğazdır başlıklı yazı bu kuyruğu görünür kılan durumları ve denetim aşamalarını inceler.
İlk bir milyon token'lık çalıştırmanızdan önce bir kontrol listesi
- [ ] İş; alt görevler ve "engellenir" bağlantılarıyla birlikte, bir incelemecinin tek oturuşta tamamlayabileceği Görevlere bölünmüştür.
- [ ] Her Görev açıklaması tamamlanmanın ne anlama geldiğini ve nelerin kapsam dışı olduğunu belirtir.
- [ ] Görev başına zaman aşımı, modelin çıktı sınırına değil Göreve uygundur (uzun arka plan istekleri dakikalar sürer).
- [ ] Üst sınırdaki bir çalıştırma, API seviyenizin harcama limitine uygundur.
- [ ] Ajanın atanan Görevler için maksimum eşzamanlılığı, bilgisayarın çalıştırabileceği miktarla değil, incelemecilerin temizleyebileceği miktarla eşleşir.
- [ ] Her çalıştırma bir değişiklik özeti, kontrol çıktısı, nelerin doğrulandığını ve bilinen sınırları döndürür.
- [ ] Mevcut davranışı korumayı amaçlayan çalışmalar, eski koda karşı diferansiyel bir kontrol içerir.
- [ ] Her Görevin atanmış belirli bir incelemecisi vardır ve onay, asla bir birleştirmenin yan etkisi değil, o kişinin durum değişikliğidir.
Bunların hiçbiri, artık ücretli herhangi bir Gemini API anahtarıyla çağrılabilen Argon'a bağımlı değildir. Google'ın cümlesi bir şablondur: büyük çıktı, ardından denetim, emülasyon testleri ve inceleme, sonrasında üretim. Çıktı boyutundaki bir sonraki sıçramayı hangi laboratuvar piyasaya sürerse sürsün, plan modelde değil Görevde yaşar. Sharkly model seçimi yapmaz: Ajanlar dokümantasyonuna göre bir Ajan, Özel argümanlar veya aracın yapılandırması üzerinden değiştirilebilen Çalışma Zamanı'nın varsayılan modelini takip eder. Çalıştırdığınız bir Çalışma Zamanı'na daha büyük bir model geldiğinde bu değer değişir; Görevler, kanıtlar ve inceleme denetimleri ise olduğu gibi kalır. Bağlam, ilerleme, engelleyiciler, sonuçlar ve insan incelemesi, istekten yayına kadar görünür kalmaya devam eder.
Hâlihazırda birden fazla ajan çalıştırıyorsanız, Sharkly bunların görevlerini ve sonuçlarını tek bir yerden yönetmenizi sağlar.
