TL;DR: Tek bir en iyi modeli aramayı bırakın. Her modeli önündeki görevin şekliyle eşleştirin: mimari ve dosyalar arası refactor'lar için derin akıl yürütme, boilerplate ve testler için hızlı ve ucuz, tüm repo'ya dair sorular için uzun bağlam, çok adımlı düzenlemeler için istikrarlı araç takibi. Terminal başına seçim yapmak bir ya da iki agent için işe yarar. Birden fazla repo'da birkaç görev çalıştırmaya başladığınızda, bu eşleştirmenin yeri kafanız değil, kaydedilmiş bir Agent'tır. İşte harita, uygulamalı bir örnek ve bugün uygulayabileceğiniz bir kontrol listesi.
Önünüzde beş terminal açık. Birinde çetrefilli bir refactor var, birinde bir grup birim testi gerekiyor, biri yarım hatırladığınız bir kod tabanı hakkındaki soruları yanıtlıyor, biri kararsız bir entegrasyon testinin peşinde, biri de bir sembolü kırk dosyada yeniden adlandırıyor. Her biri aynı sessiz soruyu soruyor: bunu hangi model çalıştırmalı? Yeniden adlandırma işine ağır bir akıl yürütme modeli verirseniz, hızlı bir modelin tertemiz bitireceği iş için token ve dakika harcarsınız. Mimari değişikliğe hızlı bir model verirseniz, üç dosya ötedeki bir bağımlılığı kaçırır. Tekrarlayan şikâyet nadiren "modeller kötü" olur. Şikâyet şudur: "Hangisini kullanacağımı bilmiyorum."
Çözüm bir liderlik tablosu değil. Sıralamalar birkaç haftada bir değişiyor ve genel bir kıyaslama testinin kazananı, sizin özel göreviniz için çoğu zaman yanlış seçim oluyor. Kalıcı hamle, modeli görevin şekliyle eşleştirmektir: ne kadar akıl yürütmeye ihtiyacı var, ne kadar bağlam tutması gerekiyor, araçları ne kadar güvenilir takip etmesi lazım ve her çalıştırma size ne kadara mal olacak. Model adları değişse bile bu özellikler neredeyse hiç yerinden oynamaz.
İşte tam bu noktada bir görev katmanı hak ettiği yeri buluyor. Sharkly, hepsi bir arada bir Agent komut ve yönetim platformu. Kodlama agent'larınızın üzerinde duruyor, böylece "hangi göreve hangi model" her terminalde yeniden verdiğiniz bir karar olmaktan çıkıyor. Kararı bir kez Agent olarak kaydediyorsunuz — bir rolün, bir runtime'ın ve kurallarının yeniden kullanılabilir bir yapılandırması — sonra Task'ı, şekli uyan Agent'a atıyorsunuz. Kodlama agent'larınız zaten var. Sharkly onları bir takıma dönüştürüyor.
Modeli liderlik tablosuna göre değil, görevin şekline göre seçin
Bir model seçimi aslında sırayla sorulan dört sorudur.
- Akıl yürütme derinliği. Görev, dosyalar arası çok adımlı planlama mı gerektiriyor, yoksa yerel ve mekanik bir değişiklik mi? Mimari, zorlu refactor'lar ve kök neden hata ayıklaması daha güçlü bir akıl yürütme modelini ödüllendirir. Yeniden adlandırmalar, biçimlendirme ve iskelet kod ise ödüllendirmez.
- Bağlam boyutu. Modelin aynı anda koca bir repo'yu, uzun bir spesifikasyonu ya da devasa bir log'u tutması mı gerekiyor? Tüm kod tabanına dair sorular ve büyük migrasyonlar, biraz daha az derin akıl yürütse bile uzun bağlamlı bir modeli ödüllendirir.
- Araçları takip etme güvenilirliği. Çok adımlı işler (düzenle, testleri çalıştır, çıktıyı oku, tekrar düzenle) modelin araçları ne kadar tutarlı kullandığına ve senaryodan sapmadığına bağlıdır. Muhteşem akıl yürütüp testi çalıştırmayı unutan bir model, burada daha istikrarlı bir modelden kötüdür.
- Hız ve maliyet. Yüksek hacimli, düşük riskli işler (testler, boilerplate, docstring'ler) çıtayı aşan en hızlı ve en ucuz modele gitmeli. Pahalı akıl yürütmeyi, buna gerçekten bağlı olan görevlere saklayın.
Yanlış bir adım size bir öğleden sonra hata ayıklamaya mal olacaksa ağır bir akıl yürütme modeli kullanın. Görev mekanik ve doğrulaması kolaysa hızlı, ucuz bir model kullanın. Çoğu gün ikisine de ihtiyacınız olur; farklı görevlerde, aynı anda. Tek bir global model ayarının kendini yanlış hissettirmesinin sebebi de bu: farklı cevaplar isteyen görevlere tek bir cevabı dayatıyor.
Görev türünden model rolüne kaba bir harita
Aşağıdaki görev adları, herhangi bir model sürümünden daha uzun yaşar. Bir kovayı bir isme sabitlemeden önce sağlayıcının güncel model kartını okuyun, sonra kovayı koruyun.
| Önünüzdeki görev | Şunu optimize edin | Model rolü |
|---|---|---|
| Mimari, dosyalar arası refactor, tasarım incelemesi | Akıl yürütme derinliği | Ağır akıl yürütücü |
| Kök neden hata ayıklama, kararsız test avı | Akıl yürütme + istikrarlı araçlar | Ağır akıl yürütücü |
| Tüm repo'ya dair soru-cevap, büyük migrasyon, uzun spesifikasyon işi | Bağlam boyutu | Uzun bağlamlı model |
| Birim testleri, boilerplate, docstring'ler, iskelet kod | Hız ve maliyet | Hızlı, ucuz model |
| Mekanik yeniden adlandırma, biçimlendirme, toplu düzenleme | Hız | Hızlı, ucuz model |
| Çok adımlı agent döngüsü (düzenle, test et, tekrarla) | Araç takip güvenilirliği | İstikrarlı araç kullanıcısı |
İki dürüst not. Birincisi, "ağır" "her zaman daha iyi" demek değildir. Bir yeniden adlandırma işinde, derin akıl yürüten bir model daha yavaş, daha pahalı ve hızlı bir modelden daha doğru değildir. İkincisi, Claude Code, Codex veya Gemini CLI gibi bir runtime kendi varsayılan modelini taşır ve model kullanımı, araçta yapılandırılan abonelikler veya API anahtarları üzerinden devam eder; yani gerçek seçenekleriniz, ekibinizin zaten parasını ödediği ve bu kovalara oturan modellerdir. SWE-bench gibi genel görev kıyaslamaları bir modelin kabaca hangi kademede olduğunu söyler; sizin tam görevinizin hangi modeli gerektirdiğini değil.
Terminal başına model seçmenin ölçeklenmeyi bıraktığı nokta
Bir veya iki agent için elle seçim sorun değil. Bir terminal açarsınız, modeli ayarlarsınız ve neyin nerede olduğunu hatırlarsınız çünkü ortada sadece iki tane var. Bugün işleyen kurulum, bir kişi ve birkaç araçtan ibaret.
Sıkıntılar hacim arttığında başlıyor. Üç repo'da altı görev çalıştırın; model-görev eşleştirmesi artık kafanızda yaşıyor: hangi terminal ucuz olan, geçen salı hangi repo'yu akıl yürütücüye ayarladınız, migrasyon neden sürünüyor (hızlı modelde bırakmışsınız). Bir ekip arkadaşınız işinizi devraldığında eşleştirme görevle birlikte gitmez; hafızanızda kalır ve sonuçlar ortak bir yere dönmek yerine özel terminallere dağılır.
Bir Agent, bir tür işin nasıl ele alınacağının kaydedilmiş yapılandırmasıdır: bir rol, bir runtime ve onun modeli, bir de beraberindeki kurallar. Modeli her terminalde yeniden kararlaştırmak yerine Agent'ı bir kez kurarsınız ("Test Yazarı" hızlı bir modelde, "Refactorer" bir akıl yürütücüde) ve Task'ı, işin şekline uyan Agent'a atarsınız. Model seçimi bir hafıza oyunu olmaktan çıkıp yeniden kullanılabilir hale gelir. Agent'lar araştırır, yürütür, test eder ve raporlar; yönü insanlar belirler ve sonucu kabul eder. Yürütme, engeller ve sonuçlar Task'a döner, böylece her model seçiminin arkasındaki mantık istekten yayına kadar görünür olur; geri kaydırma geçmişine gömülü kalmaz.
Sharkly, Claude Code, Codex veya diğer yürütme araçlarının yerini almaz. Ekibinizin zaten çalıştırdığı modellerin etrafına ortak görev, bağlam ve inceleme katmanını ekler. Tek bir terminalde yalnızca bir agent çalıştırıyorsanız, ona ihtiyacınız yok. Birden fazla agent'ı paralel çalıştırmaya başladığınızda ise model eşleştirme kararı tam da kaydetmeye değer şeydir.
Uygulamalı bir örnek: üç görev, üç Agent
Diyelim ki bir sprint kuyruğa üç görev bıraktı.
- SH-312:
UserSessionadını repo genelindeAuthSessionolarak değiştir. Mekanik, doğrulaması kolay. Hızlı ve ucuz bir modelde çalışan bir "Yeniden Adlandırıcı" Agent'a yönlendirin. Düzenler, tür denetleyicisini çalıştırır ve temiz bir diff döndürür. Burada akıl yürütücü token'ı harcamak hiçbir şey kazandırmaz. - SH-318: ödeme akışı yeniden denemede çift ücret kesiyor. Servisler arası kök neden hata ayıklaması. İstikrarlı araç kullanan ağır bir akıl yürütücüdeki bir "Hata Ayıklayıcı" Agent'a yönlendirin. Planlaması, log'ları okuması, bir hipotez kurması ve onu test etmesi gerekiyor. Burada hızlı bir model tahmin yürütür ve bir inceleme döngüsünü boşa harcar.
- SH-324: kod tabanından "faturalandırmamız Stripe ile nasıl mutabakata varıyor?" sorusunu yanıtla. Tüm repo'ya dair bir soru. İlgili dosyaları aynı anda tutabilen uzun bağlamlı bir modeldeki bir "Kod Tabanı Analisti" Agent'a yönlendirin.
Her Agent kendi izole worktree'sinde çalışır, böylece üç model birbirine basmadan aynı anda üç görevde çalışır. Her sonuç, bir değişiklik özeti ve kanıtla birlikte kendi Task'ına döner. Hafızadan yeniden kurmanız gereken üç terminali değil, tamamlanmış üç teslimatı incelersiniz. Otomasyon, sizin muhakemenizin gerektiği yerde durur: kabul edersiniz, değişiklik istersiniz ya da merge'e karar verirsiniz.
Bugün uygulayabileceğiniz kontrol listesi
Bir sonraki agent işi grubunuzdan önce bunu uygulayın.
- [ ] Her görev için önce şeklini adlandırın: akıl yürütme ağırlıklı, bağlam ağırlıklı, araç döngüsü ağırlıklı veya yüksek hacimli-mekanik.
- [ ] O şekil için çıtayı aşan en ucuz modeli atayın. Akıl yürütücüyü, yanlış bir adımın gerçek zaman kaybettirdiği görevlere saklayın.
- [ ] Uzun bağlamlı işleri alışkanlıkla favori akıl yürütücünüze değil, uzun bağlamlı bir modele verin.
- [ ] Çok adımlı döngülerde, ham kıyaslama sıralaması yerine araç takip güvenilirliğine ağırlık verin.
- [ ] Eşleştirmeyi rol başına yeniden kullanılabilir bir Agent olarak bir kez yazın; böylece siz ve ekip arkadaşlarınız her terminalde yeniden karar vermeyi bırakırsınız.
- [ ] Son kabul için bir insan bulundurun. Yolu model seçer; sonucu siz onaylarsınız.
Modeli görevle eşleştirin, eşleştirmeyi bir Agent olarak kaydedin; bu yazıyı başlatan soru ("hangisini kullanayım?") her terminalde bir kez yerine, rol başına bir kez yanıtlanır.
Her şey için tek bir modele bağlanmak yerine birden fazla kodlama agent'ı kullanmaya devam etmek istiyorsanız, Sharkly tam da bu sorunun etrafında kuruldu. Her terminalde elle bir model seçebilir ya da tüm iş akışını tek bir yerden yönetip her sonucun Task'a dönmesini sağlayabilirsiniz.
SSS
Her şey için en üst sıradaki modeli kullanmalı mıyım? Hayır. En iyi genel model, mekanik işlerde olması gerekenden daha yavaş ve daha pahalıdır ve o işlerde daha doğru da değildir. Sıralama bir modelin hangi kademede olduğunu söyler; görevinizin şekli ise hangi kademeye ihtiyacınız olduğunu söyler. Bu ikisini eşleştirmek, liderlik tablosunun kazananını varsayılan yapmaktan iyidir.
Görevin zorluğunu henüz bilmiyorsam modeli nasıl seçerim? Ucuzdan başlayın ve yükseltin. Görevi önce hızlı bir modele verin. Takılırsa, tahmin yürütürse ya da incelemeden geçemezse, bu görevin akıl yürütme ağırlıklı olduğunun işaretidir ve onu daha güçlü bir modele terfi ettirirsiniz. Döngüde insan bulunan inceleme adımı, uyumsuzluğu yayına girmeden yakaladığınız yerdir.
Sharkly modeli benim yerime mi seçiyor? Sharkly modeli kendi başına seçmez. Bir Agent oluştururken bir rolü bir runtime'a ve onun modeline bağlarsınız, sonra Task'ları işin şekline uyan Agent'a atarsınız. Seçim sizde kalır; Sharkly onu yeniden kullanılabilir kılar ve her çalıştırmanın sonucunu özel bir terminal yerine Task'ta tutar.
